Leopold__ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<mlankhorst>
danvet/airlied: so far I've never been able to fast-forward drm-misc-fixes this cycle, should I rebase, backmerge or just let it be since nobody complains?
jsa has joined #dri-devel
kts has quit [Quit: Leaving]
fab has joined #dri-devel
<mairacanal>
display folks, i'm having a problem when using non-blocking commits that I cannot guarantee that plane->state->fb == state->fb will be true for both prepare_fb and cleanup_fb. Sometimes, plane->state->fb == state->fb is true for prepare_fb (then I don't increase the refcount) and plane->state->fb == state->fb is false for cleanup_fb (then I
<mairacanal>
decrease refcount). I was wondering: this driver should guarantee this condition or it is really something we cannot guarantee?
<emersion>
mairacanal: maybe cleanup_fb runs after plane->state->fb has been updated to the new value?
<vsyrjala>
you should not consult plane->state. get the old/new state from the commit
<emersion>
right
<emersion>
but tbh not sure this check is really needed? i'd just inc/dec the refcount always
<pq>
conditional reffing sounds... strange
<mairacanal>
"but tbh not sure this check is really needed?" -> yeah, it works just fine which it
<mairacanal>
i was thinking about just removing this check, but I don't really know how to justify such a change
<pq>
I can think of a few suggestions: the old code was a) more complicated than necessary, b) fragile, c) inconsistent
<pq>
maybe even buggy, if it causes problems?
<emersion>
mairacanal: i think what ville said should be enough
<emersion>
but ideally that would be documented somewhere
<emersion>
can't find where though
bmodem has quit [Ping timeout: 480 seconds]
<emersion>
vsyrjala: is there a place where this is spelled out?
<javierm>
emersion: I also couldn't find in the docs, I remember adding 30b1a0797e0b ("drm/ssd130x: Use drm_atomic_get_new_plane_state()") but only because vsyrjala pointed out to me as well
<javierm>
btw, dri-devel ML is still down right? Or am I the only one who isn't getting emails from the list?
<vsyrjala>
i'm not sure what's spelled out in the docs. i think the get_existing_state() stuff at least is marked deprecated. but sadly seems to be lots of users left, probably equally many doing foo->state as well
<javierm>
a patch for the docs and a gpu/todo.rst entry to fix the existing users would be nice
yyds has quit [Remote host closed the connection]
Leopold_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit []
bmodem has joined #dri-devel
kts has joined #dri-devel
AnuthaDev has quit [Quit: AnuthaDev]
fab has quit [Quit: fab]
fab has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
fab has quit []
Duke`` has joined #dri-devel
kts has quit [Quit: Leaving]
Haaninjo has quit [Quit: Ex-Chat]
Duke`` has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
Duke`` has joined #dri-devel
Leopold__ has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
frieder has quit [Ping timeout: 480 seconds]
sarnex has quit [Quit: Quit]
sarnex has joined #dri-devel
dolphin` has joined #dri-devel
dolphin is now known as Guest10879
dolphin` is now known as dolphin
rsripada_ has joined #dri-devel
fdu_ has joined #dri-devel
sghuge_ has joined #dri-devel
lstrano_ has joined #dri-devel
cborah1 has joined #dri-devel
shankaru1 has joined #dri-devel
cborah has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
unerlige has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
fdu has quit [Ping timeout: 480 seconds]
Guest10879 has quit [Ping timeout: 480 seconds]
shankaru has quit [Ping timeout: 480 seconds]
sghuge has quit [Ping timeout: 480 seconds]
rsripada has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
lstrano has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
macromorgan_ has joined #dri-devel
macromorgan has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
kts has joined #dri-devel
azsxdcz has joined #dri-devel
azsxdcz has quit []
azsxdcz has joined #dri-devel
mszyprow has joined #dri-devel
azsxdcz has quit []
azsxdcz has joined #dri-devel
azsxdcz has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
bmodem has quit [Ping timeout: 480 seconds]
aravind has quit [Read error: Connection reset by peer]
hansg has quit [Remote host closed the connection]
mbrost has joined #dri-devel
kts has quit [Quit: Leaving]
kzd has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
<sima>
mlankhorst, yeah -rc1 is a bit old, but imo it's more important for -next since there's a lot more patches there and so higher chances for unbisectable regression
<sima>
I guess if you want to rolling forward once just to stay in sync after a month should be ok imo, even if there's not a direct reason
<sima>
i.e. imo backmerging -rc6 is ok if you're on -rc1 still
Leopold__ has quit [Remote host closed the connection]
frieder has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #dri-devel
neobrain has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
neobrain has joined #dri-devel
kts has joined #dri-devel
macslayer has joined #dri-devel
neobrain has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
neobrain has joined #dri-devel
hansg has joined #dri-devel
hansg has quit []
mbrost has quit [Ping timeout: 480 seconds]
moony has quit [Ping timeout: 480 seconds]
unerlige has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
<karolherbst>
jenatali: was there something I'd had to consider when lowering huge dispatches into various smaller ones?
<jenatali>
karolherbst: Yeah, you need to add offsets for the workgroup id
<jenatali>
Otherwise each dispatch will re-number those starting from 0
<karolherbst>
okay.. so with API offsets they always start at 0, but when I do set it internally to lower them, I have to account for them not starting at 0 in later dispatches
<karolherbst>
that makes sense I suppose
<karolherbst>
and I guess same for the global id
<jenatali>
karolherbst: Global ID is computed based on the local one
<karolherbst>
ehh wait
<karolherbst>
yeah..
<karolherbst>
so
<jenatali>
The global offsets are only needed to reflect the global offset functionality at the API
<karolherbst>
`global_work_offset` simply impacts the global ID of threads
<karolherbst>
okay.. yeah, so the workgroup_id is the oddball here
<jenatali>
Yep
<karolherbst>
I'll probably do shader variants for this and will also optimize the offsets == 0 case while at it I guess :D
<karolherbst>
I wonder if I want to precompile the offset shader and lazy compile the lowered one or just lazy compile them both...
<karolherbst>
mhh
<jenatali>
Yep, I do shader variants and optimize the offsets == 0 case as well
<jenatali>
I do both lazily right now, but that's mainly just because the local group size also needs to be part of my variant key and I can't even make a guess at that until enqueue time
<karolherbst>
so in the worst case there are 4 variants, but like offsets == 0 and small enough grids are like 99.9% of the cases...
<karolherbst>
well..
<karolherbst>
on the v3d driver I need huge grids lowered as the hardware has 16 bit limits on the grid :')
<jenatali>
Yeah D3D has that limit as well
<karolherbst>
I think I can lazy compile all variants, as I don't see it would impact anyway
<karolherbst>
while the GPU executes the main variant, the CPU can compile the others...
<karolherbst>
the only case which might make sense to compile ahead of time might be the api offset one but uhh...
<karolherbst>
whatever
consolers has joined #dri-devel
<karolherbst>
jenatali: I need to set `has_base_workgroup_id` to true and go from there, right?
<jenatali>
Yep
<karolherbst>
and `has_cs_global_id` needs to be false?
<karolherbst>
or true?
<consolers>
on wayland i was trying to use mpv --background=0/0/0/0 --alpha=yes to have a transparent background, and it works but when the background is white #ffffff, i.e. 1/1/1/0 (last number is the alpha) the whole thing becomes opaque. this is reported to work correctly with nvidia
<jenatali>
karolherbst: Only needs to be true if the API sets it to true IIRC
<jenatali>
Wait, that's just an unrelated thing, isn't it?
<karolherbst>
yeah..
<karolherbst>
I'm asking because there is this pattern in lower_system_values: has_base_workgroup_id || !has_cs_global_id
<karolherbst>
but I think I need has_cs_global_id to be true, and then drivers will lower it themselves if needed
<jenatali>
karolherbst: It's unrelated
<consolers>
is this a bug in xorg or mesa or what layer
<jenatali>
If you set that you're using local offsets, then the global ID is always computed from local IDs
<jenatali>
Otherwise the has_cs_global_id not determines whether that happens
<karolherbst>
you mean if I don't set it
<karolherbst>
if I keep has_cs_global_id false, then setting has_base_workgroup_id to true would enable the global_invocation_id/index lowering
<karolherbst>
if I read the code correctly
<jenatali>
It's an or - when local ID offsets are used, it doesn't matter what that field is
<consolers>
or intel
<karolherbst>
jenatali: ohh.. uhhh.. that's bad tho
<jenatali>
Why?
<karolherbst>
why would I want that lowering?
<jenatali>
Because when you run your second dispatch, and use a workgroup ID offset, then you want the global ID to automatically also be offset
<karolherbst>
but that already happens via has_base_global_invocation_id, no?
<jenatali>
I guess you could add the global offsets on the CPU side, sure
<jenatali>
It seemed simpler to just forward through the global offsets from the CL API to that sysval, and then when using local offsets you don't need to touch the global ones again
<karolherbst>
yeah.. I was thinking of just using the API offsets + fixing the workgroup_id
<jenatali>
The kernel just re-computes them
<karolherbst>
the thing is, that I kinda want drivers to use nir_intrinsic_load_global_invocation_id_zero_base when they have it
<karolherbst>
so lowering that unconditionally kinda sounds wrong
<jenatali>
Yeah, that's what I do too (SV_DispatchThreadID), unless you're lowering huge groups
<karolherbst>
I see
frieder has quit [Remote host closed the connection]
<karolherbst>
I think just setting base_global_id and base_workgroup_id is a bit simpler from my perspective here, so I still let drivers do as they please. I might have to look at some of the codegen, but I might also want to set `has_cs_global_id` regardless of the lowering already...
<karolherbst>
mhh...
<jenatali>
If you want to change the semantics there to require the dispatcher to supply local offsets + global offsets, instead of just local and letting the global be computed, I can accommodate that but it is a breaking change
<karolherbst>
I think I'll figure out first how the nir looks like and see what I'll think would be the best here, but I think for some drivers changing the semantics might allow for better code.
<karolherbst>
I'll have to see
<jenatali>
I wasn't terribly worried about the codegen for the case of huge dispatches
<karolherbst>
yeah.. but I'm hitting it with the CTS allone on v3d
<karolherbst>
256 * 65535 is the max thread count on 1D there
<karolherbst>
so I'm constantly hitting it
<jenatali>
Oh, D3D's is at least 1024 * 64K
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<karolherbst>
also.. I currently limit to 32 max threads $because_driver_limitations
<karolherbst>
so 32 * 65535 :)
<karolherbst>
v3d recompiles shaders based on bound textures/samplers/images, so that's kinda pain
<jenatali>
karolherbst: Anyway I'm open to changes here, just let me know if you think they're necessary
<karolherbst>
yeah, thanks :)
<karolherbst>
jenatali: btw.. do you know what applications use SPIR (not SPIR-V)? I might be willing to wire it up if it's important enough (even if only through wine)
<jenatali>
karolherbst: No idea
<jenatali>
I hooked up the compiler side of it but haven't hooked it into the runtime yet
<karolherbst>
ohh
<karolherbst>
I kinda thought you had a real reason to do it
kts has quit [Quit: Leaving]
Duke`` has quit [Ping timeout: 480 seconds]
sghuge_ has left #dri-devel [#dri-devel]
sghuge has joined #dri-devel
lumidify has quit [Quit: leaving]
Duke`` has joined #dri-devel
lumidify has joined #dri-devel
<jenatali>
Nah, just while I was in the area I exposed the methods to start with LLVM IR
<karolherbst>
I see...
consolers has quit [Quit: l8]
Leopold_ has quit [Remote host closed the connection]
glennk has quit [Ping timeout: 480 seconds]
moony has joined #dri-devel
glennk has joined #dri-devel
macromorgan_ has quit []
macromorgan_ has joined #dri-devel
macromorgan_ has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
jsa has quit [Read error: Connection reset by peer]
lynxeye has quit [Quit: Leaving.]
<karolherbst>
jenatali: btw.. any reason for `clc_compile_c_to_spir` to still exist? Could nuke that part at least I think...