<MrCooper>
zamundaaa[m]: remind me, how many microseconds before start of vblank does kwin aim to call drmModeAtomicCommit at the latest?
Kayden has joined #dri-devel
<jasuarez>
I'll try but can't promise. Let's see if apinheiro can do it
Company has joined #dri-devel
<zamundaaa[m]>
MrCooper: 1500
<MrCooper>
hmm, seems pretty high; how did you arrive at that?
<zamundaaa[m]>
Testing on various hardware until barely any frames were too late anymore
<zamundaaa[m]>
Note that when you move the cursor for example, it might still do some work before the actual atomic commit happens. So the real commit time can be a bit later
<MrCooper>
right, I mean specifically when drmModeAtomicCommit is called, but it sounds like you're not measuring that?
<zamundaaa[m]>
Right now we're not, but I plan to change that because we've received bug reports that on some CPU+driver combinations the atomic tests in those 1500us take so long we miss the deadline
karenw has joined #dri-devel
<MrCooper>
ah, that's including test commits, makes sense then, thanks!
<Hazematman>
suspect one of the changes is stopping the extension `GLX_EXT_import_context` from being advertised (or prehaps the changing the glx version) which is preventing this function from being avaliable
<DemiMarie>
Which GPUs have decent fault isolation, in that they allow reliably killing one context?
<DemiMarie>
That could take the form of a VRAM-preserving reset combined with a driver configured to only allow one context to run at a time.
<DemiMarie>
I know that some hardware faults cannot be recovered from this way, but I also don't care, because hardware problems can always crash the system. I only care about software faults.
<zmike>
Hazematman: I don't think any of my changes affected anything related to versioning or (that) extension enablement
<zmike>
there is no diff in glxinfo output either
<Hazematman>
If apinheirois not able to do, in a few hours when I'm back home i can try to bisect it.
<Hazematman>
Is there any easy way to grab the trace file to run locally?
amarsh04 has quit [Read error: Connection reset by peer]
amarsh04 has joined #dri-devel
<jenatali>
zmike: A heap allocation was leaked.
<jenatali>
That test runs with the Windows equivalent of valgrind (app verifier)
<zmike>
how is that possibly a new issue from this MR which just changes build stuff?
<jenatali>
zmike: why is there a link_whole in there?
<jenatali>
That... seems like a really bad idea
<zmike>
I was getting build errors
<jenatali>
That duplicates gallium into libva
<zmike>
I'm really not a meson expert, and people keep raising issues that I'm struggling to fix
<jenatali>
It's probably some thread local thing that's reporting the leak but it's just a symptom of things being in that library that shouldn't be, I think
<jenatali>
zmike: that's not really a meson thing. Link_whole means to take all the obj files and forcibly link them, instead of specifying a .a archive lib and letting the linker just pull what it needs
<zmike>
...I'm also not a linking expert
<jenatali>
Heh
<zmike>
you ask a guy with a toolbox full of hammers for help, and you get what he's got
<jenatali>
But yeah that's the wrong change. I haven't been following the refactoring too closely to know what the right one is but it's definitely not that
kts has joined #dri-devel
<zmike>
I will pray that some kind meson god takes notice and posts a one-liner to fix everything
sukuna has joined #dri-devel
<gpiccoli>
Hey folks, a maybe silly question: do we have a "nodrm" parameter, to fully disable DRM and all potential GPU drivers that rely on that? Could be nographics, nogfx..the name of such parameter is a matter of choice
<gpiccoli>
I think we don't have that, I've achieved that (I think?) by initcall_blacklist'ing drm_core_init
<gpiccoli>
a bit hacky, but seems to work. In case we don't have such nogfx parameter, would that be useful/accepted?
tzimmermann has quit [Quit: Leaving]
<jenatali>
zmike: Got a link to the linker errors you were seeing without link_whole?
<zmike>
jenatali: you can check some of the earlier pipelines in the MR
warpme has quit []
leizhou has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<jenatali>
But that also indicates that the dynamic pipe loader targets also have a full copy of gallium?
<jenatali>
Lemme see how bad we've messed things up so far
Company has quit [Remote host closed the connection]
Company has joined #dri-devel
karenw has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
warpme has quit []
<jenatali>
zmike: On Windows, all of the targets that link to libgallium_dri should link to libgallium_wgl instead. If it's easier, we can rename the meson target to libgallium_dri (or maybe libgallium_shared would be better)
<zmike>
hm
<jenatali>
Then if you're still getting linker errors after that from unresolved externals, it should just be a matter of adding them to src/gallium/targets/wgl/gallium_wgl.def
<zmike>
so you're suggesting do that instead of link_whole?
<jenatali>
I think so. Let me double-check with Sil if that's a problem for va, but I don't think it's a problem for any of the other gallium-based targets
kaiwenjon has quit [Quit: WeeChat 3.8]
kxkamil has quit []
LeviYun has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
<zmike>
I pushed an update
sukuna has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
<sima>
airlied, I guess we can wait with drm-next until monday so it starts with -rc3?
<jenatali>
zmike: If you're okay with it, I can push some Windows tweaks. Chatted with Sil and we'd like to keep the gallium bits for video statically linked into the various frontends (for better or worse)
<jenatali>
So we've got (OpenGL32.dll / libEGL.dll / libGLESv2.dll) dynamically linked against libgallium_wgl.dll, and then the video frontends each have a copy of gallium
<Hazematman>
<zmike> "https://gitlab.freedesktop.org/..."; <- I'm not able to reproduce the crash on my pi :/ I suspect I'm not running eglretrace in the same way as ci. Maybe I'm missing some env vars or something
smaeul has joined #dri-devel
<zmike>
ughhhhh
<zmike>
jenatali: I'm 100000% okay with literally anyone pushing anything to that MR
<zmike>
Hazematman: I tried to repro using all the same env vars on a few setups and I got nothing
<zmike>
I don't get how it only triggers on those few jobs when there's so many more trace jobs
<daniels>
Hazematman: eric_engestrom can help you reproduce when he’s back in a week
warpme has joined #dri-devel
jernej_ has quit []
sassefa_ has quit []
Kayden has joined #dri-devel
jernej has joined #dri-devel
DarkShadow4444 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
DarkShadow44 has quit [Ping timeout: 480 seconds]
kaiwenjon has quit [Ping timeout: 480 seconds]
warpme has quit []
leizhou has quit [Remote host closed the connection]
LeviYun has joined #dri-devel
cyrinux has quit []
LeviYun has quit [Ping timeout: 480 seconds]
cyrinux has joined #dri-devel
leizhou has joined #dri-devel
gouchi has joined #dri-devel
kxkamil has joined #dri-devel
alih has quit []
LeviYun has joined #dri-devel
kaiwenjon has joined #dri-devel
kaiwenjon has quit []
leizhou has quit [Remote host closed the connection]
<airlied>
sima: I didn't merge drm-misc-next yet because it had some amd stuff in there that was getting reverted
<airlied>
I just forgot to say that out loud until now
<airlied>
since it was a uapi change that needed reverting
<sima>
oops, but I guess tzimmermann will send the next pr tomorrow
<sima>
which should have the reverts
<airlied>
yup, just have to make sure nobody regens the mesa uapi headers for xe from drm-next :)
<airlied>
since they might get the amdgpu ones as well
glennk has quit [Ping timeout: 480 seconds]
<sima>
oh right, perfect timing :-/
<sima>
but I guess usually people only update the one header they care about ...
bmodem has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
sassefa has joined #dri-devel
kaiwenjon has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
alyssa has quit [Quit: alyssa]
LeviYun has joined #dri-devel
Duke`` has joined #dri-devel
LeviYun has quit [Remote host closed the connection]
smaeul has quit [Quit: Down for maintenance...]
warpme has quit []
kaiwenjon has joined #dri-devel
Duke`` has quit []
LeviYun has joined #dri-devel
gouchi has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
epoch101 has quit []
LeviYun has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
nerdopolis has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
frieder has quit [Remote host closed the connection]
<Lynne>
gfxstrand: yay, your branch works perfectly
guludo has quit [Quit: WeeChat 4.3.5]
smaeul has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<jenatali>
zmike: Ok yeah I tried looking at it and from the Windows side of things it looks like it should be 036e75a9 (i.e. your second try in that MR). I think I don't have enough of an understanding of the Linux linking problems...
leizhou has quit [Remote host closed the connection]
Mangix has quit [Remote host closed the connection]
Company has quit [Remote host closed the connection]
Company has joined #dri-devel
LeviYun has joined #dri-devel
<gfxstrand>
Lynne: What are you testing with?
<Lynne>
ffmpeg
<gfxstrand>
Cool
<gfxstrand>
I've got one more CTS failure to track down and then I think it's pretty much ready to go
LeviYun has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
<Lynne>
there is an issue with multiplane images, you don't seem to consider them yet
<gfxstrand>
Oh? I don't see any reason why they wouldn't work.
<gfxstrand>
That branch is also fast-moving and I literally pushed 30 seconds ago, so...
leizhou has joined #dri-devel
<gfxstrand>
Which is to say that descriptor buffer should work just as well with multiplane as normal descriptors do
Mangix has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
feaneron has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<Lynne>
you're right, I do get all planes
<Lynne>
but the brightness is 2 bits or so, not 8, so the output is almost fully dark (==green in yuv terms)
<Lynne>
multiplane or single-plane images don't matter, as long as they pass through a descriptor buffer for processing
<gfxstrand>
Weird. Maybe something's wrong with your samplers?
<gfxstrand>
Are you passing the sampler into GetDescriptorEXT?
<gfxstrand>
You have to with descriptor buffer even though it's an immutable sampler in the descriptor set layout
LeviYun has joined #dri-devel
<Lynne>
no, I'm using combined image samplers
Company has quit [Remote host closed the connection]
<gfxstrand>
Yes, you have to use combined image/samplers for YCbCr
<gfxstrand>
But there's a difference between descriptor buffer and legacy descriptor sets. With legacy descriptor sets, the sampler you pass in is explicitly ignored in favor of the one in the descriptor set layout. With descriptor buffer, you have to pass the sampler into GetDescriptorEXT because we don't know anything about the descriptor set layout at that time.
<gfxstrand>
Just me spit-balling as to why there would be a difference between the two paths
<Lynne>
just checked, I am passing the sampler properly
<gfxstrand>
:-/
<gfxstrand>
And the classic descriptor path works okay?
nopjmp has quit [Remote host closed the connection]
<Lynne>
I don't have a classic descriptor path, I deleted it with a passion
<Lynne>
if you've got ffmpeg 7.0, you could probably replicate
LeviYun has quit [Ping timeout: 480 seconds]
nopjmp has joined #dri-devel
<gfxstrand>
Ah
<Company>
(GTK has a classic YUV path, but no descriptor buffers yet)
MagicPoncho has joined #dri-devel
<gfxstrand>
I'm pretty sure YUV works. The CTS has a LOT of YUV tests and we pass them all.
<gfxstrand>
Why it's not working for ffmpeg, I don't know.
leizhou has quit [Remote host closed the connection]
<Lynne>
thie issue happens on rgba too, just tested
<gfxstrand>
Okay, then it's not the YUV path
<gfxstrand>
That's very odd
<Company>
might be dmabufs
<Company>
imported ones I mean
<Lynne>
we don't use dmabufs in ffmpeg, we create basic pure vulkan images
<gfxstrand>
Not unless the format is wrong.
<gfxstrand>
What format are you using?
<gfxstrand>
Everybody's favorite 8-bit or something a bit more interesting?
<Lynne>
no, everyone's favorite UNORM 8bit RGBA
<Company>
what formats does nvidia do btw?
<Company>
NV12 and P010? More fancy ones>
<Company>
?
<gfxstrand>
Okay, that's even weirder then
vliaskov_ has quit [Ping timeout: 480 seconds]
MagicPoncho has left #dri-devel [#dri-devel]
<gfxstrand>
I know RGBA8 works
<Lynne>
its weird, even fancy 10bit multiplane yuv images experience the same issue
<Lynne>
in the same way, so underneath, they do work, just that everything breaks in the same way
<zmike>
gfxstrand: did you test zink?
<gfxstrand>
zmike: not yet
<zmike>
the final boss awaits.
<gfxstrand>
lol
<gfxstrand>
Lynne: Are you using buffer views for anything?
<ccr>
"why did that autosave just happen and this ominous music started playing?"
<Lynne>
gfxstrand: false alarm, the filter I was testing with was bitrotten, everything works perfectly
<gfxstrand>
lmao
<gfxstrand>
\o/
<gfxstrand>
Once again, NVK has no bugs. :P
<Lynne>
download performance is legendarily slow though, 1fps on 1080p yuv420p
<gfxstrand>
Are you using HOST_CACHED memory or just HOST_VISIBLE?
<Lynne>
just host visible
<gfxstrand>
Then you're reading through a write-combein map
<Lynne>
HOST_CACHED is normal speed though
<gfxstrand>
Yeah, you want HOST_CACHED for downloads
<Lynne>
the thing is we readout the downloaded buffer to ram via the CPU-native non-temporal read instructions
<Lynne>
so non-cached paths would be more optimal
<gfxstrand>
I'm not sure how that stuff interacts with going across PCIe
<gfxstrand>
But I'm pretty sure non-temporal won't save you if you're going across the PCI bus.
<Lynne>
is there a way to tell that CACHED is more optimal?
<gfxstrand>
That's tricky
<gfxstrand>
On a discrete card, typically HOST_VISIBLE + DEVICE_LOCAL means that it lives in VRAM and you're getting a write-combine map
<gfxstrand>
On a UMA, everything is going to be HOST_VISIBLE + DEVICE_LOCAL + HOST_CACHED except for the uncached stuff which will be HOST_VISIBLE + DEVICE_LOCAL
<gfxstrand>
We don't have a bit for "Seriously, don't read from this map. You'll regret it"
<gfxstrand>
D3D12 actually does better at this because they simply advertise upload vs. download vs. device