00:01 mhenning[d]: It does trigger on kepler - I've reproduced the transfer queue issue there. Although, that patch doesn't fix it alone so we probably also need the irq storm fix
00:11 gfxstrand[d]: Yeah, probably.
05:21 carmelosantiago: So the formula i added to the continuous set to access the middlest bit descends in practice from such layout requirement n*y(n+y)/2 so in roulette this is 1*36(1+36)/2 is 666, so the supporting assembly and indexing system needs to shift , my method so far was demonstrated to work for element in the middle of the spectrum, cause 57 is the middle bit out of 32 bits. And log is somewhere
05:21 carmelosantiago: on a date where i have to check but was exposed by radom nick called MaryTrampoline. It demonstrated asto how to get 78 out of 57, but another methods where there are four times 75 75 75 75 get's to 624 a lot of testing is yet undone, but based of the logics it has to work. so on roulette it is possible to access 18th bit with this formula i gave, then shift and access more on but this
05:21 carmelosantiago: presentation i gave starting from 5 and with gaps of four increasing times 32 to higher values it would access well the 57 like this. I have been outside cause we have good weather in september, and have not identified other methods yet than this, but i suppose more could be identified if you'd register the attempts in calculator for later possible approval or confirms about the new
05:21 carmelosantiago: methods fluked through testing with enthusiasm. But so far the state is so that i know that the compression works and i know round about what are the requirements for storage.
06:29 ermine1716[d]: All that said, irc bridge doesn't screen symbols discord uses for formatting
09:25 jja2000[d]: steel01[d]: He did today!
12:45 phomes_[d]: mhenning[d]: ok. I rebased the kernel and userspace parts. Tests still pass so I hope I got it right
12:47 phomes_[d]: I added zcull to the performance sheet. +1 fps in a few games. Does that seem right?
12:53 karolherbst[d]: +1 would be a bit disappointing tbh
12:54 karolherbst[d]: but as I said, the hardware already does zcull, so maybe it is expected?
12:55 karolherbst[d]: right..
12:55 karolherbst[d]: so it only optimized zcull even further, yeah okay, +1 fps does make sense then
12:55 karolherbst[d]: phomes_[d]: maybe do more test runs to get out the variance?
12:57 karolherbst[d]: I should take a look at the MR, because I do have some docs on it
13:20 karolherbst[d]: left some comments.. not 100% sure how the `STORE`/`LOAD` stuff works, but zcull does not operate on VRAM, but on internal on-chip storage
13:21 karolherbst[d]: and the size depends on GPU architecture
13:31 cry0xen[m]: few days ago, i asked about fermi on wayland. and concluded x11 nuvo/nvidia for older hw(GF820m) though the intel (hd5500) igpu can use wayland. after that discussion a question bugging me for a while. Whats stopping nouveau for supporting wayland on older hw. theres clearly a gap/scope as nvidia wont support 390/470 hw. is this a hw or development restrictions? If its hw restriction how can intel or amd can sail smooth through this...if
13:31 cry0xen[m]: its the development restrictions, can you ask for pointers to team green as now they are becoming quite linux firendly. even hiring ben...
13:31 karolherbst: cry0xen[m]: wayland is supported on older hardware
13:31 karolherbst: ohh you mean the nvidia driver?
13:31 karolherbst: the old driver doesn't support it
13:32 karolherbst: like it's simply EoL
13:32 karolherbst: proper wayland support landed with.. 5xx something?
13:32 karolherbst: so the 470 driver branch doesn't really have it
13:32 cry0xen[m]: 515
13:33 karolherbst: yeah so it's just in maintenance only state so no new features
13:33 cry0xen[m]: but thats nvidia... what about nouveau...
13:35 karolherbst: nouveau supports it
13:36 cry0xen[m]: i am apologizing in advance. i am very noob at these topic... i take care of hw/sw for freinds and family. advocating linux and helping them to adjust to it. its just that in this part of the world these hws are pretty common and i came across 2 hw last week
13:40 cry0xen[m]: then why everyone is discouraging me using nouveau driver for wayland... its everywhere. forum chat recommendations.
13:41 karolherbst: probably mean the nvidia driver
13:41 karolherbst: but dunno.. people have weird feelings about wayland
13:45 ermine1716[d]: There's lots of fake/outdated info on wayland on various forums
13:48 cry0xen[m]: i dunno i thought its a reverse-engineering project so its always in the alpha stage like reactos
13:50 cry0xen[m]: and in a sense now that nvidia is supporting newer hardwares i thought nuvo project will pick up the abondoned ones.
14:06 x512[m]: Haiku is also reimplementation of proprietary BeOS, but it works quite good.
14:07 x512[m]: ReactOS is pure project management issue.
14:08 x512[m]: Wine is quite successful.
15:46 mhenning[d]: karolherbst[d]: I don't think that's true. The hardware can do zcull without setting up buffers or anything but you do need to actually turn it on, which we haven't been doing.
15:47 karolherbst[d]: mhenning[d]: oh we explicitly turned it off? mhh maybe in that case it won't do anything.. a bit disappointed by the small benefit still
15:49 mhenning[d]: Yeah, `SET_ACTIVE_ZCULL_REGION, 0x3f` turns off zcull and we've been doing it unconditionally so far
15:49 karolherbst[d]: I see
15:53 karolherbst[d]: there are some weird interactions with EarlyZ btw
15:54 karolherbst[d]: ZCull can function when EarlyZ is disabled, but there are some restrictions in place sometimes
15:55 karolherbst[d]: I wonder if there are SPH fields we need to make use of
15:55 karolherbst[d]: let's see..
15:58 karolherbst[d]: is there a vulkan API to specify how depth values are modified by shaders?
15:58 marysaka[d]: probably bit 611?
15:58 karolherbst[d]: yeah... might be
15:59 karolherbst[d]: soo if you modify sample coverage, ZCull can still operate but not EarlyZ
16:05 mhenning[d]: karolherbst[d]: I think we figure this out by analyzing the shader
16:05 karolherbst[d]: mhhhh
16:05 mhenning[d]: Right now I think it's just "is depth written at all?"
16:05 karolherbst[d]: I know that direction of the change matters
16:05 karolherbst[d]: but not sure we'd know it by looking at the shader
16:06 karolherbst[d]: docs mention promises applications have to made via API calls
16:06 mhenning[d]: Right, I think we ignore the direction of the change right now
16:06 karolherbst[d]: okay
16:06 karolherbst[d]: this matters for zcull tho
16:07 karolherbst[d]: like we'd have to know if they all go into the same direction
16:07 karolherbst[d]: then zcull can still trivially reject pixels
16:08 mhenning[d]: you don't need to know, you can just do the pessimistic thing
16:08 karolherbst[d]: but not sure how to program this on the hw
16:08 karolherbst[d]: oh yeah we don't, but then zcull won't do anything
16:08 mhenning[d]: and yeah I don't have any idea where that would go either
16:08 mhenning[d]: karolherbst[d]: it won't do anything if you're writing depth. I don't know how common depth writes are
16:09 mhenning[d]: that is, writing depth from the fragment shader
16:09 karolherbst[d]: yes
16:09 karolherbst[d]: but if the changes are in the same direction, zcull can still operate is my point
16:09 mhenning[d]: okay, well we can figure that out later. I really don't want to make the current mr any bigger than it is
16:10 karolherbst[d]: yeah of course, just mentioning it
16:10 mhenning[d]: aure
18:26 phomes_[d]: mhenning[d]: it put the rebased versions here: https://gitlab.freedesktop.org/phomes/mesa/-/tree/zcull-rebased and https://gitlab.freedesktop.org/phomes/linux/-/tree/zcull-rebased if you want it