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