ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<anholt>
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).
<Company>
yeah, I'm thinking about external images in particular
<anholt>
you may or may not get lucky if you glgetteximage, but I that's just luck. Just do a render.
<Company>
but I'm also trying to understand how all this stuff works - and why going through a sampler requires renders
<Company>
it feels like there should be a glCopyImage() or vkCmdBlitToBuffer() or such
<Company>
something that doesn't need a pipeline
<mclasen>
glgetteximage didn't work for yuv when I tried
co1umbarius has joined #dri-devel
<Company>
with Mesa it might work for the RGB formats, but probably not for the external_only ones
columbarius has quit [Ping timeout: 480 seconds]
<Company>
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
<anholt>
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.
<Company>
VkFormat is pretty interesting I think
<Company>
though it's really hard to wrap one's head around
<Company>
I do like mesa's utility APIs for working with formats, in particular applying the concept of blocks to YUV
<Lynne>
Company: AVFormat has some disagreements with VkFormat, particularly for 10-bit formats
<Company>
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
<Lynne>
VkFormat requires padding in the LSBs, AVFormat requires padding in the MSBs
<Company>
oh like that
<Company>
I had expected strides and alignment and such
<Lynne>
this only applied for fully planar yuv formats, like yuv420p, not for semi-packed, like nv12 or p010 or any of that family
<Lynne>
those match up, because those have a pretty rigorous microsoft definition
<Company>
that's nice
<Lynne>
but you can always work around the desyncs by claiming a 10bit format is actually 16bits for vkformat -> avformat
mclasen has quit [Ping timeout: 480 seconds]
<Company>
except I need to do math then
<Lynne>
what are you trying to do again?
<Company>
not sure what I wanna do in detail yet
<Company>
but the primary goal is enabling GTK to do passthrough of YUV dmabufs
<Lynne>
passthrough of yuv dmabufs to what?
<Company>
from video apps to Vulkan compositors
<Company>
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
<Lynne>
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.)
<Lynne>
you can use the hwcontext stuff to upload textures if not, or export them to whatever api you need
<Company>
right, that's for the appdev to figure out - they might be using ffmpeg or gstreamer or libplacebo or...
<Company>
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
<Company>
and they have often a lot less skills in YUV formats and care more about making an app with good UI/UX
digetx has joined #dri-devel
carbonfiber has quit [Quit: Connection closed for inactivity]
<i509vcb>
Company: on some hardware (agx for example) vkCmdBlit/Copy dispatch shaders under the hood
<i509vcb>
But that's really just a semantic point tbf
<Company>
still good to know
<i509vcb>
I'd think just do dmabuf with format + modifier.
<i509vcb>
All the APIs seem to just work with that
<Company>
a question is if I also want to support CPU memory YUV
<Company>
then I'd get around people having to do their own colorspace conversions etc which would all happen on the CPU
crabbedhaloablut has quit []
<DemiMarie>
I think so.
* DemiMarie
wonders if she can speed up Xen and Intel support for virtio-GPU native contexts
<DemiMarie>
(support for virtio-GPU native contexts on Xen and either Intel or AMD GPUs is the blocker for GPU acceleration in Qubes OS)
<kode54>
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
<kode54>
but it works fine on RDNA2
kws has left #dri-devel [#dri-devel]
mclasen has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
jewins has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
heat has quit [Read error: Connection reset by peer]
<ndufresne>
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
<ndufresne>
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.