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