ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
heat has joined #dri-devel
co1umbarius has joined #dri-devel
<karolherbst>
I can finally wire up proper nir_validate support in rusticl, but that also requires me to bump to meson 1.2.. oh well.. need it for some of the external crate support anyway.
<karolherbst>
dcbaker: how much of that already works btw?
columbarius has quit [Ping timeout: 480 seconds]
<dcbaker>
karolherbst: all that landed for 1.2 was the core classes and functions unfortunately :/
<karolherbst>
ahh... so I guess proper crate.io support might come in 1.3?
<maxv>
Hi. If I export gbm_bo, is it safe to immediately call gbm_bo_destroy, or should I keep it around while the buffer is used by another process?
<emersion>
you can destroy the bo immediately
<MrCooper>
maxv: export to dma-buf fd, or to KMS handle?
<maxv>
emerson: great, thanks
<maxv>
MrCooper: dma-buf
<MrCooper>
then yes, the dma-buf fd keeps the underlying kernel BO alive (a KMS handle wouldn't though)
yyds has quit [Remote host closed the connection]
donaldrobson has quit [Remote host closed the connection]
<emersion>
MrCooper: a KMS FB would i believe?
<MrCooper>
yeah, I think so
<emersion>
did you mean "GEM handle" instead of "KMS handle"?
<emersion>
and i believe a GEM handle would retain a ref as well
<emersion>
(modulo the GEM_CLOSE weirdness)
<MrCooper>
indeed I did, used the Mesa radeonsi terminology
<MrCooper>
gbm_bo_get_handle may (or may not) return the same GEM handle used by GBM itself, in which case destroying the gbm_bo may destroy the kernel BO and invalidate the GEM handle
<MrCooper>
so a GEM handle cannot be relied on for keeping the BO alive
<eric_engestrom>
DavidHeidelberg[m]: I was off yesterday, I hadn't seen your comment yet; IMO stable branches should get `sed /'compare_to: main'/d` since they don't get any benefit from not using the previous push's state, and there is a downside to specifying anything, since I see 3 possibilities: 1) you leave `main` and you get a completely wrong pipeline, 2) you set `XX.Y-branchpoint` and you get a pipeline with everything that has
<eric_engestrom>
ever changed in the stable branch, or 3) you set it to `staging/XX.Y` and you get the same pipeline as if you hadn't specified anything while working on a release, and when making a release you get a completely wrong pipeline
<eric_engestrom>
IMO it would be good to have this doc update in the same commit
<maxv>
One more question: do I understand correctly that in order to resize an EGLSurface created from gbm_surface, I need to release current EGL context, destroy EGLSurface and gbm_surface, and create new GBM/EGL surfaces with the new size? And why isn't there a resizing mechanism for gbm_surface?
<zamundaaa[m]>
Of what use would a resizing mechanism be? The surface doesn't matter, KMS only works with buffers
<maxv>
In particular I'm implementing a wayland client and currently I create an EGLImage from gbm_bo and set it as a gl renderbuffer storage. I know that EGLSurface can be created for native wl_surface, but I'm experimenting with other wayland libraries.
kts has joined #dri-devel
<DavidHeidelberg[m]>
eric_engestrom: can it look like I wrote it? This part doc isn't my strong side :P
<eric_engestrom>
haha, I was just looking at your new push
<eric_engestrom>
I can't parse the first half of your message though?
<eric_engestrom>
(the "can it look like I wrote it?")
xantoz has quit [Remote host closed the connection]
sravn has quit [Read error: Connection reset by peer]
cmichael has joined #dri-devel
godvino has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
godvino has quit [Quit: WeeChat 3.6]
itoral has quit [Remote host closed the connection]
smiles_1111 has joined #dri-devel
smilessh has joined #dri-devel
smiles_1111 has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
godvino has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
<zmike>
DavidHeidelberg[m]: have you had any time to make progress on splitting the CI CTS updates for GL versions?
<DavidHeidelberg[m]>
zmike: I'm working on doing viable package for it, so I guess it counts as yes? :D (not progressed much yet)
<zmike>
🤝
frieder has joined #dri-devel
Company has joined #dri-devel
Duke` has quit [Ping timeout: 480 seconds]
xantoz has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
<dj-death>
someone knows of a pass that would eliminate a pattern like a temporary variable stored with a value from a ubo and then read back in the next block ?
<dj-death>
when the variable could be completely removed and just the load_ubo replacing the temporary variable read
<pendingchaos>
temporaries shouldn't be in nir_var_read_only_modes
godvino has quit [Ping timeout: 480 seconds]
godvino has joined #dri-devel
<dj-death>
pendingchaos: maybe my case is too complex then
<dj-death>
pendingchaos: it's a vec2[24] loaded with a bunch of vec2 sequentially from a UBO (like memcpy exactly) and then there is an indirect indexing in the temporary array
<dj-death>
pendingchaos: do you happen to know if this pass can deal with that?
lemonzest has quit [Quit: WeeChat 3.6]
<pendingchaos>
I don't think it can
<pendingchaos>
maybe if the copy was done with a copy_deref intrinsic?
<pendingchaos>
would probably also remove the need for nir_opt_sink
Leopold has joined #dri-devel
lemonzest has joined #dri-devel
cmichael has quit [Quit: Leaving]
cmichael has joined #dri-devel
yyds has joined #dri-devel
<dj-death>
pendingchaos: ah damn, this is not a contiguous UBO array unfortunately
<maxv>
Do you think implementing gbm_surface_resize is desirable? I think it should be pretty easy and I probably can do it, but I'm not sure if something like this would be accepted.
kzd has joined #dri-devel
<emersion>
is it cumbersome to destroy and recreate?
<emersion>
because that's exactly what happens when a surface is "resized" AFAIK
<alyssa>
gfxstrand: !24326 is teaching me about the limits of gitlab
<gfxstrand>
alyssa: Well, yes. Someone's got to stress-test the system. :joy:
godvino1 has joined #dri-devel
<maxv>
emersion: It kinda is. When resize happens some buffers are locked and wait for a release event. gbm_surface_destroy docs say that all buffers need to be released and EGLSurface destroyed before calling it. This leads to a state when multiple (maybe even more than two) surfaces must exist at the same time, which is awkward.
godvino has quit [Ping timeout: 480 seconds]
<maxv>
The context switch also seems unnecessary
<alyssa>
gfxstrand: do they? my 1-line NIR patches usually stress the system just fine ;~P
<dj-death>
pendingchaos: would you happen to know what would vectorize scratch load/stores? :)
Duke`` has joined #dri-devel
<alyssa>
dj-death: i/o vectorizer can't do it?
<alyssa>
er
<alyssa>
load/store vectorizer
<alyssa>
nir_opt_load_store_vectorize.c
<pendingchaos>
the load/store vectorizer could probably be made to do that, if they aren't derefs
<pendingchaos>
before deref lowering, nir_opt_combine_stores/nir_opt_cse is part of a solution
<alyssa>
i guess that doesn't do scratch
<alyssa>
that thing scares me ngl
<pendingchaos>
I think that was because AMD hardware doesn't benefit from vectorizing scratch access
<pendingchaos>
but I don't think that's actually true, so I'm not sure why it doesn't do scratch
* alyssa
needs to setup load/store vectorizing on agx, we'd benefit
<alyssa>
(and I'm working on a lowering pass that emits piles of scalar stores in a row that are just begging to be vectorized. not trivial to emit them as vector, loop unrolling happens in the middle)
<dj-death>
also _nir_shader_variable_has_mode asserts on temp
<dj-death>
but anyway I probably want to find some other trick
<dj-death>
maybe promote those UBO loads to shared memory
<dj-death>
ah but no, it's not going work for FS :/
<dj-death>
pendingchaos: will you send a fix for the lower_shader_calls ?
<dj-death>
pendingchaos: I can Rb
<pendingchaos>
the "resume_shaders[i]" thing?
<pendingchaos>
I don't have any way to test that it does anything, at the moment
<pendingchaos>
If I'm reading stuff right, RADV doesn't use this load/store vectorizer yet
<pendingchaos>
if I get it working, I guess I can make a fix
<dj-death>
ah... store_scratch is not marked a reorderable
<dj-death>
nor store_deref apparently
rasterman has quit [Quit: Gettin' stinky!]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
<alyssa>
dj-death: can't move stores across loads
<alyssa>
CAN_REORDER is a pretty blunt flag
maxv has quit [Remote host closed the connection]
<anholt>
daniels: do you have some time to actually do dri image format #define collapsing?
<dj-death>
alyssa: I meant just move then before the loads
<dj-death>
alyssa: in the same if block
<dj-death>
alyssa: avoiding a bunch of writes if it's not going to be used
<cwabbott>
dj-death: you can't sink stores into an if except if you know that the store won't be used after the if
<cwabbott>
I don't think we have anything ATM that can do that type of analysis
<cwabbott>
it would probably have to use derefs in order to know what could potentially be a use
mvlad has quit [Remote host closed the connection]
tursulin has quit [Ping timeout: 480 seconds]
tango_ has joined #dri-devel
<dj-death>
cwabbott: yeah, the shader I'm looking at has that one temporary variable written entirely just before an if block that will read from it
<daniels>
anholt: I think it's going to become ~necessary, so yeah
<anholt>
daniels: looks like the #defines aren't abi any more, which is great.
<anholt>
I think we can #define them to PIPE_FORMATs then just start deleting no-op code.
<daniels>
anholt: you mean __DRI_IMAGE_FORMAT?
<anholt>
yeah
junaid has joined #dri-devel
junaid has quit []
<daniels>
anholt: ok, neat - I guess pull that up to src/util/, then into a table which adds canonical conversions to at least DRM_FORMAT as well as sizes/shifts, then start pulling all the hand-rolled conversions?
<anholt>
daniels: I was thinking that basically once you #define to PIPE_FORMAT/MESA_FORMAT in the header, one could start just collapsing the lookup tables translating between them. and then, you can probably delete the shifts/offsets from those tables since you should be able to get them from the format descriptions.
<anholt>
not sure we need to build a new thing first
<alyssa>
it's enunes' code, just split off from the draft MR
<anarsoul>
hmm, I thought that enunes is working on it
<anarsoul>
sure, let me take a look
<alyssa>
the draft MR has ppir working and gpir not working
<alyssa>
I split off just the ppir commit so that can land now, while gpir gets sorted
<airlied>
alyssa: where else would it be? probably has more users than panfrost :-P
<alyssa>
airlied: good point, let's kick out panfrost too ;~P
<airlied>
like why is anything in tree? let's just kick it all out to other trees
<alyssa>
ambitious!
<alyssa>
=D
<anarsoul>
alyssa: It's quite a change, I'll take a look later tonight, I made a note for myself
<alyssa>
anarsoul: thanks!
frankbinns has quit [Remote host closed the connection]
<alyssa>
(enunes wrote it and says deqp is happy, and I reviewed it with my NIR hat on and I'm happy, I just don't want to randomly merge it without an ack since I pulled it off a draft MR)
<anarsoul>
why not to ask for enunes' ack then? :)
<alyssa>
I would also accept that ;~P
enunes[m] has joined #dri-devel
<enunes[m]>
alyssa: anarsoul: I'll get back to that in the next days, unfortunately didnt have much time to followup on it since the weekend
<alyssa>
enunes[m]: thanks :) can I land the ppir commit now though?
jkrzyszt_ has joined #dri-devel
<alyssa>
(would let me busy myself deleting abs/neg/sat)
<anarsoul>
enunes[m]: btw, are there any functional changes? or differences in shader-db?
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<enunes[m]>
as far as I could tell no changes in deqp or piglit for that patch, CI should confirm that, but shaderdb takes a hit
<enunes[m]>
minor things can be improved on that patch like the remaining is_ssa and removing reg_base, but I don't necessarily object going with it now if it helps unblock work...
<enunes[m]>
if anarsoul is ok with it merge it :)
<anarsoul>
can I see shader-db diff first?
Leopold has quit [Remote host closed the connection]
Leopold has joined #dri-devel
<enunes[m]>
I don't have it at hand now
ngcortes has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
bnieuwenhuizen_ has quit []
bnieuwenhuizen has joined #dri-devel
<Kayden>
zmike: thanks for the heads up, testing a tidied iris patch now
<zmike>
I've been pinging for two weeks and I'll probably need to ping for another two before it has a chance of landing