ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<illwieckz>
For people interested in OpenCL platform development (rusticl, clover…) here is my script to build and run a patched luxmark3 with many things to make it a good tool to debug opencl platforms: https://gitlab.com/illwieckz/i-love-compute#user-luxmark3
<illwieckz>
The luxmark3 tool is now patched to be built with Qt5 so that simplifies a lot of requirement (before it required to build Qt4 that required to build GCC7 that…)
Lucretia has quit []
<illwieckz>
and luxmark3 now catches all the various opencl errors (missing platform, platform without device, opencl compilation error…) instead of just crashing, printing the useful log message
<illwieckz>
plus various environment variables to select specific code paths, add extra opencl compiler options, pre-fill submission form, etc.
<illwieckz>
plus the bugfix for LLVM-based platforms (Clover, ROCm)
<illwieckz>
Maybe in the future I'll evaluate the ability to make a flatpak from that (including all the useful patches) as I have verified it's possible to run a flatpak application with a non-system OpenCL platform
Lucretia has joined #dri-devel
<DavidHeidelberg[m]>
illwieckz: Nice work with porting to Qt5. Have you considered sending it upstream?
<anholt>
karolherbst: LP_CL=1 is getting me rusticl on llvmpipe for piglit, but when I run CL CTS I get "radeonsi: driver missing" then "ERROR: clGetDeviceIDs failed! (CL_DEVICE_NOT_FOUND from /home/anholt/src/OpenCL-CTS/test_common/harness/testHarness.cpp:428)". any ideas?
<illwieckz>
DavidHeidelberg[m], I'm writing right now a message in their forums that says mostly what I just wrote there. After that we may discuss the ability to make a 3.2 or something.
<DavidHeidelberg[m]>
illwieckz: what I know, flatpak uses their Mesa version, so not sure about the integration (what I recall, Librem 5 folks has issues that Flatpak apps couldn't utilize their Mesa fixes)
<illwieckz>
Note that they have a LuxMark 4 in the pipe for years that is actually ported to Qt5 (already), but since LuxMark 4 is only an alpha, it's still not the released one, and there is no benchmark submission in luxmark 4.
<karolherbst>
anholt: yeah, you need to overwrite the device type in the CTS
<illwieckz>
So those are basically maintenance patches.
<karolherbst>
but you have to force GPU probably anyway.. I'll fetch what you'll need
<karolherbst>
anholt: working on hooking up CI or the CTS into the deqp-runner?
<psykose>
DavidHeidelberg[m]: i'd assume with filesystem=host and messing with the ld_path you can still load a host one. was actually wondering how to get that working for steam myself..
vliaskov has quit [Remote host closed the connection]
carbonfiber has quit [Quit: Connection closed for inactivity]
off^ has quit [Ping timeout: 480 seconds]
off^ has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
MouseZhang has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
srslypascal is now known as Guest3640
srslypascal has joined #dri-devel
Guest3640 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest3641
srslypascal has joined #dri-devel
Guest3641 has quit [Ping timeout: 480 seconds]
mhenning has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
fxkamd has quit []
Peuc has quit [Quit: Peuc]
Peuc has joined #dri-devel
dviola has joined #dri-devel
Duke`` has joined #dri-devel
Lyude has quit [Quit: Bouncer restarting]
Lyude has joined #dri-devel
fab has joined #dri-devel
tzimmermann has joined #dri-devel
kts has joined #dri-devel
kts has quit []
fab has quit [Quit: fab]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
chipxxx has quit [Ping timeout: 480 seconds]
piggz has joined #dri-devel
mvlad has joined #dri-devel
danvet has joined #dri-devel
tursulin has joined #dri-devel
rasterman has joined #dri-devel
kts has joined #dri-devel
piggz has quit [Quit: Konversation terminated!]
piggz has joined #dri-devel
idr has quit [Quit: Leaving]
fab has joined #dri-devel
itoral has joined #dri-devel
jkrzyszt has joined #dri-devel
fab has quit [Quit: fab]
fab has joined #dri-devel
chipxxx has joined #dri-devel
<MrCooper>
daniels zamundaaa[m]: if the per-application policy is supposed to be handled in the Wayland compositor, a presentation timing protocol which allows the compositor to tell if an update is late would make more sense to me than an explicit tearing protocol; the Wayland client can't reliably know if tearing is needed for relaxed FIFO
<MrCooper>
zamundaaa[m]: not sure why you keep talking about environment variables when there's driconf, which allows enabling options by default for specific applications
djbw has quit [Read error: Connection reset by peer]
djbw has joined #dri-devel
vliaskov has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
rgallaispou1 is now known as rgallaispou
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
MajorBiscuit has joined #dri-devel
<pq>
swick, nah, the discussion is just a classic case of unsaid assumptions/preconditions (and saying those would have been too much to type) leading to different people using the opposite assumptions/preconditions in the counter-arguments.
<pq>
and then some "invisible heat" added in the tone
<zamundaaa[m]>
MrCooper: per application policy is intended to be about allowing tearing, not about forcing it. "vsync" settings of games are supposed to work by default
<zamundaaa[m]>
Presentation timing would of course be ideal to have but I don't intend to wait for that to happen
<zamundaaa[m]>
About env vars: I do mean driconf. Ultimately I don't think defining defaults for all games using OpenGl is feasible though, so in the end many users will still need to use an env var for this
<MrCooper>
enumerating the games which want it is more feasible than enumerating all other games and apps :)
<MrCooper>
not sure what you meant with your first line
pcercuei has joined #dri-devel
Company has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
vup has quit [Quit: vup]
<zamundaaa[m]>
Presentation timing without a tearing hint wouldn't be what I want, because apps couldn't tell the compositor their preference. So you'd need a tearing hint either way; if that's done with a separate protocol or not doesn't really matter
<zamundaaa[m]>
On a completely different topic, I read from a user that they don't get vrr in Sway with fullscreen applications unless they disable explicit modifiers
<zamundaaa[m]>
So are there really modifiers where vrr doesn't work?
<MrCooper>
don't know of any direct connection between the two; a sway/wlroots issue maybe?
<emersion>
unlikely
<emersion>
we don't do anything differently when modifiers are enabled, apart from buffer alloc
<zamundaaa[m]>
As it only doesn't work in fullscreen I doubt it's your buffer alloc that makes a difference. It should be the client buffer that causes the problem
Haaninjo has joined #dri-devel
<zamundaaa[m]>
But this would maybe require rejecting a buffer for direct scanout if the commit doesn't work with vrr enabled
<emersion>
hmmm, that makes it even more starnge
<emersion>
hm, no, maybe no
<emersion>
not*
<emersion>
disabling modifiers would disable direct scanout probably
<emersion>
WLR_DRM_NO_MODIFIERS disables modifiers in the DRM backend only
<zamundaaa[m]>
Worse though, it might require filtering out modifiers in the compositor if vrr doesn't work :/
<emersion>
the renderer can still support modifiers
<emersion>
so if the client submits a buffer with a modifier, then it'll just use the composition path
<emersion>
but VRR works with the composition path just fine as well
<zamundaaa[m]>
I'll ask the user to set KWin to 8 bit mode and make a test for comparison. In theory, the client should end up using the same modifier for direct scanout
<pq>
maybe the max VRR freq hits bandwidth limits with the chosen explicit modifier but not when the modifier is implicit?
<emersion>
it would be the reverse actually
<emersion>
ah no nvm
<emersion>
eh i'm confused now
<emersion>
VRR works with explicit modifiers, but breaks with implicit
swalker__ has quit [Remote host closed the connection]
swalker_ is now known as Guest3657
kts has quit [Read error: Connection reset by peer]
swalker__ has joined #dri-devel
vup has joined #dri-devel
vup has quit []
vup has joined #dri-devel
lygstate has joined #dri-devel
Guest3657 has quit [Ping timeout: 480 seconds]
<CounterPillow>
Didn't even know compositors needed to be aware of VRR, I thought they'd just yeet frames at their leisure and VRR will deal with it
<zamundaaa[m]>
They need to enable it and even be able to produce frames at non-fixed intervals, but the driver will indeed handle the rest. That doesn't work if the driver can't do it with the buffer it gets from the compositor though
<pq>
CounterPillow, that, compositors like to schedule things, not repaint ASAP when any client flinches. Then there are fun questions like should a mouse cursor motion slam VRR to the max rate.
<pq>
*that, and
<CounterPillow>
ah, good point
lanodan_ has joined #dri-devel
lanodan has quit [Read error: No route to host]
kj has quit [Ping timeout: 480 seconds]
itoral_ has quit [Remote host closed the connection]
kts has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<dj-death>
really weird issue that my AMD card is only able to see part of a buffer coming from DG2
<dj-death>
but coming from the integrated ADL, no problem
<dj-death>
and it seems to scan white from that buffer
tursulin has quit [Ping timeout: 480 seconds]
kts has quit [Read error: Connection reset by peer]
<dj-death>
clearly mmapping the buffer before sending it to the compositor for presentation returns the right data
<zmike>
you're using the external object api? or just dmabufs
devilhorns has quit []
heat_ has joined #dri-devel
off^ has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
i-garrison has quit [Read error: Connection reset by peer]
i-garrison has joined #dri-devel
lemonzest has joined #dri-devel
MajorBiscuit has joined #dri-devel
heat_ has quit [Read error: No route to host]
heat_ has joined #dri-devel
fab has quit [Quit: fab]
alyssa has joined #dri-devel
<alyssa>
illwieckz: Any idea if luxmark will build and run on arm64?
<illwieckz>
no idea :D
<alyssa>
Got it
<illwieckz>
it uses old branches of many things
<alyssa>
I am not feeling adventurous enough to find out! :-D
<illwieckz>
but now that it is ported to qt5 that may help
<graphitemaster>
new horror: imageStore's f32 -> f16 rounding behavior s not the same as f32 -> f16 via packUnorm2x16
<graphitemaster>
I just hate how poorly specified all this is, finding out the latter's rounding behavior is undefined just brings me joy
<graphitemaster>
GLSL is literally useless as a language.
<illwieckz>
luxmark3 requires qt5, old embree, old openimageio
<karolherbst>
alyssa: FEX is close to supporting CL anyway :P
<karolherbst>
might want to ping there and see what's the status actually
<karolherbst>
mhh
<karolherbst>
will do that later
<graphitemaster>
*packHalf2x16 I mean
<dj-death>
zmike: just dmabuf
<dj-death>
zmike: why?
<dj-death>
zmike: works fine with the integrated GPU
<zmike>
historically there were issues with external objects
<dj-death>
zmike: it's like random number of pages are visible to the AMD gpu
<dj-death>
usually between 1 and 100
<alyssa>
graphitemaster: mood
<illwieckz>
out of curiosity, what's currently the most affordable arm64 device on the market?
<HdkR>
karolherbst: I think it is basically ready to be merged, there's just some discussion about call-back lifetime handling that...might be sorted?
<karolherbst>
yeah... I've heard you discussing this, but it didn't seem like there was a finals solution yet?
<HdkR>
illwieckz: Pi Zero 2 W probably, but you won't like the perf
<illwieckz>
I may have a raspeberry pi 3 on a shelf
<illwieckz>
I mean, I have an unused raspberry on shelf, it may be a pi3 :D
<HdkR>
karolherbst: I think the final solution will be what is currently in place but just needs reviews to circle back
<karolherbst>
ahh, cool
<karolherbst>
sounds like something alyssa could try out then and report if it actually works in real world cases
<illwieckz>
there is “rpi3b” written on it, I'll see if I can get an arm64 distro running on it
<jenatali>
"real world cases" and CL are very nearly mutually exclusive :P
<HdkR>
:D
<graphitemaster>
alyssa, this language has hurt me more than all my exes
fahien has joined #dri-devel
<karolherbst>
can't be worse than C can it :P
jlawryno has joined #dri-devel
sarnex has quit [Quit: Quit]
<alyssa>
jenatali: 100%
<alyssa>
graphitemaster: ouch
<karolherbst>
jenatali: rude
<karolherbst>
:P
<alyssa>
graphitemaster: okay but how many of your exes wrote GLSL code
jlawryno_ has joined #dri-devel
<HdkR>
I've only had ELFs write GLSL for me.
<alyssa>
like, for Christmas?
jewins has joined #dri-devel
<HdkR>
For all the good little children
<HdkR>
The rest got MACH-O or something
jlawryno_ has quit []
<jenatali>
Hm, I could've sworn there were Mesa functions for helping with CL interop that I found a few years ago but I'm struggling to find them again
jlawryno has quit []
<alyssa>
jenatali: someone needs to make a Stop Doing OpenCL infographic
<jenatali>
Yeah...
<jenatali>
Unfortunately one of those "real world cases" for CL needs cl_khr_gl_sharing :(
<tango_>
jenatali: hey I have actual opencl code in production
yuq825 has left #dri-devel [#dri-devel]
<karolherbst>
jenatali: yeah... I found those as well
<tango_>
(but I don't use cl_khr_gl_sharing)
<karolherbst>
and they are liek.. uhh
<karolherbst>
I "fixed" them I think?
<alyssa>
years of drivers yet no real world use found for GPU compute
<jenatali>
I think I probably need to turn them into a proper GL extension if I want to use them from my external runtime
<karolherbst>
and I am still like: uhh.. can't that be easier?
<karolherbst>
I think we might have to teach that about modifiers as well and stuff
<karolherbst>
dunno
<karolherbst>
how would one even share images except forcing them linear?
fxkamd has joined #dri-devel
<alyssa>
"yes I want long16 apples. I want uchar8 apples." statements dreamed up by the utterly deranged
<karolherbst>
davinci resolve also requires gl_sharing :/
<jenatali>
karolherbst: Yeah that's the one
<karolherbst>
but also cl_khr_image2d_from_buffer
<karolherbst>
I got it to run, but it failed me at that one later
<jenatali>
O.o yeah that one's not happening for us anytime soon...
<karolherbst>
well.. then no davinci resolve for ya
jlawryno has joined #dri-devel
<karolherbst>
looked like a hard req otherwise it just hangs at runtime or something or even crashes
jewins has quit [Quit: jewins]
<karolherbst>
but I wouldn't mind prototyping the gallium changes for that with rusticl
jlawryno has quit []
<alyssa>
jenatali: when are we deleting clon12 and just using rusticl with glon12?
jewins has joined #dri-devel
<jenatali>
If it was like the image1d_buffer stuff where it was special in the shader, then it'd be fine, but without that... I dunno about that extension
<jenatali>
alyssa: Not sure. Might be doable?
anarsoul|2 has quit [Read error: Connection reset by peer]
jlawryno has joined #dri-devel
<karolherbst>
yeah... gl doesn't do that either, so it has to be a special CL path for drivers :/
<karolherbst>
which is fine, but...
<karolherbst>
no idea how to do that on top of vk e.g.
fahien has quit []
<jenatali>
Yeah
<jenatali>
It's a very unique CL thing
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jenatali>
Ugh all this interop stuff is of course only hooked up through dri2, so I'd have to write a way to expose it with WGL too, hoory
<tango_>
cl_khr_image2d_from_buffer?
<jenatali>
hooray*
<jenatali>
tango_: Yeah
anarsoul has joined #dri-devel
<karolherbst>
tango_: yep...
<graphitemaster>
alyssa, none, and frankly maybe writing GLSL is a red flag
<tango_>
I was wondering about that. I think it was an attempt at allowing cuda-on-opencl to be implmented, because cuda allows binding textures to properly-aligned-and-pitched linear buffers
jlawryno has quit []
jlawryno has joined #dri-devel
<tango_>
which I assumed meant nv could do it in hw
<alyssa>
this will be problematic on a pile of hw
jlawryno_ has joined #dri-devel
jlawryno has quit []
jlawryno_ has left #dri-devel [#dri-devel]
<karolherbst>
why though?
<alyssa>
limitations of linear images
<jenatali>
Yeah
<alyssa>
I think the language of the extension is tight enough that even AGX can do it
<karolherbst>
the ext advertsies limits
<alyssa>
certainly Mali can
<jenatali>
Could always copy back and forth... changes only need to be reflected at synchronization points :D
<tango_>
alyssa: you mean limitations as in size?
<karolherbst>
"CL_DEVICE_IMAGE_PITCH_ALIGNMENT_KHR" and "CL_DEVICE_IMAGE_BASE_ADDRESS_ALIGNMENT_KHR"
<alyssa>
tango_: Just, limitations
<alyssa>
no mipmapping is a fun one
<karolherbst>
aligning the pitch and base addrs should be enough for all hw, no?
<tango_>
I don't think you have to worry about mipmapping for this
jlawryno has joined #dri-devel
<tango_>
iirc opencl has a specific type to allow mipmapping and it doesn't have a 'from buffer' equivalent
<alyssa>
ack
MajorBiscuit has joined #dri-devel
<tango_>
and it's not even in 1.2
<jenatali>
karolherbst: When we tried adding linear texture sampling to D3D a few years ago we got significant pushback about hardware limitations... not sure if it was perf though or if it was flat-out incompatibility
<alyssa>
probably a mix
<jenatali>
Bottom line though is that we didn't do it
<alyssa>
I don't know any of the IHVs shipping with Windows though
<karolherbst>
mhh
<karolherbst>
yeah... mixing it with non linear images will be "fun"
<karolherbst>
but we can just advertise that on hw whcih supports it and see how it works out
<karolherbst>
don't have to be a generic on top of vulkan thing yet
<jenatali>
Until you want DaVinci Resolve on zink :P
<karolherbst>
kind of like the idea rusticl staying a gallium frontend instead of going full vulkan
<tango_>
opencl 2 has image arrays, but only same-sized ones
<karolherbst>
not sure anything uses it though
<tango_>
so I mean, if THAT is the issue it's not going to be a blocker
<karolherbst>
I doubt any of those image exts will be painful to hook up, just need to try it out
kj has joined #dri-devel
<karolherbst>
anyway.. gl_sharing and 2d_from_buffer are actually used by cool tools, so I'll focus on those first regardless
<jenatali>
Yeah I'll need to figure out what to do about gl_sharing...
<karolherbst>
the impl is painful either way, I saw what ROCm was doing :(
<karolherbst>
and they end up doing gl calls
<karolherbst>
and my patch isn't pretty either
<jenatali>
Maybe I'll just add WGL equivalent functions to what exists, or maybe I'll need to do a proper extension
<jenatali>
But that's a problem for later
<karolherbst>
I'll suspect we want to use the buffer export/import stuff we got now in GL
<karolherbst>
but uhh...
<karolherbst>
I mean, we use a mesa ext here :/
<jenatali>
Is it an actual ext? I thought it was just exported functions from EGL/GLX, I didn't see an extension string
* tango_
has no idea what rocm is doing but is pissed that the rocm amd packages have disabled opencl for his gpu anyway
<jenatali>
Still seems odd that it's in EGL/GLX instead of just GL, but oh well
<karolherbst>
well.. more of a private ext
<karolherbst>
not sure it's even advertised
<jenatali>
Yeah that's what I meant
<karolherbst>
but thing is.. I can probably not rely on that one
<karolherbst>
but we do have the import/export stuff now
<karolherbst>
so I was wondering using all the things we use for wayland/etc.. instead
<jenatali>
If they do use DRM concepts I'll have to build WDDM equivalents anyway. Our memory is strongly typed such that a handle can't be reinterpreted, but also doesn't need width/height/modifier in a side channel
MajorBiscuit has quit [Ping timeout: 480 seconds]
<karolherbst>
mhhh
<karolherbst>
yeah.. I added those changes because I was too lazy figuring out from the EGL/GLX/GL side, but ROCm uses that, so I suspect there is a way
<karolherbst>
well.. uses it without those changes
<jenatali>
From raw GL? I didn't think you could export from GL?
<karolherbst>
or it only works with radeonsi
<karolherbst>
jenatali: no, they use the mesa interop stuff
<jenatali>
alyssa: D3D had the same min-precision nonsense until quite recently
<FireBurn>
I've been seeing this the last few days with or without rusticl https://pastebin.com/PLDrauZX, I'm not sure if it was the llvm upgrade to 15.0.3 or a glibc patch that did it
<karolherbst>
luxmark is just very bad at error handling
<kchibisov>
In GLX spec there's a mention of `the attribute list should be terminated with None`, does it mean 0? I though that it's a GLX_NONE, but it seems like it's not, since nvidia doesn't like it and wants 0.
<DemiMarie>
kchibisov: Why are you using GLX instead of EGL?
JohnnyonFlame has joined #dri-devel
<kchibisov>
DemiMarie: that's not an answer unfortunatelly. EGL doesn't support all we want on X11.
<kchibisov>
But it seems like waffle is using 0, so it seems it should be 0.
ahajda has quit [Read error: Connection reset by peer]
fxkamd has quit []
<kchibisov>
Just surprising that mesa allows None in the end of such lists, but not nvidia.
<DemiMarie>
kchibisov: What do you want on X11 that EGL does not support? Do you use EGL on Wayland? `None` is defined as 0 in X11, yes.
<kchibisov>
DemiMarie: transparent window.
<kchibisov>
We use EGL on wayland, yes, since it has everything.
<kchibisov>
Firefox is also using GLX because of that iirc.
<DemiMarie>
I would not be surprised if X11 is buggy. The X server is very very poorly maintained.
<bnieuwenhuizen>
kchibisov: from X.h: #define None 0L
<kchibisov>
bnieuwenhuizen: thx, I just used wrong None...
<alyssa>
bnieuwenhuizen: Right. But GLES apps don't use that in practice, they just yeet precision mediump and sometimes it even works!
<DemiMarie>
kchibisov: I recommend using XCB and `XCB_NONE`.
<kchibisov>
DemiMarie: there's no XCB for GLX.
<DemiMarie>
kchibisov: the protocol definitions are there, IIRC
<bnieuwenhuizen>
alyssa: not even sure it is supported by GLES, it was added for Vulkan SPIR-V generation
<alyssa>
jlawryno: is this Movidius?
<kchibisov>
Yes, but no lib, so you have to do that manually, unlike like with xlib.
sdutt has joined #dri-devel
<DemiMarie>
kchibisov: file a ticket with XCB 🤣
<alyssa>
bnieuwenhuizen: right (-:
lygstate has quit [Read error: Connection reset by peer]
<alyssa>
bnieuwenhuizen: Tangentially related, how has GLSL internal shaders with build-time glslang been?
<alyssa>
(as opposed to OpenCL C shaders with clc)
<bnieuwenhuizen>
I think pretty ok
<DemiMarie>
I actually filed an MR to rip out XPrint from XCB on the grounds that nobody could be using it.
aravind has quit [Ping timeout: 480 seconds]
<DemiMarie>
alyssa: what is wrong with OpenCL?
<bnieuwenhuizen>
we have weird REF() and DEREF() macros instead of C pointer syntax but otherwise pretty similar
<bnieuwenhuizen>
and all the usual glsl goodies just work (no we didn't want to code yet another matrix inversion)
orbea has quit [Remote host closed the connection]
orbea has joined #dri-devel
jlawryno has quit [Quit: Leaving]
<FireBurn>
So I got radonsi listing rusticl devices :D but again I saw that crash when launching luxmark
<FireBurn>
The only way to avoid the crash is to RUSTICL_ENABLE=llvmpipe,radeonsi
<FireBurn>
Bascially if llvmpipe isn't enabled luxmark crashes on start up with pastebin'd error
kts has quit [Quit: Leaving]
tzimmermann has quit [Quit: Leaving]
<FireBurn>
karolherbst: Would you like me to open an issue for that?
<karolherbst>
FireBurn: I think it crashes when there is no device
<karolherbst>
clinfo and all the other things perfectly work
<karolherbst>
but dunno.. illwieckz might now
<FireBurn>
But with radeonsi enabled there are two devices and the rocm also provides two devices
<FireBurn>
But without llvmpipe being passed it crashes, super weird
<karolherbst>
strange...
<karolherbst>
maybe every platform needs to provide one dev at least?
<karolherbst>
but uhh...
<karolherbst>
huh
<karolherbst>
it makes no sense
<karolherbst>
I know just having one radeonsi device works for me
<karolherbst>
it crashes it luxmark code though, right? mhhh
<jenatali>
karolherbst: FYI, we've talked to DaVinci Resolve folks and they mentioned missing gl_sharing and 3d_image_writes... they didn't say anything about the 2d_from_buffer stuff
<karolherbst>
huh...
<karolherbst>
I am sure they are using it though
<karolherbst>
might not check for the ext
<karolherbst>
let me check...
<karolherbst>
ahh
<karolherbst>
jenatali: it's core in CL 2
<jenatali>
So? They don't require CL2 do they...?
<karolherbst>
huh.. mhhhh
<jenatali>
There's a lot of other nonsense that's core in CL2 that's not happening
<karolherbst>
I have no idea, but I know I hit it when trying to run it here
tobiasjakobi has joined #dri-devel
<jenatali>
Fair enough, just figured I'd mention. I haven't tried to run it yet personally
<karolherbst>
they might just use the feature directly
<illwieckz>
stock luxmark crashes if there is no platform, or if a platform has not device, or if kernel compilation fails
swalker__ has quit [Remote host closed the connection]
<illwieckz>
because it doesn't catch the opencl exceptions
<RSpliet>
Those sort of patches really should be mainlined, it's just poor form not testing for expected failures. That said, I'm surprised that oclPlatform throws an exception for this, it should just keep oclDevices empty and be done with it
<RSpliet>
As it's not an exceptional situation
<illwieckz>
it looks like it uses exceptions as return code -.-
<karolherbst>
yeah.............
<karolherbst>
some C++ coders think it's how it should be
alyssa has left #dri-devel [#dri-devel]
* karolherbst
looking forward purging the dynamic pipeloader
ybogdano has joined #dri-devel
adavy has quit [Ping timeout: 480 seconds]
<FireBurn>
Thanks Karl, I rebased your branch onto main, now getting slightly faster runs on rusticl than rocm on my 6800M
danvet has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
Akari has joined #dri-devel
<jenatali>
karolherbst: Ok I'm looking closer at cl_khr_gl_interop - my thinking about it this morning means I should probably just do it while it's fresh in my mind
<karolherbst>
:)
<karolherbst>
cool
<jenatali>
I think I need a v2 interface as well but for different reasons from you - want me to roll your changes into it?
<karolherbst>
yeah, would be nice
<karolherbst>
though I'd still prefer a solution not relying on mesa specific bits :/
<karolherbst>
but no idea how to do it otherwise
<karolherbst>
just used that because it was there
<jenatali>
Yeah we could do it if we had a generic GL extension for exporting stuff, but having it Mesa-specific is somewhat convenient for me
<karolherbst>
okay
<jenatali>
Specifically I want to rev mesa_glinterop_device_info to add a void* for driver-specific outputs - I want to make sure that CL and GL share the same underlying D3D device
<karolherbst>
mesa is the only useful GL impl anyway :P
<jenatali>
Amen :P
jhli has quit []
jhli has joined #dri-devel
jhli has quit []
jhli has joined #dri-devel
<jenatali>
Oh there's different versions for the different structs. I'm revving a different one than you, that should be fine
fab has quit [Quit: fab]
<karolherbst>
ahh, cool
<DavidHeidelberg[m]>
ok, I have finished NineTests integration into CI. It takes on my machine (TGL) approx. 9 seconds to run everything. Shouldn't I just add it to existing job?
<DavidHeidelberg[m]>
it seems to me a bit waste use new runner for that
_rgallaispou has joined #dri-devel
<jenatali>
David Heidelberg: Can/should it be a unit test, run in the build jobs?
<LaserEyess>
are there some good resources for starting out with libdrm? and learning about the API?
<jenatali>
karolherbst: Did you have an interface in mind for plumbing flush_resource on the CL acquire functions? If not I can add one
<karolherbst>
nope, I never actually tried getting to pass all tests or getting runtimes to work properly
<jenatali>
Fair enough. I'll probably just a third function in the same vein as the existing two for acquiring
<Frogging101>
Perusing libdrm headers might also be helpful
<jenatali>
I don't think GL needs to be notified about CL being done
<LaserEyess>
Frogging101: I have a vague idea of how drm works, but I mean libdrm specifically
<LaserEyess>
the headers are, uh, not exactly documented
<Frogging101>
yeah...
<LaserEyess>
right now I'm looking at wlroots's drm backend for some hints
<karolherbst>
jenatali: yeah... I think it's the applications repsonsibility to sync stuff anyway
<karolherbst>
afaik
<jenatali>
Right, with either a glFinish or wrapping a glSync
oneforall2 has quit [Remote host closed the connection]
<jenatali>
And a clFinish or waiting on a CL event in other direction
_rgallaispou has left #dri-devel [#dri-devel]
<karolherbst>
yep
oneforall2 has joined #dri-devel
rgallaispou1 has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
pa- has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<jenatali>
Ugh... clEnqueueAcquireGLObjects: "The application is responsible for maintaining the proper order of operations if the CL and GL contexts are in separate threads."
<jenatali>
Of course it wouldn't require the GL context to be bound to the current thread, why would it?
<DavidHeidelberg[m]>
jenatali: it needs running XORG + real hw :(
<jenatali>
David Heidelberg: I forgot I @'d you, I thought you were commenting on CL for a sec :P
pa has joined #dri-devel
<DavidHeidelberg[m]>
nope :D
pa- has quit [Ping timeout: 480 seconds]
caseif has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
caseif has joined #dri-devel
<illwieckz>
I'm running a locally built luxmark3 flatpak with my own rusticl build =)
mvlad has quit [Remote host closed the connection]
<daniels>
DavidHeidelberg[m]: just stick it on to one of the other existing jobs, maybe piglit
<DavidHeidelberg[m]>
daniels: would 100% make a sense, but do you have any tips to prevent confusion, when not piglit fails?
<daniels>
shrug … not really tbh
<daniels>
if it comes to be a big problem we can find a way to express it more clearly
ngcortes_ has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<javierm>
abhinav__: hi, I'm trying to enable support for an HP X2 Chromebook on the Fedora kernel but noticed that the msm drm driver fails to probe when built as a module
<javierm>
abhinav__: it works if is built-in though. The problem seems to be with some clocks being gated that are needed to enable the DISP_CC_MDSS_AHB_CLK clock
<javierm>
the error is: msm_dsi_phy ae94400.dsi-phy: [drm:dsi_phy_enable_resource [msm]] *ERROR* dsi_phy_enable_resource: can't enable ahb clk, -16
<DavidHeidelberg[m]>
daniels: fine, I'll append it to the piglit! :)
<javierm>
abhinav__: ah, that's exactly the issue. And now thinking about it we may already talked about this LOL
<abhinav__>
which is being debugged by our clock team for a while, we should get some update in the next week or so
<javierm>
abhinav__: comparing the clock hierarchy when built-in and module I came with the following hack that work arounds the issue: https://paste.centos.org/view/raw/dee9cf70
<javierm>
marking DISP_CC_MDSS_MDP_CLK as critical so that's not gated if unused but I don't have docs to figure out what's the proper fix
<abhinav__>
javierm thanks for trying , I will ping our clock team and circle back on the best way to fix this, will update you in 1-1.5 week
<javierm>
abhinav__: Ok, thanks! my guess is that drivers/gpu/drm/msm/dsi/phy/dsi_phy.c should ungate some AXI clock needed to access the clock controllers registers so that clk_prepare_enable() doesn't return -EBUSY
<javierm>
abhinav__: I wondered though if that workaround is something that could be considered until the problem is well understood and the clock dependency modeled correctly in the DTB ?
<javierm>
because the fedora kernel maintainers won't accept DRM_MSM=y and having support in fedora without display isn't that useful for a Chromebook :)
<javierm>
abhinav__: let me know and I can post a proper patch or if is too hacky then I can just stop trying to enable it in fedora until this issue is sorted out by your clock team
<abhinav__>
javierm no, this issue was kind of root-caused to be related to gdsc regulator although not entirely sure why. Instead of your workaround, can you just have pd_ignore_unused and clk_ignore_unused set for a short term solution as that was fixing things as well. I would prefer the proper fix comes from the clock team.
<javierm>
abhinav__: yeah, in fact only clk_ignore_unused workarounds here but that's a bigger hammer. So maybe is not the same issue after all since robclark said that pd_ignore_unused was also needed
<javierm>
in fact, that isuse is when DRM_MSM=y but PANEL_EDP=m, here is with both drivers as module
<javierm>
abhinav__: anyways, if you prefer to wait rather than marking clocks as critical then that's OK for me
<abhinav__>
javierm yes, so originally it was reported with DRM_MSM=y but PANEL_EDP=m and hence rob's trial of needing both was for that. later on, he had also reported an issue with both as m
<javierm>
abhinav__: got it
<javierm>
bummer because is the only thing that's not working for me. Everything is working pretty well with Fedora 37
<abhinav__>
javierm ah ... sorry .... tbh even i was hoping this would be fixed earlier .... we have also been living with this bug for our internal development ..... hopefully resolves soon
<robclark>
hmm I do have a kernel setup w/ PANEL_EDP=m.. hmm, but I guess I still have DRM_MSM=y
<javierm>
abhinav__: no worries. I'll just wait for you to fix then :)
<robclark>
yeah, still no problems with DRM_MSM=m either.. but OTOH I might have very old fw on this one
<javierm>
robclark: interesting. What kernel version?
<javierm>
I'm testing with v6.1-rc1
<robclark>
that was on msm-next plus patches.. v6.0-rc2
<abhinav__>
robclark was display enabled in depthcharge?
<robclark>
my guess it is a fw different
<robclark>
abhinav__: yeah, fwui is enabled
<javierm>
abhinav__: here is not enabled by depthcharge
<javierm>
AFAIU
<robclark>
fwiw if you get the screen where you can choose to boot off of internal disk vs usb, that is depthcharge enabling the display (but it is _supposed_ to shut it off afterwards)
<abhinav__>
robclark interesting, i wonder what changed .... i am guessing has to be a diff fw
<javierm>
robclark: yes, I meant that no display is enabled when booting the kernel. Since I tried with simpledrm and it didn't work
<abhinav__>
would you pls share you version
<abhinav__>
that way we know you are ahead or behind of what we reproduced it on
<abhinav__>
javierm i wanted to know rob's version as he cant repro the issue now
<abhinav__>
but thanks for yours too :)
<javierm>
abhinav__: ah, sorry
<robclark>
abhinav__: tbh I'm not entirely sure how to check the version without a CrOS userspace.. but I'm almost certainly behind you.. this device (lazor) has had fedora on it since long before it shipped. Good chance it is the FSI fw
jfalempe has quit [Quit: Leaving]
<robclark>
oh, I guess I could just use the cr50/ec console.. one sec
<javierm>
robclark: yeah, that's what I did. Used the `version` command
<abhinav__>
robclark yeah we have a newer one. ours was build this year
mhenning has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
ybogdano has quit [Read error: Connection reset by peer]
<javierm>
abhinav__: another interesting data point, making the dsi_phy node to enable the MDSS_GDSC pd leads to the clk_prepare_enable(phy->ahb_clk) to not return -EBUSY
<javierm>
abhinav__: still no display and clk_summary shows a bunch of clocks gated, but it seems the GDSC pd is needed to access some clock registers
<javierm>
I should let this go, won't ever figure out without documentation...
mhenning has quit [Quit: mhenning]
Haaninjo has quit [Quit: Ex-Chat]
<karolherbst>
jenatali: if I don't review/leave comments/whatever until Wednesday feel free to ping me on the interop MR
<jenatali>
karolherbst: Sounds good - I'm not in a rush, I still have to write the other side of it
djbw has quit [Read error: Connection reset by peer]
<jenatali>
karolherbst: Move samplers out of nir_var_uniform?
<karolherbst>
and where should I put them else?
<jenatali>
nir_var_sampler?
* jenatali
shrugs
<karolherbst>
mhhhhhhh
<jenatali>
We already did that with textures
<karolherbst>
there is no nir_var_texture though
<karolherbst>
also.. that means like changing all the drivers even more :(
<jenatali>
Oh sorry, nir_var_image is what I was thinking of
<karolherbst>
yeah...
<karolherbst>
but samplers being in var_uniform also makes like no sense even for GL...
<karolherbst>
but I am also kind of lazy of rewriting like everything
<jenatali>
Yeah that's fair
vliaskov has quit [Remote host closed the connection]
<karolherbst>
alternatively I could make radeonsi use ACO, but... uhhhh
<jenatali>
Everyone would praise you for that but yeah
<jenatali>
Oof
<zmike>
HOW HARD COULD IT BE
<karolherbst>
it's one of those cases where all alternatives are even more work
<jenatali>
zmike: Do I hear you volunteering?
<karolherbst>
and not just a little, a lot more work
<jenatali>
karolherbst: As a less-terrible hack... you could (in rusticl) temporarily move samplers into a different var mode so they don't get touched by lower_io
<karolherbst>
uhhhhhh
<jenatali>
And then move them back before sending it to the driver
<jenatali>
Ok maybe not actually less-terrible, but less far-reaching
<karolherbst>
yeah.... I'm very tempted
<jenatali>
Anyway I'm out for the day/week, good luck
<karolherbst>
thanks, though instead of luck, I just want to have fun :P
<jekstrand>
karolherbst: Why does lower_explicit_io care about samplers at all?
<FireBurn>
People can't test what doesn't compile :P
<karolherbst>
jekstrand: cause they are mem_uniform?
<karolherbst>
ehh nir_var_uniform
<abhinav__>
javierm yes gdsc is needed for enabling ahb clock but it should have already been on
<abhinav__>
thats the issue
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<karolherbst>
I can double check, but I am like 99% sure I needed this change for radeonsi