00:37imirkin: karolherbst: we know what the shader uses, but we don't know what UBOs will be bound at a particular time
00:44karolherbst: imirkin: okay sure, but to know which slots are free within the shader is good enough already
00:45imirkin: karolherbst: yeah, but something may be bound even in the "free" slots
00:46karolherbst: why though? because a slot got optimized away and there is still an UBO bound through the API? or just because the application is stupid?
00:46karolherbst: or is there actually a valid reason for that?
00:47imirkin: application is stupid or efficient
00:47imirkin: depending which way you look at things
00:47imirkin: e.g. it only ever uses 14 UBO's, they all get bound to a slot, and you never touch ubo bindings again
00:47imirkin: or something
00:48karolherbst: I see
00:48karolherbst: do we always set the binding before the draw call? Or would we have to track which one we replaced with the immediate buffer and set it back?
03:47rhyskidd: so a community question: i'm going to have some dedicated nouveau time on an upcoming long-distance flight.
03:47rhyskidd: thoughts for how best to use that. note i'll only have a mobile GPU handy
03:48rhyskidd: and a couple of Turing vbios'
03:51HdkR: Remote in to a workstation over inflight wifi? :)
03:55rhyskidd: i've tried that once before -- it's a pain
03:55rhyskidd: although i think i recall one other dev using it moderately successfully once
04:00HdkR: I did it on the way to spain, was a bit painful and I mostly fell back to doing the work locally and syncing when I wanted to test it
04:18rhyskidd: ah yes
09:57pendingchaos: karolherbst: just to clarify: are you thinking of putting the immediates in a pool shared among programs
09:57pendingchaos: or having each program have it's own pool which is switched to upon binding/selecting the program
10:08pendingchaos: karolherbst: just to clarify: are you thinking of putting the immediates in a pool shared among programs
10:08pendingchaos: or having each program have it's own pool which is switched to upon binding/selecting the program
10:08karolherbst: pendingchaos: mhh...
10:09karolherbst: in worst case we have to change the binding slot of that buffer anyway
10:09karolherbst: question is: how much do we win for having one buffer?
10:09karolherbst: keep in mind that reusing the same buffer/values has a high CPU cost
10:10karolherbst: because you either iterate over existing values to check if the one already is there or you start using hashmaps to have a value -> storage mapping
10:10karolherbst: there fits quite a lot into those buffers so we could just don't care about duplicates
10:10karolherbst: and just add values as we fold mov 0x... into the instructio via c
10:11karolherbst: and just rebind for each shader
10:11karolherbst: maybe that rebinding is quite expensive?
10:11karolherbst: depends on what the actual bottleneck is
10:11karolherbst: and normally compiler bottlenecks are less important
10:29pendingchaos: having a shared pool would probably make the code more complex and add a compilation time cost
10:29pendingchaos: I don't think it will have any CPU cost while rendering though?
10:30pendingchaos: maybe having a larger constant buffer by having a shared pool would be worse on the GPU
10:31pendingchaos: or it could be better since no rebinding has to be done?
10:35karolherbst: yeah, not quite sure
10:35karolherbst: I doubt the costs are in any way noticeable though
10:35karolherbst: sure, you have to upload one buffer, where some application may just reuse the same one over and over again
10:35karolherbst: do you know what nvidia ends up doing?
10:36karolherbst: I could imagine they just upload a new one for each shader
10:36karolherbst: but I don't know for sure
10:37karolherbst: anyway, the perf benefit for shaders is most likely bigger than the perf penalty of the rebinding anyway
10:37pendingchaos: I don't know what it ends up doing
10:38karolherbst: pendingchaos: I think at least cuda binaries have their own buffer within the binary for that
10:39karolherbst: I doubt it is that important.
10:39karolherbst: I would just go with the simplier solution and just don't care about duplicates
10:39karolherbst: and each shader has its own buffer
10:40karolherbst: pendingchaos: I guess you added a new pass you run before LoadPropagation? or did you end up writing a complete new pass?
10:40pendingchaos: currently it's done in LoadPropagation
10:41karolherbst: I see
10:41karolherbst: so for example if a limm doesn't fit you retry with a c value?
10:42karolherbst: ohh, we have insnCanLoadOffset for that, nice
10:42pendingchaos: unfortunately it always creates a load instruction because insnCanLoad requires it
10:42karolherbst: use insnCanLoadOffset ;)
10:43pendingchaos: I don't think insnCanLoadOffset checks whether the instruction can actually do the load
10:43pendingchaos: *the type of load
10:43karolherbst: just saw that
10:43pendingchaos: just whether the offset would be in range
10:43karolherbst: but should be easy to add a new function for that
10:44pendingchaos: yeah, perhaps one that just takes what would the source for the load instruction and optionally an indirect
10:44pendingchaos: or something
10:44karolherbst: or just add it to insnCanLoadOffset
10:45karolherbst: pendingchaos: well, you just need to know if that instruction is able to take a const_mem source
10:46karolherbst: mhh, allthough I think insnCanLoadOffset is also used for other files
10:46vita_cell: karolherbst I reported this too, looks like a nouveau+GNOME problem
10:47pendingchaos: so perhaps a "bool Target::insnCanLoadCB(const Instruction *i, int s)"?
10:47pendingchaos: and insnCanLoad can make use of it so code isn't duplicated
10:47karolherbst: vita_cell: mhh, could be our famous multi context issues :/ or some other random fault
10:48karolherbst: vita_cell: dmesg would help
10:48karolherbst: pendingchaos: maybe
10:48vita_cell: I am not sure from where comes the bug
10:49vita_cell: karolherbst I am on blob for now, I will unblock nouveau and reinstall it, for dmesg
10:55vita_cell: karolherbst is here some easy switch between blob and nouveau?
10:55karolherbst: best thing is to script it for your distribution
10:56karolherbst: you have to : 1. blacklist both 2. force load one module in initramfs 3. change the xorg.conf 4. change userspace libs (opengl, opencl, vdpau?, ... others)
10:57pendingchaos: I think with GLVND, both the blob and mesa's libGL can coexist
10:57pendingchaos: I think the blob has it's own glx module for the x server or something though
10:57pendingchaos: that can't coexist with the normal one
10:58karolherbst: it can
10:58karolherbst: on one of my machines I have installed both
10:58karolherbst: but I don't have glvnd there
10:58karolherbst: the bigger issue is autoloading
10:58karolherbst: so nvidia userspace tends to trigger an nvidia module load
10:58karolherbst: but that's taken care of within initramfs
10:59karolherbst: or well other module load mechanisms on boot
11:01vita_cell: karolherbst nah, I just removed blob and I am now on nouveau
11:01vita_cell: so how do you want a dmesg?
11:01karolherbst: well in case that freeze happens
11:01karolherbst: then connect via ssh or something
11:02karolherbst: or wait some minutes and see if the log contains the old dmesg
11:02vita_cell: yeah but when hang happens, it hangs whole PC, and I must to force restart from reset button
11:02vita_cell: it is still a valid dmesg after restart?
11:04vita_cell: for example, when I play a game "Broforce" which is build with Unity3d engine, I try to do things like Añt+Tab, volume change, and the game hangs the whole PC or crashes
11:08vita_cell: ahhh karolherbst I forgot to mention, crashes and PC hangs only happens with GNOME, xfce4 works without bugs
11:40vita_cell: karolherbst is kern.log enought info?
11:40karolherbst: I guess so
11:40vita_cell: hmmm stange
11:40vita_cell: Oct 22 13:07:03 maquinon kernel: [ 398.292593] input: Xbox 360 Wireless Receiver as /devices/pci0000:00/0000:00:14.0/usb3/3-4/3-4:1.0/input/input11
11:40vita_cell: Oct 22 13:10:07 maquinon kernel: [ 582.833386] rfkill: input handler disabled
11:40vita_cell: this is the latest info before hang, when I was playing game
11:41vita_cell: no more writes
11:42vita_cell: hangs only happen in GNOME
13:28orbea: karolherbst: seems Thierry came up with a fix for kmscube. :) https://github.com/thierryreding/kmscube
13:28orbea: on the other hand, with 4.18 instead of 4.17 I just get a black screen instead of broken cube with the kmscube master...
13:28karolherbst: orbea: I kind of wished for a fix within mesa though
13:31orbea: I'm not sure I am understanding right, but I think he is saying that he made a wrong assumption that kmscube needed fixes before.
13:32orbea: where it really did
13:32karolherbst: might be
14:57rhyskidd: new nv docs for Turing compute (c5c0) at https://download.nvidia.com/open-gpu-doc/
14:58rhyskidd: see under Compute-Class-Methods and Compute-QMD
14:58karolherbst: rhyskidd: old news :p
14:58karolherbst: 20 days.. :p
14:58rhyskidd: i'm getting slow ...
14:59rhyskidd: i do want to know what that new-ish falcon since Volta is .. the GSP one
14:59rhyskidd: any ideas?
15:00rhyskidd: longingly, perhaps a GPL Support Processor?
15:03karolherbst: of course
15:04karolherbst: mhh, I can't even make jokes about that one. Sad
15:07rhyskidd: you hit the icd debug cmd register, and it creates a git repo on your disk that contains signing code and the priv key?
15:09karolherbst: :D someone removed the 2060 from wikipedia
15:10karolherbst: "no offense guy but..you didn't do **** lol...I would know..No oNE before me has made the tables for the Geforce 900, 1000 , 2000 and Volta series like I have ...if it was improved on ..it was because i took the initiative to actually do the calculations (by calculator lol) and do the research ..ik others have to be thanked for for the referencesO O of most but when it comes to a few references and how the tables
15:10karolherbst: what a guy
15:10karolherbst: HdkR: ^^
15:59rhyskidd: oh wow,
15:59rhyskidd: locked wiki article
16:09karolherbst: that person is super rude though
16:12rhyskidd: how is your compute work going? is that still occupying a lot of your available time on nouveau?
16:18HdkR: karolherbst: Lol, that person is amazing
16:23karolherbst: HdkR: I know, did you check the history?
16:24HdkR: Yea, I looked at it
16:26HdkR: karolherbst: Did you continue oneward looking at their changes afterwards?
16:26karolherbst: what changes?
16:27HdkR: Massive wall of text trying to justify themselves on a user talk page
16:35karolherbst: ahh, yeah, I saw that...
16:36karolherbst: but that wasn't massive?
16:36HdkR: Maybe I just had a hard time reading it from all the facepalming