ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
eukara has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
cef has joined #dri-devel
ngcortes has joined #dri-devel
khfeng has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
<mareko>
let's clean up dri_interface.h and remove DRI2, we can do it because gbm_dri_device has no backward compatibility whatsoever, so dri_interface.h versioning is only good for drivers that don't use gbm
<mareko>
actually that's not entirely true (only the gbm<->egl interface is unstable), but the gaunglet has been thrown
<airlied>
seems like that might defeat the whole point of doing amber
<mareko>
indeed
<HdkR>
This morning I had a user hit a "dri_create_context: requested glthread but driver is missing backgroundCallable V2 extension" error in mesa which was interesting
<HdkR>
Apparently ChromeOS disables this feature in its DRI implementation or something?
<HdkR>
I'm guessing this is a server side quirk since client side is "regular"?
<mareko>
that's what you get when you or app profiles set mesa_glthread=true, but the EGL backend doesn't support it
ngcortes has quit [Remote host closed the connection]
<mareko>
I'm going to fix that for all egl backends, currently just looking at gbm and shaking my head at no back-compat mechanism
<mareko>
if you mix egl and gbm of different Mesa versions, X won't start, I guess you've noticed that at least once
jewins has joined #dri-devel
<mareko>
there is back-compat only for non-Mesa backends and Mesa doesn't use it
<HdkR>
ah fun
<HdkR>
Smells like ChromeOS is going to cause me issues then
<mareko>
no clue what ChromeOS is doing, I've heard it has minigbm
<HdkR>
Something like that, I'm not familiar with it either
<mareko>
it's a replacement for gbm, it needs to implement the background callable extension to silence that message, which will be shown always after radeonsi enables glthread by default
<HdkR>
Does minigbm even allow glx clients? Otherwise this user is going to have worse issues than just this warning message
<mareko>
no clue, probably not
<HdkR>
Welp, sucks for them :D
ngcortes has joined #dri-devel
pixelcluster has quit [Ping timeout: 480 seconds]
<zmike>
idr: \o/
pixelcluster has joined #dri-devel
<idr>
zmike: Great success!
<zmike>
idr: what do you think about backporting that MR to 22.2 for the release?
<zmike>
I would like to do cts submissions, but I can't use any driver with sparse support if that isn't included
<idr>
zmike: It should probably be safe. I feel a little guilty saying that since any damage it could cause won't affect Iris or ANV.
<idr>
As long as mareko is cool with it.
<zmike>
radeonsi isn't passing cts without it either, so it seems like there's some benefit to be had
stuart has quit []
LexSfX has quit []
LexSfX has joined #dri-devel
idr has quit [Quit: Leaving]
pixelcluster has quit []
pixelcluster has joined #dri-devel
<jenatali>
Hm, is there logic in Mesa that's supposed to prevent one context from being bound to multiple threads
<jenatali>
I'd assumed so, but I think it's probably in the frontends (and missing from wgl)
<airlied>
eglMakeCurrent should have some logic for it
<airlied>
not spotting it though :-P
<jenatali>
Yeah, so in the frontends, makes sense. I was looking at the WGL docs, couldn't find the behavior called out (other than "invalid"). GLX specifically says it should return BadAccess... but there's no hits for BadAccess in the codebase
<airlied>
jenatali: ah _eglCheckMakeCurrent
<airlied>
yeah egl says If context is current to some other thread, or if either draw or read are bound to contexts in another thread, an EGL_BAD_ACCESS error is generated.
<jenatali>
Alright so I'm not crazy then
<jenatali>
(My problem was some other component missing a lock, was just surprised I didn't see an error)
<HdkR>
So happy that `GLX_MESA_multithread_makecurrent` got removed
<jenatali>
HdkR: Removed in spirit, but the validation to follow the original GLX spec wasn't added :P
<HdkR>
oops
heat has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
saurabhg has joined #dri-devel
alanc has quit [Remote host closed the connection]
frytaped has quit [Read error: Connection reset by peer]
Duke`` has joined #dri-devel
frytaped has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
jewins has quit [Read error: Connection reset by peer]
jewins has joined #dri-devel
LexSfX has quit []
jewins has quit [Ping timeout: 480 seconds]
<airlied>
jekstrand: btw seen the turnip issue 7106?
fxkamd has quit []
<airlied>
need to consider how to have userspace manage VAs that are still in use
<daniels>
mareko: yeah your gbm backend & EGL DSOs must be tightly coupled at least in the current implementation. the driver interface just uses DRI as you’ve noted. we could make it not do that but then it gets even more tightly coupled
<HdkR>
Time for an XGBM? :P
frytaped[m] has joined #dri-devel
<daniels>
HdkR: well I mean the libgbm DSO that Mesa ships already multiplexes out to user-installable backends
frytaped has quit [Quit: WeeChat 3.5]
fab has joined #dri-devel
<HdkR>
That's good
Duke`` has quit [Ping timeout: 480 seconds]
<daniels>
doing a quick emergency GitLab upgrade
thellstrom has joined #dri-devel
mvlad has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
danvet has joined #dri-devel
khfeng has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<lygstate>
Any concern to replace all PIPE_OS_* with DETECT_OS_*
<airlied>
bnieuwenhuizen: what does amdgpu do about the va space reuse that 7106 shows for turnip?
<airlied>
I think we should probably have guideliness for drivers to get that right
fab has quit [Quit: fab]
frieder has joined #dri-devel
fab has joined #dri-devel
linkmauve has left #dri-devel [Error from remote client]
saurabhg has quit [Read error: Connection reset by peer]
rcf has quit [Remote host closed the connection]
rcf has joined #dri-devel
saurabhg has joined #dri-devel
linkmauve has joined #dri-devel
rasterman has joined #dri-devel
pcercuei has joined #dri-devel
<MrCooper>
airlied: I'm not sure, but I suspect amdgpu does something similar to what you described for i915
<MrCooper>
I suspect bnieuwenhuizen wants a way to disable that for explicit sync though :)
tomeu5 has quit []
tomeu has joined #dri-devel
hch12907 has quit [Quit: Reconnecting]
hch12907 has joined #dri-devel
hch12907_ has joined #dri-devel
<hch12907_>
anyone opposed to eglinfo showing GL/GLES extensions (along with the renderer, vendor, etc.)? those require creating a context
<hch12907_>
right now, eglinfo shows only info that are strictly related to EGL only, anything else that requires creating a GL/GLES context are ignored
<hch12907>
great, seems like my matrix bridge is working
hch12907_ has quit []
jkrzyszt has joined #dri-devel
lynxeye has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
eukara has quit []
<bnieuwenhuizen>
airlied: currently amdgpu does implicit sync before a VMA unmap of GEM_CLOSE and after a VMA map operation (and because VMA operations are executed on a global timeline that should work)
<bnieuwenhuizen>
airlied: currently amdgpu does implicit sync before a VMA unmap of GEM_CLOSE and after a VMA map operation (and because VMA operations are executed on a global timeline that should work)
<bnieuwenhuizen>
airlied: I'm trying to remove all the implicit sync (or at least the implicit sync wrt userspace submissions), which should work because Vulkan requires all GPU work be executed before the VkMemory gets deleted
frankbinns has joined #dri-devel
ppascher has joined #dri-devel
<airlied>
bnieuwenhuizen: the only prob for vulkan is cleaning up driver internal allocations
<bnieuwenhuizen>
airlied: most of them follow the same rules as external stuff (e.g. because a descriptor pool has the same rules, we automatically get the same behavior for internal memory for descriptor pools)
<bnieuwenhuizen>
only thing is we had to adjust some stuff for e.g. the per-queue rings / scratch buffers that we resize on-demand, the old version needs to be kept around for a bit
zf`_ has joined #dri-devel
zf` has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
rkanwal has joined #dri-devel
rkanwal has quit [Quit: rkanwal]
saurabh_1 has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
frytaped has joined #dri-devel
devilhorns has joined #dri-devel
frytaped has quit [Quit: WeeChat 3.5]
saurabhg has joined #dri-devel
saurabh_1 has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
fahien has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
cengiz_io has joined #dri-devel
heat has joined #dri-devel
Shibe has joined #dri-devel
<Shibe>
Hi, I'm trying to create an EGLSurface from a gbm YUV420 buffer. are there any examples of this?
<Shibe>
is there any way to do this without EGL_EXT_yuv_surface? I'm essentially trying to render an image in OpenGL and feed it to VAAPI, but my AMDGPU only seems to support some YUV formats for VAAPI encoding
<linkmauve>
Shibe, another solution that was used before these extensions was to render to the different planes from OpenGL.
<Shibe>
hmm, how would I bind each plane to an EGLSurface?
devilhorns has quit []
<lygstate>
What's the differencies of pipe_semaphore_init and util_queue_fence_init, can they be merged?
<jenatali>
lygstate: Looks like the pipe semaphore can be deleted in favor of the queue fence. The queue fence has a more efficient futex-based implementation
<jenatali>
Ah wait, no, the semaphore has an int value, the queue fence is just true/false
srslypascal has quit [Ping timeout: 480 seconds]
devilhorns has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
<lygstate>
jenatali: Yep, queue fence more like a binary semaphore
<lygstate>
oh, I am wrong about that, it's different concept
Shibe has quit [Remote host closed the connection]
halves has left #dri-devel [WeeChat 3.6]
fxkamd has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
enick_181 is now known as danylo
JoniSt has joined #dri-devel
srslypascal has joined #dri-devel
devilhorns has quit []
kts has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
alatiera4 has joined #dri-devel
<Ristovski>
anholt: What is one supposed to use to experiment with EU kernels on HSW? `cmrt` is archived now, but I guess it will still work? Or is there some better and newer alternative? (`cmrtlib` from `cm-cpu-emulation` seems to be different and I assume only supports Gen8+, just like oneAPI stuff?)
<Ristovski>
mesa has a i965 dis/assembler (used to compile the iGPU leak mitigations in kernel) too, hmm
alatiera has quit [Ping timeout: 480 seconds]
stuart has joined #dri-devel
<Ristovski>
most importantly, are there /any/ compilers that are open source and support HSW? cm-compiler is Gen9+ :/
Haaninjo has joined #dri-devel
fab has quit [Quit: fab]
khfeng has quit [Remote host closed the connection]
jewins has joined #dri-devel
alatiera4 is now known as alatiera
<jekstrand>
airlied: Oh, well that's fun.
gawin has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<anholt>
Ristovski: I would use mesa to compile shaders. never had a good standalone tool.
<Ristovski>
anholt: I assume libintel_compiler in mesa? (which is used by intel_clc afaik). Would that have similar features to what one can accomplish for cmrt?
<Ristovski>
with cmrt*
<anholt>
I don't know anything about cmrt
<anholt>
when we were doing experiments, we tended to have things like a shader_test that rasterized one pixel and had one channel being an add, then replaced the "add" emit in the compiler with whatever custom code we wanted.
<Ristovski>
I see, hacky :P
<Ristovski>
shame that all this tooling for older gens is going to waste :/ same with intel-hybrid-driver which has some binary media kernels that were never open sourced :(
<robher>
airlied: FYI, your emails are bouncing: <airlied@skynet.ie>: can't create user output file. Command output: /var/log/procmail
fab has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
vs^ has quit [Remote host closed the connection]
saurabhg has joined #dri-devel
kathleen____ has quit []
kathleen has joined #dri-devel
gawin has joined #dri-devel
galston has quit [Quit: Leaving]
LexSfX has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
fxkamd has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
fxkamd has quit []
lkw has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
mattst88 has quit [Read error: Connection reset by peer]
mattst88 has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
Dr_Who has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
gawin has quit [Quit: Konversation terminated!]
gouchi has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
ybogdano has joined #dri-devel
Company has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<jenatali>
Hm... if I have an app that tries to use GLES1 entrypoints on desktop GL... would folks be amenable to a driconf (or similar) option to not filter the entrypoint table based on API version?
thellstrom has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
lkw has quit [Quit: leaving]
mbrost has joined #dri-devel
ybogdano has joined #dri-devel
<JoniSt>
If anyone wants to take another look at it: MR 17338 (TC multicontext fix) might need another review or two and should then be ready for merging :)
lkw has joined #dri-devel
nchery has joined #dri-devel
<cwabbott>
does anyone know what the interaction of graphics pipeline libraries and dynamic states is supposed to be? does the library's list of dynamic state have to match the pipeline's, or does it only have to match for the state subset defined by the library, or are we supposed to stitch together the lists from the libraries, or...
cheako has quit [Quit: Connection closed for inactivity]
idr has joined #dri-devel
<zmike>
cwabbott: it's combined
<zmike>
each dynamic state corresponds to various gpl stages
sdutt has quit [Read error: Connection reset by peer]
<zmike>
mareko: do you have any objection to backporting the sparse texture fixup MR for 22.2?
<mareko>
no
<zmike>
great
<zmike>
dcbaker: I'm gonna push some patches to staging
<zmike>
pushed
iive has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
<jekstrand>
cwabbott: The dynamic states relevant to the bits of state in the pipeline library go in that pipeline library
<jekstrand>
cwabbott: If you want to emit state directly in pipeline libraries, you only have to look at the dynamic state set when that pipeline library is created.
<anholt>
jekstrand: how hard do you think it would be to do a pass to lower mediump variable accesses so that the mediump parts were 16-bit and f2fmp/i2imped on store and 2x32'ed on load?
<anholt>
We've got !18100, but actually I think we want to do this to shared vars, temps that will be moved to scratch instead of vars-to-ssaed, etc.
<jekstrand>
anholt: Should be tractable.
<jekstrand>
anholt: Well... Hrm.
<jekstrand>
I'm trying to remember where RelaxedPrecision goes in SPIR-V
<jekstrand>
Looks like it can go on variables
<anholt>
we've got RP hooked up to making the vars mediump already.
<jekstrand>
Should be tractable. The thing you'll have to look out for is if you ever hit a deref cast.
<jekstrand>
Shouldn't ever happen on function/shader_temp. I don't think it can happen on shared, either.
<jekstrand>
But it can on SSBOs, so you just need to make sure your pass doesn't blow up if it sees one.
<jekstrand>
If you keep it to entirely internal things, I think you should be ok
danvet has quit [Ping timeout: 480 seconds]
<jekstrand>
(i.e. local/global/shared
<anholt>
yeah, local and shared are the modes I'm concerned about right now.
<anholt>
a little concerned about trying to keep the deref types updated as I go.
<jekstrand>
We have a nir_fixup_deref_modes() but no nir_fixup_deref_types(). We should write one. :)
<jekstrand>
There's a couple other places it's useful.