ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Surkow has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
Surkow|laptop has joined #dri-devel
oneforall2 has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
<Company>
ndufresne: is there an issue for the multiple-of-256 radeon issue?
<Company>
because it affects Vulkan, too
<ndufresne>
But it's not a bug, this is how the HW works, or perhaps I missed something?
<Company>
but I don't know that
<Company>
all I know is that the driver claims it can do NV12
<Company>
and when I hand it NV12 it says "nope, can't do that"
<ndufresne>
It's very annoying design indeed, on ChromeOS they created minigbm, that hardcode some HW knowledge and let the GPU driver allocate
<Company>
there could be a way for negotiating a proper stride, but I don't see one
<ndufresne>
Currently DRM does not give you a stride / width / height unless you ask the driver to allocate something
<ndufresne>
It's probably to the only thing for which V4L2 does a better job :-)
<Company>
the way the eglCreateImage() API reads (and the Vulkan API, but the Vulkan API doesn't even define how DRM formats map to VkFormats), the driver is the one to copy the memory if it can't deal with the stride
<ndufresne>
In VK though, there is ways a driver can inform of it's memory constraints (I'm just not very knowledgeable), Lynne might know more
<Company>
the question I'm trying to answer is "can this dmabuf be imported?"
<Company>
and the answer seems to be "who knows?"
<ndufresne>
On EGL side, today's answer is, yes if the EGLImage import succeed
<Company>
right
<Company>
but that doesn't help me when creating the dmabuf
<Company>
the question is what do I put in my GStreamer element's caps?
oneforall2 has quit [Remote host closed the connection]
<kode54>
Company: polaris?
<kode54>
I found a specific commit where nv12 broke for a 720 wide video, and only on polaris
<ndufresne>
Company: on GST, all the formats you can support, unfortunately, you can't guarantee zero copy on any of them
<Company>
ndufresne: if my sink says it can do NV12 and then eglCreateIamge() doesn't work in GTK, GStreamer can't help me
<ndufresne>
That's why we like modifiers, cause buffer with modifiers rarely fail to import
<ndufresne>
Company: you have to fallback to different way to send pixels to GL
<ndufresne>
Well, you can, nobody is forced, you would also document that you are only offering zero-copy
<Company>
ndufresne: but I don't have a different way - and even if I made one, that still wouldn't work with modifiers
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
xzhan34 has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
crabbedhaloablut has joined #dri-devel
<Company>
columbarius: my card has modifiers, but it claims to also do 0
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Allak has joined #dri-devel
cphealy has joined #dri-devel
Allak has quit [autokilled: This host violated network policy and has been banned. Mail support@oftc.net if you think this is in error. (2023-10-16 03:36:12)]
fxkamd has quit []
ced117 has quit [Remote host closed the connection]
ced117 has joined #dri-devel
<mareko>
do I need to use phi for x in NIR if I have: if (cond) x = ...; other_stuff(); if (cond) use(x); ?
JohnnyonFlame has quit [Read error: Connection reset by peer]
jewins has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
<kode54>
is there some environment variable for AMD to turn off framebuffer compression?
<kode54>
I found an artifact with Proton TkG running on an RDNA2 card, if I run Borderlands: GOTY Enhanced, and set the game to "Fullscreen" and set the resolution to something less than my native resolution
<kode54>
it went away when I switched the game to native resolution (which this card handles fine anyway)
<cmarcelo>
mareko: I think yes, the usage should be dominated by the definition and while we "know" cond is the same, I don't think at this level NIR can take that into consideration. you can have the phi = (x [from the if], undef [from not taking the if])
<daniels>
Company: eglCreateImage doesn’t copy
<Company>
doesn't it somehow have to get the buffer into vram?
Duke`` has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
<cmarcelo>
(and to be clear, I think the use() in the second cond would be use(ssa of the phi))
Haaninjo has quit [Quit: Ex-Chat]
fab has joined #dri-devel
<daniels>
Company: no
kts has quit [Quit: Konversation terminated!]
mclasen has quit [Ping timeout: 480 seconds]
<Company>
daniels: so who's gonna figure out then how to create a compatible buffer that radv is not failing to import?
<daniels>
well, if you want something that radv doesn’t fail on, you can always allocate via radv and upload to it
<Company>
sure
<Company>
but that assumes I have full control
<daniels>
if you want a bulletproof multi-device allocator for zerocopy buffers, we don’t have one of those
<Company>
but I'm just the toolkit here
* daniels
shrugs
<Company>
and I want to offer an API to app developers that's unlikely to break if they go to v4l or pipewire, grab a dmabuf and hand it to me
<daniels>
the slow thing works everywhere and all the time, but is slow. the fast thing is hard.
<Company>
does it have to be hard though?
<Company>
I mean, obviously it's gonna be harder than the slow thing
<daniels>
no, we just like irritating people
<Company>
dmabufs feel like that sometimes
<Company>
I mean, I don't mind telling people "if you allocate a buffer with DRM_FORMAT_FOO and modifier 12345, it needs to have a stride and alignment of 256 and whatever else I need to tell people
<Company>
but EGL pretends like all you need to know is the drm format and the modifier
tzimmermann has joined #dri-devel
<Company>
or it could be that alignment is part of the modifier, but then radv probably shouldn't advertise modifier 0
Duke`` has quit [Ping timeout: 480 seconds]
<daniels>
nah, alignment can't be part of the modifier
<daniels>
I assume your API's more complicated than you're letting on, since consuming devices have to be part of the allocation negotiation; as you've picked up, format/modifier sets are part but not all of it
<Company>
I don't have an API yet
<Company>
I'm trying to come up with one
<Company>
the format/modifier idea was the result of looking at EGL
<daniels>
stride alignment (to either pixels or macroblock units) is part of it, but that isn't always a single fixed number
bmodem has joined #dri-devel
<daniels>
formats/modifiers are the common bit that everyone agrees on so far, but not a complete answer
<daniels>
for more information, go look at the talks from past XDCs about how cross-device allocation is hard, and the design we've agreed on but hasn't yet been implemented
<Company>
also Wayland only exposes dmabufs I guess?
<Company>
*format/modifiers for dmabufs
<Company>
I guess it has the device in there, too
<Company>
I'm trying to come up with a GtkDmabufInformation kinda object that I can hand the application that enables them to create dmabufs that GTK can consume via GL/Vulkan (or pass through to the compositor)
<Company>
and then GStreamer and pipewire and whoever else can take that and set up their video stuff
<daniels>
sure, so those talks will explain what it would be that you'd have to surface for cross-device/subsystem/vendor/etc compatibility, otoh none of the allocation APIs to make use of that exist, so
<Company>
so it might not quite be ready for consumption yet
<Company>
and needs people from different projects to get together and agree on something and actually implement it
<daniels>
right now the zerocopy path involves doing actual allocations then trying imports to see whether or not they succeed; if they don't, you get to fall back to copying yourself
<daniels>
there's no 'just do something that is guaranteed to work everywhere' bulletproof api
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
<Company>
the hard part about "copying myself" is that I can't do that with a random dmabuf
<Company>
because if eglCreateImage() fails, all I have is an fd that I can't access
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
<Company>
so I need to talk to the actual creator of the dmabuf and have them do the thing for me
fab has quit [Read error: No route to host]
bmodem has quit [Excess Flood]
<daniels>
you can mmap dmabufs
fab has joined #dri-devel
bmodem has joined #dri-devel
<Company>
only linear ones I thought
kts has joined #dri-devel
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
pekkari has joined #dri-devel
fab has quit [Quit: fab]
i-garrison has quit []
i-garrison has joined #dri-devel
xroumegue has quit [Quit: WeeChat 2.3]
kzd has quit [Quit: kzd]
<daniels>
you can mmap non-linear dmabufs too, but the results will be non-linear
<Company>
so I'd need to have knowledge about the formats if I wanted to copy stuff out of it
aravind has joined #dri-devel
glennk has joined #dri-devel
fab has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
xroumegue has joined #dri-devel
simon-perretta-img has quit []
simon-perretta-img has joined #dri-devel
tursulin has joined #dri-devel
vliaskov has joined #dri-devel
vliaskov_ has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
ficoPRO10 has joined #dri-devel
cmichael has joined #dri-devel
oneforall2 has joined #dri-devel
sarahwalker has joined #dri-devel
<pq>
DemiMarie, yes; do everything in more reliable ways that we can test in CI without actual hardware first, then implement hardware off-loads, and the option to drop correctness requirements to allow use of even more hardware if wanted..
<pq>
robclark, what do you refer to with KHR_blend_equation_advanced? On Friday I was talking about a) EGL/GL importing YUV buffers and producing RGB samples automatically, and b) the use of KMS hardware to do color conversion operations in order to use KMS blending and avoid some GPU usage.
tyalie has quit []
<pq>
robclark, I've never used KHR_blend_equation_advanced and I don't know what I'd need it for.
tyalie has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest3570
sarahwalker has quit [Ping timeout: 480 seconds]
<robclark>
pq: ignoring (b) kms/display stuff, my point was for gpu the CSC is done by adding a matrix multiply in the shader for nearly all GPUs.. so for linear YUV, having the driver do it or having app do CSC in shader amounts to same thing. (The situation is different when you add modifiers in the picture.. not because of the CSC but because of how the GPU reads the data.. the CSC is still done in the shader. We could invent an extension to
<robclark>
return unconverted YUV and let app do whatever it wants with it.)
hansg has joined #dri-devel
<pq>
robclark, ah, sure. My problem is with EGL_EXT_image_dma_buf_import spec though. But if Mesa can have its own CI tests to enssure that things like EGL_YUV_COLOR_SPACE_HINT_EXT are actually respected, that would be useful.
<pq>
That cannot be tested in CTS AFAIU, because the spec does not require taking those hints into account at all.
frieder has quit [Ping timeout: 480 seconds]
mairacanal has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
<pq>
Since (Mesa) drivers can individually claim to support the hints but still hand-wave the implementation, if I want to promise correct YUV decoding to my users, I need to either test it on every compositor start-up or just avoid that direct YUV import path altogether. Of course, there will be users who don't care about strict correctness, so they can opt-in to use the import anyway.
frieder has joined #dri-devel
<pq>
EGL_YUV_COLOR_SPACE_HINT_EXT is the most obvious one, but the chroma siting hints are not just the right matrix, are they?
jfalempe has joined #dri-devel
<pq>
I don't particularly want raw YUV samples in my shaders per se, but since I haven't heard of any guarantees or test coverage, I have no choice. And EGL_EXT_image_dma_buf_import is at least missing the constant luminance variant, which would pull in the transfer characteristic too.
cmichael has quit [Ping timeout: 480 seconds]
<pq>
Supporting raw YUV sampling might be easier than adding the constant luminance support, and also more future-proof.
<pq>
in the end, there is much more than just the matrix at play here
<pq>
There is also ICtCp.
<pq>
The generic model would be matrix-TF-matrix for YUV-RGB conversion, but then there is also chroma siting.
<pq>
alternatively, if one could program a custom matrix as EGL_YUV_COLOR_SPACE_HINT_EXT, I think that would be enough for everything.
<pq>
except chroma siting
<gfxstrand>
dcbaker: If 1.3 could have everything we need, that would be amazing! :D
<Company>
pq: You'll probably have to have a fallback in place anyway - considering how basically any feature of the Vulkan Ycbcr spec is optional
<Company>
(and assuming that Vulkan specs are written against existing hardware features)
<pq>
yeah, there's two levels to this: optionality in the first place, and what can be expected when the optional feature is present.
<Company>
I also have no idea how it influences performance
<Company>
ie if the matrix run by the yuv hardware is faster (and if so, how much) than a shader
<pq>
right, I'm not even thinking about performance yet, just correctness
<Company>
and afaiu all the matrices convert between YUV and the sRGB colors, so if you have different primaries, you need to run a shader anyway
<pq>
no, that's fortunately not that bad
<pq>
the YUV-RGB conversion matrix is kind of independent of the colorimetry, though it is common to define both in the same spec.
<pq>
While a YUV-RGB matrix could be somehow optimal for a certain set of primaries and white point for certain use, it does not enforce the primaries or white point in any way.
<karolherbst>
cmarcelo: okay :) it all works in the end after I fixed the zink side
Company has quit [Quit: Leaving]
aravind has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
aravind has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
ficoPRO10 has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<wv>
currently trying to replace DRM in an application (cog/wpewebkit) by a drm-lease from a drm-master. It looks quiet well, gets detected and all. But does not pass the authenticate step?
<wv>
this is with drm: [3083033.269] wl_drm@5.authenticate(1)
<wv>
this is with a lease: [2887550.595] wl_drm@5.authenticate(1)
<wv>
I'm not really into these. Why is authentication failing? What needs to get authenticated where?
<wv>
using drm-lease-manager from AGL btw
apinheiro has joined #dri-devel
<karolherbst>
cmarcelo: mhh.. apparently for private memory it doesn't work, but I'm also not sure if it's supposed to work. I've done the same as for shared memory and spirv-val at least doesn't complain
<karolherbst>
but I also don't know if the CTS actually tests that private blocks alias
<karolherbst>
the nir passes kinda split it all apart and dce the store
<pq>
wv, that "authentication" is a legacy API for getting GPU rendering access approved by the "display server". Nowadays you don't use that, because we have render nodes that give you the same access with less hassle, and in a more secure way.
<pq>
wv, render nodes are /dev/dri/render*
<pq>
wv, I don't know if leased DRM devices are supposed to allow authentication or not.
<wv>
pq, what do you mean with nowadays? This is just on master... Who is initiating this authenticate? Is this mesa, or the client application?
<pq>
wl_drm was supposed to be a Mesa-internal Wayland extension, but it's possible that applications could be using it directly too, so I don't know.
<pq>
wl_drm was replaced with zwp_linux_dmabuf_v1 Wayland extension that is public, and with apps opening DRM render nodes directly (done by Mesa).
<pq>
wv, maybe check if you have a render node exposed and open-able by the app?
<pq>
wv, since I guess wpewebkit might be using Wayland internally, maybe it doesn't actually implement the display server side of zwp_linux_dmabuf_v1? Or maybe you need newer cog/wpewebkit? I'm just wildly guessing here.
<wv>
I'll have a look. I know it can run without weston running whatsoever, so just from console (using platform drm), but it gives thes wl_drm outputs anyway
ficoPRO10 has joined #dri-devel
neniagh_ has joined #dri-devel
neniagh has quit [Read error: No route to host]
DodoGTA has quit [Quit: DodoGTA]
glennk has joined #dri-devel
pekkari has joined #dri-devel
DodoGTA has joined #dri-devel
<pq>
wv, yeah, that is what makes me believe the app uses Wayland internally; you don't run any Wayland compositor as you know of. Hence there must be one inside the app.
<pq>
and it may well be that the auth fail is about the app talking to itself (components in different processes)
<pq>
wv, I wouldn't know if it might be even intentional that some processes of the app need to use wl_drm auth. I can imagine a reason to do so.
lemonzest has quit [Quit: WeeChat 4.0.5]
kts has joined #dri-devel
mclasen has joined #dri-devel
lemonzest has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<wv>
pq, well, if I can disable this auth somehow... I dont care a thing...
kts has joined #dri-devel
<wv>
is it an option to patch libdrm to return always true? will it havge other impacts?
<wv>
I'm in full control of the system, so...
<pq>
well, it's the kernel that says whether something is allowed or not, so patching libdrm only helps if the auth was unnecessary to begin with.
<pq>
try it?
kts has quit []
Guest3570 has quit [Remote host closed the connection]
karolherbst has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
pekkari has quit [Quit: Konversation terminated!]
sarahwalker has joined #dri-devel
mvlad has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
ungeskriptet is now known as Guest3588
ungeskriptet has joined #dri-devel
shashanks_ has quit [Remote host closed the connection]
Guest3588 has quit [Ping timeout: 480 seconds]
shashanks has joined #dri-devel
nh2042 has joined #dri-devel
frieder has joined #dri-devel
shashanks has quit [Remote host closed the connection]
frieder has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
nh2042 has quit []
kts has quit [Quit: Leaving]
robmur01_ is now known as robmur01
bmodem has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
onox[m] has quit []
aravind has quit [Ping timeout: 480 seconds]
tristianc6704 has joined #dri-devel
fab has quit [Quit: fab]
JohnnyonFlame has joined #dri-devel
jewins has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
apinheiro has quit [Quit: Leaving]
illwieckz has quit [Remote host closed the connection]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
fab has quit []
fab has joined #dri-devel
fab has quit []
mbrost has joined #dri-devel
frieder has joined #dri-devel
kzd has joined #dri-devel
hansg has quit [Quit: Leaving]
bmodem has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
<tnt>
So posting here in case this rings a bell in some intel experts mind :) In rusticl running on DG2 the upper half of the 'Y' dimension of the local group seems to not be executed when running on DG2. Works fine on iGPU 12th gen.
frieder has joined #dri-devel
Duke`` has joined #dri-devel
<tnt>
Actually localsize 1,1 / 1,2 / 1,4 / 1,8 work fine. starting from 1,16 then only the lower half of the workgroup "executes".
<hch12907>
Can anyone check whether they can access registry.khronos.org? For me, it just loads indefinitely until the connection times out
<tnt>
hch12907: works for me.
illwieckz has joined #dri-devel
<hch12907>
interesting...
<hch12907>
huh, I can visit the site just fine if I connect to it by IP (174.138.88.143)
<hch12907>
it can't be ipv6, can it?
<hch12907>
it is ipv6. I can't ping 2604:a880:800:10::985:a001
<hch12907>
weird that firefox isn't falling back to ipv4 though...
frieder has quit [Remote host closed the connection]
simon-perretta-img has joined #dri-devel
heat_ has joined #dri-devel
<fluix>
ipv6 doesn't respond for me either, but FF falls back. maybe something to do with your DNS server? not sure
<tnt>
I'm setting a bunch of debug env var ( NIR_DEBUG=print MESA_DEBUG=1 CLC_DEBUG=verbose,dump_spirv RUSTICL_DEBUG=program,clc ) and yet nothing gets printed ...
<robclark>
pq, re: EGL_YUV_COLOR_SPACE_HINT_EXT .. nir_lower_tex_options does have bt709/bt2020/etc.. which look like they are wired up in mesa/st. But the yuv import test coverage isn't great, so who knows.. Adding some piglit tests for this would be helpful, right now I would have no way to know if it was/wasn't working properly. (ps. sorry for delayed response.. xdc travel this week)
<hch12907>
not sure what's happening - other sites fallback to ipv4 just fine on FF. But nothing the /etc/hosts file can't fix I guess
yyds has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
pekkari has joined #dri-devel
DemiMarie has left #dri-devel [#dri-devel]
bmodem has quit [Ping timeout: 480 seconds]
ficoPRO10 has quit [Ping timeout: 480 seconds]
MrCooper has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
yyds has quit [Remote host closed the connection]
devarsht[m] has quit []
jfalempe has quit [Read error: Connection reset by peer]
jfalempe has joined #dri-devel
<austriancoder>
anybody has an idea for what mesa_glinterop.h is used?
pekkari has quit [Read error: No route to host]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
jessica_24 has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
airlied has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
MrCooper has quit [Ping timeout: 480 seconds]
airlied has joined #dri-devel
simon-perretta-img has joined #dri-devel
Surkow|laptop has quit [Quit: 418 I'm a teapot - NOP NOP NOP]
Surkow|laptop has joined #dri-devel
anholt has joined #dri-devel
ficoPRO10 has joined #dri-devel
cobralt^ has quit [Ping timeout: 480 seconds]
cobralt^ has joined #dri-devel
pa has joined #dri-devel
habernir has joined #dri-devel
habernir has quit []
simon-perretta-img has quit []
simon-perretta-img has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
ngcortes has joined #dri-devel
gouchi has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
Company has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
robert_mader has joined #dri-devel
robert_mader has quit [Quit: Leaving.]
ngcortes has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
i509vcb has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
benjaminl has quit [Remote host closed the connection]
benjaminl has joined #dri-devel
ngcortes has joined #dri-devel
Duke`` has joined #dri-devel
AnuthaDev has joined #dri-devel
<zmike>
austriancoder: EXT_external_objects
<mareko>
austriancoder: Mesa-ROCm interop
<tnt>
Also working on making it used for intel-compute-runtime interop. And rusticl uses it for its GL interop.
Haaninjo has quit [Quit: Ex-Chat]
alatiera is now known as Guest3630
alatiera has joined #dri-devel
fab has quit [Quit: fab]
ngcortes has quit [Read error: Connection reset by peer]
<austriancoder>
Thx
Thymo has quit [Write error: connection closed]
Thymo has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
mvlad has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
anholt has quit [Ping timeout: 480 seconds]
Guest3072 has quit []
gerddie6 has quit []
opotin65 has quit []
AnuthaDev has quit []
RAOF_ has quit [Remote host closed the connection]