ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
icecream95 has joined #dri-devel
pixelcluster has quit [Quit: Konversation terminated!]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
eukara_ has joined #dri-devel
eukara has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
tarceri_ has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
Daanct12 has joined #dri-devel
heat_ has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
eukara__ has joined #dri-devel
eukara_ has quit [Read error: Connection reset by peer]
nvishwa1 has joined #dri-devel
slattann has joined #dri-devel
bmodem has joined #dri-devel
jvesely has joined #dri-devel
jvesely has quit [Read error: Connection reset by peer]
lemonzest has joined #dri-devel
mbrost has joined #dri-devel
anholt has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
<dj-death>
haasn: thanks a lot
Duke`` has joined #dri-devel
srslypascal has joined #dri-devel
Company has quit [Quit: Leaving]
Arsen has quit [Ping timeout: 480 seconds]
Arsen has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
lplc has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
mszyprow has joined #dri-devel
lplc has joined #dri-devel
aravind has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
tzimmermann has joined #dri-devel
srslypascal is now known as Guest1920
srslypascal has joined #dri-devel
Guest1920 has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
wv has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
jagan_ has joined #dri-devel
itoral_ has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
itoral__ has joined #dri-devel
frieder has joined #dri-devel
jkrzyszt has joined #dri-devel
itoral_ has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
saurabhg has joined #dri-devel
thellstrom has joined #dri-devel
frieder has joined #dri-devel
nvishwa1_ has joined #dri-devel
mbrost_ has quit [Read error: Connection reset by peer]
ahajda has joined #dri-devel
jfalempe has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
nvishwa1 has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
shankaru has joined #dri-devel
guru_ has joined #dri-devel
srslypascal is now known as Guest1928
srslypascal has joined #dri-devel
Guest1928 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
oneforall2 has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
bmodem1 has joined #dri-devel
heat_ has joined #dri-devel
pcercuei has joined #dri-devel
rasterman has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
guru_ has quit []
oneforall2 has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
Ella[m] has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
pixelcluster has joined #dri-devel
alarumbe has quit [Ping timeout: 480 seconds]
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
nvishwa1_ has quit [Ping timeout: 480 seconds]
saurabhg has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
chaim has joined #dri-devel
kj has joined #dri-devel
<marex>
ahajda: robclark: would it be OK to pull this https://patchwork.freedesktop.org/patch/489203/ in via drm-misc-next ? I messed up with previous patch, so that should be the fix for error reported by LKP
thellstrom has quit [Quit: thellstrom]
srslypascal has quit [Remote host closed the connection]
elongbug has joined #dri-devel
srslypascal has joined #dri-devel
z-s-e has joined #dri-devel
alarumbe has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
vliaskov has joined #dri-devel
flacks has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
<apinheiro>
jekstrand, how crazy would be to add a nir_opt_find_array_copies_run on shader_info (like already existing divergence_analysis_run)
<apinheiro>
and use it instead of passing allow_copies to any nir optimize method?
jagan_ has quit [Remote host closed the connection]
Daanct12 has quit [Quit: Leaving]
ramaling has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
srslypascal has joined #dri-devel
Surkow has quit [Ping timeout: 480 seconds]
saurabh_1 has joined #dri-devel
MajorBiscuit has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
saurabh_1 has quit [Remote host closed the connection]
Company has joined #dri-devel
Surkow|laptop has joined #dri-devel
shankaru has quit [Quit: Leaving.]
<LaserEyess>
zink-only openGL seems to be going well, some issues with firefox but otherwise it does indeed Just Werk™
<LaserEyess>
compiling with zink only didn't allow vaapi and some other stuff I sort of wanted to I only compiled the bare minimum of gallium drivers and forced zink with GALLIUM_DRIVER
<zmike>
GALLIUM_DRIVER doesn't affect zink unless you're on Windows though 🤔
<kisak>
this morning I thought, "Boy howdy, I sure am glad that cgit.fd.o is still up"
<LaserEyess>
zmike: oops I'm using radeonsi then
<LaserEyess>
zmike: is there no way to force zink then? I can't compile mesa without at least one other gallium driver for vaapi support and I think some other things I didn't want to touch
<zmike>
MESA_LOADER_DRIVER_OVERRIDE=zink
<zmike>
zink doesn't work for vaapi, so there's not much point building it
<LaserEyess>
I use vaapi with vulkan though, via mpv
itoral_ has joined #dri-devel
itoral__ has quit [Read error: Connection reset by peer]
itoral_ has quit [Remote host closed the connection]
<MrCooper>
LaserEyess: zink doesn't provide a VA-API driver, only radeonsi does
fcarrijo has joined #dri-devel
<LaserEyess>
yes I understand, hence I compiled with both zink and radeonsi
<LaserEyess>
but mpv has the ability to use vaapi with vulkan, I don't know if it secretly uses openGL for the vaapi parts under the hood, but the rendering part is certainly vulkan on mpv's side
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<MrCooper>
in which case VA-API uses radeonsi internally, zink isn't in the picture
<LaserEyess>
that's fine I guess, it's not really important as long as the other rendering is zink for openGL stuff
<LaserEyess>
my only question would be, considering something like firefox, if it's using vaapi acceleration for e.g. youtube but I have forced zink via an env, will it ignore that and use radeonsi instead for rendering?
<MrCooper>
it'll use radeonsi for VA-API API calls and zink for OpenGL
<MrCooper>
I suspect some OpenGL will always be involved even for video playback
<LaserEyess>
well, there's a solution for that on the horizon I guess
saurabhg has joined #dri-devel
<LaserEyess>
but I'm not testing vaapi stuff, I'm testing rendering so if that's still zink it's fine
<MrCooper>
I mean even while using VA-API for decoding
<jekstrand>
apinheiro: Why? AFAICT, the only reason for the divergence analysis one is to know whether or not to print the little "con" and "div" tags. What are you thinking find_array_copies_run would be used for?
<LaserEyess>
MrCooper: I know, the "solution on the horizon" I meant was vulkan video acceleration, the horizon being pretty far away
<apinheiro>
jekstrand, well, not nothing else
<apinheiro>
that was my point
<LaserEyess>
but if I can only test "removing openGL" for rendering that's good enough
<apinheiro>
so just store on shader_info that it was just run
<apinheiro>
as it is assumed to be run just once
<apinheiro>
and not need to pass allow_copies when calling it
<apinheiro>
just check shader_info
<apinheiro>
in any case, not a big improvement, just wondering as radv, brw, and v3dv have a equivalent nir_optimize method, that requires to pass allow_copies
<apinheiro>
as a parameter
<apinheiro>
just to know that find_array should only be called once
<apinheiro>
hmm, well, although I guess that one could say that keeping a tracking variable on shader_info is worse than that
<MrCooper>
LaserEyess: I think I get what you mean, but FYI, "rendering" in your questions is ambiguous — VA-API decoding could also be considered "rendering"
<LaserEyess>
hence the quotes, I get what you're saying too, but my goal is "can I use zink as a daily driver and have everything Just Werk™", it would be nice to completely remove all other openGL drivers from my system but I can't without breaking functionality I use
<LaserEyess>
so oh well
<jekstrand>
apinheiro: It has less to do with whether or not find_array_copies has been run as with whether or not it's allowed.
mclasen has joined #dri-devel
<jekstrand>
apinheiro: After we've called nir_lower_var_copies, we don't want to run passes which may add copies.
<MrCooper>
LaserEyess: you can rm radeonsi_dri.so
<LaserEyess>
would that break vaapi?
<MrCooper>
nope
<jekstrand>
apinheiro: brw_nir_optimize() gets called several times and it's only called with allow_copies = false once at the end after we've lowered copies away.
<LaserEyess>
hmm
<LaserEyess>
how does that work?
<LaserEyess>
why won't it compile without radeonsi being enabled then?
<MrCooper>
radeonsi_drv_video.so is the VA-API driver
camus has quit []
<LaserEyess>
and it uses nothing from radeonsi?
<MrCooper>
LaserEyess: because Mesa's meson build system hasn't been tailoured to meet your particular need yet ;)
<MrCooper>
it has radeonsi in the name...
<MrCooper>
radeonsi is a Gallium driver, Gallium sits below OpenGL / VA-API / ...
<LaserEyess>
hmmm
<LaserEyess>
I guess I don't know much about how meson works internally
<LaserEyess>
uhhh, mesa*
<apinheiro>
> apinheiro: brw_nir_optimize() gets called several times and it's only called with allow_copies = false once at the end after we've lowered copies away.
<apinheiro>
jekstrand, well, as far as I see
<apinheiro>
it is called several times with allow_copies as false
<apinheiro>
like for example on brw_postprocess_nir or brw_link_shaders
<MrCooper>
LaserEyess: zink is also a Gallium driver, but it doesn't support the VA-API frontend (yet?), so there's no zink_drv_video.so
<apinheiro>
so it is basically a first call with allow_copies to true, and any other call to false
<apinheiro>
so that's the reason I though on just track if the lowering was call or not
<apinheiro>
in any case, this was a really small thing,
<LaserEyess>
MrCooper: yes, that in particular I didn't know how it worked, but what you're saying makes sense
<apinheiro>
as it is, is fine
<LaserEyess>
I could simply not install the radeonsi_dri.so file, too
<apinheiro>
sorry for the noise
mbrost has joined #dri-devel
<jekstrand>
apinheiro: Hrm... Looks like you're right. We're getting rid of copies earlier than I thought.
<jekstrand>
apinheiro: If we wanted to track something, we'd want to track whether or not nir_lower_var_copies has been called.
<jekstrand>
And then maybe add something to the validator to ensure no new ones get inserted.
akselmo has joined #dri-devel
oneforall2 has quit [Read error: No route to host]
oneforall2 has joined #dri-devel
pjakobsson_ has joined #dri-devel
pjakobsson has quit [Ping timeout: 480 seconds]
<apinheiro>
jekstrand, ok, makes sense, will think about that
<apinheiro>
and perhaps include on what Im doing now
<apinheiro>
thanks for the chat and the advice
<jekstrand>
yw. Always happy to help!
shankaru has joined #dri-devel
mclasen has quit [Remote host closed the connection]
apinheiro has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
<robclark>
marex, ahajda: ok by me
mattst88 has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<marex>
robclark: thanks and sorry for the mess
<daniels>
gitlab is back
<daniels>
enjoy
<robclark>
marex: no worries
<robclark>
daniels: \o/
<daniels>
bentiss ftw
saurabh_1 has joined #dri-devel
<zmike>
heroic
Haaninjo has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
mattst88 has joined #dri-devel
z-s-e has quit []
sdutt has quit []
sdutt has joined #dri-devel
saurabh_1 has quit [Ping timeout: 480 seconds]
nvishwa1 has joined #dri-devel
nchery has joined #dri-devel
fcarrijo has quit []
i-garrison has quit [Read error: Connection reset by peer]
pixelcluster has quit [Read error: Connection reset by peer]
i-garrison has joined #dri-devel
frieder has quit [Remote host closed the connection]
JoniSt has joined #dri-devel
Duke`` has joined #dri-devel
saurabhg has joined #dri-devel
shankaru has quit [Quit: Leaving.]
wv has quit [Ping timeout: 480 seconds]
slattann has quit []
saurabh_1 has joined #dri-devel
tobiasjakobi has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
tobiasjakobi has quit []
<haasn>
I have a system with both nouveau and intel drivers on it, but `eglCreateContext` just gets me the nouveau driver, not intel - is there some kind of env var I can choose to force it to use intel?
mclasen has quit []
mclasen has joined #dri-devel
<emersion>
DRI_PRIME
saurabh_1 has quit [Ping timeout: 480 seconds]
<haasn>
doesn't work, note this is a headless system with no X running
<haasn>
What works is creating a new directory `/tmp/dri`, symlinking the driver I want to it, and then setting LIBGL_DRIVERS_PATH=/tmp/dri
shankaru has joined #dri-devel
<haasn>
but this is a complete hack
<haasn>
What I want is something like LIBGL_DRI_DRIVER=iris
ybogdano has joined #dri-devel
<haasn>
Setting LIBGL_DRIVERS_PATH to the .so I want directly doesn't work either :(
<haasn>
all the calls up to this point seemed to work fine
<haasn>
Why is it suddenly glDisableVertexAttribArray that requires libGLESv2.so.2?
mszyprow has quit [Ping timeout: 480 seconds]
zf_ has joined #dri-devel
zf has quit [Read error: Connection reset by peer]
ybogdano has quit [Ping timeout: 480 seconds]
heat_ has quit [Ping timeout: 480 seconds]
srslypascal has quit [Quit: Leaving]
ybogdano has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<linkmauve>
haasn, this symbol became core in either GL 2.0 or GLES 2.0, are you sure you didn’t explicitly request an ES context?
<haasn>
I did explicitly request an ES context
<haasn>
I'm more surprised about it giving me the context and getting that far before aborting() on some random call
<haasn>
if libGLES are missing
<linkmauve>
Hmm, is the library not available on your system?
oneforall2 has quit [Remote host closed the connection]
<haasn>
I guess what happened is, libepoxy already had those symbols cached from the GL context I was using before the ES context
<haasn>
Everything except glDisableVertexAttribArray (because it was using VAOs for GL)
oneforall2 has joined #dri-devel
<haasn>
So bizarre
<linkmauve>
haasn, for your first issue, instead of eglCreateContext() you could use the EGL_EXT_platform_device/EGL_EXT_device_base/EGL_EXT_device_enumeration/EGL_EXT_device_query set of extensions, to select the device you want.
<haasn>
that sounds like a decent thing to be doing in the libplacebo test framework this issue concerns
<linkmauve>
haasn, glDisableVertexAttribArray() is about vertex attributes, not VAOs.
<linkmauve>
haasn, you can use eglinfo in order to test this set of extensions, here it lets me choose between iris, radeonsi, and swrast.
<linkmauve>
To test it on your system, and to get a code sample.
<haasn>
this container doesn't even have eglinfo installed :p
<haasn>
it's fine, I think I tracked down the root cause of the problem already
<haasn>
I was just wondering why it was failing in this random way and now I know
<linkmauve>
What was it?
<linkmauve>
But yeah, it’s unlikely a random container will have mesa-utils installed.
<haasn>
libGLESv2.so not being installed on the system, plus the weirdly specific way in which libepoxy doesn't retroactively delete procaddr pointers if you go through multiple API versions on the same process
<haasn>
So it was creating a GLES context successfully even though libGLESv2 was not installed, because it still had all the necessary pointers cached from libGL
<haasn>
Until it hit glDisableVertexAttribArray which is the only call that i _only_ need on GLES (because, again, no VAOs)
<ajax>
haasn: ... oh god i never thought of that
<haasn>
So it segfaults here because it can't actually load any GLES function pointers
<haasn>
Hilarious
<linkmauve>
Oh wow.
<haasn>
I should probably run the opengl test process multiple times :)
<ajax>
i'm starting to suspect glad might be a better approach than epoxy
<haasn>
Entirely possible
<ajax>
for, like, everything.
<haasn>
I think libplacebo's codebase is stable to the point where we might just write our own function dispatch table already, too
<haasn>
Heh, glad seems interesting. Although in this case I can assume the user is in charge of giving me a glGetProcAddr* pointer instead of loading it from dlsym et. manually
<linkmauve>
eglGetProcAddr() will only work for core functions if the EGL version is 1.5 or if EGL_KHR_client_get_all_proc_addresses is exposed, though.
<haasn>
so shoves the responsibility onto the user :)
<ajax>
linkmauve: i wouldn't worry too much about that? mesa's supported the latter for about eight years now
<ajax>
and behaved as if it did even before that, whoopsie
vliaskov has quit [Remote host closed the connection]
<ajax>
i guess you could care about someone else's libEGL but why
<linkmauve>
I personally don’t, but haasn might.
<linkmauve>
Drivers other than Mesa don’t exist to me. :p
<haasn>
And otherwise it appears to just link to glXGetProcAddressARB etc. directly somehow
<haasn>
linkmauve: nah I'm perfectly happy shoving this responsibility onto the user
toolchains has joined #dri-devel
shankaru has quit [Quit: Leaving.]
<haasn>
It's a billion times better than requiring dlsym code in a library that should have nothing to do with this
<ajax>
haasn: GetProcAddressARB is required by the linux libgl abi spec
<ajax>
it's entirely safe to import it statically
srslypascal has joined #dri-devel
<linkmauve>
What is the status of the replacement of libGL.so with libOpenGL.so and libGLX.so btw?
<linkmauve>
Still a distant pipe dream, because every other program links against it directly?
toolchai_ has joined #dri-devel
<ajax>
i think the way you'd effect that change is by updating the abi spec, which is probably quite easy to do, but i do not know of anyone working on it
<HdkR>
linkmauve: Doesn't Ubuntu already ship glvnd by default?
<ajax>
but practically speaking if you want to link yourself that way today you are welcome to do so, and in practice glvnd will mean you work in most places.
<ajax>
i don't think we ever fixed mesa itself to emit a standalone libGLX.so ? would be quite easy to do though, and that way mesa and glvnd would have the same abi surface
<feaneron>
now seems like a good time to ask this
<ajax>
slow horrible dawning realization as i write this that i'm basically the glx maintainer so maybe i should get on this...
mszyprow has joined #dri-devel
<feaneron>
was it a bad idea to drop the glx renderer from obs-studio? (and switch entirely to egl for that)
<anholt>
ajax: glx maintainer and also most knowledgable in linkers. doomed.
<feaneron>
eh, did you folks get my last messages?
<feaneron>
lord please no matrix bridge issues again...
<ajax>
feaneron: if there's nothing missing in egl but present in glx that you need, then it's a fine idea. i switched Xephyr from glx to egl for similar reasons
toolchains has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
<ajax>
there _are_ some things glx can let you do that egl does not, either intentionally or because nobody's implemented it yet. but if you don't need them, egl's fine, it's certainly not going away
<feaneron>
ajax: i guess it was the exact opposite - things available in egl but not in glx, namely dma-buf importing
<feaneron>
well, at least, not easily available
<feaneron>
fortunately the gl usage of obs-studio does not strictly require the alpha channel, so it doesn't have the same problems that e.g. gtk had when trying to switch to egl by default on x11
mbrost has quit [Remote host closed the connection]
<feaneron>
though people seem to be having trouble to port the NvFBC code to it, it seems to require GLX
mszyprow has quit [Ping timeout: 480 seconds]
<ajax>
hah yeah it might
jkrzyszt has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
Guest1955 has joined #dri-devel
oneforall2 has joined #dri-devel
Guest1955 has left #dri-devel [#dri-devel]
<JoniSt>
robclark: I hope I'm not making a fool of myself in Mesa MR 16993... First time contributing here. Thanks for looking at it though!
iive has joined #dri-devel
ybogdano is now known as Guest1956
ybogdano has joined #dri-devel
<robclark>
JoniSt: no, it looks reasonable.. I did want to check what multi-context uses cases matter enough to worry about disabling that opt.. chrome (and probably ffox) is one case that comes to mind