00:05 RSpliet: 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:06 RSpliet: Those are all quite generic hints though, not sure how specific you're looking for information...
00:16 Subv: 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:45 someosdev: So, I've been looking at a mmt from glxgears to see the difference between SLI and normal mode.
00:45 someosdev: 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:45 someosdev: All the commands are actually sent to a completely different buffer.
00:45 someosdev: 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:46 someosdev: Any suggestions?
00:51 someosdev: Is there a problem with the indirect buffer handling?
05:18 Subv: 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:38 airlied: Subv: when you map something it likely happens
05:39 Subv: oh, so it unconditionally waits for all commands to finish instead of just the ones related to the buffer it's reading from?
05:40 airlied: Subv: it might not do any of that, it might use another operation to do a transfer
05:40 airlied: and wait on the result of that
05:40 airlied: nouveau_buffer_transfer-map
05:40 airlied: nouveau_buffer_transfer_map has the code
05:41 airlied: for buffers
05:41 airlied: (nouveau_buffer_busy + nouveau_buffer_sync)
05:42 airlied: nvc0_mt_sync does something similiar for textures
05:48 Subv: ah
05:48 Subv: i see that for glReadPixels it calls nouveau_bo_map which calls nouveau_bo_wait unconditionally though
05:48 Subv: so that's probably it, thanks!
09:52 alkisg: 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:52 alkisg: and all of them get solved with pageflip off
09:52 alkisg: It's rather weird that it hasn't become a big deal yet, I've seen it in most nvidia cards here...
09:52 alkisg: All this in ubuntu 18.04 fully updated
10:49 RSpliet: 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:39 mupuf: RSpliet: thanks, I would have missed it
17:42 karolherbst: mhh interesting
17:42 karolherbst: 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:43 karolherbst: only found a german newspage with that info... without linking to a source
17:45 pendingchaos: karolherbst: https://devblogs.nvidia.com/nvidia-turing-architecture-in-depth/ perhaps?
17:45 karolherbst: ahh, nice
17:45 karolherbst: thanks
17:45 pendingchaos: there's also https://www.nvidia.com/content/dam/en-zz/Solutions/design-visualization/technologies/turing-architecture/NVIDIA-Turing-Architecture-Whitepaper.pdf
17:46 karolherbst: ahhh
17:46 karolherbst: there it is
17:46 karolherbst: ohh wait
17:46 karolherbst: no
17:46 karolherbst: mhh
17:46 karolherbst: I look for public information on something I want to talk about
17:46 karolherbst: but apperantly it isn't there
17:51 karolherbst: uhm, btw, do we do memory compression at all?
17:52 pendingchaos: I think so
17:53 pendingchaos: in nvc0_mt_choose_storage_type()
17:53 pendingchaos: I guess some flag is set in the page table and it's all transparent
17:53 karolherbst: okay
17:53 karolherbst: never looked into any of that
17:54 pendingchaos: *set in the page table entry
18:32 someosdev: karolherbst: Do you need a German, der dir das übersetzt?
18:38 kernel-3xp: lol
19:06 karolherbst: ...
19:28 someosdev: Ah, I see. I feel very retarded right now...
19:58 karolherbst: nice, "nvc0_screen_get_param: unhandled cap 180"
19:59 karolherbst: PIPE_CAP_MAX_VERTEX_ELEMENT_SRC_OFFSET