14:15karolherbst: did somebody took a deeper look into those mmio error codes?
14:15karolherbst: mwk maybe?
14:17mwk: I seem to recall writing these down, but a grep on my notes turns up nothing
14:18karolherbst: I was taking a look and noticed some strong patterns
14:18karolherbst: most interesting is badf1301 for registers which existed on previous gens, but not on the current one
14:18karolherbst: not 100% sure it's that
14:18karolherbst: but it looked like it
14:18mwk: it was badf, not dead
14:19karolherbst: there is bad0 as well
14:19mwk: docs/hw/mmio.rst :p
14:19karolherbst: but I think those are actually runtime errors
14:49karolherbst: pendingchaos: what's the status with the NOUVEAU_TRANSFER_PUSHBUF_THRESHOLD stuff?
14:50pendingchaos: I think I was going to remind you about the benchmark thing sometime today
14:52pendingchaos: looking at my own old results, I think 64 KiB is where putting the data in the pushbuf starts being less efficient
14:52karolherbst: pendingchaos: do you have some kind of benchmark to automate the entire though? It looked like I had to recompile beteween each iteration
14:54pendingchaos: that was originally the case, though it should not be needed now: https://gist.github.com/pendingchaos/036407c96bcbfb760327e26871363457
14:54karolherbst: ahh, didn't see that one
14:54karolherbst: pendingchaos: well, the thing with bigger values is, that it might stall other things as well
14:55karolherbst: because you can do copies asynchronous, but if you stall the fifo you can't parallize stuff anymore (afaik)
14:55karolherbst: or well, the gpu can't work on the fifo because it is busy with the copy
14:56karolherbst: from the data it looked like that 512 or 1024 were good enough values as the benefit decreases with higher values + the overall runtime wasn't that much longer
14:56karolherbst: but yeah, would be good to have benchmarks verifying that
14:56karolherbst: but for now I would rather be more careful
14:56pendingchaos: I don't see any kind of synchronization with nve4_m2mf_copy_linear? but smaller values should be fine
14:58pendingchaos: I think there was some talk about this kind of stuff not that long ago
14:58karolherbst: or maybe it doesn't matter afterall.. dunno
14:58karolherbst: pendingchaos: did you check some of the gputest benchmarks with it?
14:59karolherbst: afaik only hitman were hitting 256 and increasing the value improved thinks significantly, correct?
15:01pendingchaos: not sure exactly what you mean, but just setting it to 256 should improve hitman by 7%-10%
15:02pendingchaos: I think setting it to 1 GiB improved Deus Ex: Mankind Divided by 2% or so
15:03pendingchaos: according to imirkin, for ubo uploads, nve4_m2mf_copy_linear stalls the pipeline and nve4_p2mf_push_linear doesn't
15:06karolherbst: I see
15:06karolherbst: but we use nve4_m2mf_copy_linear on kepler+
15:06karolherbst: ohh wait
15:07karolherbst: the push_data function matters
15:07karolherbst: yeah, I guess I could test this on kepler/maxwell/pascal, but I kind of guess we would more or less get the same results
15:07karolherbst: I have a low spec tesla GPU here though
15:08karolherbst: but this one uses nv50
15:08karolherbst: still interesting to see the results
15:09pendingchaos: it might be more correct to say nvc0_cb_bo_push doesn't stall the pipeline
15:10pendingchaos: I might test nvc0_cb_bo_push too
15:10pendingchaos: just a warning: the test seems to have a tendency to make gnome-shell lag
15:19karolherbst: HdkR: was there something threaded disabled inside dolphin, which triggered the multithreading issues?
15:27HdkR: karolherbst: Yea, threaded shader compilation is disabled in Dolphin for Nouveau
15:29HdkR: karolherbst: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/DriverDetails.cpp#L106 Change the true on that line to false and it'll be reenabled
15:35intelminer: karolherbst: Lyude asked me to come here and poke you RE: "GP108M PMU issues". Because I was the one with them
16:48karolherbst: HdkR: seems like I can't install dolphin without root priviliges, might be a bug when setting the install prefix later
16:49HdkR: weird. I've never tried messing with local install configurations with cmake though :)
16:50karolherbst: trying a clean build now
16:50karolherbst: yeah... that works
16:51HdkR: Silly cmake then
16:55karolherbst: HdkR: okay... uhm, bug inside dolphin found
16:55HdkR: lol, that was fast
16:55karolherbst: HdkR: the rom view refreshes quite frequently, so if you scp one from one to another machine, it always shows the message
16:55karolherbst: like, you click it away, it comes back :p
16:55karolherbst: sure there is "Ignore for this session button"
16:55karolherbst: still ;)
16:56HdkR: Ah, GUI things
16:56karolherbst: at some point I have to recheck all those gc bugs I filed, there might be still a few game bugs around
16:57karolherbst: once I filed some bug for mario party
16:57karolherbst: ohh, now the GUI glitches :D
16:57karolherbst: removes and readds the rom
16:59karolherbst: HdkR: mhh, when should that compilation bug trigger?
17:00HdkR: oh right
17:00Lyude: karolherbst: poke; not sure if you noticed but the person I mentioned with the GP108M issues is here today ( intelminer)
17:00karolherbst: Lyude: yeah.. I just don't have much to add here, I think I already mentioned talking to skeggsb, no?
17:00Lyude: oh right, forgot about that!
17:01HdkR: karolherbst: If you go in to the graphics configuration there is a "Shader Compilation" section. Change that to "asynchronous (Ubershaders)" and run a game
17:01karolherbst: HdkR: ohh right, ubershaders just don't work on kepler, right?
17:01karolherbst: or is that all fixed?
17:01HdkR: I don't remember that being an issue
17:01karolherbst: "double free or corruption (fasttop)" nice
17:02karolherbst: anyway, I kind of hit the same issue with OpenCL
17:02karolherbst: I kind of plan to fix the multithreading issues we have in general... might be easier to start with fixing the shader compiler
17:03karolherbst: HdkR: is there some gdb mode for dolphin?
17:04HdkR: Find the Dolphin.ini in the XDG config folder and change the `Fastmem=True` to `Fastmem=False` and gdb will work
17:05karolherbst: you should add an --gdb option or detect that at runtime ;)
17:06karolherbst: HdkR: also "Mesa: User error: GL_INVALID_OPERATION in glBindVertexArray(non-gen name)"
17:06HdkR: Yea, it isn't likely that anyone is going to want gdb + fastmem. Not sure why it hasn't been added really..
17:08karolherbst: HdkR: https://gist.githubusercontent.com/karolherbst/4ec91d31a63128bc376cf7e599e525d4/raw/326b8a4a9b61d5db8a41f51690a200aa4dff852d/gistfile1.txt :)
17:08karolherbst: at some point the console messed up
17:08karolherbst: and parts were stuck
17:09karolherbst: that's the multithreading compilation issue though
17:09kernel-3xp: hi guys, first of all thanks for your work, second how far away is fermi reclocking?
17:09karolherbst: kernel-3xp: people want to work on it, but they have other more important work sadly :/
17:10kernel-3xp: ok, so maybe 2 yrs or sth?
17:10karolherbst: I think it might require somebody new who wants to dig into it
17:11karolherbst: I doubt I will find any time for it
17:11HdkR: karolherbst: Ah, it is binding a VAO as well in the compilation thread as well. Could be part of the issue? :P
17:11karolherbst: no idea about skeggsb, and I doubt RSpliet will find it
17:11karolherbst: HdkR: dunno, first thing: fix logging
17:11kernel-3xp: ok thanks, i will think about it
17:11karolherbst: not the issue, but... needs to be fixed nonetheless
17:12HdkR: Binds a VAO to prevent the Nvidia blob from doing attribute optimizations as far as I'm aware
17:28karolherbst: ohh, interesting
19:06karolherbst: anybody a better idea than using a forward_list (or a normal list) for compilation logs?
19:16karolherbst: mhh, allthough maybe realloc would be fine and so would be a vector
20:32pendingchaos: karolherbst: how does setting NOUVEAU_TRANSFER_PUSHBUF_THRESHOLD to 1024 on Kepler+ sound?
20:34karolherbst: I think it should be fine
20:34karolherbst: didn't got to test it yet, but maybe I will do it later today, or tomorrow
20:35pendingchaos: I've updated the test in the past 5 minutes or so btw
21:19karolherbst: buh... debug_printf isn't thread safe?
21:22karolherbst: uff, 512 chars at most in one go