simon-perretta-img has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
sukrutb has joined #dri-devel
lynxeye has joined #dri-devel
ced117 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
Haaninjo has joined #dri-devel
pochu has quit [Quit: leaving]
vliaskov has joined #dri-devel
rasterman has joined #dri-devel
sukrutb has quit [Ping timeout: 480 seconds]
sarahwalker has joined #dri-devel
pochu has joined #dri-devel
dtmrzgl has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest4812
sarahwalker has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
junaid has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
fab has quit [Quit: fab]
yuq825 has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
junaid has quit [Remote host closed the connection]
Guest4812 has quit [Remote host closed the connection]
swalker__ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<swick[m]>
sima: the atomic commit state validation that's currently done on the current state to a new state, you said we'd need to change all drivers over to use arbitrary state to arbitrary state to improve the situation
<swick[m]>
sima: but why? can't we change one driver at a time and expose some cap or new uAPI?
swalker__ has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
<yrlf>
Company: emersion: if you use wl-mirror fullscreen on the same output it's recording it basically always displays a 1 frame old image
<emersion>
it depends on the timings
<emersion>
the outputs' refresh rates are not synchronized
<yrlf>
that it does
<yrlf>
that creates a pretty trippy "draw with your mouse" effect
<emersion>
oh, "on the same output"
<emersion>
then yeah, exactly 1 frame late
<yrlf>
yeah, wl-mirror is also still a pretty naive client. I think I'm not doing everything correctly with DMA-BUF import yet
<yrlf>
export-dmabuf works, but the dmabuf from the pipewire screencast (in my feature branch) displays black (with no gl errors)
<emersion>
ah, pipewire fun
<yrlf>
I need to check screencopy with dmabuf, and see if that behaves the same way
* emersion
has nightmares with SPA_Pod in them
<yrlf>
the DMA-BUF from xdg-desktop-portal-wlr is created with libGBM i believe, which I am not using at all yet
mclasen has joined #dri-devel
<emersion>
you shouldn't need to use GBM
<yrlf>
oh god, SPA_Pod and the whole format negotiation shenanigans is ugly
<emersion>
grab the FDs+metadata from pw, pipe that into linux-dmabuf
<yrlf>
I need to import the buffer into gl, for some of the other effects wl-mirror is using
<emersion>
then you can use the EGL import API without GBM
Danct12 has quit [Quit: A-lined: This user has been AViVA-lined!]
<emersion>
GBM is mainly useful for allocating buffers
<emersion>
but you shouldn't need to do that
Danct12 has joined #dri-devel
<yrlf>
afaik i'm using that EGL API already, but I'm not sure what's going wrong, since the buffer is just blank
yyds has quit [Remote host closed the connection]
swalker__ has joined #dri-devel
<columbarius>
yrlf: for the negotiation stuff look at the PipeWire plugin in obs
<sima>
swick[m], the drivers you could convert easily are not the drivers where you want to know the answer ...
<sima>
so yeah we could do it one-by-one, but we kinda have been trying to push that ground work for years ...
<sima>
so at the current pace you'd never get this feature for the drivers where you actually want it
<sima>
plus to validate the uapi we'd need at least one such more complex driver where this uapi extension does something
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
fab has joined #dri-devel
fab has quit []
Company has joined #dri-devel
<pq>
yrlf, texture min/mag modes in GL? Those helpfully default to "black screen" values for imported dmabuf, IIRC.
<yrlf>
columbarius: yeah, I've taken a lot of insights from the obs code, but currently my format negotiation is still very stubbed out, will expand that
<yrlf>
pq: thanks for the hint, will take a look; though I'm confused why the behaviour is different between wlr-dmabuf-export and pipewire
<yrlf>
pq: no mesa debug output, even when setting MESA_DEBUG=flush,incomplete_tex,incomplete_fbo,context
<yrlf>
I'll try to dig further; manually setting GL_TEXTURE_MIN_FILTER and MAG_FILTER after every dmabuf import also hasn't resulted in any change in behaviour or log output
<pq>
yrlf, so you have the same code path doing the same things, and for some dmabuf you get a good picture and for some you get black?
<yrlf>
yup!
<pq>
smells like driver failure to indicate failure :-p
<yrlf>
I think I'll try to find different hardware (non-intel) or try force mesa to run my entire desktop session in llvmpipe and check if the same happens
<gfxstrand>
airlied, karolherbst: We should consider switching to the LLVM SPIR-V back-end.
<gfxstrand>
I'm sitting through a presentation on it right now and aparently they have it compiling the entire OpenCL CTS so it should maybe be ready for us to use.
<gfxstrand>
This is different from SPIRV-LLVM-Translator
<karolherbst>
yeah...
<karolherbst>
with LLVM-17 or LLVM-18?
<karolherbst>
gfxstrand: but yeah, I'd be open for this, just need to check how much issues it would cause down the line. Anyway, is this all upstream already? And what's the ETA on availability?
<gfxstrand>
It's all upstream now
<gfxstrand>
IDK what version. I'm going to ask.
<karolherbst>
cool, thanks
<karolherbst>
airlied: that means we should also look into updating libclc to use that
<karolherbst>
would remove some distribution packaging pain
<karolherbst>
but that's assuming it can build libclc :)
<gfxstrand>
17 should be okay, or so they claim
<karolherbst>
mhhhh
<karolherbst>
doubt, but okay
<karolherbst>
gfxstrand: mind asking how that looks like in regards to optimization levels?
<karolherbst>
because with the translator only O0 is supported
<gfxstrand>
-O2 and -O3 both work
<karolherbst>
okay
<karolherbst>
assuming they don't push annoying to optimize spirv to us, that would help a lot
<karolherbst>
okay, yeah I can look into it then once I'm done with all the zink stuff :D
<karolherbst>
worst case the first step is a runtime/compile time flag
pochu_ has quit []
<gfxstrand>
They're asking for bug reports. :)
<karolherbst>
cool
<gfxstrand>
And it has a properly LLVM legalize pass in front of it so it should be a lot more robust.
<karolherbst>
the only change for us is to use the spirv target and compile a bit furhter or somethign, right? Might be good to have some "what you need to change" slide, but shouldn't be hard to figure out
<gfxstrand>
Yeah, we just need to figure out what knobs to tweak to get LLVM to spit out SPIR-V directly instead of linking against and using SPIRV-LLVM-Translator.
<gfxstrand>
It would also mean Mesa can drop a dependency which would be nice.
<karolherbst>
I think I already done so in the past and the main difference is to use `spirv` instead of `spir` as the llvm target
<gfxstrand>
right
<karolherbst>
the sad part is, that clover doesn't use clc
<karolherbst>
the good part is airlied had patches
<gfxstrand>
There's an easy solution to that. ;-)
<karolherbst>
heh
<karolherbst>
yeah. fix r600
<karolherbst>
maybe we should amber clover...
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<gfxstrand>
I'm a fan of amber clover
<alyssa>
do it
heat has joined #dri-devel
<gfxstrand>
Okay... new plan. We need to write a new compute-only gallium driver for nvidia that uses NAK. Let's make NVIDIA's OpenCL implementation obsolite.
<tnt>
does zink work over nak ?
<gfxstrand>
Trying to go through Vulkan is kind-of a pain still
kts has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<gfxstrand>
dcbaker: For now, I think I'm going to just update my meson wraps to set native:true inside the meson.build in the project.
junaid has joined #dri-devel
yyds has quit [Remote host closed the connection]
Danct12 has left #dri-devel [A-lined: This user has been AViVA-lined!]
<gfxstrand>
dcbaker: Okay, that gets it to configure but now I'm getting "^^^^ maybe a missing crate `core`?"
Danct12 has joined #dri-devel
kts has joined #dri-devel
luben has joined #dri-devel
nir2042 has joined #dri-devel
kzd has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
<gfxstrand>
cwabbott: Does turnip support tessellation?
MajorBiscuit has quit [Quit: WeeChat 4.1.0]
<zmike>
yes
<cwabbott>
gfxstrand: yes, why?
<gfxstrand>
Tweaking the SPIR-V parser a bit and trying to make sure I get all the tess-capable drivers
<karolherbst>
gfxstrand: mhhhhh
<karolherbst>
I could do that I guess :D
<karolherbst>
unless somebody else wants to
<karolherbst>
but yeah... might also be a good idea to start a new gallium driver as compute only and see if that's even feasible
<karolherbst>
though.. radeonsi already does so with some of their GPUs
<gfxstrand>
karolherbst: We don't need to think about that for a bit.
<gfxstrand>
Just thinking that if we're going to amber all of nouveau GL, we might still want to keep enough around for rusticl.
<gfxstrand>
But use the new UAPI and everything
<karolherbst>
ohhhh
<karolherbst>
right...
<karolherbst>
does amber even support gallium?
<gfxstrand>
That sounds easier than revamping the entire GL driver.
<gfxstrand>
It should
<karolherbst>
yeah.. totally agree
<karolherbst>
and starting from compute might be a good idea anyway
<gfxstrand>
IDK how much we'd have to backport, though.
<karolherbst>
mhh.. yeah
<karolherbst>
well
<karolherbst>
sometihng we can keep in mind
<zmike>
amber2 ?
<gfxstrand>
We could make amber2
<gfxstrand>
jinx!
<karolherbst>
yeah....
<zmike>
I guess one of us has to take an extended vacation
<karolherbst>
I also don't know how hard it is to amber frontends
<wv>
I have this strange issue. cog/wpewebkit is running on mesa/freedreno. But I need to do some true pixel manipulation. Only the pixels I set may be set. Canvas is fullscreen and there is no scaling whatsoever. If I take a screenshot using webinspector it works fine. If I do a weston-screenshooter, it appears the pixels on top are also manipulated.
<wv>
but I have no clue what causes te pixels on the top. I already disabled dithering in freedreno (which is working as I already see banding now on gradients)
<wv>
but still something is interfereing
<jenatali>
zmike: Can it wait until next week? This is my last day of parental leave :)
<jenatali>
(re-sent since I forgot to auth)
<zmike>
jenatali: I guess? today's my last day for the year, so it won't get touched again until 2024
<gfxstrand>
Ooh, spicy!
<karolherbst>
anyway.. maybe I can file for rusticl on zink conformance like this or next week... :D
luben has quit [Ping timeout: 480 seconds]
<jenatali>
zmike: ooh well that's bad timing
<zmike>
I didn't expect to be affecting anyone :/
<jenatali>
I don't have a set up to investigate right now so it wouldn't be a quick thing for me to look today, otherwise I would try
<zmike>
nbd
<zmike>
probably nobody will touch any of this for a few months
<gfxstrand>
Yeah, I think it can wait until January
<gfxstrand>
It's not like that error hasn't been missing for half a decade or more.
<zmike>
pipe down captain jinx
<gfxstrand>
:P
<gfxstrand>
That's Queen jinx to you! 😂
<zmike>
👏👏👏
<zmike>
I'll be expecting full glcts conformance on nvk when I get back
<jenatali>
zmike: from the title of the MR and the fails/unexpected pass, it looks like there's some texture format(s) that fail to create in our driver
<zmike>
the XPASS I assume is just more correctly detecting a failure case, but the others are likely returning no support for some cases
<jenatali>
The new fails are ones that didn't try to use it and so they could query properties about it even though it internally failed to create
<jenatali>
The new pass is a test that treated that format as optional and handled failure, but since the failure didn't bubble up, it just saw wrong results
<jenatali>
So just update the baseline
<jenatali>
Maybe file an issue on me too?
<zmike>
if you're okay with that then sure
<zmike>
gfxstrand: oh I didn't consider that
<jenatali>
Yeah. I really need to drive our fail list down, it's already way higher than I want. Adding a few more isn't a big deal
<zmike>
cool
<karolherbst>
I hope I haven't added any regressions in the meantime not caught by CI :')
jfalempe has quit [Quit: Leaving]
rgallaispou has left #dri-devel [#dri-devel]
<zmike>
anholt_: are you able to update your reviews today? I'd like to get things merged before I leave
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
<pH5>
g l
<pH5>
apologies, keyboard focus mishap
vaxry has quit [Remote host closed the connection]
swalker__ has quit [Remote host closed the connection]
<alyssa>
jenatali: btw any plans for higher gl versions in glon12?
<alyssa>
or for dozen features to get dozenk up to gl4.6?
<alyssa>
zmike: is dozenk the right term
<zmike>
😬
<alyssa>
type-c emoji
<zmike>
zenk?
<ccr>
:D
<ccr>
"Zenk" sounds like a laundry detergent brand.
<jenatali>
alyssa: yeah, we've got active requests for 4.3
<jenatali>
But once we get there is really not much more to get 4.6
<ccr>
a cheap knock-off of the well-established Zink brand, "Zenk"
<jenatali>
alyssa: but also I have no idea what management's priorities for me will be. I've seen some emails that seem to promise I'll make 4.3 happen though
djbw has quit [Read error: Connection reset by peer]
<zmike>
jenatali: I tagged you on the MR since it's not going to be mergeable today in any case
<zmike>
whenever you get to it is fine
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<jenatali>
alyssa: we're already at 4.2
<jenatali>
zmike: 👍
<robclark>
zmike: hrm, wha?
<zmike>
no idea tbh
<zmike>
just adding gl errors to gl error cases
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
alanc has quit [Remote host closed the connection]
<lileo>
robertmader[m]: i've been following your direct-scanout development on mutter (nice!) I remember coming across a gitlab comment mentioning that you're looking into using libliftoff at some point. Just curious, what's the challenge with using it today?
<lileo>
Curious since I'm working on adding underlay support to libliftoff
<lileo>
maybe some of those challenges can be addressed along the way
<robclark>
zmike: so fd is rejecting some of the resource_from_memobj because the memobj is too small.. not sure if this is tu or test bug. (But also seems like the same tests failed before your MR, just with a different error)
<robclark>
zmike: possibly tu is picking linear and fd is picking UBWC?
<zmike>
🤔
<robclark>
I'm not entirely sure how this is _expected_ to work because modifier isn't passed explicitly
lynxeye has quit [Quit: Leaving.]
yyds has quit [Remote host closed the connection]
greenjustin has joined #dri-devel
sukrutb has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
vaxry has joined #dri-devel
vaxry has quit [Remote host closed the connection]
vaxry has joined #dri-devel
junaid has quit [Remote host closed the connection]
nir2042 has quit []
alanc has joined #dri-devel
vaxry_ has joined #dri-devel
vaxry has quit [Read error: Connection reset by peer]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
jernej_ has joined #dri-devel
anujp has joined #dri-devel
<robclark>
zmike: can the EXT_external_objects thing be used across process, or only within the same process?
<zmike>
good q
<DemiMarie>
alyssa: congratulations on geometry shaders!
<zmike>
I'd have to review the spec more carefully
jernej has quit [Ping timeout: 480 seconds]
<robclark>
looks like it expects semaphores to be shared across process.. but not so clear about memobj's
<robclark>
or rather the uuid part mentions cross process, so I guess that is implied to apply to both semaphores and memobjs
eukara has quit []
<jenatali>
My gut says across processes
<robclark>
yeah, I could maybe get away without new kernel uabi if it wasn't cross process, but I think I'm not getting off so easily :-/
<zmike>
alright I'm off, see everyone next year! 👋
mvlad has quit [Remote host closed the connection]
<javierm>
sima, airlied: would there be another PR of drm-misc-next for v6.7 ?
tobiasjakobi has joined #dri-devel
<javierm>
or are we in that time where drm-misc-next-fixes should be used instead for fixes of patches that are going to land in v6.7 ?
gouchi has joined #dri-devel
Haaninjo has joined #dri-devel
<airlied>
mlankhorst: did i miss a mr? ill chexk later
<airlied>
gfxstrand: add functions calls to NAK :-)
<airlied>
javierm: should be in misc-next-fixes.time
<javierm>
airlied: thanks. And I guess that can cherry pick from drm-misc-next then if landed there
<airlied>
yup, though mlankhorst did send a late misc next pr
<airlied>
so check that
sravn has quit [Quit: WeeChat 3.5]
rasterman has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<bl4ckb0ne>
is it me or there's no way to get an EGL context reset notification strategy
<javierm>
airlied: I see. Sigh, I missed mlankhorst for hours :(
<javierm>
Ok, will cherry-pick then
tobiasjakobi has quit []
<javierm>
dim cherry-pick pollutes the kernel history though because the same commit is twice, right ?
sukrutb has quit [Ping timeout: 480 seconds]
<karolherbst>
what's the best way to profile GPU memory usage of an application?
<karolherbst>
on vulkan
sima has quit [Ping timeout: 480 seconds]
<robclark>
perfetto does device some memory related trace events.. not sure if anyone hooked those up.. Otherwise, nvtop?
<karolherbst>
"This version of Nvtop is missing support for reporting Intel GPU memory, power, fan and temperature" :')
<karolherbst>
well, in the end I just need something which tells me what memory I'm not freeing
<javierm>
airlied: hmm, but first I need to wait for drm-misc-next to back merge drm-next since is still in v6.5-rc2 ?
<javierm>
this is just a fix for a DT binding schema warning in a uncommon driver. I'll ask Rob if really wants this to be in v6.7 or could just wait for v6.8
sravn has joined #dri-devel
vliaskov has quit []
karolherbst_ has joined #dri-devel
<mlankhorst>
It only happens as needed
<javierm>
mlankhorst: I see. My vote would be to just wait for this DT binding fix to land in v6.8, it's basically just a fix for a doc warning so not worth the trouble IMO
<javierm>
I've asked Rob, let's see what he says
Shibe has quit [Remote host closed the connection]
anujp has quit [Remote host closed the connection]
<gfxstrand>
airlied: Yeah... one day.
<karolherbst>
okay.. I think I found my last CL on zink bug 🙃
<karolherbst>
somehow the amount of mapped memory raises over time
<karolherbst>
*rises
<HdkR>
Woo, no more CL on Zink bugs, it was the last one!
<javierm>
airlied, mlankhorst: actually, I could just wait for drm-misc-fixes to be back merged and land it as a part of the -rc cycle. I'll do that, thanks again
<karolherbst>
HdkR: I haven't said I fixed it yet :D
<HdkR>
Finding the cause is halfway to fixing it :P
<karolherbst>
somehow not all memory gets unmapped
akselmo has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
<karolherbst>
ahhhhhhhhh
<karolherbst>
it's a multithreading bug
<karolherbst>
RIP myself
<alyssa>
karolherbst: rewrite zink in rust
<karolherbst>
alraedy on it
<alyssa>
you have 2 months before zmike is back
<karolherbst>
zmike just haven't noticed yet
<alyssa>
i'll rb as a christmas present
<karolherbst>
yeah
<karolherbst>
but where is the data race...
<karolherbst>
atomics within a locked region also make total sense
<karolherbst>
ehh maybe in this case it does
eukara has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
rasterman has quit [Quit: Gettin' stinky!]
Leopold__ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]