dragonfeed has quit [Remote host closed the connection]
Guest2096 has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
thaytan has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
sukuna has quit [Remote host closed the connection]
sima has joined #dri-devel
sukuna1 has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
sukuna2 has joined #dri-devel
Duke`` has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
sukuna1 has quit [Ping timeout: 480 seconds]
sudeepd__ has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
fab has joined #dri-devel
itoral has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
sudeepd__ has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
sudeepd__ has quit [Ping timeout: 480 seconds]
worky has joined #dri-devel
willy has quit [Ping timeout: 480 seconds]
macromorgan_ has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
jsa has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
qyliss has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
qyliss has joined #dri-devel
simon-perretta-img has joined #dri-devel
glennk has joined #dri-devel
fab has joined #dri-devel
jkrzyszt has joined #dri-devel
mripard has quit [Ping timeout: 480 seconds]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
frieder_ has joined #dri-devel
frieder has quit []
frieder_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
mripard has joined #dri-devel
frieder_ has joined #dri-devel
lynxeye has joined #dri-devel
jsa has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
Company has quit [Quit: Leaving]
sgruszka has joined #dri-devel
xantoz has quit [Read error: Connection reset by peer]
YuGiOhJCJ has joined #dri-devel
xantoz has joined #dri-devel
xantoz has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
apinheiro has joined #dri-devel
zxrom has joined #dri-devel
xantoz has joined #dri-devel
frieder_ has quit [Ping timeout: 480 seconds]
iyes has joined #dri-devel
xantoz_ has joined #dri-devel
flynnjiang has quit [Quit: flynnjiang]
pcercuei has joined #dri-devel
frieder_ has joined #dri-devel
xantoz has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
iyes has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
jfalempe has quit [Quit: jfalempe]
RSpliet has left #dri-devel [#dri-devel]
RSpliet has joined #dri-devel
jfalempe has joined #dri-devel
sukuna2 has quit [Remote host closed the connection]
sukuna has joined #dri-devel
iyes has joined #dri-devel
yyds has quit [Remote host closed the connection]
sukuna has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
jsa has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.2.2]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
kts has joined #dri-devel
itoral has quit [Remote host closed the connection]
zxrom has quit []
zxrom has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
BesterGester has quit [Quit: Ping timeout (120 seconds)]
BesterGester has joined #dri-devel
lemonzest has joined #dri-devel
guludo has joined #dri-devel
nukelet has joined #dri-devel
<mwalle>
robertfoss: thanks!
vliaskov has quit [Remote host closed the connection]
fab has quit [Ping timeout: 480 seconds]
chloekek has joined #dri-devel
kts has quit [Remote host closed the connection]
alane has quit []
alane has joined #dri-devel
yyds has joined #dri-devel
apinheiro has quit [Quit: Leaving]
fab has joined #dri-devel
kzd has joined #dri-devel
fab has quit []
mlankhorst has joined #dri-devel
zxrom has quit [Ping timeout: 480 seconds]
iyes has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
iyes has joined #dri-devel
epoch101 has joined #dri-devel
zxrom has joined #dri-devel
epoch101 has quit []
epoch101 has joined #dri-devel
fab has joined #dri-devel
bolson has joined #dri-devel
kzd has joined #dri-devel
epoch101 has quit []
halves has quit [Quit: o/]
halves has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
halves has quit []
halves has joined #dri-devel
kts has joined #dri-devel
halves has quit []
halves has joined #dri-devel
sudeepd has joined #dri-devel
yyds has quit [Remote host closed the connection]
frieder_ has quit [Remote host closed the connection]
yyds has joined #dri-devel
worky is now known as willy
epoch101 has joined #dri-devel
epoch101 has quit []
<MrCooper>
zamundaaa[m]: seeing a similar performance hit with explicit sync on Intel ADL-P iGPU, so it's not RADV / amdgpu specific
mripard has quit [Remote host closed the connection]
egbert is now known as Guest2146
egbert has joined #dri-devel
Guest2146 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
yyds has quit [Remote host closed the connection]
Company has joined #dri-devel
anujp has joined #dri-devel
Haaninjo has joined #dri-devel
tarceri_ has quit [Ping timeout: 480 seconds]
iyes has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
iive has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
anujp has joined #dri-devel
coldfeet has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
jeeeun84135190815 has quit []
jeeeun84135190815 has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
kts has joined #dri-devel
epoch101 has joined #dri-devel
sgruszka has quit [Quit: Leaving]
jsa has quit [Ping timeout: 480 seconds]
worky has joined #dri-devel
willy has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
feaneron has quit [Quit: feaneron]
feaneron has joined #dri-devel
jsa has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
chloekek has quit [Remote host closed the connection]
sudeepd_ has joined #dri-devel
sudeepd__ has joined #dri-devel
mvlad has quit [Remote host closed the connection]
sudeepd has quit [Ping timeout: 480 seconds]
sudeepd_ has quit [Ping timeout: 480 seconds]
<feaneron>
i'm trying to debug a problem with gtk4, vulkan, and webkit, and i'm hitting a wall now, perhaps people around here know something that can help
<feaneron>
to start, webkit renders web pages in a subprocess, and sends the rendered buffer using dmabuf with the parent process. it does so by using gbm on the subprocess, pretty stand stuff, and the buffer is imported using e.g. egl.
<feaneron>
standard* stuff
kts has quit [Ping timeout: 480 seconds]
<feaneron>
gtk4 is able to render dmabufs both on vulkan and opengl. on opengl, it uses the egl dmabuf import routines. on vulkan it does so using VK_STRUCTURE_TYPE_EXTERNAL_MEMORY_IMAGE_CREATE_INFO & family
<feaneron>
if available, webkit uses the gtk4 api to import dmabufs
<mattst88>
Company: ^
<feaneron>
Company is aware of that :)
<mattst88>
ah, great
<feaneron>
recently gtk4 switched to vulkan by default, and that has caused a problem in webkit: the imported dmabufs are entirely black!
ungeskriptet is now known as Guest2164
ungeskriptet has joined #dri-devel
<emersion>
feaneron: Vulkan doesn't do implicit sync, maybe that's the issue?
<feaneron>
i've debugged webkit and it picks the exact same format, modifiers, number of planes, etc, regardless of gtk4 using vulkan or opengl
<feaneron>
on opengl, the dmabuf importing works; on vulkan, it's empty
<feaneron>
emersion: hold on, there's a plot twins coming
<feaneron>
these failures are true for radv and intel
<feaneron>
but, it didn't always fail; assuming e.g. XR24, some modifiers would work, others wouldn't
<emersion>
sync issues are a bit random
<emersion>
if you add a fat big sleep(), does it work?
<feaneron>
after lots of testing, we noticed something: the format+modifiers pairs that failed had dcc modifiers on them (afaics intal calls that ccs)
<feaneron>
so much so that importing works if webkit is run with RADV_DEBUG=nodcc / INTEL_DEBUG=noccs
Guest2164 has quit [Ping timeout: 480 seconds]
<feaneron>
emersion: i've tried that! it doesn't seem to make a difference. i also tried fences, glFinish(), etc
<feaneron>
so somehow, this seems to be related to dcc / css (what generic terminology do people use for them?)
<jenatali>
Sounds like a missing resolve
<feaneron>
missing resolve?
<jenatali>
Resolving the compression data into the actual surface data
<emersion>
maybe the planes with index>0 aren't imported properly?
jkrzyszt has quit [Ping timeout: 480 seconds]
<feaneron>
sorry, that's not something i'm familiar with. where can i read more about it?
<emersion>
wlroots would also be a good source of inspiration for sync stuff and VK_EXT_image_drm_format_modifier
<dj-death>
there is some discussion right now with gamescope devs
coldfeet has quit [Quit: Lost terminal]
<emersion>
where is that?
<mattst88>
feaneron: regarding "resolves", dcc/ccs works by having a secondary surface that holds information like "this whole block in the real surface is the clear color"
<dj-death>
using UNDEFINED as oldLayout with modifiers using compression is breaking for use
<zamundaaa[m]>
emersion: I've wondered before... why do you need or want image layout transitions with VkImages that just refer to a dmabuf with a modifier?
<mattst88>
feaneron: which makes things faster by avoiding reading or writing the real surface
<mattst88>
feaneron: a "resolve" means to actually write out the data in the secondary surface to the primary surface, so that the primary surface can be used directly without the secondary surface
<dj-death>
it looks like various drivers/apps are relying on unspecified behavior
<zamundaaa[m]>
Like, I see why it could make sense when you render to a dmabuf, but when reading from it I'd think you wouldn't want to touch anything about it
<dj-death>
which could generate hangs on Intel HW
<feaneron>
mattst88: i see, i did notice that all faulty formats were multiplanar, this explain it
<emersion>
ouch, long discussion is long
<feaneron>
Company: ^^^ if this interests you
<mareko>
zmike: do you mean lowering sampler derefs? we haven't done that yet, but if we do, it would probably be better to transition radeonsi and radv at the same time
<zmike>
mareko: I mean currently I'm using integer sampler indexing, but using derefs would be more optimal and if there aren't plans to delete that path then I might get to it soon
* mattst88
remembers hearing people talk about "HiZ resolves" years ago at Intel and having zero clue what they meant
<zmike>
it's what radeonsi uses currently
<dj-death>
mattst88: it's the compressed depth buffer resolve
<mattst88>
dj-death: yeah, I understand what it means now. just not in 2013 :)
<dj-death>
ah sorry :)
<mattst88>
still at least 1000 things about graphics drivers I still feel this way about today though :P
<Company>
dj-death, emersion: so what VkImageLayout should I assume for a freshly imported dmabuf?
<dj-death>
Company: that's subject to debate atm
<Company>
I think this just runs the generic codepath in GTK which uses UNDEFINED
<dj-death>
Company: you kind of need to know in what was used last to generate the data
<Company>
oof
<dj-death>
but literally anything but UNDEFINED for use with modifiers
<dj-death>
because that will whack the data on some HW
<dj-death>
because not initializing compression data can lead to hangs on some generations
<dj-death>
so we have no choice but avoid it
<jenatali>
FWIW D3D generally expects our "COMMON" layout to be used for any cross-API stuff, which I think would map to GENERAL for Vk
<dj-death>
yeah GENERAL would be a good idea
<dj-death>
Company: also be careful to image creation parameters
<dj-death>
Company: they need to match between importer/exporter
<dj-death>
including usage flags
<Company>
dj-death: the exporter is GL
<Company>
so...
<dj-death>
ah okay, with modifiers that should be fine-ish
<Company>
feaneron: gsvulkanimage.c:828 - try setting that to VK_IMAGE_LAYOUT_GENERAL and see if that helps
<zamundaaa[m]>
This unspecified mess sounds a lot like implicit modifiers all over again
<Company>
but yeah, I never considered anything about this
<Company>
zamundaaa[m]: to me that sounds like the whole dmabuf import/export thing wasn't thought entirely through - because it was only spec'd out as far as necessary, but not as far as people were inevitably gonna drive it
<feaneron>
okay, my commit message will probably suck but i'll do it anyway :P
<Company>
feaneron: also, get mcatanzaro to test on intel
<feaneron>
mcatanzaro doesn't use intel, i'll try and get someone else
<Company>
feaneron: commit message is something like "UNDEFINED means that the data can be discarded and we don't want to discard it. Because the spec is unclear (see $link for a discussion), err on the side of caution and use GENERAL"
<Company>
"Fixes import failures with webkit, see $webkit-bug-if-vailable"
<feaneron>
okay i was writing something along these lines. glad my understanding is not too wildly off :)
<Company>
feaneron: so, on our previous 50/50 discussion about it being a GTK issue or Mesa issue, what do we decide now? 50/50 GTK and Mesa? :D
<feaneron>
i'd put it on the infinitesimally small middle point between both, schrodinger style
<emersion>
i'd blame Khronos :P
<emersion>
thanks for the links
<jenatali>
Yeah, I'd blame Khronos too
<feaneron>
thanks everyone for the directions
<jenatali>
Layout should be part of API or spec for import/export
<Company>
the khorons dmabuf stuff is almost entirely done by people in here, or?
<Company>
or are Google and/or Nvidia involved in there, too?
<colinmarc>
so the issue is transitioning the dmabuf to undefined when releasing it? just trying to figure out if I have this bug. it looks like I'm transitioning to GENERAL after reading
<Company>
this was about import
imre is now known as Guest2171
imre has joined #dri-devel
<Company>
GTK was setting UNDEFINED for dmabufs on import
<colinmarc>
for the dst layout?
<Company>
src layout
<colinmarc>
sorry if I'm being thick, why does the src layout matter? (I'm doing that too)
<dj-death>
there is no way to ignore the layout in a queue transfer
<emersion>
JoshuaAshton is also saying that the layout should be ignored by the driver
Guest2171 has quit [Ping timeout: 480 seconds]
<dj-death>
people have been relying on "yeah just don't do anything... juuuust for modifiers"
<dj-death>
that's not really in the spec
<dj-death>
there is no way to deal with an import with actual undefined content
<dj-death>
we just need to add a way to do that
<Company>
colinmarc: yeah, that line should probably say GENERAL because UNDEFINED is taken as "can be ignored" and not as "unknown"
<dj-death>
and tell everybody...
<colinmarc>
huh. I took undefined to mean "whatever it currently is".
<Company>
yeah, same here
<colinmarc>
I think there's even a validation layer check that it's undefined
<dj-death>
yeah on first use
<Company>
so, if I want to export the vkImage, what do I transition it to? GENERAL for the layout, but what access and pipeline stage?
<colinmarc>
should be NONE for dst on both, right? (also asking because I want to make sure I'm doing it right)
<Company>
I was wondering if it needs to be BOTTOM_OF_PIPE or TOP_OF_PIPE
<mareko>
zmike: there are potentially plans to remove all derefs paths
<Company>
and access I don't have the slightest idea
<dj-death>
Company: stage/access for source or destination?
<mareko>
zmike: how are derefs more optimal? shouldn't they be the same but clunkier?
<Company>
dj-death: for destination right before calling GetMemoryFdKHR() and handing that fd off to external code
<dj-death>
Company: for destination stage=VK_PIPELINE_STAGE_ALL_COMMANDS_BIT access=VK_ACCESS_MEMORY_READ_BIT should cover you
<dj-death>
unless you also want the thing to be CPU readable, also throw in VK_ACCESS_HOST_READ_BIT
<Company>
which might end up being libva or eglImportTex or mmap() or whatever
<dj-death>
and VK_PIPELINE_STAGE_HOST_BIT then
<Company>
I don't know what the user of the dmabuf is gonna do with it
<colinmarc>
is undefined only a problem for dmabuf transfers? or should I not be transitioning from undefined for like color attachments and stuff either?
<dj-death>
colinmarc: it's only a problem for queue transfers
<dj-death>
colinmarc: I mean...
<dj-death>
colinmarc: it'll be a problem too if you have some data on a non imported buffer and you essentially discard the content with UNDEFINED
<colinmarc>
I've been using it for cases where I don't know the layout (or I just want the code to be a bit more general)
<colinmarc>
ie as "unknown"
<Company>
UNDEFINED means DONT_CARE
<colinmarc>
right, that's how I understood it
<Company>
about the data
<Company>
not about the layout
jsa has quit [Ping timeout: 480 seconds]
<colinmarc>
I guess I don't get how transitioning from UNDEFINED would discard anything
<colinmarc>
but if that's the case I need to change a few things :)
<dj-death>
colinmarc: in most case it doesn´t
<Company>
the driver is allowed to "optimize" things
<dj-death>
colinmarc: on Intel there might be a hidden compressed buffer associated with an image
<dj-death>
colinmarc: that's what gets reset on UNDEFINED
<Company>
ultimately it means you make the driver take the same codepaths as it would for a new buffer
<colinmarc>
ahhh that makes sense
<colinmarc>
like you're signaling initialization
<Company>
yeah
<Company>
at least that's how I interpret it
Duke`` has quit [Ping timeout: 480 seconds]
<colinmarc>
man I hope this fixes that weird nv bug I've been having
<DemiMarie>
dj-death: what happens if the modifiers do not match? Is it a security problem or will it just result in junk being rendered?
<DemiMarie>
I’m asking because the child process is sandboxed.
fab has quit [Quit: fab]
<dj-death>
DemiMarie: yeah undefined
pcercuei has quit [Quit: dodo]
<dj-death>
DemiMarie: garbage if you're lucky
<dj-death>
DemiMarie: more likely failure to import or something because of potential size differences
<dj-death>
DemiMarie: and then if you have matching sizes but compressed/uncompressed mismatch, possibly hangs
<zmike>
mareko: well right now I have some really awful code to turn non-derefs back into derefs anyway, and being able to delete that and just have derefs the whole way through would be more optimal in every way
sima is now known as Guest2175
sima has joined #dri-devel
<zmike>
eric_engestrom: nice work!
<zmike>
🚢 🚢 🚢
sima has quit [Quit: Leaving]
Guest2175 has quit []
sima has joined #dri-devel
<DemiMarie>
dj-death: can it cause memory corruption (on CPU or GPU)? The concern here is a child process passing a malicious DMA-BUF to compromise the parent.
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<eric_engestrom>
zmike: thanks! 🤗
guludo has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
guludo has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<jenatali>
zmike: I've been meaning to add a pipe cap to stop the GL frontend from lowering shared to explicit I/O and keep it in derefs as well. Not sure if SPIR-V wants derefs for that but I think it does?
<jenatali>
Right now we're un-lowering those as well
<zmike>
uhhhhh
<zmike>
yeah...it does...but also it kinda doesn't matter since I think I'm just jamming in a dword array for it
<zmike>
so it's less annoying there by far
Haaninjo has quit [Quit: Ex-Chat]
<jenatali>
Oh I guess it's GL so no 16-bit shared
<jenatali>
Or 64-bit
<zmike>
there is, but I just alias it
<zmike>
or maybe that's with CL, I don't remember
<jenatali>
Yeah CL can alias, I don't think GL can
<jenatali>
Forgot that SPIR-V added aliasing. DXIL doesn't allow that :(
<zmike>
I meant the 16/64 bit types
glennk has quit [Ping timeout: 480 seconds]
<jenatali>
I see
feaneron has quit [Quit: feaneron]
guludo has quit [Quit: WeeChat 4.2.2]
tarceri has joined #dri-devel
simon-perretta-img has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
simon-perretta-img has joined #dri-devel
simon-perretta-img has quit [Remote host closed the connection]