00:05RSpliet: Subv: There could be many reasons... the GPU might be chillin' in a different context, or working on other queues. It might be DMA'ing your pushbuf in (... well, I'm not 100% sure about that one, don't actually know where the pushbufs reside)
00:06RSpliet: Those are all quite generic hints though, not sure how specific you're looking for information...
00:16Subv: turns out the address we were using for a GPU query was being cached by the CPU, leading to all sorts of 'what' moments
00:45someosdev: So, I've been looking at a mmt from glxgears to see the difference between SLI and normal mode.
00:45someosdev: However demmt has problems with the pushbuf in SLI mode since DMA_PUT is set to a buffer not mmaped ("found, but disabled" which seems to be a known problem according to the code of demmt).
00:45someosdev: All the commands are actually sent to a completely different buffer.
00:45someosdev: Although demmt does not have a problem with DMA_PUT in normal mode, most of the important commands are sent to a pushbuf not recognized by demmt.
00:46someosdev: Any suggestions?
00:51someosdev: Is there a problem with the indirect buffer handling?
05:18Subv: i can't seem to find the code where nouveau waits for rendering to finish before executing glReadPixels, the nouveau driver doesn't appear to register a handler for that so mesa uses _mesa_readpixels, but i can't see any waiting code in it
05:38airlied: Subv: when you map something it likely happens
05:39Subv: oh, so it unconditionally waits for all commands to finish instead of just the ones related to the buffer it's reading from?
05:40airlied: Subv: it might not do any of that, it might use another operation to do a transfer
05:40airlied: and wait on the result of that
05:40airlied: nouveau_buffer_transfer_map has the code
05:41airlied: for buffers
05:41airlied: (nouveau_buffer_busy + nouveau_buffer_sync)
05:42airlied: nvc0_mt_sync does something similiar for textures
05:48Subv: i see that for glReadPixels it calls nouveau_bo_map which calls nouveau_bo_wait unconditionally though
05:48Subv: so that's probably it, thanks!
09:52alkisg: So, update, we have lots and lots of issues in a wide range of models, e.g. tnt2, geforce 400, 4000, 5200, from segfaults to corrupted output,
09:52alkisg: and all of them get solved with pageflip off
09:52alkisg: It's rather weird that it hasn't become a big deal yet, I've seen it in most nvidia cards here...
09:52alkisg: All this in ubuntu 18.04 fully updated
10:49RSpliet: mupuf: Mind giving your input on [Nouveau] [PATCH] drm/nouveau: Don't disable polling in fallback mode ? I think Ben meant you... but wasn't sure since you haven't been added explicitly to the conversation :-P
11:39mupuf: RSpliet: thanks, I would have missed it
17:42karolherbst: mhh interesting
17:42karolherbst: with Turing we apperenatly don't get 128 cores per SM anymore, but 64 float + 64 int cores, halfed texture units, but doubled SMs in general
17:43karolherbst: only found a german newspage with that info... without linking to a source
17:45pendingchaos: karolherbst: https://devblogs.nvidia.com/nvidia-turing-architecture-in-depth/ perhaps?
17:45karolherbst: ahh, nice
17:45pendingchaos: there's also https://www.nvidia.com/content/dam/en-zz/Solutions/design-visualization/technologies/turing-architecture/NVIDIA-Turing-Architecture-Whitepaper.pdf
17:46karolherbst: there it is
17:46karolherbst: ohh wait
17:46karolherbst: I look for public information on something I want to talk about
17:46karolherbst: but apperantly it isn't there
17:51karolherbst: uhm, btw, do we do memory compression at all?
17:52pendingchaos: I think so
17:53pendingchaos: in nvc0_mt_choose_storage_type()
17:53pendingchaos: I guess some flag is set in the page table and it's all transparent
17:53karolherbst: never looked into any of that
17:54pendingchaos: *set in the page table entry
18:32someosdev: karolherbst: Do you need a German, der dir das übersetzt?
19:28someosdev: Ah, I see. I feel very retarded right now...
19:58karolherbst: nice, "nvc0_screen_get_param: unhandled cap 180"