tarceri_ has quit [Remote host closed the connection]
oneforall2 has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
tarceri has joined #dri-devel
aravind has joined #dri-devel
Danct12 has quit [Quit: Quitting]
tarceri has quit [Read error: Connection reset by peer]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #dri-devel
pnowack has joined #dri-devel
Lucretia has joined #dri-devel
unsolo_ has quit [Ping timeout: 480 seconds]
vivijim has joined #dri-devel
<mslusarz>
karolherbst: definitely not me and I don't know who started it
lplc has quit [Remote host closed the connection]
iive has joined #dri-devel
egbert has quit [Ping timeout: 480 seconds]
unsolo has joined #dri-devel
mclasen has joined #dri-devel
camus has joined #dri-devel
flacks has quit [Quit: Quitter]
camus1 has quit [Ping timeout: 480 seconds]
flacks has joined #dri-devel
itoral has quit []
tarceri has joined #dri-devel
Hi-Angel has joined #dri-devel
joe_ has joined #dri-devel
lplc has joined #dri-devel
joe_ has quit [Remote host closed the connection]
camus1 has joined #dri-devel
<karolherbst>
mslusarz: huh...
<karolherbst>
strange
<karolherbst>
then I have no idea who it can be
camus has quit [Read error: Connection reset by peer]
<karolherbst>
all I know is that the first commit is from poland according to the reverse DNS lookup address
j0 has joined #dri-devel
<j0>
Is VK_KHR_synchronization2 supported by radv? The extension is not present on my Vega 10 GPU
<pendingchaos>
not yet
unsolo has quit [Ping timeout: 480 seconds]
Lucretia has quit []
<j0>
thanks
Company has joined #dri-devel
Lucretia has joined #dri-devel
rgallaispou has joined #dri-devel
alatiera57 has joined #dri-devel
unsolo has joined #dri-devel
alatiera5 has quit [Ping timeout: 480 seconds]
j0 has quit [Quit: Leaving]
Danct12 has joined #dri-devel
Net147 has quit [Quit: Quit]
tonyk has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
Net147 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
sdutt has joined #dri-devel
ppascher has joined #dri-devel
fxkamd has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
dongwonk has quit [Ping timeout: 480 seconds]
elongbug has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
fxkamd has quit []
nchery has joined #dri-devel
Duke`` has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
go4godvin is now known as frytaped
<jekstrand>
alyssa, bnieuwenhuizen, other NIR types: Any opinions on how we should represent a store_global that we want do do a write, even if it's in a helper invocation?
<jekstrand>
pendingchaos, anholt: ^^
<jekstrand>
We need it for VK_KHR_ray_query because the way we communicate with the ray-tracing HW is via global memory writes and the ones to set up the query need to happen even in helpers.
<jekstrand>
I'm contemplating adding an ACCESS_* flag for it. Not sure if I think that's a total hack or not.
<dj-death>
jekstrand: another index on the intrinsic?
<dj-death>
ah yeah access would be nicer I guess
<jekstrand>
Access would be the least invasive option
<jekstrand>
I'm just not sure what we'd want to call the flag or what we'd want its semantics to be
<jekstrand>
If we did add an access flag, I'd want nir_lower_io to mark scratch that way too
<jekstrand>
I'm just not sure what we'd name it and if the flag should mean "write regardless of helpers" or if it should mean "disable in helper invocations".
<pendingchaos>
I think an access flag sounds fine to me
<pendingchaos>
ACCESS_INCLUDE_HELPERS?
<pendingchaos>
another index sounds like more effort
<dj-death>
yep
<jekstrand>
ACCESS_INCLUDE_HELPERS or ACCESS_DISABLE_IN_HELPERS?
<jekstrand>
I think we could go either way without causing a problem.
<jekstrand>
It's just a bit of typeing in glsl_to_nir and spirv_to_nir to add `DISABLE_IN_HELPERS` whenever we're in a fragment shader.
aravind has quit [Ping timeout: 480 seconds]
<jekstrand>
ACCESS_EXCLUDE_HELPERS?
<cmarcelo>
jekstrand: why default the "include helpers" behavior and not the other way around?
<jekstrand>
cmarcelo: disabling for helpers feels like the exceptional case to me
<jekstrand>
For one, it only applies to fragment shaders
<jekstrand>
it's also the one that requires additional work in the back-end
<jekstrand>
But I could probably be convinced to go the other way
<karolherbst>
okay... I think I need a complete other approach for automating those annoying things with MRs...
<dj-death>
jekstrand: kind of curious about why you mentioned scratch
<dj-death>
oh... we would just plumb it into SURFACE_LOGICAL_SRC_ALLOW_SAMPLE_MASK
<jekstrand>
dj-death: We currently special-case load/store_scratch in brw_fs_nir.cpp to not do the predicate
<jekstrand>
dj-death: Yup
<dj-death>
we could assert on it and that would give use some coverage of the NIR lowering :)
<dj-death>
s/use/us/
<jekstrand>
it would
<karolherbst>
daniels: are you familiar with gitlab bots?
<karolherbst>
kind of search for something you can instruct to do things, like "@bot sob" and it would start adding tags to the commits or something..
<karolherbst>
or maybe we should really just script it with dim :/
<karolherbst>
dim annotate-mr ...
<karolherbst>
and it would just fetch the commits, add tags and repush
<karolherbst>
and then use marge-bot without touching the commits at all
dongwonk has joined #dri-devel
<karolherbst>
danvet, airlied: any opinions on that? I kind of come to the conclusion, that bots can't really do what we need, because you can't know what tags you need to remove once marge fails and you retry (e.g. a different person retries)
<karolherbst>
so I am thinking about something more explicit
<Lyude>
did they somehow rename that to coding instead of encoding like they did with link_coding_cap
<pinchartl>
airlied: I've CC'ed you on a trivial 4CC addition patch, not for the 4CC itself, but because it's a format that isn't used by any DRM/KMS kernel driver at this point. it's needed by userspace only, in libcamera, as we use the DRM/KMS 4CCs to avoid creating yet another set of 4CCs
<pinchartl>
I don't want to sneak this in without an approval of the rationale
<airlied>
Lyude: oh didn't get agd5f patch in that
<airlied>
just different parallel compile path led to warning
<Lyude>
oooh, gotcha
<Lyude>
yeah it seems to compile without warnings when I disable DCN here (using an x86_64 config)
Kayden has quit [Ping timeout: 480 seconds]
<Lyude>
airlied: just resolving a conflict on drm-tip now