00:13 imirkin: skeggsb: do you have a good way of finding out what chips the 0x0597 class was present on? or should i just add it to all the nv3x's and hope for the best?
01:00 imirkin: karolherbst: around?
01:01 imirkin: could i get a mmt trace of dEQP-GLES31.stress.tessellation_geometry_interaction.render_multiple_limits.output_required_max_tessellation_max_geometry on the blob?
01:03 mwk: imirkin: it's confirmed on NV31, NV34, NV35
01:03 mwk: and not tested on NV30, NV36
01:03 mwk: so I'd guess all NV3x have it
01:03 imirkin: mwk: ok, seems likely
01:03 imirkin: i wonder how accurate it is
01:04 imirkin: wrt blocking nv30 features in the nv25 class
01:17 mupuf: mwk: how long did you take in the end to come back home?
01:17 mupuf: So, tomorrow, apparently, I will get to hear sound emited by an nv01
01:17 mupuf: or, should I say today?
01:19 imirkin: mwk: hm, all of those have the NV25 class, or the NV20 one?
01:19 imirkin: mwk: coz NV30 has 0x397 and NV35 has 0x497
01:20 imirkin: so it'd be odd if they also had 0x597
01:28 mwk: mupuf: I got home about 0300
01:29 mwk: mupuf: so, what's the plan for tomorrow?
01:29 mwk: other than playing Dream Theater on NV1 :p
01:29 mupuf: well, you mean, after my friends gives us the permission to go nerding out ...?
01:29 mwk: which will obviously happen once we drink enough near that thing
01:29 mupuf: well, yeah, that sounds great, then reviewing your platforms
01:29 mwk: no, I mean what happens before :p
01:30 mupuf: and probably discussing about how to make them available for a CI system
01:30 mupuf: 20 machines is a lot dude! :D
01:30 mwk: I also talked to Gabriela, she just returned to Warsaw and would very much like to meet you :p
01:30 mwk: yeah, would be nice to integrate it somehow
01:31 mupuf: apparently, we are leaving to town at 10am (so probably not before 11am, but who knows?). I'll send you a message when we have firmer plans.
01:31 mwk: though we'd have to think up a proper power management system first, I'm guessing the fuses won't like it if I bring up more than 10 machines at once or so
01:31 mupuf: As for gabriela, that is great news!
01:32 mupuf: mwk: yeah, one at a time would be great already
01:32 kyan: Hi :) How do I go about setting up an external monitor using Nouveau? The picture is all chopped up and it flickers… Thanks!
01:32 mwk: honestly, I haven't touched half these machines in years, it's going to be a miracle if they all work
01:33 imirkin: kyan: it should Just Work (tm). please provide additional details.
01:33 mwk: imirkin: and as for the classes... well just see for yourself
01:34 mwk: http://0x04.net/~mwk/nvscan/
01:34 mwk: basically, NV3x respond to quite a few 3d classes
01:34 kyan: I'm using Plasma 5 w/ Compiz-Reloaded window manager, GeForce 9400M
01:34 imirkin: mwk: cool
01:34 mwk: and handling of the NV2x ones is quite involved
01:34 kyan: The monitor is a Samsung SyncMaster 930B LCD
01:34 imirkin: mwk: ah looks like it also does 0x0097 (at least nv31 does)
01:34 mwk: in particular, they dynamically translate NV20 vertex shader ISA to the NV30 vertex shader ISA
01:34 mwk: yeah
01:35 mupuf: mwk: nvidia really went the extra mile to ease bringup, nice :)
01:35 mwk: I haven't fully unpacked all the scans, see the NVxxscan files for full list
01:35 kyan: The computer is a mid-2009 MacBook Pro
01:35 imirkin: mwk: yeah, thanks.
01:35 mwk: mupuf: well, it was easy back then... it literally was just moving fixed bitfields around in the 128-bit instruction word
01:35 kyan: What other information would be helpful?
01:36 imirkin: kyan: pastebin xorg log, and the output of 'xrandr'
01:36 kyan: Ok
01:36 imirkin: kyan: also, how is the monitor connected?
01:37 kyan: Monitor has DVI end of DVI/HDMI cable plugged into it. HDMI to Mac monitor port adapter is in the other end and connected to the mac.
01:38 mupuf: Must have had a perf cost, but being able to ship immediatly, even if bring up with the new class failed was probably quite a sweet deal!
01:39 imirkin: mupuf: they stopped doing it after nv3x
01:39 kyan: Xorg log: https://gist.github.com/ethus3h/1734547014c9b8b9fcfb515b6b49cccc
01:39 mupuf: imirkin: probably started doing emulation around this point :)
01:39 mupuf: And they would not even send the wafers to production without it
01:40 imirkin: kyan: anything in dmesg?
01:40 mwk: well, it's just an alternate frontend to the same engine
01:40 mupuf: mwk: anmyway, bed time!
01:40 mwk: in particular, the NV20 features that NV30 class doesn't have are not supported
01:40 mupuf: night is going to be short
01:40 mwk: like tesselation
01:41 kyan: xrandr output: https://gist.github.com/ethus3h/56a45e7f380ad9019c93eb5dc5a9ed26
01:41 mwk: oh yes
01:41 mupuf: and the shower to get rid of this sausage smell that we got on the beach has not helped
01:41 mwk: yeah, I can still smell that in my hair
01:41 mupuf: AHAH, yes, tesselation
01:41 mupuf: they were delicious ... but definitely smelly!
01:42 kyan: dmesg output: https://gist.github.com/ethus3h/96122ec96f4aafe6566e32bc79058107
01:42 imirkin: kyan: hm, i see. so it's a DP -> HDMI -> DVI situation?
01:42 mwk: I didn't even get to eat one :(
01:42 kyan: imirkin: yes
01:42 mwk: anyhow
01:42 mwk: good night
01:43 mwk: let your friend sleep, she seemed real damn tired 3 hours ago already :p
01:43 imirkin: kyan: does this only happen with plasma, or also other WMs?
01:43 kyan: Mm, well, plasma's the DE rather than the WM, but I'll try other WM
01:43 kyan: I don't have any other DEs installed
01:44 imirkin: well, whatever runs your compositor
01:44 imirkin: try running without a compositor
01:44 imirkin: does that fix everything?
01:44 kyan: That would be compiz
01:44 mupuf: mwk: she has been sleeping for an hour already ;)
01:44 mupuf:was just slowly catching up with emails
01:45 kyan: Using Openbox, it's somewhat more usable (less corrupted) but still flickers like a boss
01:45 imirkin: ok, so flickering might be a separate issue
01:45 kyan: Like epilepsy warning time
01:45 imirkin: you should be able to adjust the pstate
01:45 imirkin: check /sys/kernel/debug/dri/0/pstate
01:45 imirkin: (pastebin that)
01:46 kyan: cat: /sys/kernel/debug/dri/0/pstate: No such file or directory
01:46 imirkin: root
01:46 imirkin: and is debugfs mounted?
01:47 imirkin: [oh hm, when did we move pstate into debugfs...]
01:47 kyan: /sys/module/nouveau/parameters/pstate exists, though.
01:47 imirkin: oh. in 4.5
01:47 imirkin: sorry, you have to load nouveau with nouveau.pstate=1
01:47 mwk: mupuf: fair enough, see you tomorrow
01:47 mwk: *lights out*
01:47 imirkin: and then it'll be in sysfs
01:48 kyan: My pstate adventures: https://gist.github.com/ethus3h/c00f82a3cd8ccfacc9165212358edae2
01:48 kyan: (cat /sys/module/nouveau/parameters/pstate is 0)
01:49 imirkin: right
01:49 imirkin: hence loading nouveau with nouveau.pstate=1
01:49 imirkin: (you can't just update it at runtime)
01:49 kyan: Should I reboot, and add nouveau.pstate=1 in my GRUB command line?
01:49 imirkin: yes.
01:49 imirkin: ideally into your menu.lst directly
01:51 kyan: Ok, I added it to my default grub command line pref, and rebuilt the grub.cfg
01:51 kyan: (IDK what a menu.lst is, sorry)
01:51 kyan: I have 1600x1200.png fonts grub.conf locale x86_64-efi custom.cfg grub.cfg grubenv themes in /boot/grub
01:52 imirkin: oh. might be grub.conf for the cool people.
01:52 kyan: Ah, my grub.conf is a symlink to grub.cfg, which I make using grub-mkconfig, which generates it from /etc/defaults/grub
01:52 kyan: Which strikes me as kinda complicated, but it works well enough AFAICT :p
01:53 kyan: Shall I reboot with the shiney new kernel parameter?
01:53 imirkin: that'll be a start
01:53 kyan: Ok, will be back in a bit, thanks! :)
01:57 kyan: Ok, back again
01:57 imirkin: ok, now you should have a /sys/class/drm/card0/device/pstate
01:57 kyan: Ah! yp
01:57 imirkin: pastebin that?
02:00 kyan: imirkin: ta dah https://gist.github.com/ethus3h/056cf24da4bac42e03dcd46b679c5759
02:00 imirkin: ok, so it boots in a pretty high state already... you can try doing 'echo 0f > .../pstate'
02:00 imirkin: and see if that fixes your monitor woes
02:00 imirkin: although tbh i kinda doubt it will
02:01 imirkin: i was hoping it was booting into a much lower pstate
02:01 kyan: Hey, fickering's gone!
02:01 kyan: and so is the "l" in that word, apparently
02:02 imirkin: blame it on a lost interrupt
02:02 imirkin: definitely not *your* fault
02:02 kyan: Oh, no, flickering's back
02:02 imirkin: so's the l
02:02 imirkin: the go hand-in-hand apparently
02:03 kyan: At least I seem to be able to use the compositing ok
02:03 kyan: (instead of it barfing when I do)
02:03 kyan: but still, flicker flicker flicker…
02:04 imirkin: sorry, dunno =/
02:04 kyan: Oh well :P Thanks for helpig me get compositing working! :)
02:05 imirkin: i very much doubt this fixes compostiing
02:05 imirkin: at least not long-term
02:05 kyan: Oh…
02:07 kyan: well, thank you for your help!
02:08 imirkin: btw what version of libdrm and mesa do you have?
02:09 kyan: libdrm 2.4.65; mesa 11.0.6
02:12 imirkin: hm, well that libdrm is definitely fine
02:13 imirkin: can't for the life of me remember when i was fixing random issues that were making people using plasma run into tons of fail
02:14 imirkin: looks like a bunch of that made it into 11.0.6
02:14 imirkin: anyways, if you feel like rolling dice, you could try updating to mesa 12.0 and see if that improves anything.
02:15 kyan: Cool. I've turned off accelerated rendering in Plasma for now to see what that does
02:16 kyan:tries installing Mesa 12.0.1
02:17 kyan: Flickering happening with XRender as the Plasma backend, and Openbox as the WM
02:20 kyan: Well, I've got to go to bed soon, but I'll leave mesa installing
02:20 kyan: (IIRC it's a fairly long compile.) Anyway, thanks!
02:22 imirkin: good luck
02:23 imirkin: you can try to catch pmoreau - i think he has identical hardware
02:23 imirkin: (he has one of the muxed ones with NVAC / NV96 combos... not sure if you have the NV96 as well or just the NVAC, but should be basically same hw)
02:24 kyan: cool, thanks! :)
02:30 kyan: Tried enabling the compositor with the monitor plugged in just now, and I think my computer had a mad wild acid trip
02:30 kyan: had to switch to a vtty, killall -9 compiz
02:30 kyan:will use the laptop's display for now :3
02:31 imirkin: is this a regression, or are you trying this software stack for the first time?
02:31 kyan: Trying it for the first time. I only installed GNU/Linux in this computer a couple weeks ago for the first time
02:31 kyan: s/weeks/months
02:31 imirkin: ok
02:31 kyan: been using Mac OS X since it came with it and I couldn't be bothered to get GNU/Linux going
02:32 imirkin: sure
02:32 imirkin: do note that you have the option of switching to nvidia blob drivers
02:32 kyan: (got the computer as a handmedown a couple years ago to replace my sadly deceased Thinkpad X60)
02:32 imirkin: if you don't care about open-source drivers, they do tend to be much higher quality
02:32 kyan: I tried them. They were much lower quality :3
02:33 imirkin: surprising
02:33 imirkin: usually they do a pretty good job
02:33 kyan: Worse performance, and apps regularly segfaulted, and the entire system locked up every few hours, and the vttys didn't work
02:33 imirkin: having docs is kinda cheating, of course...
02:33 kyan: Tried multiple combinations of drivers and kernels
02:33 kyan: and it was like *nope*
02:34 imirkin: fun.
02:34 kyan: (At least the external display didn't flicker, IIRC…)
02:35 kyan: (but given the other problems, that kind of pales in comparison…0
02:38 kyan: Since switching to Nouveau, this computer's been significantly more stable than under Mac OS
02:39 kyan: (WindowServer crashed every couple days, ending the login shell, but not properly killing all the apps, so e.g. youtube would keep playing with no easy way to kill it :P)
02:41 kyan: Good night; thanks again! :)
03:00 freddd: My boys!
03:00 freddd: I swapped my 980 Ti with a Fury. And uhm, does AMDGPU still require proprietary non-free firmware to boot up the card? S:
03:10 imirkin: it does ... do you really feel robbed of the 100kb used on your hard drive, instead of it residing on a ROM on the card?
03:11 imirkin: [probably more like a few MB if you count the video decoding/encoding fw as well]
03:13 freddd: imirkin that statement can go both ways.
03:13 imirkin: you could answer "yes" or "no" :)
03:13 freddd: I want a native out-of-the-box open experience, that is my goal.
03:13 imirkin: i.e. "yes, i wish the card were a little more expensive and they had stuck that stuff into a ROM"
03:13 imirkin: or "no, i don't care if i have to store a few MB of junk on my HD to get it to load"
03:13 freddd: It has nothing to do with that.
03:14 imirkin: "out of the box"?
03:14 freddd: Yes.
03:14 freddd: Free software experience.
03:14 imirkin: that's specific to your distro of choice
03:14 freddd: They opened up the driver.
03:14 freddd: But the firmware is not free.
03:14 freddd: What is the point.
03:14 imirkin: if it doesn't have the out-of-the-box experience you want, pick a different distro
03:14 imirkin: no firmware is free (almost)
03:14 freddd: I doubt another distribution is magically able to provide open and free AMD firmware.
03:14 imirkin: the firmware inside your cpu isn't free
03:15 imirkin: and yet you appear to have no problem running it
03:17 imirkin: and to be clear, no driver was "opened".
03:17 imirkin: however one was developed in the open
03:17 freddd: I am confused how come Debian can boot with my CPU then?
03:17 imirkin: because your CPU includes the firmware in a ROM inside of it
03:18 freddd: Why does AMD not do that then?
03:18 imirkin: (or it's loaded on there by your bios)
03:18 imirkin: dunno - no need, i guess. more of a pain than it's worth.
03:18 imirkin: no technical advantage
03:18 imirkin: for a cpu, you kinda have to, since there's no real way around that
03:19 imirkin: anyways, the issue is debian being anti-user-friendly here... the files in question are fully redistributable, so there's no issue with that
03:20 freddd: Oh they do distribute it.
03:20 freddd: In the non-free repository.
03:24 imirkin: great. so what's the issue again?
03:35 freddd: imirkin you see purpose in nouveau, an open and free software driver, but no purpose in an open and free firmware stack?
03:36 imirkin: i see them as totally unrelated things
03:36 imirkin: and imo the open software driver is *vastly* more useful than open firmware
03:39 imirkin: e.g. i don't care that nvidia requires signed firmware for GM20x, i'm just pissed that they aren't making that firmware available for redistribution.
04:22 JodaZ: imirkin, with that attitude you might as well run a useful os where drivers don't have to be reverse engineered for
04:22 imirkin: JodaZ: i do... it's called "linux"
05:58 Calinou: <freddd> I swapped my 980 Ti with a Fury. And uhm, does AMDGPU still require proprietary non-free firmware to boot up the card? S:
05:58 Calinou: AMD devs actually defend that, FWIW
05:58 Calinou: ie. bridgman
05:58 Calinou: "company secret!!!"
08:06 pmoreau: kyan: Could you try Linux 4.7? I was able to use an external monitor using HDMI -> miniDP, which wasn’t the case before IIRC. But it doesn’t seem to work with every adapter either… :-/
08:30 pmoreau: Great… "evo hannel stalled", "DDC responded but no EDID for DP-1" (that one might be a consequence of the previous error?), and then "disp: ERROR 5 [INVALID_STATE] 0b [] chid 1 mthd 0080 data 00000000"
08:39 pmoreau: Weird… the VGA -> miniDP and one HDMI -> miniDP work, but the other HDMI -> miniDP and the DVI -> miniDP do not. And they both fail with "evo channel stalled", "no EDID"
10:10 pmoreau: kyan: BTW, there is already a bug report open for it: https://bugs.freedesktop.org/show_bug.cgi?id=88272
10:11 karolherbst: imirkin: do you still need a trace?
10:13 karolherbst: Calinou: ? the heck?
10:17 pmoreau: kyan: Hum… looks like it is still as buggy as before, and that I was using the G96 instead of the MCP79 to drive the external screen… :-/
10:18 karolherbst: imirkin: the publisher of that game indeed responded :O maybe we get something usefull out of that
10:24 Yoshimo: more usefull than thanks for your feedback? ;)
10:25 karolherbst: I should bookmark the link to the tegra sources...
10:43 karolherbst: mupuf_: do you have any good ideas how to do the clock gating stuff? add a new function to nvkm_engine which gets implemented by the various chipsets?
10:43 karolherbst: or make multiple for each use case
10:43 karolherbst: or something else?
10:43 karolherbst: I have no good idea, cause it is so simple on kepler+ and I didn't bother to figure out how that works out on fermi
10:47 karolherbst: for tegra they only do it for the GR and CE2
11:36 kyan: pmoreau: Will do! (I couldn't get Mesa 12 to install as imirkin suggested due to dependency issues…, FWIW.)
11:37 kyan: Thanks!
12:29 Calinou: karolherbst: AMD is not notorious for their ethics
12:30 Calinou: (same for NVIDIA, but that's another story)
12:30 Calinou: what annoys me is that AMD is presented as the "good guy" where in reality they're no better than Intel or NVIDIA
12:31 karolherbst: Calinou: just because they have data on the chip instead of the filesystem?
12:32 Calinou: karolherbst: firmware ought to be open source regardless
12:32 Calinou: look at HDD/SSDs, tons of people are getting scared of them due to that
12:32 karolherbst: and then it wouldn't stop there, even if their firmware would be completly open, then the next person around the corner says: AMD is bad, cause their gpu design is closed :O
12:32 karolherbst: bad amd
12:32 Calinou: malware happened in those already
12:32 Calinou: I hate it when someone *defends* proprietary software
12:33 Calinou: it's just indefendable
12:33 karolherbst: it ain't software
12:33 karolherbst: software is stuff which gets exectued _somewhere_
12:33 karolherbst: but a vbios isn't executed at all
12:33 Calinou: VBIOS ≠ firmware
12:33 karolherbst: at least on nvidia
12:33 karolherbst: right, you need some efi stuff too and what not
12:34 karolherbst: if it contains code which is indeed run 1to1 on the CPU, then I would say it is an issue, but
12:34 karolherbst: a gpu can access your entire RAM anyway
12:35 karolherbst: it is a friggin pcie device, so it doesn't matter if the firmware gets uploaded from disc or is there rom the start
12:35 karolherbst: and saying that the issue wouldn't be as serious if the firmware is embedded on the device is silly
13:40 karolherbst: oh wow, that's nice
13:40 karolherbst: mupuf_: I think with maxwell2 nvidia doens't set the clock gating stuff on the host, but on the pmu
13:41 karolherbst: or somewhere else
14:53 imirkin: karolherbst: yes please
14:56 karolherbst: okay
14:57 imirkin: karolherbst: something we're not doing quite properly which is causing that test to kill the gpu
14:57 imirkin: a single patch input causes 4M primitives to be generated
14:57 imirkin: so i assume it's some buffer not being configured properly, or who knows
14:58 karolherbst: ohh, that is a deqp test
14:59 imirkin: indeed it is
14:59 karolherbst: how do I run the test again?
15:00 imirkin: ./deql-gles31 --deqp-visibility=hidden --deqp-case='the thing i told you'
15:00 imirkin: ./deqp-gles31 that is
15:02 RSpliet: pmoreau: isn't NV_INFO hidden in the default kernel config?
15:05 karolherbst: mhh
15:05 karolherbst: FATAL ERROR: GLX extension "GLX_EXT_create_context_es2_profile" not supported at tcuX11GlxPlatform.cpp:273
15:06 imirkin: RSpliet: don't think so
15:06 imirkin: karolherbst: srsly? pastebin glxinfo
15:06 karolherbst: https://gist.github.com/karolherbst/f5a4c1cc6ce95d790d244a45e5cc34de
15:06 karolherbst: mhh wait
15:06 karolherbst: I have ti do the DISPLAY trick here
15:07 imirkin: what. the. fuck.
15:07 karolherbst: ohh wait
15:07 karolherbst: I remember again
15:08 karolherbst: now it works :)
15:08 imirkin: ok cool
15:08 karolherbst: yep, I need to run it inside a optirun -b none bash shell to have corrected library paths for the nvidia driver
15:09 karolherbst: Failed: 1/1 (100.0%)
15:09 imirkin: but didn't hang the box, did it? :)
15:09 karolherbst: well, it ran for 52 seconds
15:10 imirkin: wow!
15:10 imirkin: maybe it did hang then.
15:10 karolherbst: wanna the mmt nethertheless?
15:10 imirkin: yea
15:10 karolherbst: okay
15:10 karolherbst: the driver indeed hangs
15:10 imirkin: bleargh
15:11 imirkin: ok, now i don't feel so bad
15:11 imirkin: they just know how to recover
15:11 karolherbst: https://gist.github.com/karolherbst/32fe0e715b1ac278e1da505612138b54
15:11 karolherbst: well "know" and "how"
15:11 karolherbst: :D
15:11 karolherbst: it managed to unload the driver though
15:11 imirkin: nice one.
15:12 imirkin: ok, so that is just the test of death
15:12 imirkin: i can live with that.
15:12 imirkin: none of the stress tests are in the master file
15:13 karolherbst: imirkin: http://filebin.ca/2t8PvyhkMogZ/dEQP-GLES31.stress.tessellation_geometry_interaction.render_multiple_limits.output_required_max_tessellation_max_geometry.mmt.xz
15:13 karolherbst: somehow I like filebin.ca for not putting a silly download site before downloads :)
15:16 imirkin: so this is my list of tess fails... http://hastebin.com/agozimuvoy.avrasm - i think the precise ones are kinda expected
15:16 imirkin: need to figure out wtf is going on with the "user_defined_io" ones
15:35 pmoreau: RSpliet: By default, NOUVEAU_DEBUG_DEFAULT is set to INFO.
15:56 karolherbst: hakzsam: how long will you need reator today?
16:10 hakzsam: I don't use it
16:11 karolherbst: hakzsam: then you left it turned on
16:11 hakzsam: yeah, forgot
16:11 karolherbst: k
16:33 karolherbst: mhh odd, nvidia does the clock gating stuff still on the host
16:33 karolherbst: wondering why I don't see it in the mmiotraces in the repository
17:15 karolherbst: gnurou: do you plan on implementing the clock gating stuff (reg 0x20200-0x2025c) within nouveau for tegra?
17:16 gnurou: karolherbst: not in the near future, depending on the clock it may even not be necessary on Tegra (e.g. RAM)
17:17 karolherbst: yeah, I saw that on gk20a it only happens for GR and CE2
17:17 karolherbst: but GR is the most important one anyway
17:17 karolherbst: others are all <20% effect of GR
17:17 karolherbst: but if so, we should discuss an architecture should that it integrates nicely with the nvkm_engine architecture
17:18 karolherbst: because I will NAK all tegra-only solutions for this :p
17:19 gnurou: agreed
17:19 karolherbst: I have it constantly enabled on my kepler for over half a year and no issues since then
17:19 karolherbst: we just need to find a good solution on how to implement it
17:19 karolherbst: and also, I have no clue about those delays
17:20 karolherbst: I guess those are timeouts for when the auto off triggers
17:21 karolherbst: gnurou: what do you think how much time would it take to get documentations for those registers?
17:22 karolherbst: I would hope it would be rather fast, cause it also benefits tegra
17:22 gnurou: karolherbst: throw a few dozen dices... :/
17:22 gnurou: brb
17:41 karolherbst: gnurou: on one gm206 with full reclocked engines: 55W -> 38W :)
17:41 karolherbst: on lowest clocks the difference was below 5% though
17:41 karolherbst: kepler has higher effects on lower clocks, but lower on higher compared to maxwell
17:42 karolherbst: well my kepler also doesn't reach 1.2V, so maybe that's why
17:43 RSpliet: karolherbst, gnurou: maybe it's worth investigating how the Android Tegra open driver works wrt clock gating, and discuss what's right and wrong about that (here or in person at XDC)
17:44 karolherbst: RSpliet: I already checked
17:44 karolherbst: it is boring there, just set it on init and be done with it
17:44 karolherbst: and that's also how nvidia does in on desktop gpus on kepler+
17:44 RSpliet: karolherbst: sure? I recall the clock changing routine on some Tesla's to disable and re-enable parts
17:44 karolherbst: fermi is a totally different story
17:44 karolherbst: RSpliet: nope, it is set to auto, and the hardware handles everything
17:45 karolherbst: no need for the driver to do anything beyond setting the bit
17:45 karolherbst: there might be silly exceptions, but I didn't found those in the tegra driver
19:28 hakzsam: playing life is strange on my gf119, looks fine :)
19:30 imirkin: hakzsam: iirc it worked fine for me too. just hung after a few minutes.
19:30 imirkin: like somewhere in the game, not in mesa iirc
19:33 hakzsam: no hung yet
19:34 imirkin: perhaps they updated their code
19:34 imirkin: or perhaps i'm just special
19:38 hakzsam: no ideas, works fine here
20:02 karolherbst: hakzsam: yay
20:02 karolherbst: hakzsam: it also looked fine on my gk106
20:02 karolherbst: and no hangs
20:02 karolherbst: but I never have hangs
20:03 hakzsam: you are lucky :)
20:03 karolherbst: I was surprised after imirkin told me 3h+ is unusualy
20:03 karolherbst: :D
20:03 karolherbst: *unusual
20:03 karolherbst: because usually stuff runs for me the entire day if I want to
20:04 hakzsam: nice to hear
20:04 hakzsam: I'm testing the witcher 2 right now
20:04 hakzsam: some glitches in medium spec at beginning
20:05 karolherbst: withcer 2 runs soo bad
20:05 karolherbst: :D
20:05 karolherbst: well
20:05 karolherbst: slow as hell
20:05 karolherbst: ohh you mean the vertex glitches?
20:05 karolherbst: wait
20:05 hakzsam: yep it's slow
20:05 karolherbst: I have something for ya
20:05 hakzsam: not sure what you mean by "vertex glitches" though
20:05 karolherbst: disable buffer_storage
20:05 karolherbst: then you don't have glitches anymore
20:06 hakzsam: huh?
20:07 karolherbst: hakzsam: https://github.com/virtual-programming/witcher2-linux/issues/153
20:07 karolherbst: ohh right
20:07 karolherbst: it crashes without this
20:07 karolherbst: maybe the linked binaries are still downloadable
20:07 karolherbst: they aren't
20:07 hakzsam: mmh
20:07 karolherbst: but I have those
20:11 hakzsam: so what's the issue?
20:12 karolherbst: no clue
20:12 karolherbst: something
20:14 karolherbst: you should see a lot of graphical issues once ingame, like if vertices are messed up
20:14 karolherbst: maybe I have images somewhere
20:15 karolherbst: nice
20:16 karolherbst: hakzsam: https://i.imgur.com/qc9dNL9.jpg
20:20 hakzsam: yeah ok
20:21 hakzsam: imirkin, oh and btw, life is strange hits the "out of code space" thing
20:21 imirkin: a ton of games do
20:21 imirkin: it's not like a strange thing to have happen
20:21 hakzsam: sure
20:21 imirkin: were you going to fix that thing finally btw, or should i?
20:22 hakzsam: yeah, will do this week
20:22 imirkin: k
20:22 imirkin: i've been hacking away at GLES 3.2 + AEP - have a branch where it's all enabled now
20:22 hakzsam: yeah I saw that
20:22 imirkin: except ... not really for nvc0 yet :)
20:22 imirkin: i965 gen9 is the only thing in mesa for now
20:23 imirkin: for nvc0 need to decode astc in software, and pipe through advanced blend
20:23 hakzsam: any ideas how to fix the "too fast submission" thing ?
20:23 imirkin: need to make the pushbuf submit ioctl return a value saying like "i have this much left"
20:23 imirkin: so that the driver can then throttle
20:24 hakzsam: oh okay
20:25 imirkin: and/or make a thing that can do a wait() until space becomes available
20:26 hakzsam: yep, makes sense
20:27 hakzsam: I'm just too frustrated with F1, I still didn't find wtf is going on...
20:28 hakzsam: did you look at the generated code btw?
20:28 imirkin: no
20:28 hakzsam: k
20:28 imirkin: i don't remember that you ever sent me a thing with "this shader compiles to this" type of thing
20:28 hakzsam: I did yesterday :)
20:28 hakzsam: http://hastebin.com/mayewiqoma.avrasm -> http://hastebin.com/bediwiboci.coffee
20:30 hakzsam: it appears correct to me
20:31 imirkin: you took out the update of r10.w
20:31 imirkin: which is part of the break condition
20:31 imirkin: now it's always 1.0, and 1.0 > 0.05 always passes
20:32 imirkin: so it'll definitely never break out of the loop
20:32 karolherbst: hakzsam: silly question, but did you disassemble the generated binary?
20:32 hakzsam: sure
20:33 karolherbst: k
20:33 karolherbst: once I also had an issue I couldn't just figure out, in the end it was the emitter emitting garbage :/
20:33 hakzsam: and compared with nvidiasm too
20:42 imirkin: hakzsam: that's the wrong shader binary
20:42 hakzsam: sure not, I double checked
20:42 imirkin: that's a vert shader
20:43 hakzsam: http://hastebin.com/bediwiboci.coffee that one?
20:43 hakzsam: it's a frag shader
20:43 imirkin: the shader binary at the end is wrong
20:44 imirkin: or rather
20:44 imirkin: it's from a diff shader
20:44 imirkin: the way things are printed is a bit confusing
20:44 imirkin: but the shader is printed at compile time
20:44 imirkin: while the shader binary is printed at upload time
20:44 imirkin: (since there are upload-time fixups)
20:44 hakzsam: yeah I know that
20:44 imirkin: so in this case it's first uploading a vert shader
20:45 hakzsam: mmh
20:46 hakzsam: I won't look into it right because it's almost time to sleep
20:47 towo`: naja, wirds heute halt nix mehr
20:47 towo`: grr, wrong channel
20:47 towo`: sorry
21:09 karolherbst: imirkin: if the dev of the game asks what is the best way to deal with the BGRA4 situation, what shall I answer?
21:09 imirkin: check if the fb is complete, and try other formats until you find one that works
21:09 imirkin: basically *every* driver supports BGRA8 - it might even be mandated by the spec
21:10 karolherbst: so if creating a BGRA4 texture succeeds, but the framebuffer is incomplete, the texture needs to be recreated as BGRA8?
21:10 imirkin: that's too presctiptive
21:10 imirkin: for example perhaps BGR5A1 would be enough for them
21:10 imirkin: and would remain a 16-bit format
21:11 imirkin: or perhaps they don't really need the alpha and can do it with B5G6R5
21:11 imirkin: etc
21:13 karolherbst: mhh
21:13 karolherbst: I think they need the alpha, because the broken texture is some "shadow" overlay
21:13 imirkin: i think they know what they need
21:13 karolherbst: right
21:13 imirkin: so you shouldn't tell them what format to use
21:13 karolherbst: but that means they need to recreate the texture, or can they check beforehand?
21:14 imirkin: they can check once at startup
21:14 karolherbst: okay
21:14 karolherbst: how?
21:14 imirkin: which formats are renderable and which aren't
21:14 imirkin: by creating a texture, attaching it to a fb, and seeing if the fb is complete
21:15 imirkin: might also be able to use ARB_internalformat_query2
21:15 karolherbst: that sounds like something horrible to do, isn't there any better way to find out?
21:15 karolherbst: mhh
21:15 karolherbst: the game uses like glsl 120
21:16 karolherbst: it seems ARB_internalformat_query2 is based on 2.0
21:16 karolherbst: still
21:16 imirkin: no, there isn't a better way to find out
21:17 imirkin: doing a handful of api calls at startup doesn't seem SO horrible
21:17 karolherbst: it sounds horrible in every situation
21:17 karolherbst: :D
21:17 karolherbst: so ARB_internalformat_query2 would be the best way?
21:18 imirkin: no
21:18 imirkin: i just read over it
21:18 imirkin: that ext is useless
21:18 karolherbst: k
21:18 karolherbst: so there is _no_ good way of finding that out?
21:19 imirkin: sure there is
21:19 imirkin: create a texture, attach it to fb, check if fb is complete
21:19 imirkin: this is THE standard way of doing it
21:19 imirkin: every piece of GL software does this
21:19 karolherbst: well, it sounds stupid even if that's the standard way
21:20 imirkin: ok
21:20 imirkin: 3 API calls doesn't seem *too* crazy
21:20 imirkin: but what do i know
21:20 karolherbst: doing a create fail until suceed loop sounds silly in every situation
21:20 karolherbst: that's not the point
21:20 imirkin: the point is that you need to find out what formats are renderable
21:20 imirkin: this is the way you find out.
21:20 karolherbst: I just complain about the pattern you have to code against
21:21 skeggsb: it makes sense when you consider that the fb can be incomplete for basically any reason, and would be extremely hard to express all limitations via queries
21:21 karolherbst: well, wouldn't be too hard to have something like glIsRenderable(GL_TARGET_FRAMEBUFFER, GL_FORMAT_BGRA4) or something
21:22 karolherbst: skeggsb: okay right, didn't thought about that, but at least the coarse stuff you could handle much better
21:22 imirkin: karolherbst: heh, but then you'd discover that GL_BGRA4 works and GL_BGRA4 + Z16 works, but GL_BGRA4 + Z24 does not work.
21:22 imirkin: there's a lot of subtlety potentially involved.
21:23 karolherbst: yeah, maybe opengl is just too complex to do something like that then :/ I really have no clue anyway
21:23 karolherbst: so the answer is: create until it works out
21:23 imirkin: karolherbst: the answer is "check if formats you care about are supported at startup"
21:24 karolherbst: okay
21:24 imirkin: the way you perform the check is by attaching to a fb.
21:24 karolherbst: skeggsb: I asked gnurou and mupuf already, but maybe you have any ideas already
21:24 karolherbst: skeggsb: already thought about a way, how we could integrate clock gating into nvkm_engine?
21:25 imirkin: karolherbst: in the GL 4.2 spec:
21:25 imirkin: Implementations are required to support certain combinations of framebuffer
21:25 imirkin: internal formats as described under “Required Framebuffer Formats” in section
21:25 imirkin: 4.4.4.
21:25 skeggsb: karolherbst: ask me again on friday :) i'm actually on leave again for 4 days, just trying to sort out a few things before i go
21:25 karolherbst: skeggsb: :( k
21:25 skeggsb: i'll do another review of your patches then too, from my last review, i suspect they'll be ok to merge this time around
21:26 karolherbst: as you might noticed, I spitted out the things you didn't had any serious issue for
21:26 karolherbst: mainly I splitted the update on therm thing into a second series now
21:26 karolherbst: so the entire clock update code isn't in the last posted series
21:27 imirkin: karolherbst: interesting. depending on how you read things, we could be out-of-spec -- i.e. GL_RGBA4 might be required to be renderable
21:27 karolherbst: but it includes every single bit for a much improved reclocking experience, just the volt drop on higher temps isn't there
21:27 karolherbst: but we also have no sw throttling, so there is that
21:27 karolherbst: imirkin: :O
21:28 imirkin: karolherbst: not 100% sure it's the case though
21:28 imirkin: would have to get clarification from someone who knows how to read that BS
21:28 karolherbst: let me see
21:29 karolherbst: you mean the 3.9.3 and 4.4.2 stuff?
21:29 imirkin: i mean all of that text taken together
21:30 karolherbst: yeah, I know
21:30 karolherbst: something references to 3.9.3
21:30 imirkin: anyways, if you can get idr to give a ruling against me on it, i'll do a fix in the st.
21:30 karolherbst: and "RGBA4" is a texture and renderbuffer color format, which should be required for framebuffer completness
21:30 imirkin: and i'm pretty sure if you create a *renderbuffer* with RGBA4, it'll all work out
21:31 karolherbst: k
21:31 imirkin: but in this case, a texture is created
21:31 karolherbst: maybe we should ask in #dri-devel
21:31 karolherbst: well, you would, because I would write garbage
21:32 karolherbst: imirkin: is the "Required Framebuffer Formats" section the important one?
21:32 imirkin: karolherbst: i dunno
21:32 karolherbst: I see
21:33 imirkin: all that stuff is *incredibly* confusing
21:33 imirkin: and it's not helping matters that i don't feel like doing additional work
21:33 karolherbst: would you mind asking in the channel or on the ML (and put me into CC there)? Because as I said, I would write garbage
21:33 imirkin: and on top of that, i guarantee that if i sent out a patch to "fix" it, everyone would come out of the woodwork to say "no, the spec doesn't guarantee that", and so i'd be left arguing for a position i don't 100% believe in in the first place
21:33 imirkin: i try to avoid those situations.
21:34 karolherbst: right
21:34 karolherbst: so we should discuess before you write a patch ;)
21:35 imirkin: what i'm definitely _not_ doing is removing BGRA4 support from nouveau
21:35 imirkin: st/nine uses it with positive effect
21:36 karolherbst: required by nine?
21:36 karolherbst: right
21:36 karolherbst: what positive effects? more speed?
21:36 imirkin: well, it's not using the format just for the hell of it
21:36 imirkin: it's using it because some application requests it and uploads a texture that way
21:36 karolherbst: k
21:36 imirkin: if the format were not supported, there would have to be a conversion somewhere
21:36 imirkin: which is dumb
21:36 karolherbst: so otherwise we would have to convert that one and
21:36 karolherbst: k
21:37 karolherbst: so it is a performance thing in the end
21:37 imirkin: however, st/mesa could *force* render support on the formats it picks for certain texture internal formats
21:54 mupuf_: karolherbst: Yeah, I think we shoud add a clock and power gate function pointer in subdev and engin
21:55 karolherbst: mupuf_: why also subdev?
21:55 mupuf_: and probably one init function
21:55 karolherbst: or are there some engines not implemented as nvkm_engine?
21:55 karolherbst: allthough I have no idea how complex that thing will be with fermi
21:55 mupuf_: because many blocks have block-level clock gating but are no engines anyway?
21:55 karolherbst: but honestly, I don't really care yet anyway about fermi
21:56 karolherbst: mupuf_: uhhh, maybe?
21:56 mupuf_: fermi == kepler for the architecturre
21:56 karolherbst: well, kepler is a lot easier here
21:56 mupuf_: dude, have you looked at how many blocks there are?
21:56 karolherbst: yes, and nvidia touches like 7
21:56 karolherbst: 4 alone are the video engines
21:56 mupuf_: we could also just have a cg subdev
21:56 mupuf_: and this one would set all the default values
21:57 mupuf_: not in my mmiotrace :D
21:57 mupuf_: define touch
21:57 karolherbst: changes them
21:57 mupuf_: sorry, not too sober, had a nifty amount of vodka with mwk
21:57 karolherbst: :D
21:57 karolherbst: doesn't matter
21:57 karolherbst: fact is, on kepler that is brutally easy
21:57 frobos: I'm running an old 8400gs with newest kernel + mesa12, getting some errors on dmesg: http://hastebin.com/epepicogan.css should I be worried?
21:57 mupuf_: really?
21:58 karolherbst: on engine init: switch 0x1 bit over, configure delays
21:58 karolherbst: that's all
21:58 karolherbst: and don't touch those again
21:58 mupuf_: oh, right
21:58 karolherbst: well, maybe there are some corner cases
21:58 karolherbst: but well
21:58 karolherbst: I have that stuff enabled for over half a year without issues
21:58 mupuf_: but there are all the BLCG and SLPC regs that needs to be set also!
21:58 karolherbst: no clue?
21:58 mupuf_: you are talking about the aster switch
21:58 karolherbst: it worked on every card I tested
21:58 mupuf_: master
21:58 karolherbst: without touching anything else
21:59 mupuf_: well, we need to set SLPC and BLCG regs
21:59 karolherbst: yeah, but that should be in the traces really near to the 20200+ regs
21:59 karolherbst: I hope
21:59 mupuf_: yes
21:59 karolherbst: but even if not, we could leave out the slpc blcg for _now_ I think
22:00 mupuf_: so you are right, engines could have this clock gating control function
22:00 karolherbst: what worries me more is, the fermi is such a fuck up here and I didn't see any pattern why those regs are changed, like a lot
22:00 mupuf_: that allows you to say disable, auto or enable
22:00 karolherbst: well
22:00 karolherbst: we only auto enable
22:00 karolherbst: and only ENG_CLK
22:00 karolherbst: that's all
22:00 mupuf_: oh, right, fermi was annoying
22:00 mupuf_: sure, but provide what the hw provides
22:01 karolherbst: hihi
22:01 mupuf_: so, a cg subdev that sets all the joe regs?
22:01 karolherbst: on your gm206: 22000044 -> 22002245
22:01 karolherbst: that's what nvidia did
22:01 karolherbst: no idea why nvidia enabled the 2200 bits
22:01 mupuf_: and each engine with a cg control function?
22:02 karolherbst: only a few
22:02 karolherbst: but every engine the same way
22:02 karolherbst: on my gpu: 0x27722444 -> 0x27722445
22:02 karolherbst: wait not true
22:02 karolherbst: 0x27722444 -> 0x27722445 -> 0x27724545
22:02 karolherbst: to writes
22:03 karolherbst: pgraph, ppdec, pvld, pppp, pcopy, pcopy2, pvenc
22:03 karolherbst: only those
22:03 karolherbst: but I enabled it here on all engines without any issues too
22:03 mupuf_: right, but it is not OK to just write the value and be done, we should have something more generic
22:04 karolherbst: yeah
22:04 karolherbst: we should figure out, why nvidia sets those specific values
22:05 karolherbst: we could in the first implementation just flip over 0x1 and get something working already and hide it behine a "experimental_pm_features" flag or something
22:05 karolherbst: anyway
22:05 karolherbst: gk20a and gm20b will get that feature sooner or later anyway, but it is les priority, so we _might_ just get the docs faster than usual
22:05 mupuf_: what do you want to figure out?
22:06 karolherbst: all the other bits?
22:06 mupuf_: isn't it documented in the gk20 driver anyway?
22:06 karolherbst: not really
22:08 karolherbst: mupuf_: they just mask the other bits
22:08 karolherbst: and flip over 0x1 or 0x10
22:08 karolherbst: that's all
22:09 mupuf_: right, ok. I meant the headers
22:09 karolherbst: mupuf_: yeah, nice functions, called "therm_gate_ctrl_r"
22:09 karolherbst: or "therm_gate_ctrl_eng_pwr_auto_f"
22:09 karolherbst: so, thats' that
22:10 karolherbst: I am more interessted in the 0xffffff00 bits
22:10 karolherbst: like which delay to set
22:10 karolherbst: or what that ENG_FILTER, ENG_MANT thing does
22:10 karolherbst: and which value we have to put there
22:10 karolherbst: and from where we get that information
22:12 mupuf_: right
22:12 mupuf_: this is quite hard to reverse
22:12 mupuf_: but if nvidia never touches it, we can do the same
22:12 karolherbst: well, nvidia does touch _some_ of them
22:12 karolherbst: like on your gm206
22:12 karolherbst: 22000044 -> 22002245
22:13 karolherbst: ENG_CLK = RUN -> AUTO
22:13 karolherbst: ENG_FILTER = 0 -> 0x2
22:13 karolherbst: ENG_MANT = 0 -> 0x1
22:13 karolherbst: maybe we can simply ignore those, maybe they are important, so we should at least figure that out
22:14 karolherbst: I think the delays most likely tell the hardware how fast to turn off the clock signal
22:15 mupuf_: this is supposed to be done at the block level
22:15 mupuf_: but yeah, seems likely
22:20 frobos: I'm running an old 8400GS with kernel 4.4.6 + mesa 11.0.6 on gentoo, getting some errors on dmesg after some normal usage on chrome: http://hastebin.com/epepicogan.css should I open a bug report?
22:21 karolherbst: another crash on unload
22:23 karolherbst: skeggsb: https://gist.github.com/karolherbst/ec9321a3dd11e781a7129c8824e0f588
22:23 karolherbst: any ideas?
22:24 karolherbst: I assume the worker object was killed too fast or something
22:24 karolherbst: but the worker was still doing stuff
22:24 imirkin: frobos: my only theory is that chrome has started to submit things in parallel sometimes... you could try my locking branch: https://github.com/imirkin/mesa/commits/locking -- maybe it'll make things better for you, but i really dunno.
22:28 frobos: imirkin: hmmm, I had some errors when using compton as well, maybe the bugs are more generic
22:28 frobos: or the card is borked?
22:29 imirkin: it's _highly_ unlikely to be an issue with the hardware itself
22:30 imirkin: although some of those chips do like to desolder themselves every so often
22:31 frobos: yea, the card would crash I guess
22:31 frobos: unless it has corrupt ram
22:31 mupuf_: night
22:31 imirkin: the real issue is that nouveau hasn't really been hardened for "random ol' application" usage, and all of a sudden every application has decided it wants to use GL.
22:32 imirkin: it used to be that crashing was a perfectly acceptable way to deal with issues, but that's no longer the case. also the actual usage patterns of regular applications are quite different.
22:32 imirkin: a lot of effort has gone into filling out the various features of nouveau, but almost none towards hardening it for "daily" use
22:33 frobos: hard to debug these issues as well
22:33 imirkin: yep
22:34 imirkin: anyways, i don't mean any of that to say "this is not a valid issue", but more like "you shouldn't be too surprised when you run into issues like that"
22:34 frobos: I see, unsupported driver and all
22:34 imirkin: not enough manpower
22:35 imirkin: and hard to find volunteers who want to chase bugs that don't happen for their use-cases
22:35 karolherbst: kind of sad, that this year gsoc didn't really turned out, or do we have somebody doing a gsoc nouveau thing? :O
22:36 imirkin: no applicants, and no mentors, iirc
22:36 karolherbst: well, we had some who asked, but well
22:36 mwk: mupuf_: so, are you going to show today's video on XDC? :p
22:36 karolherbst: liked the one best who asked "what is nouveau"
22:36 imirkin: iirc the applicants weren't particular interested
22:36 imirkin: or capable
22:37 karolherbst: right
22:37 imirkin: so that falls under "no applicants"
22:37 karolherbst: :D
22:37 karolherbst: I see
22:37 karolherbst: mupuf_: maybe we should go into universities with the sticker I asked about and tell them, hey, wanna money? do gsoc for us! :D
22:38 mwk:will RE for food
22:38 karolherbst: t-shirts!
22:38 karolherbst: we need those too
22:38 mwk: and a logo!
22:38 mwk: what happened to that one?
22:38 karolherbst: we are just bad prepared, that's why gsoc won't work out
22:38 karolherbst: well
22:39 karolherbst: it is still valid I guess
22:39 karolherbst: mwk: wanna rename the envytools project to nouveau and put the logo on it?
22:39 karolherbst: :D
22:39 mwk: yeah, that'd be great
22:40 karolherbst: just breaking links everywhere, but who cares! :D
22:40 mwk: let's just take the nouveau logo, strike through the nouveau text, and scribble "envytools" on top of it in some crappy mismatched font
22:40 mwk: that'd capture the spirit
22:40 karolherbst: true
22:42 mwk: anyhow
22:42 mwk: got drunk with mupuf today, listened to Dream Theater on the NV1, and drew a "3D" textured quad on it
22:43 mwk: it was fun, and we got a video :p
22:43 imirkin: encoded by the NV1 hw itself, i assume?
22:43 karolherbst: done
22:43 karolherbst: mwk: https://i.imgur.com/6V8yOrq.png
22:43 mwk: imirkin: afraid not :(
22:43 mwk: karolherbst: ah, that's a great logo, exactly what I had in mind!
22:43 imirkin: mwk: next time
22:43 karolherbst: I think this is what you expected? :D
22:45 karolherbst: mwk: do you want that picture now or somehting else? :D
22:46 mwk: no no, it's perfect
22:46 karolherbst: :D
22:46 mwk: where do I upload a logo on github...
22:46 karolherbst: done
22:46 mwk: ah, you beat me to it
22:47 karolherbst: mhh, maybe I change my profile pic too
22:48 karolherbst: perfect, found the best one
22:48 mwk: I have absolutely no idea what that is
22:48 mwk: but oh well :)
22:49 karolherbst: well, I made it myself!
22:49 karolherbst: no idea either
22:49 karolherbst: was just messing around with quartz extreme on my mac back then
22:49 karolherbst: created stuff like that applying filter at random
22:49 t-ask: there was no wacom involved ;)
22:49 karolherbst: sure not
22:50 t-ask: :D
22:50 karolherbst: liveQuartz!
22:50 karolherbst: that was the application
22:50 karolherbst: best one there is
22:51 karolherbst: I created crappy images with paint and like 100+ braushes
22:51 karolherbst: *brushes
22:51 karolherbst: and just put crappy and a lot of quartz filters on top of that
22:51 t-ask: why does that remind me of Krita :)
22:52 karolherbst: well
22:52 karolherbst: krita has like 10x the features my applications had
22:52 karolherbst: maybe even 100x
22:52 t-ask: not sure on brush presets .)
22:52 karolherbst: who needs presets? :D
22:52 t-ask: haha :)
22:53 karolherbst: right
22:53 karolherbst: I used Paintbrush
22:53 karolherbst: see what that can do
22:53 karolherbst: nothing
22:53 karolherbst: :D
22:53 karolherbst: even more crap than paint is
22:53 karolherbst: http://paintbrush.sourceforge.net/
22:54 t-ask: maybe try deluxe paint ,)
22:54 karolherbst: only amateurs use software like adobe photoshop and all that overpriced crap software :p
22:54 karolherbst: it is like aim assist in shooters
22:54 karolherbst: :p
22:56 karolherbst: but my new picture _should_ be a bird, I think I had this in mind while creating this... or something?
22:57 t-ask: a bird which doesn't fly ?! .)
22:58 karolherbst: the hell should I know, I didn't actually talked to the bird
23:00 t-ask: Husten, we have a problem, we talk to PCs not birds :P
23:00 t-ask: Housten*
23:02 t-ask: I'm probably too tired :)
23:03 t-ask: getting the wifi pw and then time to have a rest
23:07 t-ask: I have to pick a nice bike tour route this month, as long as the weather is fine
23:12 TA5K: Bordeau-London or Amsterdam migth be interesting