ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
tristianc6704 has joined #dri-devel
<Lynne>
is there someone who picked up the gsp firmware patchset after skeggs?
alyssa has quit [Quit: alyssa]
kzd has quit [Quit: kzd]
YuGiOhJCJ has joined #dri-devel
kzd has joined #dri-devel
matheus has joined #dri-devel
matheus has left #dri-devel [#dri-devel]
crabbedhaloablut has quit []
Surkow|laptop has quit [Ping timeout: 480 seconds]
Surkow|laptop has joined #dri-devel
columbarius has joined #dri-devel
<airlied>
Lynne: dakr and myself mostly so far
co1umbarius has quit [Ping timeout: 480 seconds]
heat_ has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
mstoeckl has joined #dri-devel
yyds has joined #dri-devel
mceier has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
luben has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
Company has quit [Quit: Leaving]
<kode54>
oops
<kode54>
AUR package intel-gpu-tools-git fails to build because they forgot to run `ninja -C build igt-gpu-tools-doc` before attempting to install
<kode54>
I reported that to them
<kode54>
aww, boo, I thought it somehow would have a per-process GPU load analyzer that worked on amdgpu, since there's some sort of amdgpu stuff going on in that project tree
<kode54>
oh, somehow never heard of amdgpu_top
jewins has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
mbrost has joined #dri-devel
<kurufu>
nvtop should be integrated with the new fdinfo interface that shows per process load.
<kurufu>
(for amdgpu despite the name of the tool)
shashanks__ has joined #dri-devel
tyalie has quit []
tyalie has joined #dri-devel
bmodem has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
bbhtt has quit [reticulum.oftc.net liquid.oftc.net]
calebccff has quit [reticulum.oftc.net liquid.oftc.net]
shashanks_ has quit [reticulum.oftc.net liquid.oftc.net]
KitsuWhooa has quit [reticulum.oftc.net liquid.oftc.net]
kbingham has quit [reticulum.oftc.net liquid.oftc.net]
BobBeck has quit [reticulum.oftc.net liquid.oftc.net]
pixelcluster has quit [reticulum.oftc.net liquid.oftc.net]
lcn has quit [reticulum.oftc.net liquid.oftc.net]
vyivel has quit [reticulum.oftc.net liquid.oftc.net]
melonai has quit [reticulum.oftc.net liquid.oftc.net]
Amber_Harmonia has quit [reticulum.oftc.net liquid.oftc.net]
fdu has quit [reticulum.oftc.net liquid.oftc.net]
kj has quit [reticulum.oftc.net liquid.oftc.net]
cyrinux has quit [reticulum.oftc.net liquid.oftc.net]
italove8 has quit [reticulum.oftc.net liquid.oftc.net]
aissen has quit [reticulum.oftc.net liquid.oftc.net]
minecrell has quit [reticulum.oftc.net liquid.oftc.net]
sre has quit [reticulum.oftc.net liquid.oftc.net]
ndufresne has quit [reticulum.oftc.net liquid.oftc.net]
enunes has quit [reticulum.oftc.net liquid.oftc.net]
Emantor has quit [reticulum.oftc.net liquid.oftc.net]
fkassabri[m] has quit [reticulum.oftc.net liquid.oftc.net]
pinchartl has quit [reticulum.oftc.net liquid.oftc.net]
cwfitzgerald[m] has quit [reticulum.oftc.net liquid.oftc.net]
AlexisHernndezGuzmn[m] has quit [reticulum.oftc.net liquid.oftc.net]
samueldr has quit [reticulum.oftc.net liquid.oftc.net]
dantob has quit [reticulum.oftc.net liquid.oftc.net]
aradhya7[m] has quit [reticulum.oftc.net liquid.oftc.net]
tak2hu[m] has quit [reticulum.oftc.net liquid.oftc.net]
EricCurtin[m] has quit [reticulum.oftc.net liquid.oftc.net]
ram15[m] has quit [reticulum.oftc.net liquid.oftc.net]
x512[m] has quit [reticulum.oftc.net liquid.oftc.net]
aura[m] has quit [reticulum.oftc.net liquid.oftc.net]
egalli has quit [reticulum.oftc.net liquid.oftc.net]
Ella[m] has quit [reticulum.oftc.net liquid.oftc.net]
Armote[m] has quit [reticulum.oftc.net liquid.oftc.net]
treeq[m] has quit [reticulum.oftc.net liquid.oftc.net]
ttayar[m] has quit [reticulum.oftc.net liquid.oftc.net]
jasuarez has quit [reticulum.oftc.net liquid.oftc.net]
Eighth_Doctor has quit [reticulum.oftc.net liquid.oftc.net]
rppt has quit [reticulum.oftc.net liquid.oftc.net]
Quinten[m] has quit [reticulum.oftc.net liquid.oftc.net]
emersion has quit [reticulum.oftc.net liquid.oftc.net]
bl4ckb0ne has quit [reticulum.oftc.net liquid.oftc.net]
Nefsen402 has quit [reticulum.oftc.net liquid.oftc.net]
Hazematman has quit [reticulum.oftc.net liquid.oftc.net]
reactormonk[m] has quit [reticulum.oftc.net liquid.oftc.net]
nielsdg has quit [reticulum.oftc.net liquid.oftc.net]
msizanoen[m] has quit [reticulum.oftc.net liquid.oftc.net]
shoffmeister[m] has quit [reticulum.oftc.net liquid.oftc.net]
Anson[m] has quit [reticulum.oftc.net liquid.oftc.net]
nyorain[m] has quit [reticulum.oftc.net liquid.oftc.net]
Kwiboo has quit [reticulum.oftc.net liquid.oftc.net]
CATS has quit [reticulum.oftc.net liquid.oftc.net]
Venemo has quit [reticulum.oftc.net liquid.oftc.net]
jmondi has quit [reticulum.oftc.net liquid.oftc.net]
moxie has quit [reticulum.oftc.net liquid.oftc.net]
vjaquez has quit [reticulum.oftc.net liquid.oftc.net]
tnt has quit [reticulum.oftc.net liquid.oftc.net]
ccr has quit [reticulum.oftc.net liquid.oftc.net]
evadot_ has quit [reticulum.oftc.net liquid.oftc.net]
rawoul has quit [reticulum.oftc.net liquid.oftc.net]
llyyr has quit [reticulum.oftc.net liquid.oftc.net]
mlankhorst has quit [reticulum.oftc.net liquid.oftc.net]
Koniiiik has quit [reticulum.oftc.net liquid.oftc.net]
a1batross has quit [reticulum.oftc.net liquid.oftc.net]
dj-death has quit [reticulum.oftc.net liquid.oftc.net]
robertfoss has quit [reticulum.oftc.net liquid.oftc.net]
Guest3072 has quit [reticulum.oftc.net liquid.oftc.net]
lanodan has quit [reticulum.oftc.net liquid.oftc.net]
ds` has quit [reticulum.oftc.net liquid.oftc.net]
sven has quit [reticulum.oftc.net liquid.oftc.net]
iokill has quit [reticulum.oftc.net liquid.oftc.net]
skinkie has quit [reticulum.oftc.net liquid.oftc.net]
mriesch has quit [reticulum.oftc.net liquid.oftc.net]
jadahl has quit [reticulum.oftc.net liquid.oftc.net]
<tnt>
Does anyone know where the decision of the tiling mode is made for a given gl texture spec ? (for intel)
hikiko has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
kxkamil has joined #dri-devel
kxkamil has quit []
cheako has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #dri-devel
<MrCooper>
tnt: for a normal GL texture, the driver picks the modifier
<tnt>
MrCooper: I would expect it, I'm asking if you can point to a function/source code line where this happens :)
<tnt>
I'm trying to trace from glTexImage2D but I can't even figure out the _entry_point_ of that function in the mesa source.
<MrCooper>
then I have to defer to someone more familiar with the iris/crocus code
<MrCooper>
tnt: breakpoint on glTexImage2D or _mesa_TexImage2D should work
<tnt>
Ah thanks ! I was grepping for glTexImage2D to no avail in the source code.
<MrCooper>
probably some macros or similar trickery involved
<tnt>
yup.
<MrCooper>
also, glTexImage2D is in lib(Open)GL, which normally comes from GLVND these days
<daniels>
tnt: look at the pipe_screen resource_create hook, which is probably inside iris_resource.c or similarly named
<cheako>
I have an app that doesn't draw a single frame, but I want to dump the shaders... I'm writing a layer to do this, is that the way to go?
<tnt>
daniels: tx will have a look.
<dj-death>
cheako: dump what exactly?
<dj-death>
cheako: you can get the disassembled binary in renderdoc
<cheako>
For renderdock... you need at least one frame, right?
<dj-death>
it works with single frames yeah
<cheako>
On the desktop I get a windows looking dialog with an assertion for vkCreateComputePipelines and not much else that looks important, there is no code.
<cheako>
The app prints "0" frames.
<cheako>
I want to peek at what shader is throwing an error.
<dj-death>
ah you want the spirv code
<dj-death>
yeah I guess writing layer to intercept the spirv data would work
yuq825 has joined #dri-devel
tursulin has joined #dri-devel
kxkamil has joined #dri-devel
mbrost has joined #dri-devel
lynxeye has joined #dri-devel
sukrutb has quit [Ping timeout: 480 seconds]
mbrost has quit [Read error: Connection reset by peer]
jkrzyszt has quit [Remote host closed the connection]
rasterman has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
Duke`` has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<tnt>
So admittidely, I'm flying by the seat of my pants here but when I look at isl_tiling_to_i915_tiling , it maps ISL_TILING_4 to I915_TILING_NONE. which then gets mapped by tiling_to_modifier to DRM_FORMAT_MOD_LINEAR.
<tnt>
so when exporting it you get a dmabuf with modifier=DRM_FORMAT_MOD_LINEAR . But I don't think it's actually linear unless I'm misunderstanding what ISL_TILING_4 is.
<tnt>
I'm guessing it should be I915_FORMAT_MOD_4_TILED
dos1 has quit [Ping timeout: 480 seconds]
<dj-death>
tnt: there are multiple things at play there
<dj-death>
I915_TILING_* is for the kernel to do detiling magically through mmap()
<dj-death>
that support got dropped from HW in Gfx12 if I remember correctly
<dj-death>
that's why you get I915_TILING_NONE for a number of tilings
<dj-death>
tiling_to_modifier() will only get used when we don't know the tiling (because we were not given a modifier)
<dj-death>
and so on Gfx12+ it'll default to linear
<tnt>
dj-death: But isl_surf_init_s picked ISL_TILING_4 so res->surf.tiling = ISL_TILING_4.
<tnt>
So wouldn't that mean the gpu think it's tiled ?
<tnt>
but after the isl_surf_init_s , res->mod_info never gets set to whatever was picked, maybe that's the issue ?
<tnt>
(in iris_resource_configure_main )
dos1 has joined #dri-devel
glennk has joined #dri-devel
bmodem has joined #dri-devel
<daniels>
tnt: ignore all the I915_TILING_* stuff - that's for a pre-modifier legacy backchannel which only supports X and Y tiling
<daniels>
so there are a number of tiling modes which can't be translated at all to that set of tiling flags, and attempting to do so is an error
nir2042 has joined #dri-devel
<dj-death>
tnt: I don't know exactly what you're doing, but I'm guessing you create an image, export it and reimport it
cmichael has joined #dri-devel
<daniels>
isl is the canonical tiling description, and the modifiers describe a subset (the usefully-exportable subset) of those
<daniels>
dj-death: hole in one
<dj-death>
tnt: if the import in iris_resource_from_handle() is picking up linear, it's probably because there is no modifier given on import
<tnt>
dj-death: Yeah, it for rusticl. We call the mesaglinterop extension and this returns a dmabuf with modifier=0 ... and then re-import it (for CL use). But I think the modifier=0 in the export was wrong and it's not linear at all.
<dj-death>
tnt: sounds like the issue indeed
<dj-death>
tnt: yeah, I think the issue is that the image is not created with a modifier
<tnt>
And that's because mod_info=NULL at that point to it call the tiling_to_modifier(isl_tiling_to_i915_tiling(surf->tiling)) ... which yield 0.
<dj-death>
tnt: so even if it's tiled, we don't given you a modifier matching
<dj-death>
I think it's only the DRI stuff that will call the resource_create_with_modifiers() vfunc
<dj-death>
not really an expert in the GL winsys insanity :)
<dj-death>
maybe GBM can hook into that vfunc somehow?
<dj-death>
like if you create a gbm_bo_create_with_modifiers2()
<daniels>
yeah, the core issue is mod_info==NULL
<daniels>
dj-death: indeed gbm_bo_create_with_modifiers2() calls resource_create_with_modifiers() - in general GBM works ~identically to any other winsys
glennk has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
Duke`` has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.0.5]
<tnt>
I'm not entirely sure what the path forward is, I didn't quite follow those last few statements.
Duke`` has quit []
Duke`` has joined #dri-devel
lemonzest has joined #dri-devel
<sima>
daniels, tnt isn't the issue that the export doesn't provide the right modifiers? for somewhat unclear reasons maybe ...
<sima>
or maybe it's the classic mixup between no modifier and linear modifier
<tnt>
sima: yes.
<sima>
but for future proofing probably better to make this fully modifier'ed
alyssa has joined #dri-devel
<tnt>
Actually even in the case where mod_info is set, it seems weird to me to use res->mod_info->modifier. Because right before we disabled aux usage and didn't change/update mod_info so mod_info->modifier no longer represent reality. Unless I'm reading this wrong.
<tnt>
(in iris_resource_get_handle )
<karolherbst>
all this CL-gl interop stuff is quite madness :') at least for cl-vk interop the WG wants to get this modifier part right
<sima>
karolherbst, full of implied modifier semantics for the cl-gl case still?
<karolherbst>
but for cl-gl we can only pray and hope that the CL side can accept the modifier and the driver simply has to tell us what they choose
<karolherbst>
sima: the API is pretty dumb here
<karolherbst>
you can import arbitrary GL textures, that's the API
<karolherbst>
do you have to mark the as "I'll export them for CL later?" no
<sima>
karolherbst, yeah but the isssue here seems to be that the modifiers flat-out fall through somehow
<karolherbst>
the idea here is really to just make the GL object available to CL as is
<karolherbst>
yeah
<sima>
not that gl exports something that cl can't consume
<karolherbst>
I suspect that's the actual bug
<karolherbst>
I'm sure the texture isn't linear at all, because why would it be
<karolherbst>
tnt: did you try to figure out what modifier on the import side would make it work? :D
<sima>
atm I even suck at finding the right extensions, but I've defo been nerd-sniped
<tnt>
I hacked mesa to prefer allocating LINEAR (changing preference order) and then it works ... so it's definitely not linear.
<karolherbst>
at least with that you won't have to query the gl context anymore
<karolherbst>
anyway...
<karolherbst>
the driver needs to provide the correct modifier through it
shashanks has quit [Remote host closed the connection]
kts has joined #dri-devel
<MrCooper>
in principle, it should be possible to give rusticl access to the underlying pipe_resource if the GL driver is Mesa?
kts has quit [Quit: Konversation terminated!]
<tnt>
MrCooper: I'm also trying to implement the same extension in the intel compute runtime :) (and hitting basically the same issue where I get a dmabuf in an unknown format).
<karolherbst>
MrCooper: not really, because it's in different so files.
<karolherbst>
well.. in theory we could make it work, but...
jewins has quit [Ping timeout: 480 seconds]
<karolherbst>
the issue is that in theory you could also mix different versions and other things
<karolherbst>
anyway, I'm more interested in making it work properly for vk-cl interop
<dj-death>
alyssa: you can't generate the tile commands from a shader?
<karolherbst>
it's also a bit more flexible and I'm sure it can also be used for gl
<karolherbst>
and there is `cl_khr_external_memory_dma_buf` which is just a saner interface
<karolherbst>
the modifier part is still WIP though
kts has joined #dri-devel
<pq>
ndufresne, company, since you seem interested in direct import of YUV dmabuf into EGL, have you looked into the problem of EGL not promising to decode YUV correctly? By the spec it's just best effort which matrix, siting, or quant.range it uses even when EGL has API for it.
<alyssa>
dj-death: i guess the impl depends
<alyssa>
if you loop the generate shader it's fine
<alyssa>
you just can't, like, having the generate shader in parallel with the draws or something
<alyssa>
i guess not really a tiler thing?
<dj-death>
you have to trigger a draw call per tile?
* dj-death
is a tiler noob
<alyssa>
not on apple or mali
<alyssa>
dunno about qcom
<dj-death>
then I don't see why you couldn't do what we do in the Anv MR
<dj-death>
you have to be careful with the order
<dj-death>
our command ordering is : generate-shader, emit the draw pipeline, jump into the generated draw calls, jump back to generate-shader
<dj-death>
the last jump is written by the generate-shader which either jumps back to the beginning of the sequence or jumps out to the next set of commands in the batch
<dj-death>
so all your tile setup should be in the second step, which you never generate, it's only written from the CPU
munuba has quit [Remote host closed the connection]
tarceri_ has joined #dri-devel
gawin has joined #dri-devel
kts has joined #dri-devel
JohnnyonFlame has joined #dri-devel
nir2042 has quit []
tarceri has quit [Ping timeout: 480 seconds]
bmodem has quit [Quit: bmodem]
bmodem has joined #dri-devel
junaid has joined #dri-devel
aravind has quit [Read error: Connection reset by peer]
mclasen has quit []
junaid has quit [Remote host closed the connection]
<karolherbst>
tnt: isn't the issue that `isl_tiling_to_i915_tiling` is simply returning a wrong tiling mode? Why can't we just handle all the relevant variants there instead?
<karolherbst>
the isl_drm_modifier_info table seems to cover everything
<karolherbst>
mhh though your change the is kinda the same, just not put into a function
fab has quit [Quit: fab]
<tnt>
karolherbst: the I915_TILING_* defines are quite limited ... only 3 defined.
<karolherbst>
you could add more
<tnt>
And the comment says "Do not add new tiling types here. The I915_TILING_* values are for de-tiling fence registers that no longer exist on modern platforms."
<karolherbst>
ehh wait.. those are uapi things
<karolherbst>
yeah. uhh.. I see
<tnt>
The above patch doesn't check modifier_is_supported so I need to add that too or I get MeteorLake modifier returned for DG2 ... :)
<karolherbst>
right
<karolherbst>
but yeah, I think the principle of your patch is more or less correct
<tnt>
I've sent it to the user so he can try.
<tnt>
(Don't have a DG2 hardware myself so ...)
<karolherbst>
cool
<karolherbst>
maybe I can also get antonio to work on the external memory stuff or maybe I should do it myself :D
<tnt>
So vulkan has a way to export to dma_buf ?
<karolherbst>
yeah
<karolherbst>
the idea of the new cl_khr_external_memory stuff is, that the runtime doesn't have to use private APIs
<karolherbst>
and the application explicitly passes in the fd or dma_buf handle
<karolherbst>
via cl_khr_external_memory_opaque_fd or cl_khr_external_memory_dma_buf
alyssa has quit [Quit: alyssa]
<karolherbst>
it should also work from GL just the same way
<karolherbst>
or any API really
<karolherbst>
just need a way to export such a handle
<tnt>
Then we can use zink and the the dma_buf though the underlying vulkan to get cl/gl sharing :)
<karolherbst>
yeah
<karolherbst>
actually.. we don't need that for that
<tnt>
How does it work for the aux/ccs/cc stuff though ? Because you'd need several dma_buf right ?
<karolherbst>
just don't have to use the gl interop stuff
<ndufresne>
pq: same for gstreamer, so I doubt it can be much worse ;-P
<karolherbst>
tnt: that's all driver details
<karolherbst>
I think the problem is, that external_memory also relies on cl_khr_semaphore
<karolherbst>
for synchronizing access and stuff
<ndufresne>
pq: someone would have to redo the work with correctness in mind, but this is "on-demand", also, even if best effort, there is not much we can do if we want to use compressiond
<karolherbst>
and uhh.. cl_khr_external_semaphore
<karolherbst>
uhh, there is a lot to implement actually
<pq>
ndufresne, I wonder if we are talking about the same thing here.
<karolherbst>
I kinda have to figure out how solid the CTS tests here are
<ndufresne>
pq: you ask about correct range, transfer, matrix and primaries along with chrome-siting, and the fact GL stack do this best effort, gstreamer is damn best effort in this regard
<karolherbst>
but if nothing is using it yet, then uhh.. I have a few more important things to do myself
<pq>
ndufresne, well, the EGL extension says that the EGL can simply ignore what the app is telling about those, while there is a unique well-defined correct result in theory.
<ndufresne>
well, GStreamer will ignore everything it does not support in the GL stack, I don't see the difference
<pq>
transfer and primaries are *not* part of this
bmodem has quit [Ping timeout: 480 seconds]
<ndufresne>
you mean it must respect the tranfer and primaries ?
<pq>
An API that does not promise to implement these attributes correctly is useless for me. Of course, each to their own, I thought Gst has some guarantees about correct conversions, but I guess not.
<ndufresne>
yes, and indeed, only COLOR_SPACE_INT (matrix), RANGE and siting (this one is not implemented in gst gl)
<pq>
or that specific Gst elements might make guarantees
<ndufresne>
pq: you are confusing things, there is API for it, the implementations may not be complete, we don't have infinit budget for these, so its on-demand
<pq>
ndufresne, right. An API is useless to me, if it does not promise to do what it says.
bmodem has joined #dri-devel
<ndufresne>
I know everything is useless for you, but in practice, it is still very useful to most
<ndufresne>
gst or GL will always be useful for you specifically cause you have to take into account the display charateristic
<ndufresne>
* useless
<pq>
I do require these attributes to be correctly implemented, which means I'll have to opt out of delegating that to EGL, because EGL does not promise to do it right.
<pq>
You can't even write a CTS for EGL for this, because the spec is "everything goes".
<ndufresne>
yes, which in the context of GL, forces you to opt out video compression unless you have a GL YUV extensions implemented (no MESA driver have that)
<pq>
Which compression?
<ndufresne>
anything that you can't shade and is described with a modifier
<pq>
losless compression is totally fine
<ndufresne>
well, you missed something about EGL then ;-P
<pq>
lossy compresions I'd like to avoid, indeed
<ndufresne>
most EGL API will only import YUV compressed buffers and deliver it as RGBA to you shader
<pq>
ndufresne, please, forget everything I said. I learnt that Gst doesn't care, and that all I needed.
<ndufresne>
you are so so so wrong ...
<pq>
What is "YUV compression"?
<ndufresne>
we care, and if we have time for adding some missing implementation, we will, stating that we don't care is limit insulting
<pq>
well you did say you are fine with not guaranteering a correct result
<ndufresne>
pq: a YUV format combines with a specific compressor (on memory controller)
<pq>
and those are usually lossy?
<ndufresne>
pq: I said we can live with missing cases, and add later
<ndufresne>
pq: no, they are losseless, what I'm saying is that EGL hides the YUV components, unless you have this yuv texture extension which nobody implements
<pq>
I want to write tests that verify the result is close enough according to the theory.
<ndufresne>
so in todays GL stack, you can't do anything about it
<tnt>
(the correct pattern is the color gradient with gree lines. The other pattern is something I pre-fill the texture with with glTexImage2D)
mclasen has joined #dri-devel
<ndufresne>
pq: IMG supports this in their vendor driver though, so I would expect eventually the mesa driver will have it, I think I've seen few MR to start this, and you really strictly need this in GL, you can always move to vulkan of course, were more care has been placed
mclasen has quit []
<pq>
ndufresne, I mean, what I (Weston) does do, is import YUV buffers as R8+GR88 and use shaders.
<lynxeye>
ndufresne: pq: I think you are both right: Gst cares and does implement things correctly when time allows to do so. The EGL API is horrible, as it only allows hints to the driver and doesn't specify a fixed result, so it's nearly impossible to use correctly.
<ndufresne>
pq: no exactly, weston will try the direct (GL side conversion) first, this is the only way to enable compression and tiling in weston
<ndufresne>
lynxeye: :-D good summary
<lynxeye>
Probably only way to fix this is to have another EGL ext specified to allow user to query which of those color format hints the driver will actually honor.
<pq>
ndufresne, exactly, I will disable that direct import, when color management is in use.
<ndufresne>
I just want to emphasis, that peformance may win, and that's why weston and gst implement EGL direct upload were the stack cares of conversion (in best effort unfortunatly)
fab has joined #dri-devel
<pq>
I will force the shader conversion path.
<ndufresne>
pq: which will disable all tiling and compression, you can re-implement couple of shader for the tiling you care about, that's easy, but compression ...
<ndufresne>
you will also loose zero copy for any videos which aren't aligned to your GPU requirement on Mali
<pq>
ndufresne, that is all fine, because when you enable color mangement, you care about the result.
<ndufresne>
well, you also care about performance, since these high quality videos are often also 4K
<pq>
I will also disable all KMS overlay planes until there is a KMS UAPI that guarantees the results.
<karolherbst>
tnt: pain
<pq>
I will definitely do correctness first, with tolerance, and once all that works, we can think when and what requirements would be good to relax.
<tnt>
karolherbst: yeah, I'm learning way more about intel gfx than I ever wanted to know :)
<pq>
and those will be separate configs
<ndufresne>
pq: fun :-( this first implementation will not be very useful in real life imho
<karolherbst>
:D
<pq>
ndufresne, that's what research is. Make it work first, then figure out how to make it fast.
<ndufresne>
sure, but its no justification for saying the rest of the world is wrong and don't care here
<pq>
I didn't say that.
<pq>
I was asking if were aware that EGL gives no guarantees, and you are.
<ndufresne>
I believe you said that toward gst folks
<pq>
*if you
<pq>
no
<ndufresne>
of course we are aware, do you think the rest of the world is stupid
<karolherbst>
tnt: the cursing of getting involved in mesa stuff
<pq>
ndufresne, now you are calling me stupid.
<karolherbst>
you start fixing some bug, and before you know it, you know the details of all the GPUs out there
<ndufresne>
pq: no exactly, I saying that you treat everyone else not doing your research are people that don't care of don't know in your spelling, and that really offend me
<pq>
ndufresne, and no, people are often surprised by the attributes being hints.
<tnt>
karolherbst: :)
<pq>
ndufresne, got it. I'll try very hard to never speak to you again. Farewell.
<ndufresne>
pq: also, if its open source, we can do something about it, most of mesa egl color conversion is just bunch of shaders that we can certainly fix (well more extension for the attr needed I suppose, but that's doable too, wehave mesa extensions)
<ndufresne>
(and from the read, these shader are already quite complete, so pq let someone know about your test result, so this someone can tell me ... or don't take this too seriously)
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
bmodem has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
heat_ has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
rcf has quit [Remote host closed the connection]
i509vcb has joined #dri-devel
shashanks has joined #dri-devel
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
qyliss_ has left #dri-devel [#dri-devel]
qyliss has joined #dri-devel
rcf has joined #dri-devel
mripard has quit [Quit: mripard]
<DemiMarie>
pq: why do you need to use OpenGL instead of Vulkan?
<DemiMarie>
Is KMS too high-level an API? I wonder if a better solution would be to expose all of the various hardware features in the uAPI, and do any abstraction over the hardware in userspace.
<DemiMarie>
That is what Vulkan/OpenCL/OpenGL all do.
kts has joined #dri-devel
<pq>
DemiMarie, Weston needs to pick some rendering API for compositing on the GPU, and it has chosen GL ES many years ago. Pushing client content straight to KMS is not always possible, like when the scenegraph doesn't allow it or KMS UAPI lacks the needed things.
kzd has joined #dri-devel
<pq>
The existing KMS UAPI is quite limited and not well defined especially on the color pipeline side, which is why the effort to create a new color pipeline UAPI is going on.
sukrutb has joined #dri-devel
glennk has joined #dri-devel
<MrCooper>
ndufresne: I don't get why you're so aggressive against pq; even if you already knew what he pointed out, no need to attack him for doing so
<ndufresne>
MrCooper: I was only reacting badly to pq comment that GStreamer folks don't care and isn't relevant in the context of proper HDR
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<ndufresne>
this is not nice comment considering all the effort we put into this
<DemiMarie>
pq: Should Weston switch from OpenGL ES to Vulkan?
<hakzsam>
emersion: IIRC, you are the libdrm release manager ?
<pq>
DemiMarie, I don't know of pressing reasons to do so. It would be a lot of work.
<emersion>
hakzsam: there are no libdrm release managers, anyone with push access + SSH access can release
<pq>
DemiMarie, OTOH, I'm also not sure if there are systems using Weston that do not have Vulkan drivers. There might be, given that Weston has most uses in embedded.
<pq>
then again, I've set it so that enabling color management in Weston requires GL ES 3, but that is optional.
<pq>
I mean enabling color management is optional
<DemiMarie>
pq: it looked like Weston needs some features that are in Vulkan but not OpenGL ES.
<DemiMarie>
Given how new color management is, I would not be surprised if it needs new APIs that are Vulkan-only.
<pq>
Maybe that YUV compression is one, I didn't know it even existed.
jewins has joined #dri-devel
<pq>
My task is just to get color-management and HDR working at all to begin with and ensure they can be trusted.
<pq>
When the Wayland color management planes were discussed years ago, people from traditional color management side were screaming that they absolutely must be able to completly bypass the whole display stack, or nothing will work. I'm starting to see where they came from.
<pq>
*plans
<ndufresne>
its fine to step away, get things working correct, as long as its plan to re-integrate the working bits, or to accept some tradeoff where we cannot do without HW
<ndufresne>
(HW meaning dedicated, rather then all done in GPU code)
<pq>
I've only been talking about the EGL API today, how it defines some attributes and then does not require implementations to use them correctly. Such API is useless if you want the correct result. You'd have to validate the implementation every time the program starts.
<pq>
The Wayland color-management extension OTOH is being designed to have clear promises of the result when used in certain ways. An implementation of that extension simply cannot use components that don't give the necessary guarantees.
<pq>
This is merely the starting point for satisfying the users of traditional color management.
MrCooper has quit [Remote host closed the connection]
<pq>
Those requirement apply to anything a compositor is using, including EGL, GL, Vulkan and KMS.
yyds has joined #dri-devel
MrCooper has joined #dri-devel
AnuthaDev has joined #dri-devel
<pq>
My vision is that eventually *our* requirements will be driving hardware design in part.
<lynxeye>
pq: DemiMarie: There are whole fleets of devices shipping with weston and etnaviv, with currently no Vulkan driver.
<tnt>
pq: there is a reason BMD has 'dedicated video output' cards :) Pretty much can't trust anything if you don't control end to end.
<tnt>
(and unless you get it really wrong, it's also very hard to tell if you get it "a little" wrong)
glennk has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
<sima>
tnt, oh dg2 explains things, that doesn't have these magic I915_TILING_ values anymore
<sima>
so yeah the detour through this legacy api stops working
phire has quit [Remote host closed the connection]
phire has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
AnuthaDev has joined #dri-devel
yyds has quit []
tursulin has quit [Ping timeout: 480 seconds]
<DemiMarie>
pq: my understanding of what you wrote is that you plan to just do everything in shaders initially, and then try to use hardware offloads later. Is this accurate?
kts has quit [Ping timeout: 480 seconds]
<tnt>
I'm trying to understand how iris_resource_from_handle is supposed to work. Like, how would iris_resource_finish_aux_import ever be called ? Do you need to call iris_resource_from_handle 3 times once for each plane or something ?
tarceri_ has quit [Read error: Connection reset by peer]
glennk has joined #dri-devel
tarceri_ has joined #dri-devel
tarceri has quit [Read error: Connection reset by peer]
Duke`` has joined #dri-devel
mclasen has quit []
mclasen has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
jhli has quit []
jhli has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
tarceri_ has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
sukrutb has quit [Ping timeout: 480 seconds]
<robclark>
pq: is there any gpu that _doesn't_ implement KHR_blend_equation_advanced in the frag shader? What fixed-function color processing (in the gpu, not display) are you expecting?
Company has joined #dri-devel
<cheako>
Kayden, thanks for the tip... I tried that and I think because the app exists instead of segv the dump is not triggered.
<cheako>
...though I'm kinda confused as to how a segv handler is called?
mszyprow has joined #dri-devel
mclasen has quit []
mbrost has joined #dri-devel
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<cheako>
I was also wondering it the dumps would be tagged with the return code from pipeline creation?
ngcortes has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
sukrutb has joined #dri-devel
tarceri has joined #dri-devel
<ndufresne>
Company: so, after fixing tones of issue in the recent gst drm fourcc/modifier support, I could finally test NV12 and YUY2 EGLImage import on Intel, interesting, on this old F36, it renders fine in gnome-shell, though with gst gbm backend, it renders all weird, so on Intel at least, the problem is probably complex, I guess you were on Gnome 45 with
<ndufresne>
the latest mutter ?
<ndufresne>
and of course, there could be regression in mesa, this is old 22 working "mostly"
<ndufresne>
I'll let you know when I have a change to upgrade
rasterman has quit [Quit: Gettin' stinky!]
<Company>
ndufresne: no, I was on F38's mutter (but custom git main Mesa)
<Kayden>
cheako: it ought to dump normally, FOSSILIZE_DUMP_SIGSEGV just also makes it finish dumping the files even if compilation crashes
<Company>
ndufresne: F45 Mutter supports YUV Wayland buffers (and afaik uses custom shaders for those, with no support for EXT_OES_import)
<ndufresne>
which probably saves the day imho
<ndufresne>
at least, we have a solution for users, stay on OpenGL, you'll get more accurate results atm
<Company>
hrm actually
<Company>
zmike: does zink do EGLImage import and in particular YUV?
<zmike>
about the same as other drivers
<Company>
I was wondering about VkSamplerYCbCrConversion
<zmike>
kinda partially plugged in
sukrutb has quit [Ping timeout: 480 seconds]
<Company>
I guess that's good enough - if it's actually used, it can be plugged in more
<Company>
but it could have been it's impossible to do or sth
<Company>
that's why I was wondering
tarceri_ has joined #dri-devel
cyrinux has quit []
cyrinux has joined #dri-devel
tarceri_ has quit [Remote host closed the connection]
<daniels>
if zink didn't do EGLImage import, it couldn't do ~anything
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
<cheako>
Kayden, I'll try a few more things, but are there docs I could read then?
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
sukrutb has joined #dri-devel
manmower is now known as ManMower
fab has quit [Quit: fab]
sima has quit [Ping timeout: 480 seconds]
<cheako>
That's sad, no good. I wonder if starfield is looping and running out of mem/space? I feel almost done writing my layer, though.
illwieckz has quit [Remote host closed the connection]
<robclark>
Company, ndufresne: Are there any mesa drivers that don't support yuv egl import? mesa/st has fallback code for that (which does the CSC in the shader.. but I think nearly everyone does it with shader lowering regardless)..
<robclark>
(also note that the R8+R8G8 trick doesn't necessarily work once modifiers come into the picture, ie. you can't import nv12+ubwc as R8+R8G8)
<ndufresne>
robclark: mesa, there should not be any, what mesa does not support is delivery the unmodified YUV component to a shader (in EGL at least), we chear with R8/RG88 tricks, but you can't use modifiers with that
<ndufresne>
chear/cheat
<ndufresne>
actually, on Intel you can transfer modifier from/to any formats, but this is not true notably for AFBC
<ndufresne>
and there is nothing at Intel to ensure this will stay true, its just a state
<robclark>
an extension to get the result in yuv space probably wouldn't be too hard.. or perhaps just to give the app control over the matrix used for csc
<ndufresne>
I believe there is one already
<Company>
robclark: the problem is that the mesa drivers are all broken
<ndufresne>
it also very useful to transform image that then get passed to an encoder, the CSC is not always needed in that context
<ndufresne>
(e.g. transcoding)
<Company>
robclark: so importing a YUYV/NV12 EGLImage fails or if it works, it doesn't sample properly in a shader
<robclark>
rendering _too_ yuv might be a bit more work.. but just not applying CSC transform would, I think not be hard
<robclark>
hmm, I know we use that on CrOS so I don't think you can say they are "all broken"
<Company>
robclark: "all" here meas Intel and AMD
<robclark>
we defn use that on intel and amd chromebooks.. so 🤷
<Company>
no idea - we tried it on all the hardware we had and on recent Mesa it seems broken
<Company>
though apparently it worked on F36 for ndufresne ?
<Company>
so maybe something got busted, but we haven't been smart enough to figure out if/what
<daniels>
'I posted a snarky message on IRC about how Mesa sucks then quit without providing any details' is not exactly a top-tier bug report
<Company>
it seems like it should work, because there's lots of code in Mesa that wouldn't be there if it didn't work...
<daniels>
but I'm sure it'll be fixed any minute now with this illuminating detail
<daniels>
that's a bug related to YUV import, yeah
<daniels>
which is absolutely unrelated to your analysis this morning that nothing related to YUV import could ever work because DRI was outsmarting other parts of Msa
<daniels>
but perhaps fixing ndufresne's bug will magically fix your bugs which occur with unknown usage on unknown hardware. let's find out.
<robclark>
so, the one difference with CrOS is minigbm.. which magically knows all the hw constraints so it can allocate you a yuv buffer with appropriate stride/etc
<Company>
I was trying to understand what's going on
<Company>
so I could file a better bug report / actually do an MR
<daniels>
Company: you've turned up, been very snarky about code quality (in a codebase you don't understand the nuances of, because there are bits you haven't noticed), provided zero detail, then quit
<daniels>
if you want to have a discussion, then have a discussion. if you want to file a good bug, file a good bug. if you want to prove that you're smarter than everyone else, comment on reddit
<ndufresne>
daniels: yeah, this bug was fixed at some point (wrongly, cause my be who had no clue), but then only bits and pieces got merged, the YUVV buffer and stride stride is still wrong, and unless you know that wrong formula is used, your YUV imports will get rejected
<ndufresne>
on GFX 9 or AMD, not random AMD here
<daniels>
don't just add noise to the backlog then make it even worse by leaving anyone else unable to continue the thread because you've gone to have breakfast or whatever
<ndufresne>
*of AMD
<daniels>
ndufresne: yeah, the stride%256 check is pretty brutal, but well, hardware is hardware
<Company>
daniels: I didn't know I wasn't allowed to have a life if I talk in here
<daniels>
Company: if you want to chat away, then at least be vaguely respectful
<ndufresne>
daniels: no, that's ok, the stride it expects is incorrect, by a factor of 2
<ndufresne>
its so niche, maybe I should rework that issue subject ...
AnuthaDev has quit []
<Company>
daniels: I think analyzing how well code is structured is pretty relevant to me when trying to find bugs - but I can see that it can come out wrong when people think I'm making a judgement about their coding skills
<robclark>
so I haven't looked amd layout code, so not sure about that factor of two.. and YUYV might be less well tested than NV12. Maybe we could do something with that fake/test v4l2 device to get some better YUV testing?
<Company>
which is definitely not what I was going for, nor even interested in
<daniels>
Company: would you like to hear my thoughts about GObject next time I encounter a bug in GNOME?
<Company>
if that helps you dig into the code, sure
<daniels>
it's shit
<daniels>
hth
<ndufresne>
robclark: just few integration tests would do, I think stuff like weston simple dmabuf client works great, it got updated this year for that kind of reason, and side effect, Panfrost works great now ;-P
<ndufresne>
but I prefer a BAD_ALLOC from EGLImage, that is easy to take care, compare to flipped components (which is what Company have hit today, apparently, I wasn't able to reproduce)
<ndufresne>
in some modified form of course, but that's base on the idea I had
<robclark>
ahh, ok
<daniels>
Company: we all know the DRI interface is rubbish. there are ABI reasons why it couldn't be cleaned up until now. there are multiple MRs in flight right now to clean it up. there are historical reasons why it had to be this way until now. if you want to ask questions and contribute positively, then do that. if you want to only contribute bug reports, then follow the template and post a lot of details. if you want to join a
<daniels>
developer channel without doing any development but being very snarky and judgmental about things you know nothing about, without contributing anything useful, then stick to Reddit or Phoronix rather than trying to show the world that you could have created something better
<daniels>
ndufresne: safe to say everyone agrees that loud failure is better than silent failure :) we do have some integration tests along those lines already, but could always have more - do you know of any problematic scenarios which could be improved?
<ndufresne>
robclark: its the allocation part that is ... complicated, the fix I did breaks something else, then some other fix got made, but it didn't cover my original use case, oops, if it was covered by a upstream mesa test, I think it would have more chances
<ndufresne>
oh yeah. we all prefer loud
<ndufresne>
I think for the allocation case, having test that allocates from another driver, or perhaps a heap, but that's very complicated, in short, if you over-allocate, as long as you use your allocator it works
<ndufresne>
but when a third party needs to import it fails
<ndufresne>
for CSC, well, there is piglit tests, notice that 20815 ended with enabling more test, cause they started passing after that change
<ndufresne>
robclark: if you want to look at the swizzling, Company underlined that many other set of format exist and have the same swizzling copy pasted, so if it get used by the generic CSC code, it may go wrong
<ndufresne>
I wanted to try and fix some, but I didn't find any convention on how to map YUV and XYZ in that file
<ndufresne>
my original patch was just trial and error and deduction from what worked
Duke`` has quit [Ping timeout: 480 seconds]
<Company>
Actually, are there piglit tests for this issue that are disabled? (The wrong size failing to import I mean.)
<Company>
*The right size failing to import and wrong size being claimed
<ndufresne>
no, since the buffer is being allocated by the same driver, so the over-allocation is hidden this way
<Company>
Or is there no such test?
<ndufresne>
I think we'd need a HW specific test, which just validate expectation, but I'm not too sure how
<ndufresne>
I think most tests are entirely generic too
<Company>
somebody mentioned udmabuf as an option, but I have no idea if piglit has access to that
sukrutb has quit [Ping timeout: 480 seconds]
<ndufresne>
yeah, but it leave behind CMA cases, and also memory shared from the same discret GPU
mvlad has quit [Remote host closed the connection]
<Company>
yea, it's not perfect
<robclark>
not entirely clear to me the cpu cache situation with udmabuf.. which might be an issue with some hw
junaid has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
gawin has quit [Quit: Konversation terminated!]
gabertron has quit [Quit: No Ping reply in 180 seconds.]
gabertron has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
Lynne has quit [Remote host closed the connection]
sarnex_ has joined #dri-devel
sarnex- has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
Lynne has joined #dri-devel
sarnex_ has quit [Ping timeout: 480 seconds]
Lynne has quit []
sarnex- has quit [Remote host closed the connection]