<Company>
DRI is smarter than the drivers apparently
<Company>
eglQueryDmaBufFormats() goes via dri2_yuv_dma_buf_supported() which assembles YUV formats from other formats but eglCreateImage does not, so I get claims of supported formats when the formats in fact aren't supported
junaid has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
mszyprow has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
Leopold_ has quit []
sima has joined #dri-devel
Leopold_ has joined #dri-devel
junaid has joined #dri-devel
luben has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
rasterman has joined #dri-devel
junaid has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
ManMower_ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
ManMower has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #dri-devel
Zopolis4 has quit [Quit: Connection closed for inactivity]
aravind has joined #dri-devel
mvchtz has quit [Quit: WeeChat 3.5]
JohnnyonFlame has joined #dri-devel
mvchtz has joined #dri-devel
frieder has joined #dri-devel
fab has joined #dri-devel
Company has quit [Remote host closed the connection]
neniagh has joined #dri-devel
pcercuei has joined #dri-devel
vliaskov_ has joined #dri-devel
sgruszka has joined #dri-devel
mvlad has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
tursulin has joined #dri-devel
sarahwalker has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
<daniels>
snark-and-quit is definitely an antipattern, yeah
lynxeye has joined #dri-devel
sarahwalker has quit [Ping timeout: 480 seconds]
junaid has joined #dri-devel
JohnnyonFlame has quit [Remote host closed the connection]
sarahwalker has joined #dri-devel
<MrCooper>
daniels: if you mean Company, he said he's only interested in real-time conversations, otherwise we should just ignore what he wrote
<MrCooper>
if only the latter was that simple
yyds has quit []
yyds has joined #dri-devel
junaid has quit [Remote host closed the connection]
<tnt>
well he quit 2h later, it's not like he joins, rents, quits instantly ... not everyone has a bouncer ...
<sima>
mdnavare, we could probably put that WARN_ON into drm_atomic_get_crtc_state
<sima>
just need to set a flag in drm_atomic_state before we enter the driver's ->atomic_check code
<sima>
mdnavare, https://paste.debian.net/hidden/5ae7baf2/ this should give you a nice backtrace in exactly the offending code, completely implemented in generic code
<sima>
vsyrjala_, ^^ thoughts?
ficoPRO10 has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
BobBeck is now known as Guest3072
BobBeck has joined #dri-devel
junaid has joined #dri-devel
junaid has quit [Remote host closed the connection]
<sima>
mripard, uh I meant to delete the exploratory ones, not all
<sima>
from a very quick look drm_test_mm_init|debug|once look reasonable at least
<sima>
and drm_test_budy_alloc_limit too
junaid has quit [Remote host closed the connection]
<sima>
buddy_alloc_pessimistic/optimistic might be fine too
<sima>
essentially keep the ones that are efficient and check some corner case like whether we can allocate to the last page forward/backwards (since those go down by page order they should be log(n) of the allocator size, which should be ok)
<sima>
but maybe I misread some of the tests
<sima>
mripard, it's also easier to encourage people to fill the test holes if there's a little bit there still :-)
ManMower_ is now known as manmower
<mripard>
Ack :)
<mripard>
I'll send a v2, thanks
kts has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
<sima>
mripard, I'd say in the end just measure the runtime and then sanity check the tests that are left, if they look like log(n) or less it should be fine even on more extreme cases
fab has quit [Quit: fab]
yuq825 has quit []
Leopold_ has quit [Remote host closed the connection]
bmodem has joined #dri-devel
junaid has joined #dri-devel
Leopold_ has joined #dri-devel
AnuthaDev has joined #dri-devel
junaid has quit [Remote host closed the connection]
Ahuj has joined #dri-devel
Haaninjo has joined #dri-devel
Dark-Show has quit [Quit: Leaving]
Ahuj has quit [Quit: Leaving]
kts has joined #dri-devel
Company has joined #dri-devel
<pq>
sima, I certainly don't disagree with getting something useful even if somewhat deficient, if the known desires have been evaluated and rejected. I only oppose to not even evaluating, and even if rejected for now, reducing potential future burdens should be done if feasible.
Company has quit [Remote host closed the connection]
Company has joined #dri-devel
Company has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
Company has joined #dri-devel
<DavidHeidelberg>
shadeslayer: which flight u talking from BCN to LCG? 20:20?
kzd has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
pjakobsson has quit []
pjakobsson has joined #dri-devel
alyssa has joined #dri-devel
fab has joined #dri-devel
luben has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
<shadeslayer>
DavidHeidelberg: It's the one that leaves on Monday morning
<Company>
Imported EGLImages have an implementation-defined formats and it is valid to for example consider them compressed (like Mesa). And compressed formats are not color-renderable, so cannot be attached to framebuffers
<shadeslayer>
DavidHeidelberg: I land in LCG at 08:30 AM
<pq>
Company, they can be attached, but the FBO won't be complete, and it needs to be complete for glReadPixels to work?
ficoPRO10 has quit [Ping timeout: 480 seconds]
dviola has quit [Ping timeout: 480 seconds]
<Company>
pq: yes
<pq>
alright, good to have an answer.
<Company>
so it's implementation-defined if the code will work
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
ficoPRO10 has joined #dri-devel
<MrCooper>
offhand it seems odd that color-renderable would be required for glReadPixels, I guess it's plausible though
fab has quit [Quit: fab]
Duke`` has joined #dri-devel
hikiko has joined #dri-devel
hikiko has quit [Read error: Connection reset by peer]
<alyssa>
I don't see how it'd be possibly affected which makes me suspect an intel backend bug or something
mort_ has quit [Quit: Ping timeout (120 seconds)]
tyalie has quit []
bbhtt- has joined #dri-devel
sigmaris_ has quit [Remote host closed the connection]
wv has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
Whooa22 has joined #dri-devel
_kbingham has joined #dri-devel
qyliss has quit [Remote host closed the connection]
shashanks_ has quit [Remote host closed the connection]
Rayyan has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
RSpliet has quit [Quit: Bye bye man, bye bye]
alatiera has quit [Quit: Ping timeout (120 seconds)]
bbhtt has quit [Quit: Bye!]
pixelcluster has quit [Remote host closed the connection]
sigmaris has joined #dri-devel
CME has quit []
KitsuWhooa has quit [Quit: Unable to handle kernel NULL pointer dereference at null]
kbingham has quit [Remote host closed the connection]
karolherbst has quit [Remote host closed the connection]
Plagman has quit [Remote host closed the connection]
CME has joined #dri-devel
tyalie has joined #dri-devel
pixelcluster_ has quit []
pixelcluster has joined #dri-devel
qyliss has joined #dri-devel
Plagman has joined #dri-devel
<alyssa>
only the opt algebraic changes could even possibly change things and, the patterns are correct and all non-intel hw is happy
<alyssa>
Kayden: maybe ^
ngcortes has joined #dri-devel
co1umbarius has quit [Remote host closed the connection]
calebccff has quit [Remote host closed the connection]
bbhtt- has quit []
FLHerne has quit [Quit: There's a real world out here!]
Whooa22 has quit [Remote host closed the connection]
FLHerne has joined #dri-devel
calebccff has joined #dri-devel
KitsuWhooa has joined #dri-devel
bnieuwenhuizen has quit [Remote host closed the connection]
bbhtt has joined #dri-devel
bnieuwenhuizen has joined #dri-devel
CME has quit []
halfline has joined #dri-devel
co1umbarius has joined #dri-devel
CME has joined #dri-devel
ngcortes has quit [Quit: Leaving]
ngcortes has joined #dri-devel
alatiera4 has quit []
_kbingham is now known as kbingham
mbrost has joined #dri-devel
alatiera4 has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
<zmike>
mareko: on the other hand AMD isn't really my target for this
alatiera4 is now known as alatiera
junaid has joined #dri-devel
jkrzyszt has joined #dri-devel
<Company>
ndufresne: I think the problem here is that code doesn't agree if the magic RGRB format is a 2px-block 32bit format or a 1-px block 16bit format
<Company>
and half the code assumes the first while the other half assumes the 2nd
<Company>
so you inevitably run into sanity checks that bail out somewhere
<Company>
like, AMD allocates memory for a 1px-block 32bit format and then bails because the size of the dmabuf is only half of the allocated GPU buffer
<Company>
no idea where intel gets confused
<Company>
I might track that down next
<mareko>
alyssa: it would be CPU intensive to do tiling coord->address conversions and mapping textures in VRAM directly would confuse memory management that could move them to RAM permanently
<mareko>
so the extra RAM->VRAM upload copy is actually good for you
alatiera has joined #dri-devel
<Kayden>
alyssa: so dEQP-GLES31.functional.shaders.sample_variables.sample_mask_in.bit_count_per_sample.singlesample_rbo regresses due to the last patch, "Optimize LLVM booleans"
<Kayden>
not sure why yet but that narrows it down a little
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
<alyssa>
mareko: fair enough!
<alyssa>
Kayden: smells like intel compiler bug
<Kayden>
yeah, definitely
AnuthaDev has quit []
<Kayden>
it looks like we propagated a negate into the first thing but not anywhere else
mbrost has quit [Ping timeout: 480 seconds]
karolherbst_ is now known as karolherbst
AnuthaDev has joined #dri-devel
i509vcb has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<ndufresne>
Company: I'm starting to recall this, and yes, I diged up on why the BAD_ALLOC on image import, and reason was bad expected stride/size, and this is the bit that never got merged, then the swizzling was wrong, which is the part that got merged as-is
<ndufresne>
AMD requires the stride to be exactly ROUND_UP(width, 256) fyi, anything else get discarded
<ndufresne>
but someone reported that the old vaapisink (which is pure GL machinary inside mesa for AMD), got the swizzling wrong, I showed them what wrong there, and they refused to correct it, anyway, we are dropping vaapisink support in gst, so I don't have any interest in this blunt argument thingy
<Company>
this is a whole-stack issue though
* ndufresne
wonder if meson devenv works these days with mesa ...
<Company>
kinda like HDR
<Company>
because we want GStreamer to produce dmabufs (either via pipewire/webcam or via hardware decoding, then move thm through GTK and the Wayland compositor into the display hardware
<Company>
while allowing both GTK and the compositor to unpack it if they need to
<Company>
so putting hacks in one place won't work anyway
<ndufresne>
ah, so you are looking at possibly have a passthrough inside some GTK code path ?
<Company>
yes
<Company>
that's the long-term goal
<ndufresne>
that's a good idea, does it mean you endup with a sandswitch of renders ?
<Company>
that goal is somewhat independent of working YUV
<ndufresne>
e.g. glrender | passthroug sub-surface | glrender ?
<Company>
because Boxes wants it for virtio
<ndufresne>
I see
<ndufresne>
but swizzling issue is extremely common with RGB formats too ;-D
<Company>
and yes, likely that's the best solution - have GTK create additional surfaces and distribute the rendering to them
<Company>
but we can swizzle ourselves in RGB!
<ndufresne>
well, when direct dmabuf import fails on gst side, all colors are correct :-D
<ndufresne>
(shader side csc)
<ndufresne>
but the direction I want to push, and you saw robertfoss work I guess, is that this GL glue in gst should not be needed
<ndufresne>
whatever gst do, the compositor can do really
<ndufresne>
and widget libraries can take better decisions too
<Company>
that's block size 2 and 16bit - either you want block size 1 or 32bit
<Company>
but no clue what the right choice is
<ndufresne>
wow, ok, that seems very familiar, they can't all have the same swizzling lol
<ndufresne>
yeah, that's the scary part, when I wrote the fix for YUY2, it was written in trial and error, and I pushed the MR as a draft, cause I had no rationale
<ndufresne>
but since it fixed all the piglit tests, they just flipped it over and pushed it
heat_ has joined #dri-devel
<Company>
the swizzling part happens elsewhere I think
<ndufresne>
Company: what I did is check dri2, check which one is picked by default, and gave that one xyz1, and then adjusted all the others accorindgly
<Company>
when it maps YUYV => RGRB or wherever
heat has quit [Read error: No route to host]
<ndufresne>
this code is only used for internal shader based swizzling, panfrost notably does not use it, it has an other swizzler which have an incompatible configuration interface
<ndufresne>
at least this is my understanding
<Company>
I should see what my rpi does
darkglow has joined #dri-devel
<tleydxdy>
is it proper to export a vulkan binary semaphore and import it as a timeline semaphore? either via opaquefd or syncobj
<Company>
ndufresne: but on the GTK side, the way forward is adding dmabuf import for well-working formats (read: RGB), then switch boxes to that and everything that uses GdkGLTexture now, and then look into pushing stuff straight to Wayland without going through GL's renderer
glennk has joined #dri-devel
<Company>
ndufresne: because I want to get away from GL textures and to dmabufs as a sharing mechanism - it avoids the GLContext mess and it works with Vulkan
<Company>
which means GtkGLArea would work with a Vulkan renderer
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
<Company>
and once YUV works, we can hook it in
<ndufresne>
at least I'm happy to say it works on panfrost here ;-D
<Company>
or if it does already on panfrost or whatever, we can hook it in now
<Company>
v4l2src doesn't do dmabufs - or did you add that recently?
<ndufresne>
yes, its a dmabuf produces (linear only)
<ndufresne>
* producer, just like pipewire v4l2 support
<ndufresne>
(or libcamera, but you get the point)
<Company>
neither v4l2src nor pipewiresrc produced dmabufs for me, when I recently tried (but on stock F38)
<ndufresne>
the difference with pipewire, is that you don't have to use the buffer before pipewire have run over the array of FDs (something to be fixed in pw)
<ndufresne>
I've turned v4l2src in dmabuf only about 7 years ago I think
<ndufresne>
but its not using the dmabuf caps feature
<Company>
glimagesink used glTexImage2D() to upload
<ndufresne>
when dmabuf are linear, you can pass that as normal memory, we have wrapper for mmap and dmabuf sync around these fds
<Company>
and not eglCreateImage()
<ndufresne>
most of the time, this is because the GPU can't import it
<ndufresne>
modern GPU are pretty limited in regard to foreign memory
<Company>
well, this one claims it can and then breaks - but GStreamer didn't
<ndufresne>
which platform was that ?
<Company>
so I set some breakpoints and they were never hit
<Company>
Fedora 38 - my AMD desktop
<ndufresne>
e.g. on panfrost, this import thing only works with GLES2, since there is no external eos texture on big gl
<Company>
I tried GLES
<ndufresne>
what was the resolution ? was the width a multiple of 256 ?
<ndufresne>
cause AMD you know ...
<Company>
probably not
<ndufresne>
panfrost needs 64 (or a multiple), AMD 256 (exactly)
<ndufresne>
except that panfrost for YUV supports 2 I think
<ndufresne>
which is because there is a specialised sampler
<ndufresne>
(in short, we can zero-copy with YUV direct import, but can't always fallback or R8/RG88 + shader)
<ndufresne>
sharing dmabuf is a complex world, you always need a good fallback
<Company>
I had naively assumed that every GPU has specialized samplers
<ndufresne>
well, maybe they do, but rarely are the one which have that implemented
<Company>
because they all seemed to support VkYCbCrConversion
<ndufresne>
I think its more commonly implemented for VK drivers, but haven't been testing this much, gst vk don't have dmabuf support at all
<ndufresne>
RPi is a good platform to check
<Company>
I first need to fix my Vulkan code to not use features that the rpi driver doesn't support ;)
<MrCooper>
ndufresne: yes, meson devenv works with Mesa
<ndufresne>
MrCooper: thanks, that's good news !
<ndufresne>
now, do I set gst as subproject of mesa, or mesa as subproject of gst ....
<MrCooper>
ndufresne: surely AMD GPUs support multiples of 256 as well
<ndufresne>
(hard choice eheh)
<ndufresne>
MrCooper: you mean the HW ? cause in the YUV import path, it was pretty much validating with ==
<ndufresne>
assuming in fact that you know your padding, and deal with the cropping
<MrCooper>
sounds like a bug then
<ndufresne>
(fun fact, the padding when its stride driven is actually lost in the pipeline, very commonly at least)
<ndufresne>
a side effect of how we implemented things 20years ago lol
<Company>
considering it's failing at x16 vs x32 and blockwidth 1 vs 2, I'm not surprised stride handling is somewhat buggy
<Company>
what confuses me is that both AMD and Intel are broken in roughly the same way, even though they're different codebases
<ndufresne>
remind me, what do you test on Intel that breaks ? maybe I can try and repro ? I don't recall having YUV swizzling issues with Intel
<Company>
eglCreateImage() failing
<ndufresne>
ah, you mean it get rejected
<ndufresne>
that require breaking into mesa, cause there is no indication which params got rejected
hansg has quit [Quit: Leaving]
<ndufresne>
I think it does matter though that you should support RG88 fallback
<ndufresne>
(with your own shaders)
<Company>
I'm not sure I want to do that
<Company>
because then I need to encode dmabuf implementation details into my code
<ndufresne>
how do you fallback atm ?
<ndufresne>
you can't rely on dmabuf import to always work on all PC GTK will be running on
<ndufresne>
even virtio have copy path
<ndufresne>
the alternative is to never let anyone else then the GPU driver allocate the memory, but then it may fail import on the other side
<Company>
by the time GTK imports a dmabuf, it guarantees it can download it
<Company>
if we can't make that happen, we don't import the dmabuf
<Company>
what we need to make that happen: no idea
<ndufresne>
what does this mean ?
<ndufresne>
you mean that its guarantied to be able to use texture2D fallback ?
<ndufresne>
so you basically offer direct import or texture2D?
<ndufresne>
(nothing in between ?)
<Company>
it means it is guaranteed to be able to give you a GBytes * with pixels that look like the dmabuf
<ndufresne>
hmm, so DRM modifiers is out of the way here ?
<Company>
how that has to happen is still up for debate
<Company>
nah, if we can have a path via GL that works, that is fine
<Company>
and if that involves copying the dmabuf into a texture before downloading, that is also fine
<ndufresne>
well, then why not "just" implement pixel upload ?
<Company>
what do you mean "just"?
<Company>
I want to ideally support a fast-path where host memory never touches the pixels
<Company>
but I also want to be able to always support a path where the pixels end up in host memory
<ndufresne>
well, the reality is that to cover wide range of drivers for zero-copy, you need a set of method, similar to what compositors do, which is direct dmabuf import (let the GL/VK stack convert), indirect dmabuf (use well support R/RG/ARGB formats and shade it), and finally upload the pixels (still need the same shaders here)
<Company>
oh you mean upload support for YUV pixels?
<ndufresne>
in the case of wayland, I add : copy the pixels to a dmabuf, cause that can dramatically improve performance over copying into a shm
<ndufresne>
well, even for RGBA, you should enumerate wha the DMABuf import backendd supports, and use a substitution with a swizzling shader to ensure wider support
<ndufresne>
(though it quite rare these days that the direct path does not already support all swizzling)
<Company>
I don't think it's my job to work around broken drivers - fixing the drivers also helps more than just GTK
<Company>
and I absolutely do not want to encode implementation details about dmabuf formats into GTK - unless they are well-defined somewhere
<Company>
because that's a game of bug whack-a-mole that I'm not interested in
tango_ is now known as Guest3146
tango_ has joined #dri-devel
AnuthaDev has quit []
Guest3146 has quit [Ping timeout: 480 seconds]
<ndufresne>
drivers don't have to support direct YUV import, this isn't a broken HW
<ndufresne>
*dirver
<Company>
sure
<ndufresne>
and YUV through pixel upload is not something I've seen working anywhere
<Company>
but if drivers don't support it, there's not much benefit in us supporting it
<ndufresne>
so better just giveup on yuv ;-P
<ndufresne>
well, we clearly added YUV shading in compositor and gst for a reason ;-P
<Company>
which one though?
<ndufresne>
GPU csc is a clear winner against CPU
<ndufresne>
I personally think we should push into compositors as much as possible, but I'm praying for my personal goals here
<Company>
well sure, but you can just use an RGB dmabuf and attach some colorspace info to get conversion going
diego has joined #dri-devel
<ndufresne>
it won't help you toolkit library if you need to blur the video, or other funky transforms
<ndufresne>
*your
<ndufresne>
e.g., it won't give you a texture in gtk to play with
frieder has quit [Remote host closed the connection]
<ndufresne>
(but apps can do that for you)
<Company>
why not?
<Company>
I get a dmabuf and a colorspace and then the GTK color conversion routines do the YUV=>RGB conversion
<ndufresne>
Great, then why not implement import with substitute like I suggested ?
<ndufresne>
I smell you didn't really get the ladder around dmabuf importation ...
Duke`` has quit [Ping timeout: 480 seconds]
<Company>
which spec lays out dmabuf substitutes?
<Company>
as an application I am explicitly meant to treat dmabufs like a black box and just pass everything through
<Company>
so if I start subsituting random stuff, that's wrong
<ndufresne>
the contradiction here is that you want to do color conversion routines
<ndufresne>
if GTK knows about DMR fourcc XYVx, and the modifier is linear, you don't have to tread that as a black box
<Company>
sure, for linear formats there's a clear definition
<ndufresne>
e.g. I420 have 3 planes, which can be imported as 3 textures using R8 format
<ndufresne>
you cannot do that for non-linear formats, except on Intel (but then you started coding HW specificities, which I decided not to in gst fyi)
<Company>
though that is for map() afaik, not for eglCreateImage()
<ndufresne>
map or eglCreateImage have the same semantic
<ndufresne>
just that one is a copy to GPU mem, were the other uses the memory in-place
<Company>
do they?
<ndufresne>
yes, as long as you have non "external only" format, which you can query
<ndufresne>
as soon as you have an eglImage, you can shade it as if it was a pixel upload
<ndufresne>
you may want to read weston renderer, I believe its in pretty good and clean shape, it implement the full ladder here
<ndufresne>
e.g., first you try and see if GL can make your buffer look like RGBA, second, try and zero-copy import as substitute before opting for slow pixel upload, the two last will use the same shaders and same substitutes
<Company>
yeah, something like that could be feasible
<Company>
I'm stsill not a fan of it because I need to encode implementation details of drm formats for it
kts has quit [Quit: Konversation terminated!]
<Company>
and it's not (yet) important, because too much other stuff is missing in GTK
<Company>
and we're better off letting GStreamer do the relevant conversions to RGB
<ndufresne>
Company: so RPi, tested gst-launch-1.0 libcamerasrc ! video/x-raw,format=NV12 ! glimagesink, it happily picked NV12 directly, but then VC4 driver crashed on the first render, ;-P
<ndufresne>
(could be why they say wayland is experimental)
ngcortes has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
<tnt>
On intel, modifier == 0 would be ... linear ?
<Company>
bah, my webcam is USB-C and I have no converters
<tnt>
Although I though there would be at least the vendor id in the MSB.
<Company>
modifier == 0 is always linear, no matter where
<tnt>
Company: tx.
wv- has quit [Remote host closed the connection]
Kayden has quit [Quit: -> JF]
wv has joined #dri-devel
wv has quit []
Duke`` has joined #dri-devel
wv has joined #dri-devel
wv has quit [Remote host closed the connection]
wv has joined #dri-devel
<tnt>
I'm playing with teh dmabuf export of GL textures ATM. Could running under Xorg and under Xwayland lead to different modifier ? I'm a bit surprised I'm getting a linear modifier for a gl texture, I would have expected some tiled format (this is on a a750 on wayland). And under a Xorg on a 12thgen iGPU, I do get a tiled format.
diego has left #dri-devel [#dri-devel]
<dj-death>
tnt: not so surprising to me
<dj-death>
tnt: if we don't who is going to be the receiver of that dmabuf, probably the only common thing is linear
dviola has joined #dri-devel
<tnt>
dj-death: I'm just wondering why my iGPU and the A750 behave differently in that respect.
<tnt>
The use case is for the cl-gl interop with the 'intel compute runtime' fwiw.
ngcortes has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
Peuc has quit [Quit: Peuc]
jkrzyszt has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
Peuc has joined #dri-devel
<dj-death>
tnt: it's definitely different drivers
<dj-death>
tnt: not even sure the compute runtime knows about modifiers
<ndufresne>
tnt: modifier 0 is linear, not just intel
<tnt>
dj-death: it doesn't know about modifiers ... ATM I pretty much just pray that whatever the compute stack decide the format is matches what mesa decided the format is.
<tnt>
Which is obviously not great ... but I have no clue how the compute runtime memory stuff works and have not been able to find anyone that does ...
fab has quit [Quit: fab]
halfline has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
Duke`` has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
mhenning has joined #dri-devel
ngcortes has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
vliaskov_ has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
junaid has quit [Remote host closed the connection]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
Rayyan6 has quit []
Kayden has joined #dri-devel
Rayyan has joined #dri-devel
<daniels>
tnt: don’t do export from GL - allocate externally and import
<tnt>
daniels: It's not like I have a choice ...
<tnt>
The app use CL/GL sharing extension ... I do what I can to support it.
<tnt>
but I didn't invent it.
<Company>
daniels: what's the best place to allocate externally?
<Company>
or is the answer per-task?
glennk has quit [Ping timeout: 480 seconds]
mszyprow has quit [Ping timeout: 480 seconds]
mhenning has quit [Quit: mhenning]
vliaskov has quit [Remote host closed the connection]