<emersion>
pq: ^ you wrote an explanation of why it's not a good idea to check in scanner-generated code right?
<emersion>
if you have a link that'd be useful
AnuthaDev has joined #dri-devel
sadlerap1 has joined #dri-devel
sadlerap has quit [Ping timeout: 480 seconds]
Guest4655 has quit []
sima has joined #dri-devel
enick_702 is now known as go4godvin
i509vcb has quit [Quit: Connection closed for inactivity]
glennk has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
bmodem has quit [Ping timeout: 480 seconds]
pochu_ has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
hansg has quit [Quit: Leaving]
hansg has joined #dri-devel
<wv>
pq, you where a weston developer right? I'm trying to debug my gstwaylandsink to get the best memory path. But it's failing on dmabuf creation, so fall backs to SHM. Would you have any clue where to look for?
<wv>
it appears zwp_linux_buffer_params_v1_create is failing on me
<wv>
but I have no idea where this one is going to
<wv>
width, height, format is 360x240, NV12
hansg has quit [Quit: Leaving]
hansg has joined #dri-devel
<pq>
emersion, I don't think I can find any explanation I might have written about checking in wayland-scanner generated code. But I should have no problem thinking up the points again.
luben has quit [Ping timeout: 480 seconds]
<pq>
wv, hmm, I wonder if weston actually had any debugging already written for that...
<pq>
wv, it's most likely Mesa that rejects the dmabuf when you get a graceful failure. Or whatever you use as your EGL implementation.
<wv>
well, the gracefull failure is gstreamer reporting it cannot create the linux-dmabuf buffer, depending on !data.wbuf
<wv>
if I know the code where zwp_linux_buffer_params_v1_create is actually calling to, I can maybe add some debugging there, but I'm a bit lost currently
<pq>
the graceful error I'm talking about is the Wayland event zwp_linux_buffer_params_v1.failed.
<pq>
wv, right, so you can see that Weston's linux-dmabuf.c has very few paths that would fail without sending a protocol error.
<pq>
most likely it's gl_renderer_import_dmabuf() that fails
<wv>
how can I output wl_resource_post_error?
<pq>
wv, env var WAYLAND_DEBUG=client, but I would hope that gst would print it too somehow.
<pq>
it's a protocol error, and protocol errors always disconnect the client, which means the app usually quits
<pq>
it cannot fall back
<pq>
that's why I think you are not hitting a protocol error
<pq>
also modifier is linear for both, so nothing odd here
<pq>
wv, remind me, is this upstream version of Weston and Mesa drivers?
<wv>
yes, weston 10.0.2, mesa 23.1.8
<pq>
my likely guess is that the GPU driver just doesn't like the dmabuf for some reason
<wv>
I'm just seeing my weston version is quiet off mesa... Upstream weston is already at 12.x
<pq>
IIRC NV12 should have two import paths in Weston, as NV12 and as R8+GR88, and both would fail here.
<wv>
Well, I've limited my planes to be rgb565, maybe that can be an issue?
<pq>
well, should be easy to get the latest Weston and test, right?
<pq>
I don't remember anything that might have improved that inside Weston, but it's possible
<pq>
it could be something as silly as the dmabuf pointing to wrong type of memory, like VRAM vs. sysram, or some more subtle difference
frankbinns has quit [Quit: Page closed]
frankbinns1 has joined #dri-devel
<pq>
that's why zwp_linux_dmabuf_v1 latest version tells the client which DRM devices the dmabuf should work with, so that the app can try its best
frankbinns1 has quit []
<pq>
I don't know how much gst tries to make use of that information
frankbinns has joined #dri-devel
hansg has quit [Quit: Leaving]
<wv>
I'll try some things out. Would it be possible that it's because I limited my plances capabilities to be rgb565 only?
<pq>
of course!
<pq>
erm...
glennk has quit [Ping timeout: 480 seconds]
<pq>
if you hacked EGL, then yes
<pq>
NV12 is not RGB565, obviously
<pq>
and if you removed NV12 support from KMS planes, then naturally NV12 cannot be scanned out directly but needs to go through a GPU copy/conversion.
<pq>
For dmabuf import in Weston though, the important part is EGL.
<pq>
Weston will reject any dmabuf it cannot import to EGL for texturing by the GPU, because that's is the ultimate fallback path that always needs to work.
sgruszka has quit [Remote host closed the connection]
<pq>
emersion, feel free to lift that to anywhere more accessible :-)
glennk has joined #dri-devel
<tomba>
In a situation where the bootloader sets up the display, and simplefb provides an early fb, are there any mechanisms/helpers to move/copy the early fb or its contents to the main DRM driver's fb?
<tomba>
(In a context of the fb being in the system ram)
kts has joined #dri-devel
sukrutb has quit [Ping timeout: 480 seconds]
<cwabbott>
alyssa: I'm looking at one of the GL CTS double tests because of something else and it looks like there's a bug with the preamble pass where it's storing extra values in the preamble that are never used
<cwabbott>
it's doing ceil() of a dvec2 uniform, and thanks to your work the entire thing is getting shoved in the preamble and the main shader just reads 4 constants, however the preamble is writing way more than 4 constants
<cwabbott>
the test is KHR-GL46.gpu_shader_fp64.builtin.ceil_dvec2 if you wanna reproduce
<cwabbott>
I'm not sure if I'll have time to look into it
<mclasen>
yes, I've read that (or rather, the identical part of the xml), but my dmabufs are coming from pipewire or gstreamer. Should I give them the device? If so, how?
<pq>
I guess the most fundamental problem is still unsolved? some sort of API where you could list all devices and tell it allocate.
<pq>
or The Unix Device Allocator project
glennk has quit [Ping timeout: 480 seconds]
<swick[m]>
mclasen: in general you could try to allocate on that device to increase your chances to get direct scanout but I'm not sure if pipewire or gstreamer can be told which device to use for something
<emersion>
there is no "identical part of the xml"
<emersion>
the xml and this document are complementary
<pq>
...or to get dmabuf import working at all to begin with
<swick[m]>
true
<mclasen>
emersion: good to know, I had so far mistaken the xml as the sole protocol docs
kts has quit [Ping timeout: 480 seconds]
sgruszka has quit [Ping timeout: 480 seconds]
<emersion>
the xml is pretty terse/dry because it's normative
<emersion>
the docs give specific guidelines for specific client architectures
<mclasen>
thanks, very useful
<emersion>
"if your client does XXX, then this is how you should use the protocol"
<emersion>
(and in particular interpret the device events)
glennk has joined #dri-devel
fab has quit [Quit: fab]
Danct12 has quit [Quit: WeeChat 4.1.0]
<Company>
next step: do a fullscreen playback of a screencast and try to make it hit direct scanout
<Company>
and if you do it right, you invented a method to make the compositor loop-de-loop present
<Company>
the reddit guy with the drawing tablet is gonna love that
<emersion>
sway supports this already, via wl-mirror
<Company>
the one who used obs to mirror his HDR monitor onto the tablet when drawing
<alyssa>
in the sense it no longer stores the if conds
<alyssa>
BUT it's a huge shaderdb loss
<alyssa>
because it also no longer stores if-conds for if's that we end up not moving
<alyssa>
(regressing stuff where you have a big uniform expression for a condition but the interior of the if is not uniform)
<alyssa>
see android/angle/hill_climb_racing/73.shader_test in rob's shaderdb for ex
<alyssa>
i've paged out the candidate vs can_move vs replace vs .. details so not sure rn what the proper fix is
rasterman has quit [Quit: Gettin' stinky!]
<MrCooper>
Company: the client would probably get stuck, because the compositor can't release the scanout buffer
<Company>
MrCooper: there's a pool involved though, so that should work (assuming the pool is large enough)
<MrCooper>
hmm, frozen screen might actually be the expected result for that, since the client is asking the compositor to present what it's already presenting
<Company>
it's a fun question to think about what should happen
<Company>
you can then take 2 monitors and play the game with a screencast of monitor 1 displaying on monitor 2 and vice versa
<Company>
do they display the same buffer?
dtmrzgl has joined #dri-devel
pochu has quit [Quit: leaving]
<robclark>
tursulin: a-b
<tursulin>
robclark: ty!
Danct12 has joined #dri-devel
sgruszka has joined #dri-devel
heat has joined #dri-devel
tristianc6704 has quit [Read error: No route to host]
hansg has quit [Quit: Leaving]
dtmrzgl has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
tristianc6704 has joined #dri-devel
yuq825 has quit []
kzd has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit []
simon-perretta-img has joined #dri-devel
mdroper has joined #dri-devel
luben has joined #dri-devel
shashanks__ has quit [Remote host closed the connection]
hansg has joined #dri-devel
kzd has joined #dri-devel
Duke`` has joined #dri-devel
ungeskriptet is now known as Guest4701
ungeskriptet has joined #dri-devel
ungeskriptet is now known as Guest4702
ungeskriptet has joined #dri-devel
<gfxstrand>
dcbaker: Any progress on 32-bit proc macro stuff?
<gfxstrand>
dcbaker: I'd really like to land NAK next week and that's the blocker.
<Venemo>
is there any reason we have "feature", "feature_request" and "enhancement" tags in GitLab? it seems they are redundant
Guest4701 has quit [Ping timeout: 480 seconds]
Guest4702 has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Quit: Leaving]
djbw has joined #dri-devel
<gfxstrand>
Do the a*_vk_full tests normally fail?
<pendingchaos>
I suppose that features are user facing (an extension, for example), while enhancements (an optimization or maybe a cleanup) might not be
<gfxstrand>
cwabbott, danylo: They're blowing up on !25894 and I don't think anything I'm doing there should affect blits...
<cwabbott>
gfxstrand: there's a commit from anholt_ that fixes the expectations, I think
<alyssa>
gfxstrand: also _full is a nightly fwiw
<cwabbott>
usually they blow up because someone updated CI and forgot to run the _full jobs
<cwabbott>
sorry, updated deqp
glennk has joined #dri-devel
<cwabbott>
the blit tests failing are actually sorta your fault because we have the same issue intel had where we canonicalize NaNs when copying and you were the one to sign onto disallowing copies doing that
<alyssa>
...heh
<alyssa>
In file included from ../src/asahi/lib/shaders/texture.cl:6:
<cwabbott>
that happened like 6 years ago, but then later someone (qcom?) ran into the same issue, didn't see your issue, and changed the CTS to avoid NaNs in the copy tests, then recently someone noticed that and reverted it
<alyssa>
In file included from /usr/lib/llvm-15/lib/clang/15.0.6/include/stdint.h:52:
<alyssa>
/usr/include/stdint.h:26:10: fatal error: 'bits/libc-header-start.h' file not found
<alyssa>
Error executing LLVM compilation action.
<alyssa>
~~opencl was a mistake i regret my choices~~
<ccr>
:/
<alyssa>
happening ci but not locally, ofc
<ccr>
of course.
<cwabbott>
gfxstrand: I'm going to have to determine exactly how screwed we are later
<dj-death>
alyssa: I was going to ask, how's that going
<dj-death>
?
<alyssa>
dj-death: waiting on review mostly
<alyssa>
WARNING: Tried to mix libraries for machines 0 and 1 in target 'asahi_clc' This will fail in cross build.
mdroper has quit [Read error: Connection reset by peer]
<alyssa>
exciting
<cwabbott>
decompressing uses the same path as normal blits, so we can't just decompress and blit with a different format since the decompression step will also canonicalize
<cwabbott>
it sounds like that was what you did in anv to solve the problem, but we can't do that
oneforall2 has joined #dri-devel
<alyssa>
exciting
<gfxstrand>
cwabbott: Oh, that' makes a depressing amount of sense.
<gfxstrand>
cwabbott: Sadly, I think the whole thing with copies is pretty settled at this point. It's a memcpy
<gfxstrand>
Which sucks in some cases
<cwabbott>
yeah, that might completely screw us over
<cwabbott>
as in, no compression at all for any float formats
<gfxstrand>
But it's been a while
<gfxstrand>
Yeah, Intel can't compress 11_11_10 for that reason
<gfxstrand>
And it costs a bit of perf in a few benchmarks
<alyssa>
this sounds like a vk spec bug
<cwabbott>
isn't R16 more common than 11_11_10 though?
<alyssa>
>V
<cwabbott>
R16_FLOAT that is
<gfxstrand>
Yeah, R16_FLOAT kinda sucks but Intel can compress that as R16_UINT
<cwabbott>
we... can't
<gfxstrand>
Ugh
<cwabbott>
qcom added stuff on a7xx to do reinterpreting copies correctly
<cwabbott>
but it got brought up again recently, where someone pointed to this issue
<cwabbott>
which i think led to some CTS changes aiming to avoid NaNs getting reverted breaking us
vcunat has joined #dri-devel
<cwabbott>
qualcomm themselves have stopped caring, and I would love to not care about a6xx too, but it's what has actual users at this point
<anholt_>
gfxstrand: lots of vk full fails due to timeouts currently post cts 1.3.7.0. I'm probably going to disable those jobs shortly, in the absence of a workaround.
<anholt_>
gfxstrand: there's one job iirc that does complete but didn't get updated, which is in my draft VK CTS MR.
vcunat has quit []
junaid has joined #dri-devel
diego has left #dri-devel [#dri-devel]
<cwabbott>
hmm, maybe it's just happenstance that the test changed to introduce NaNs into the mix
<gfxstrand>
anholt_: In this case, it was the copy fails that cwabbott just mentioned.
junaid has quit [Remote host closed the connection]
<cwabbott>
it was happening because the source texture is white (1.0) and 1.0 for unorm_16 and snorm_16 are a NaN in fp16
dviola has joined #dri-devel
rasterman has joined #dri-devel
luben_ has joined #dri-devel
luben_ has quit []
<gfxstrand>
Yeah, it's also a problem for INT16_MIN in an SNORM image
luben has quit []
luben has joined #dri-devel
<cwabbott>
yeah, we already disable compression for snorm (although on a7xx we can reinterpret snorm as unorm)
<cwabbott>
I have to do more research, but I think the situation is that on a7xx we can make everything work perfectly by using new HW features but on a6xx we're just screwed
<cwabbott>
especially if we have to disable compression for all floating-point formats
AnuthaDev has quit []
i509vcb has joined #dri-devel
<alyssa>
sigh
<alyssa>
I suspect this will screw over M1 too..
<DemiMarie>
Time for a global configuration file?
rcf has quit [Quit: WeeChat 3.8]
lynxeye has quit [Quit: Leaving.]
<DemiMarie>
That would allow users to select between “I want full conformance at the cost of performance” and “I want improved performance at the cost of being slightly out of spec in ways that will almost certainly not break anything”
<cwabbott>
alyssa: there's a nuclear option here, but you won't like it
<cwabbott>
can't believe I'm even typing this, but...
<DemiMarie>
cwabbott: what about allowing users to pick between fast and conformant?
<alyssa>
we haven't r/e'd the compression algo and i'd rather not
<cwabbott>
me too
<DemiMarie>
I know that certain Arm CPUs allow choosing between “RunFast” mode (flush to zero + denormals are zero + no traps), which is implemented entirely in hardware, and strict conformance mode, which requires certain operations to be implemented in software.
<DemiMarie>
alyssa: is this because of effort or because of e.g. patents?
pochu has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
<alyssa>
hopefully we can cast to uint
<alyssa>
unsure
simon-perretta-img has quit []
simon-perretta-img has joined #dri-devel
shalem has joined #dri-devel
<alyssa>
dj-death: review welcome ;)
<alyssa>
(big MR but most of it is driver changes, just a few common code commits on top)
hansg has quit [Ping timeout: 480 seconds]
sukrutb has joined #dri-devel
gouchi has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
eukara has quit []
eukara has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
cyrinux has quit []
cyrinux has joined #dri-devel
sgruszka has quit [Remote host closed the connection]
luben has quit [Ping timeout: 480 seconds]
shalem has quit []
Company has quit [Read error: No route to host]
Company has joined #dri-devel
Kayden has quit [Quit: -> JF]
Haaninjo has joined #dri-devel
fab has quit [Quit: fab]
antoniospg has joined #dri-devel
luben has joined #dri-devel
<bl4ckb0ne>
are all the gl_renderbuffer_attachment Zoffset and CubeFaceMap field the same for a given gl_framebuffer?
<bl4ckb0ne>
im trying to add a given layer to `do_blit_framebuffer`
mripard has quit [Quit: mripard]
dviola has quit [Quit: WeeChat 4.1.0]
<bl4ckb0ne>
Zoffset is set at 2 places in fbobject.c
frieder has quit [Remote host closed the connection]
mclasen has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
<austriancoder>
emersion: pq: thanks for the feedback .. will try to generate the files. Expect from the wayland-scanner thing.. does the rest of the wl changes look okay?
<emersion>
yeah, sounds fine
<emersion>
dispatch_pending, not sure why that call is necessary though
rasterman has joined #dri-devel
<austriancoder>
emersion: without it none listener was called and there was no window shown that displays .. in my case some green quads