02:21juri_: I notice the envytools pages are pretty out of date.
02:22juri_: should i be trying to update those, or has a better source of low level data been created?
02:24imirkin: what's out of date about them?
02:25juri_: well, the 2013 copyright is not inspiring, but they start to get really vague around the GF100 or so.
02:28imirkin: as long as it's copyrighted after mickey mouse, the year doesn't matter
02:29imirkin: updating the year implies some kind of material update, and debating what that is precisely is not a useful way to spend time
02:29juri_: I'm just making sure i'm not duplicating effort, by contributing to these docs.
02:30imirkin: there is no more "up-to-date" source of docs, other than code in nouveau
02:30juri_: ok then. thanks!
02:56imirkin: juri_: but probably wise to check here before doing any substantial work
02:56imirkin: thing is ... not much has changed since GF100 for a ton of things
03:02HdkR: Why change things that aren't broken? :D
03:12imirkin: HdkR: they do that all the time... on every isa rev, tex instruction operands change.
03:13HdkR: imirkin: Obviously they must be broken
03:57imirkin: Lyude: i think i see what's wrong with adding outputs -- i don't manage crtc's properly
03:57imirkin: ugh, this is all coz of zaphodheads
04:00imirkin: er hm. maybe that's not it =/
04:30imirkin: Lyude: well, i pushed the fix to avoid crash on unplug, hopefully
04:33imirkin: Lyude: when you plug the other screens, i'd be curious what happens when you look at 'xrandr', as well as what happens when you try to futz with them by turning them on/off (with xrandr)
04:34imirkin: i suspect you have some kind of desktop manager which is muddying the waters
05:25npnth: I've got a system (GK106) which is mostly stable, except that gimp acts like a time bomb. After a couple minutes of use, the machine pretty usually locks up hard. I can move the cursor, but no input appears to be accepted.
05:26npnth: Remoting in via ssh doesn't seem to help anything; killing everything from gimp down to X doesn't bring back functionality.
05:27npnth: I've got KASAN and some other debugging stuff turned on, but all I see in dmesg is "nouveau 0000:01:00.0: fifo: FB_FLUSH_TIMEOUT". (I think I also might occasionally see some stuff about a channel, but I don't see that right now.
05:28npnth: I'm using -mainline, latest libdrm, all that, and this has been happening for a couple of months right now.
05:30npnth: What should I do in order to get useful information for a bug report next time this happens? I should probably run nouveau's upstream kernel, of course. Would output from strace help, or are there some CONFIG_ switches I should flip?
05:30imirkin: npnth: GTX 660?
05:32imirkin: some of those boards inexplicable hang. using blob grctxsw firmware seems to help in those cases.
05:34npnth: imirkin: A 650, but that sounds close enough.
05:35npnth: I've not heard of that firmware, but I'll look into it, thanks.
05:37imirkin: npnth: follow the instructions here: https://nouveau.freedesktop.org/wiki/VideoAcceleration/#firmware
05:38imirkin: npnth: and then boot with nouveau.config=NvGrUseFW=1
05:38npnth: imirkin: Will do, thanks!
05:39imirkin: i've only heard of this issue on some GTX 660's
05:40imirkin: but we haven't the faintest clue what causes it
05:40imirkin: since boards that repro it have never been in the right developer's hands
05:43npnth: Hm, I'm on gentoo, I have sys-firmware/nvidia-firmware installed, and I'm booting with nouveau.config=NvGrUseFW=1. However, dmesg does contain a few lines like "nouveau 000:01:00.0: Direct firmware load for nvidia/gk106/fecs_inst.bin failed with error -2".
05:44npnth: Is that expected, or am I perhaps still missing some files?
05:45npnth: Hm, well manually running your scripts for extraction produces quite a few more files than I have in /lib/firmware/nouveau currently. Perhaps that would help.
13:47karolherbst: imirkin: I am currently wondering how much of a perf increase we get if we wouldn't do certain bound checks like on image operations. Hidden behind an env variable or extension, which can be enabled for certain applications/games or so
13:59imirkin: karolherbst: none, i'm sure. image operations are slow.
14:00karolherbst: imirkin: we do bound checks on other things as well, no? Maybe something involving shared memory?
14:00imirkin: memory operations are slow.
14:00imirkin: gmem operations are slow.
14:00imirkin: alu is fast.
14:01karolherbst: reading from const memory is also kind of fast I guess?
14:02imirkin: relatively, yeah
14:06imirkin: karolherbst: feel free to play with it
14:06imirkin: i just really doubt it'll have any effect
14:06karolherbst: yeah, should be relativly easy to figure out what is affected by that
14:06karolherbst: but my thinking was it still kills 3 instructions per access + one read less from const memory
14:07imirkin: at the cost of GL conformance
14:07gnarface: and uh... security?
14:08karolherbst: gnarface: virtual memory
14:08imirkin: gnarface: userspace doesn't enforce security
14:08karolherbst: imirkin: yeah right, we could only do that for application never going out of bounds
15:10pendingchaos: am I correct in thinking that nvc0_screen_fence_emit() is only called when pushbuf is being flushed?
15:10pendingchaos: if so, shouldn't there be a PUSH_KICK() or something in nvc0_hw_query_fifo_wait()?
15:11imirkin_: the first bit is correct.
15:12imirkin_: the second part isn't
15:12imirkin_: let's see here...
15:12imirkin_: so the query has a sequence number
15:13imirkin_: what query_fifo_wait does is throw a wrench into the fifo works until the memory address where the fence lives == the sequence number
15:13imirkin_: hm, but your point is that if hq->is64bit, this could lead to a deadlock? i'd have to think about it.
15:14imirkin_: i don't remember how fence emission works precisely enough
15:14imirkin_: oh, no, because hq->fence->sequence != the current sequence number
15:15imirkin_: also tbh i dunno if ACQUIRE_EQUAL is right. should probably be greater-or-equal or something
15:15pendingchaos: yeah, i'm talking about queries when hq->is64bit is true
15:15imirkin_: this stuff is pretty subtle
15:15imirkin_: anyways, so the fence's memory address never changes
15:15imirkin_: but each fence object has its own sequence number
15:16imirkin_: you know
15:16imirkin_: maybe there *is* something missing
15:16imirkin_: not a push_kick
15:17imirkin_: but maybe a check if hq->fence == screen->fence
15:17imirkin_: or rather
15:17imirkin_: if hq->fence->state != emitted
15:17imirkin_: then emit it
15:46imirkin_: pendingchaos: hrmph... nouveau_fence_kick would be the function, but it's not public. i guess easy enough to just do if (hq->fence->state < NOUVEAU_FENCE_STATE_EMITTED) PUSH_KICK()
16:01pendingchaos: should I create a patch adding that and changing ACQUIRE_EQUAL to ACQUIRE_GEQUAL?
16:03imirkin_: pendingchaos: well, like i said ... this stuff is pretty subtle
16:03imirkin_: it'd be worth playing with, at least
16:04imirkin_: did you run into some issue, or did this come up when just reading code?
16:04pendingchaos: I ran into some issue
16:05pendingchaos: adding a PUSH_KICK() seems to fix the issue
16:05imirkin_: are you using the pipeline stats counters?
16:05imirkin_: or is this for the query overflow thing?
16:05pendingchaos: it's for the query overflow thing
16:05imirkin_: nice :)
16:06imirkin_: i'd say definitely throw in the PUSH_KICK when state < EMITTED
16:06imirkin_: that's a clear bugfix.
16:06imirkin_: i wonder if in that case
16:06imirkin_: you can do something simpler
16:06imirkin_: like throw in a synchronize and just move on
16:06imirkin_: but ... meh
16:07imirkin_: i.e. NVC0_3D_SERIALIZE
16:13freecoder_: the link to "block architecture diagram" at https://nouveau.freedesktop.org/wiki/NvHardwareDocs/ seems to be broken
16:13imirkin_: should probably just delete that page
16:14imirkin_: you can probably use web.archive.org to find it...
16:15freecoder_: cool. but i suppose the page is probably outdated by now?
16:15imirkin_: freecoder_: http://ixbtlabs.com/articles2/gffx/nv40-part1-a.html
16:17pendingchaos: the images on the page don't load though
16:17pendingchaos: they seem to refer to digit-life.com
16:18freecoder_: the link from wayback machine appears to work - https://web.archive.org/web/20080111122628/http://www.digit-life.com/articles2/gffx/nv40-part1-a.html
17:51imirkin_: freecoder_: thanks. updated.
22:19karolherbst: the hell is this blend_support_all_equations thing :O
22:20karolherbst: I am sure this string has the worst chars/instruction ration of all possible strings you can come up in glsl...
22:30karolherbst: imirkin: FBFETCH is used to "read outputs" in fragment shaders?