00:01 Lynne: is there someone who picked up the gsp firmware patchset after skeggs?
00:54 airlied: Lynne: dakr and myself mostly so far
02:54 kode54: oops
02:55 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
02:55 kode54: I reported that to them
02:58 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
02:59 kode54: oh, somehow never heard of amdgpu_top
04:05 kurufu: nvtop should be integrated with the new fdinfo interface that shows per process load.
04:06 kurufu: (for amdgpu despite the name of the tool)
04:49 i509vcb: Horrible idea: how painful does it sound to implement Vulkan-Portability using gallium (I'd imagine very)
04:50 HdkR:stacks the layers harder
04:51 airlied: probably not an easier that implementing full vulkan
04:51 airlied: which is to say pretty pointless
04:51 i509vcb: It does sound hilarious to see a stack like Vulkan Portability -> Gallium -> Vulkan -> D3D
04:51 i509vcb: yeah it's probably not a good idea
06:46 tnt: Does anyone know where the decision of the tiling mode is made for a given gl texture spec ? (for intel)
07:20 MrCooper: tnt: for a normal GL texture, the driver picks the modifier
07:21 tnt: MrCooper: I would expect it, I'm asking if you can point to a function/source code line where this happens :)
07:22 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.
07:22 MrCooper: then I have to defer to someone more familiar with the iris/crocus code
07:22 MrCooper: tnt: breakpoint on glTexImage2D or _mesa_TexImage2D should work
07:23 tnt: Ah thanks ! I was grepping for glTexImage2D to no avail in the source code.
07:23 MrCooper: probably some macros or similar trickery involved
07:23 tnt: yup.
07:24 MrCooper: also, glTexImage2D is in lib(Open)GL, which normally comes from GLVND these days
07:26 daniels: tnt: look at the pipe_screen resource_create hook, which is probably inside iris_resource.c or similarly named
07:28 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?
07:29 tnt: daniels: tx will have a look.
07:31 dj-death: cheako: dump what exactly?
07:31 dj-death: cheako: you can get the disassembled binary in renderdoc
07:32 cheako: For renderdock... you need at least one frame, right?
07:32 dj-death: it works with single frames yeah
07:33 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.
07:33 cheako: The app prints "0" frames.
07:33 cheako: I want to peek at what shader is throwing an error.
07:34 dj-death: ah you want the spirv code
07:35 dj-death: yeah I guess writing layer to intercept the spirv data would work
08:03 Kayden: wouldn't fossilize work for that?
08:04 Kayden: VK_INSTANCE_LAYERS=VK_LAYER_fossilize FOSSILIZE_DUMP_SIGSEGV=1 FOSSILIZE_DUMP_SYNC=1 FOSSILIZE_DUMP_PATH=/tmp/foz
08:04 Kayden: <app>
09:06 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.
09:08 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.
09:10 tnt: I'm guessing it should be I915_FORMAT_MOD_4_TILED
09:16 dj-death: tnt: there are multiple things at play there
09:16 dj-death: I915_TILING_* is for the kernel to do detiling magically through mmap()
09:17 dj-death: that support got dropped from HW in Gfx12 if I remember correctly
09:17 dj-death: that's why you get I915_TILING_NONE for a number of tilings
09:18 dj-death: tiling_to_modifier() will only get used when we don't know the tiling (because we were not given a modifier)
09:18 dj-death: and so on Gfx12+ it'll default to linear
09:23 tnt: dj-death: But isl_surf_init_s picked ISL_TILING_4 so res->surf.tiling = ISL_TILING_4.
09:23 tnt: So wouldn't that mean the gpu think it's tiled ?
09:26 tnt: but after the isl_surf_init_s , res->mod_info never gets set to whatever was picked, maybe that's the issue ?
09:26 tnt: (in iris_resource_configure_main )
09:37 daniels: tnt: ignore all the I915_TILING_* stuff - that's for a pre-modifier legacy backchannel which only supports X and Y tiling
09:37 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
09:37 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
09:37 daniels: isl is the canonical tiling description, and the modifiers describe a subset (the usefully-exportable subset) of those
09:38 daniels: dj-death: hole in one
09:38 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
09:40 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.
09:41 dj-death: tnt: sounds like the issue indeed
09:42 dj-death: tnt: yeah, I think the issue is that the image is not created with a modifier
09:42 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.
09:42 dj-death: tnt: so even if it's tiled, we don't given you a modifier matching
09:43 dj-death: I think it's only the DRI stuff that will call the resource_create_with_modifiers() vfunc
09:44 dj-death: not really an expert in the GL winsys insanity :)
09:44 dj-death: maybe GBM can hook into that vfunc somehow?
09:45 dj-death: like if you create a gbm_bo_create_with_modifiers2()
09:47 daniels: yeah, the core issue is mod_info==NULL
09:48 daniels: dj-death: indeed gbm_bo_create_with_modifiers2() calls resource_create_with_modifiers() - in general GBM works ~identically to any other winsys
10:05 tnt: I'm not entirely sure what the path forward is, I didn't quite follow those last few statements.
10:07 sima: daniels, tnt isn't the issue that the export doesn't provide the right modifiers? for somewhat unclear reasons maybe ...
10:08 sima: or maybe it's the classic mixup between no modifier and linear modifier
10:08 tnt: sima: yes.
10:08 sima: but for future proofing probably better to make this fully modifier'ed
10:09 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.
10:09 tnt: (in iris_resource_get_handle )
10:10 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
10:11 sima: karolherbst, full of implied modifier semantics for the cl-gl case still?
10:11 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
10:11 karolherbst: sima: the API is pretty dumb here
10:11 karolherbst: you can import arbitrary GL textures, that's the API
10:12 karolherbst: do you have to mark the as "I'll export them for CL later?" no
10:12 sima: karolherbst, yeah but the isssue here seems to be that the modifiers flat-out fall through somehow
10:12 karolherbst: the idea here is really to just make the GL object available to CL as is
10:12 karolherbst: yeah
10:12 sima: not that gl exports something that cl can't consume
10:12 karolherbst: I suspect that's the actual bug
10:13 karolherbst: I'm sure the texture isn't linear at all, because why would it be
10:14 karolherbst: tnt: did you try to figure out what modifier on the import side would make it work? :D
10:14 sima: atm I even suck at finding the right extensions, but I've defo been nerd-sniped
10:14 tnt: I hacked mesa to prefer allocating LINEAR (changing preference order) and then it works ... so it's definitely not linear.
10:14 karolherbst: yeah
10:14 karolherbst: sima: https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Ext.html#cl_khr_gl_depth_images and following extensions
10:15 karolherbst: ehhh
10:15 karolherbst: sima: https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Ext.html#cl_khr_gl_sharing
10:15 karolherbst: 10 is the base and there are additions on top
10:15 karolherbst: 11 describes importing
10:16 karolherbst: and then we have this mesa GL interop private extension to handle the GLX/EGL side
10:16 karolherbst: `mesa_glinterop.h`
10:16 sima: oh it's all magic within mesa, I thought the app would export on one side and import on the other itself
10:16 karolherbst: no :D
10:16 karolherbst: that's all up for the runtime to do
10:16 sima: sweeeeeet
10:16 karolherbst: other runtimes even bind a GL context to current, because.....
10:17 karolherbst: they do GL calls to query infos about the buffer to import
10:17 karolherbst: it's all very bad
10:17 karolherbst: the VK side is better, but that's also still WIP
10:17 karolherbst: maybe we should implement it just to see if it actually works
10:17 karolherbst: sima: fyi.. ROCm and intel's CL stack use the same mesa private extension :D
10:18 karolherbst: rocm in an inferior way
10:18 sima: oh you need to create the cl context to link it to a gl context
10:18 karolherbst: yeah
10:18 sima: was just wondering where you get the gl context from
10:18 sima: yeah this sounds like big time fun
10:18 sima: I think I should go back to bikeshedding atomic kms semantics
10:18 karolherbst: :D
10:19 karolherbst: the mesa MR to extend the interop stuff is here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21305
10:20 karolherbst: at least with that you won't have to query the gl context anymore
10:20 karolherbst: anyway...
10:20 karolherbst: the driver needs to provide the correct modifier through it
10:29 MrCooper: in principle, it should be possible to give rusticl access to the underlying pipe_resource if the GL driver is Mesa?
10:35 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).
10:36 karolherbst: MrCooper: not really, because it's in different so files.
10:36 karolherbst: well.. in theory we could make it work, but...
10:37 karolherbst: the issue is that in theory you could also mix different versions and other things
10:37 karolherbst: anyway, I'm more interested in making it work properly for vk-cl interop
10:37 dj-death: alyssa: you can't generate the tile commands from a shader?
10:39 karolherbst: that's the vk sharing stuff: https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_Ext.html#cl_khr_external_memory
10:39 karolherbst: it's also a bit more flexible and I'm sure it can also be used for gl
10:39 karolherbst: and there is `cl_khr_external_memory_dma_buf` which is just a saner interface
10:41 karolherbst: the modifier part is still WIP though
10:46 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.
10:49 alyssa: dj-death: i guess the impl depends
10:50 alyssa: if you loop the generate shader it's fine
10:50 alyssa: you just can't, like, having the generate shader in parallel with the draws or something
10:50 alyssa: i guess not really a tiler thing?
10:53 dj-death: you have to trigger a draw call per tile?
10:53 dj-death:is a tiler noob
10:53 alyssa: not on apple or mali
10:53 alyssa: dunno about qcom
10:54 dj-death: then I don't see why you couldn't do what we do in the Anv MR
10:54 dj-death: you have to be careful with the order
10:55 dj-death: our command ordering is : generate-shader, emit the draw pipeline, jump into the generated draw calls, jump back to generate-shader
10:56 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
10:57 dj-death: so all your tile setup should be in the second step, which you never generate, it's only written from the CPU
11:10 alyssa: ok, yeah, I think that would work :)
11:22 tnt: So is this crazy talk or does it make sense https://pastebin.com/4VVfyZv6 ?
12:25 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?
12:26 karolherbst: the isl_drm_modifier_info table seems to cover everything
12:27 karolherbst: mhh though your change the is kinda the same, just not put into a function
12:29 tnt: karolherbst: the I915_TILING_* defines are quite limited ... only 3 defined.
12:29 karolherbst: you could add more
12:29 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."
12:30 karolherbst: ehh wait.. those are uapi things
12:30 karolherbst: yeah. uhh.. I see
12:31 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 ... :)
12:31 karolherbst: right
12:31 karolherbst: but yeah, I think the principle of your patch is more or less correct
12:31 tnt: I've sent it to the user so he can try.
12:32 tnt: (Don't have a DG2 hardware myself so ...)
12:32 karolherbst: cool
12:32 karolherbst: maybe I can also get antonio to work on the external memory stuff or maybe I should do it myself :D
12:35 tnt: So vulkan has a way to export to dma_buf ?
12:36 karolherbst: yeah
12:36 karolherbst: the idea of the new cl_khr_external_memory stuff is, that the runtime doesn't have to use private APIs
12:36 karolherbst: and the application explicitly passes in the fd or dma_buf handle
12:36 karolherbst: via cl_khr_external_memory_opaque_fd or cl_khr_external_memory_dma_buf
12:36 karolherbst: it should also work from GL just the same way
12:36 karolherbst: or any API really
12:36 karolherbst: just need a way to export such a handle
12:37 tnt: Then we can use zink and the the dma_buf though the underlying vulkan to get cl/gl sharing :)
12:37 karolherbst: yeah
12:38 karolherbst: actually.. we don't need that for that
12:38 tnt: How does it work for the aux/ccs/cc stuff though ? Because you'd need several dma_buf right ?
12:38 karolherbst: just don't have to use the gl interop stuff
12:38 ndufresne: pq: same for gstreamer, so I doubt it can be much worse ;-P
12:38 karolherbst: tnt: that's all driver details
12:38 karolherbst: I think the problem is, that external_memory also relies on cl_khr_semaphore
12:39 karolherbst: for synchronizing access and stuff
12:39 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
12:39 karolherbst: and uhh.. cl_khr_external_semaphore
12:39 karolherbst: uhh, there is a lot to implement actually
12:40 pq: ndufresne, I wonder if we are talking about the same thing here.
12:41 karolherbst: I kinda have to figure out how solid the CTS tests here are
12:41 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
12:41 karolherbst: but if nothing is using it yet, then uhh.. I have a few more important things to do myself
12:42 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.
12:42 ndufresne: well, GStreamer will ignore everything it does not support in the GL stack, I don't see the difference
12:42 pq: transfer and primaries are *not* part of this
12:43 ndufresne: you mean it must respect the tranfer and primaries ?
12:43 pq: no, I mean this API does not consider those
12:45 pq: I'm talking about the https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt API
12:46 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.
12:46 ndufresne: yes, and indeed, only COLOR_SPACE_INT (matrix), RANGE and siting (this one is not implemented in gst gl)
12:47 pq: or that specific Gst elements might make guarantees
12:48 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
12:48 zmike: mareko: ping on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25624 review
12:48 pq: ndufresne, right. An API is useless to me, if it does not promise to do what it says.
12:48 ndufresne: I know everything is useless for you, but in practice, it is still very useful to most
12:49 ndufresne: gst or GL will always be useful for you specifically cause you have to take into account the display charateristic
12:49 ndufresne: * useless
12:49 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.
12:50 pq: You can't even write a CTS for EGL for this, because the spec is "everything goes".
12:50 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)
12:51 pq: Which compression?
12:51 ndufresne: anything that you can't shade and is described with a modifier
12:51 pq: losless compression is totally fine
12:52 ndufresne: well, you missed something about EGL then ;-P
12:52 pq: lossy compresions I'd like to avoid, indeed
12:52 ndufresne: most EGL API will only import YUV compressed buffers and deliver it as RGBA to you shader
12:52 pq: ndufresne, please, forget everything I said. I learnt that Gst doesn't care, and that all I needed.
12:53 ndufresne: you are so so so wrong ...
12:53 pq: What is "YUV compression"?
12:53 ndufresne: we care, and if we have time for adding some missing implementation, we will, stating that we don't care is limit insulting
12:53 pq: well you did say you are fine with not guaranteering a correct result
12:54 ndufresne: pq: a YUV format combines with a specific compressor (on memory controller)
12:54 pq: and those are usually lossy?
12:54 ndufresne: pq: I said we can live with missing cases, and add later
12:54 tnt: karolherbst: damn :/ It improves things but doesn't fix it completely https://i.imgur.com/WQlsdtf.png
12:55 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
12:55 pq: I want to write tests that verify the result is close enough according to the theory.
12:55 ndufresne: so in todays GL stack, you can't do anything about it
12:55 tnt: (the correct pattern is the color gradient with gree lines. The other pattern is something I pre-fill the texture with with glTexImage2D)
12:56 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
12:56 pq: ndufresne, I mean, what I (Weston) does do, is import YUV buffers as R8+GR88 and use shaders.
12:57 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.
12:57 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
12:57 ndufresne: lynxeye: :-D good summary
12:57 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.
12:58 pq: ndufresne, exactly, I will disable that direct import, when color management is in use.
12:58 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)
12:58 pq: I will force the shader conversion path.
12:58 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 ...
12:59 ndufresne: you will also loose zero copy for any videos which aren't aligned to your GPU requirement on Mali
12:59 pq: ndufresne, that is all fine, because when you enable color mangement, you care about the result.
12:59 ndufresne: well, you also care about performance, since these high quality videos are often also 4K
13:00 pq: I will also disable all KMS overlay planes until there is a KMS UAPI that guarantees the results.
13:00 karolherbst: tnt: pain
13:01 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.
13:01 tnt: karolherbst: yeah, I'm learning way more about intel gfx than I ever wanted to know :)
13:01 pq: and those will be separate configs
13:01 ndufresne: pq: fun :-( this first implementation will not be very useful in real life imho
13:01 karolherbst: :D
13:01 pq: ndufresne, that's what research is. Make it work first, then figure out how to make it fast.
13:02 ndufresne: sure, but its no justification for saying the rest of the world is wrong and don't care here
13:02 pq: I didn't say that.
13:02 pq: I was asking if were aware that EGL gives no guarantees, and you are.
13:02 ndufresne: I believe you said that toward gst folks
13:02 pq: *if you
13:03 pq: no
13:03 ndufresne: of course we are aware, do you think the rest of the world is stupid
13:03 karolherbst: tnt: the cursing of getting involved in mesa stuff
13:03 pq: ndufresne, now you are calling me stupid.
13:03 karolherbst: you start fixing some bug, and before you know it, you know the details of all the GPUs out there
13:04 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
13:04 pq: ndufresne, and no, people are often surprised by the attributes being hints.
13:04 tnt: karolherbst: :)
13:04 pq: ndufresne, got it. I'll try very hard to never speak to you again. Farewell.
13:05 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)
13:07 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)
14:09 DemiMarie: pq: why do you need to use OpenGL instead of Vulkan?
14:11 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.
14:11 DemiMarie: That is what Vulkan/OpenCL/OpenGL all do.
14:20 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.
14:21 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.
14:37 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
14:43 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
14:43 ndufresne: this is not nice comment considering all the effort we put into this
14:46 DemiMarie: pq: Should Weston switch from OpenGL ES to Vulkan?
14:47 hakzsam: emersion: IIRC, you are the libdrm release manager ?
14:49 pq: DemiMarie, I don't know of pressing reasons to do so. It would be a lot of work.
14:49 tomeu: uff, finally got it off my chest: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25714
14:51 emersion: hakzsam: there are no libdrm release managers, anyone with push access + SSH access can release
14:51 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.
14:52 pq: then again, I've set it so that enabling color management in Weston requires GL ES 3, but that is optional.
14:53 pq: I mean enabling color management is optional
14:53 DemiMarie: pq: it looked like Weston needs some features that are in Vulkan but not OpenGL ES.
14:54 DemiMarie: Given how new color management is, I would not be surprised if it needs new APIs that are Vulkan-only.
14:58 pq: Maybe that YUV compression is one, I didn't know it even existed.
14:59 pq: My task is just to get color-management and HDR working at all to begin with and ensure they can be trusted.
15:01 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.
15:01 pq: *plans
15:08 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
15:09 ndufresne: (HW meaning dedicated, rather then all done in GPU code)
15:10 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.
15:13 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.
15:14 pq: This is merely the starting point for satisfying the users of traditional color management.
15:15 pq: Those requirement apply to anything a compositor is using, including EGL, GL, Vulkan and KMS.
15:22 pq: My vision is that eventually *our* requirements will be driving hardware design in part.
15:22 lynxeye: pq: DemiMarie: There are whole fleets of devices shipping with weston and etnaviv, with currently no Vulkan driver.
15:26 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.
15:26 tnt: (and unless you get it really wrong, it's also very hard to tell if you get it "a little" wrong)
15:45 sima: tnt, oh dg2 explains things, that doesn't have these magic I915_TILING_ values anymore
15:45 sima: so yeah the detour through this legacy api stops working
15:46 orbea: this is a bug in mesa? https://github.com/mpv-player/mpv/issues/12468#issuecomment-1761523042
15:46 sima: (the code really shouldn't go through these legacy values at all when handling modifiers)
15:46 tnt: sima: I opened https://gitlab.freedesktop.org/mesa/mesa/-/issues/9994 to track this FWIW.
16:44 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?
17:00 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 ?
17:01 zmike: yes
17:01 tnt: zmike: ok, thanks !
18:53 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?
19:10 cheako: Kayden, thanks for the tip... I tried that and I think because the app exists instead of segv the dump is not triggered.
19:11 cheako: ...though I'm kinda confused as to how a segv handler is called?
19:27 cheako: I was also wondering it the dumps would be tagged with the return code from pipeline creation?
19:42 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
19:42 ndufresne: the latest mutter ?
19:44 ndufresne: and of course, there could be regression in mesa, this is old 22 working "mostly"
19:44 ndufresne: I'll let you know when I have a change to upgrade
19:45 Company: ndufresne: no, I was on F38's mutter (but custom git main Mesa)
19:45 Kayden: cheako: it ought to dump normally, FOSSILIZE_DUMP_SIGSEGV just also makes it finish dumping the files even if compilation crashes
19:45 Company: ndufresne: F45 Mutter supports YUV Wayland buffers (and afaik uses custom shaders for those, with no support for EXT_OES_import)
19:46 ndufresne: which probably saves the day imho
19:47 ndufresne: at least, we have a solution for users, stay on OpenGL, you'll get more accurate results atm
19:50 Company: hrm actually
19:51 Company: zmike: does zink do EGLImage import and in particular YUV?
19:52 zmike: about the same as other drivers
19:52 Company: I was wondering about VkSamplerYCbCrConversion
19:53 zmike: kinda partially plugged in
19:54 Company: I guess that's good enough - if it's actually used, it can be plugged in more
19:54 Company: but it could have been it's impossible to do or sth
19:54 Company: that's why I was wondering
19:56 daniels: if zink didn't do EGLImage import, it couldn't do ~anything
20:00 cheako: Kayden, I'll try a few more things, but are there docs I could read then?
20:03 Kayden: there's a readme at https://github.com/ValveSoftware/Fossilize
20:32 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.
20:37 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)..
20:38 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)
20:38 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
20:38 ndufresne: chear/cheat
20:39 ndufresne: actually, on Intel you can transfer modifier from/to any formats, but this is not true notably for AFBC
20:40 ndufresne: and there is nothing at Intel to ensure this will stay true, its just a state
20:40 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
20:40 ndufresne: I believe there is one already
20:40 Company: robclark: the problem is that the mesa drivers are all broken
20:40 ndufresne: it also very useful to transform image that then get passed to an encoder, the CSC is not always needed in that context
20:41 ndufresne: (e.g. transcoding)
20:41 Company: robclark: so importing a YUYV/NV12 EGLImage fails or if it works, it doesn't sample properly in a shader
20:41 robclark: rendering _too_ yuv might be a bit more work.. but just not applying CSC transform would, I think not be hard
20:42 robclark: hmm, I know we use that on CrOS so I don't think you can say they are "all broken"
20:43 Company: robclark: "all" here meas Intel and AMD
20:43 robclark: we defn use that on intel and amd chromebooks.. so 🤷
20:44 Company: no idea - we tried it on all the hardware we had and on recent Mesa it seems broken
20:44 Company: though apparently it worked on F36 for ndufresne ?
20:44 Company: so maybe something got busted, but we haven't been smart enough to figure out if/what
20:45 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
20:45 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...
20:45 daniels: but I'm sure it'll be fixed any minute now with this illuminating detail
20:46 Company: daniels: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8112 does exist
20:46 daniels: that's a bug related to YUV import, yeah
20:47 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
20:48 daniels: but perhaps fixing ndufresne's bug will magically fix your bugs which occur with unknown usage on unknown hardware. let's find out.
20:49 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
20:49 Company: I was trying to understand what's going on
20:49 Company: so I could file a better bug report / actually do an MR
20:49 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
20:50 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
20:50 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
20:50 ndufresne: on GFX 9 or AMD, not random AMD here
20:50 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
20:50 ndufresne: *of AMD
20:51 daniels: ndufresne: yeah, the stride%256 check is pretty brutal, but well, hardware is hardware
20:51 Company: daniels: I didn't know I wasn't allowed to have a life if I talk in here
20:52 daniels: Company: if you want to chat away, then at least be vaguely respectful
20:52 ndufresne: daniels: no, that's ok, the stride it expects is incorrect, by a factor of 2
20:53 ndufresne: its so niche, maybe I should rework that issue subject ...
20:56 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
20:57 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?
20:57 Company: which is definitely not what I was going for, nor even interested in
20:58 daniels: Company: would you like to hear my thoughts about GObject next time I encounter a bug in GNOME?
20:59 Company: if that helps you dig into the code, sure
20:59 daniels: it's shit
20:59 daniels: hth
21:00 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
21:00 robclark: so https://gitlab.freedesktop.org/mesa/mesa/-/issues/8112#note_1731443 looks like probably a legit issue.. I'd need to page back in u_format.. but you should probably test that as MR
21:01 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)
21:02 ndufresne: robclark: this one is merged, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20815
21:02 ndufresne: in some modified form of course, but that's base on the idea I had
21:02 robclark: ahh, ok
21:02 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
21:02 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
21:03 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?
21:03 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
21:04 ndufresne: oh yeah. we all prefer loud
21:05 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
21:05 ndufresne: but when a third party needs to import it fails
21:06 ndufresne: for CSC, well, there is piglit tests, notice that 20815 ended with enabling more test, cause they started passing after that change
21:06 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
21:07 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
21:08 ndufresne: my original patch was just trial and error and deduction from what worked
21:08 Company: Actually, are there piglit tests for this issue that are disabled? (The wrong size failing to import I mean.)
21:08 Company: *The right size failing to import and wrong size being claimed
21:08 ndufresne: no, since the buffer is being allocated by the same driver, so the over-allocation is hidden this way
21:08 Company: Or is there no such test?
21:09 ndufresne: I think we'd need a HW specific test, which just validate expectation, but I'm not too sure how
21:09 ndufresne: I think most tests are entirely generic too
21:10 Company: somebody mentioned udmabuf as an option, but I have no idea if piglit has access to that
21:12 ndufresne: yeah, but it leave behind CMA cases, and also memory shared from the same discret GPU
21:13 Company: yea, it's not perfect
21:17 robclark: not entirely clear to me the cpu cache situation with udmabuf.. which might be an issue with some hw