00:03anholt: Company: glgetteximage, though you'll probably be disappointed if it's an external image. also, it's likely to just run a shader if you do any format conversions (where "format conversion" may include swizzling vs the native format chosen).
00:04Company: yeah, I'm thinking about external images in particular
00:05anholt: you may or may not get lucky if you glgetteximage, but I that's just luck. Just do a render.
00:05Company: but I'm also trying to understand how all this stuff works - and why going through a sampler requires renders
00:06Company: it feels like there should be a glCopyImage() or vkCmdBlitToBuffer() or such
00:07Company: something that doesn't need a pipeline
00:08mclasen: glgetteximage didn't work for yuv when I tried
00:10Company: with Mesa it might work for the RGB formats, but probably not for the external_only ones
00:15Company: I'm also trying to make sense of AvFormat, VkFormat, drm_fourcc, mesa_format, GStreamer's video/x-raw-yuv and friends to figure out what the best match for GTK's APIs would be
00:19anholt: mesa/pipe format are pretty bad for yuv. I've got a wip branch making it less of a disaster, but it's not there yet.
00:21Company: VkFormat is pretty interesting I think
00:22Company: though it's really hard to wrap one's head around
00:23Company: I do like mesa's utility APIs for working with formats, in particular applying the concept of blocks to YUV
00:26Lynne: Company: AVFormat has some disagreements with VkFormat, particularly for 10-bit formats
00:26Company: one thing I'm not sure about is if planes should be part of the format, or if planar formats should be assembled from regular formats
00:26Lynne: VkFormat requires padding in the LSBs, AVFormat requires padding in the MSBs
00:27Company: oh like that
00:27Company: I had expected strides and alignment and such
00:27Lynne: this only applied for fully planar yuv formats, like yuv420p, not for semi-packed, like nv12 or p010 or any of that family
00:27Lynne: those match up, because those have a pretty rigorous microsoft definition
00:28Company: that's nice
00:29Lynne: but you can always work around the desyncs by claiming a 10bit format is actually 16bits for vkformat -> avformat
00:31Company: except I need to do math then
00:31Lynne: what are you trying to do again?
00:31Company: not sure what I wanna do in detail yet
00:32Company: but the primary goal is enabling GTK to do passthrough of YUV dmabufs
00:32Lynne: passthrough of yuv dmabufs to what?
00:32Company: from video apps to Vulkan compositors
00:33Company: and "enabling" here means providing fallbacks for when things don't work, like when the compositor can't do the format and/or GL can't do the format and so on
00:34Lynne: ah, if you use hardware decoding, ffmpeg will give you a surface (vkimage for vulkan, dmabuf for v4l2, vaapi handle for vaapi), which you can then do whatever you'd like with it (export it to dmabuf, etc.)
00:35Lynne: you can use the hwcontext stuff to upload textures if not, or export them to whatever api you need
00:35Company: right, that's for the appdev to figure out - they might be using ffmpeg or gstreamer or libplacebo or...
00:36Company: but the easier I can make GTK's API the less likely those developers are to screw up when trying to map their video lib of choice to GTK
00:37Company: and they have often a lot less skills in YUV formats and care more about making an app with good UI/UX
01:00i509vcb: Company: on some hardware (agx for example) vkCmdBlit/Copy dispatch shaders under the hood
01:00i509vcb: But that's really just a semantic point tbf
01:02Company: still good to know
01:04i509vcb: I'd think just do dmabuf with format + modifier.
01:04i509vcb: All the APIs seem to just work with that
01:08Company: a question is if I also want to support CPU memory YUV
01:10Company: then I'd get around people having to do their own colorspace conversions etc which would all happen on the CPU
01:27DemiMarie: I think so.
01:28DemiMarie:wonders if she can speed up Xen and Intel support for virtio-GPU native contexts
01:29DemiMarie: (support for virtio-GPU native contexts on Xen and either Intel or AMD GPUs is the blocker for GPU acceleration in Qubes OS)
03:05kode54: does Mesa VAAPI now require modifiers?
03:06kode54: as of a specific Mesa commit that doesn't appear to have anything to do with this thing in particular, found by bisect, NV12 stops working with VAAPI on Polaris 10
03:06kode54: but it works fine on RDNA2
15:38co1umbarius: how can i choose the minimal vulkan version required for an extension to be present in the headers to build?
17:50karolherbst: yo pain.. "nir_shrink_vec_array_vars" is broken :'(
17:50karolherbst: https://gist.githubusercontent.com/karolherbst/3f5f00aecd69264c12e921dae0352e95/raw/87daaa8d28b218162aa255253f2cb5af7ed830ff/gistfile1.txt
17:51karolherbst: mhhh
17:51karolherbst: or rather...
17:51karolherbst: something splits variables apart...
17:52karolherbst: yeah.. that's more on the spirv_to_nir side of things..
17:56karolherbst: or rather on the spirv.. pain
19:20karolherbst: and SPV_KHR_workgroup_memory_explicit_layout is busted :'(
19:23karolherbst: pain
20:02cmarcelo: karolherbst: re: explicit_layout. how so?
20:19karolherbst: cmarcelo: shared memory doesn't get aliased even if it's declared in the spir-v like that
20:20karolherbst: so with anv I see an offset applied to the second variable
20:23karolherbst: though the VK CTS tests seem to pass.. mhh, maybe something is also wrong with the spirv or something else is going wrong
20:31karolherbst: mhh yeah.. something is very odd here
20:34cmarcelo: karolherbst: you mean, two blocks were supposed to be pointing to the same (workgroup memory) offset but somehow are not?
20:34karolherbst: yeah
20:35cmarcelo: karolherbst: do you have a before/after applying explicit layouts to wg NIR output?
20:35karolherbst: or rather.. it kinda works for scalar shaders, but not if like vec2 stuff is going on
20:36karolherbst: but zink might also be wrong here.. let me paste the nir
20:38karolherbst: cmarcelo: https://gist.githubusercontent.com/karolherbst/b9da80f72d9d5a97b556e4498ccd322c/raw/bb83b5b4096fad6b74dda41e347c39ee701e0103/gistfile1.txt
20:38karolherbst: the spirv https://gist.githubusercontent.com/karolherbst/b9da80f72d9d5a97b556e4498ccd322c/raw/73959582622265319d1d923026721371454ea973/gistfile2.txt
20:43karolherbst: anyway.. in the spirv both Workgroup variables should alias
20:49karolherbst: mhhh
20:49karolherbst: maybe something wrong with the layout stuff... I guess a bit more info is needed on the spir-v level?
20:53karolherbst: ahh yeah.. I have to add `Offset` decorations :')
20:55cmarcelo: karolherbst: yeah, the spirv variables need to have (internal) layout annotations
20:55cmarcelo: s/annotations/decorations/ :)
20:56karolherbst: are those legal for private memory?
20:57karolherbst: but yeah.. guess I'll fix zink
21:09karolherbst: cmarcelo: mhh... it kinda still doesn't work. Now I have `OpDecorate %_arr_uint_uint_128 Offset 0` on the arrays
21:10karolherbst: or do I have to wrap it inside a struct?
21:10karolherbst: kinda feels pointless, but...
21:10cmarcelo: karolherbst: needs to be in a block if I recall correctly
21:11karolherbst: "Apply only to a structure-type member." :')
21:11karolherbst: yeah.. looks like it
21:12karolherbst: yeah, so that's going to be a bit of a bigger rework then
21:12cmarcelo: there were some discussion, but the general idea was to be consistent with "Block == internal layout"
21:12cmarcelo: internal explicit layout
21:12karolherbst: yeah.. it's not really a problem as from a gallium perspective we just get an array anyway
21:12karolherbst: just need to wrap it
21:13cmarcelo: karolherbst: what are you transofrming from?
21:13karolherbst: cl
21:13cmarcelo: ok
21:13karolherbst: from a zink perspective it's just a normal GL compute shader though
21:13cmarcelo: right
21:14karolherbst: just with GL you normally don't mix nad match 8/16/32/... bit accesses
21:14karolherbst: but at least now I know what's wrong and how to fix it
21:15karolherbst: only 25 fails to fix until I'm conformant on top of vulkan 🙃 that issue is hit by 6 of those
21:15karolherbst: and 15 are image clamping not precise enough
23:51ndufresne: DemiMarie: regarding coherency handling limitation in DMABuf, I'm still looking for someone with a decent solution, there has been lengthly discussion last year, some ideas were promising around the cohérant flag on dev, but it quickly became apparent this solution was too simplistic, and devices can have multiple patch with different coherence
23:57ndufresne: In it's design, exporters are responsible for everything, which ignores who owns the cache (which can be on the device), whose the producers vs receiver, etc.