<Company>
MrCooper: but if 2 processes use the same image and one of them does a layout transition, won't that break?
<karolherbst>
alyssa: though to be fair, C++ compiles fast as well if you don't include the STL
<MrCooper>
Company: shouldn't with Wayland (or DRI3/Present), since there's a clear ownership transfer
<karolherbst>
but yeah.. nice :)
<karolherbst>
ehh wait
<karolherbst>
the first comment to the others, and the second one is for you
<MrCooper>
Company: hmm, we were talking about the client reading from the image when it doesn't own it though
<Company>
MrCooper: yeah, I was about to point at that
<MrCooper>
do compositors really need layout transitions though? Honestly not sure
<Company>
MrCooper: which is what zmike meant with "you need to acquire it first"
<Company>
in Vulkan terms, everything needs a layout transition
<Company>
if that needs layout transitions in the real world: no idea
<MrCooper>
my expectation would be that Vulkan WSI transitions to presentable layout before handing off to the presentation engine
<pq>
C compiles so fast, because the code author has had to do the expensive compilation in their head first.
hansg has joined #dri-devel
<emersion>
that's not really true
<alyssa>
pq: the C version is shorter & clearer than the C++
<Company>
pq: considering how many abstractions C++ has, I don't believe the load in C is much less - what compilers do though is verify correctness, and C++ or Rust do that better
<alyssa>
now, this was bad C++
<alyssa>
but I've rarely seen good C++.
<Company>
is that so different with C?
<daniels>
MrCooper: we don't use layout transitions in Mesa but the IHVs were specifically asking for it - mostly NV iirc
<alyssa>
Company: C++ provides more degrees of freedom to do bad ;)
<Company>
daniels: what is a layout transition, in hardware terms? Is it just copying around memory between different caches?
<Company>
daniels: I'm mostly asking because I'm wondering because I want to identify it in bug reports - "oh this looks like use-after-layout-transition" or so
<daniels>
Company: one example from Intel is that they can, behind the scenes, allocate extra storage to allow them to use 'compression' within the client, then when the image gets handed over to the server, fully resolve the image so the server could read it as if uncompressed
<daniels>
or perhaps if you want to render to one tiling layout, but scan out from a different kind of tiling layout, blit between the two
<Company>
so you end up with something that looks either completely garbled, or those images where the stride looks off that look skewed
<pq>
wouldn't layout transition happen in-place, though? like the compression example, except an actual layout transition which makes access with old layout produce garbage as well, kind-of destroying the contents (temporarily) from at least someone's perspective?
<pq>
until transitioning back to the original layout
paulk has joined #dri-devel
frieder has quit [Remote host closed the connection]
kzd has joined #dri-devel
<Company>
I now wonder if I've seen intel transition linear layouts to tiled ones, because the data only needs to be linear when the memory is readable
<Company>
or if that was a case where I screwed up LINEAR and OPTIMAL tiling in vkCreateImage()
<Company>
can the driver even do anything to a LINEAR layout? because the vkMemory of that can be mapped at all times
<Company>
but then, all the swapchain images will always be OPTIMAL I think?
Duke`` has joined #dri-devel
<dj-death>
Company: Anv doesn't transition linear to tiled
<dj-death>
Company: we only decompress if need be
<Company>
then it was me messing up LINEAR and OPTIMAL
<jenatali>
Hey everyone, I'm back after ~3 months. Did I miss anything? :)
<alyssa>
jenatali: NIR 2.0 merged!
<jenatali>
\o/
<jenatali>
I'm going to have to re-learn how to write lowering I guess
<karolherbst>
jenatali: uhm.. we do CL C code instead of nir builder now
<jenatali>
Instead of? Or in addition to?
<karolherbst>
depends which future me you ask
<karolherbst>
or rather future alyssa
<karolherbst>
jenatali: but yeah... make sure I haven't regressed anything in the past, though I also didn't tinker too much with clc
<karolherbst>
_but_
<karolherbst>
if you are bored and want something to look into, we are thinking about using llvms spir-v target
<jenatali>
Lol I am decidedly not bored
<karolherbst>
:'(
<karolherbst>
but but
<jenatali>
Last I saw that shelled out to an external llvm-spirv tool, didn't it?
<karolherbst>
huh......
<karolherbst>
ohhh right
<karolherbst>
there was that as well....
<karolherbst>
let me see who pinged me on it..
<karolherbst>
I don't remember
<karolherbst>
but it's apparently using the native backend now
<jenatali>
Oh cool
<jenatali>
I'll be interested to hear what the difference is
<karolherbst>
it allows us to use O2 and O3
pekkari has joined #dri-devel
<karolherbst>
so mostly just smaller binaries
<karolherbst>
and I think future development shifts to that anyway
<alyssa>
jenatali: write code once in C, run both on the CPU in driver and on the GPU from a lowering pass, 0 bindings, native perf, nothing short of magic
<karolherbst>
(and also less packaging pain)
<jenatali>
Yeah that'll be nice
<jenatali>
Let me know how it goes, I'll be interested to switch CLOn12 to that too assuming it goes well
<karolherbst>
I mean.. it will be a flag to clc anyway
<karolherbst>
but yeah
<alyssa>
:D
<jenatali>
Yeah, it just means different packaging
<karolherbst>
once I test it you can ack the MR :P
<jenatali>
Since we statically link everything, it's one less dependency to pull
<karolherbst>
yeah
<alyssa>
(application: needing to preprocess a draw. do it on the CPU if direct draw, do it in a 1 shot kernel if indirect draw. only write the logic once.)
<karolherbst>
some distros build libclc as part of llvm and libclc requiring the translator annoys some
<dj-death>
people here remember what the frcp alu stands for?
<jenatali>
Float reciprocal?
<dj-death>
ah 1.0f / src0
<dj-death>
didn't know about the reciprocal name :)
aljazmc has quit [Remote host closed the connection]
hansg has quit [Quit: Leaving]
tobiasjakobi has quit [Remote host closed the connection]
sima has quit [Ping timeout: 480 seconds]
ficoPRO10 has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
sgruszka has quit [Ping timeout: 480 seconds]
jhli has quit [Remote host closed the connection]
jhli has joined #dri-devel
Namarrgon has quit [Ping timeout: 480 seconds]
aljazmc has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
Namarrgon has joined #dri-devel
tobiasjakobi has joined #dri-devel
mvlad has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
heat_ has quit []
heat has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
aljazmc has quit []
apinheiro has quit [Quit: Leaving]
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
aradhya7 has quit [Quit: Connection closed for inactivity]
Danct12 has joined #dri-devel
ficoPRO10 has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
<Company>
is there a way to get dmabuf data (read: multiplane YUV) into a GL texture without having a dmabuf?
tobiasjakobi has quit []
<Company>
or alternatively, is there a way to get data to memcpy into?
<dj-death>
just copy it over to a buffer
<Company>
I think I can make that happen in Vulkan - just allocate the right VkFormat and set a YcbcrConversion and then just map the vkMemory and copy into it
<Company>
what kind of buffer?
<dj-death>
do you want the converted data or the data prior to sampling?
Aura has quit [Ping timeout: 480 seconds]
<Company>
I have the data
<Company>
I want to hand it to GL
<Company>
but I have it in regular memory, not as a dmabuf
<Company>
basically, I decoded a frame with ffmpeg and now I want to make GL do the colorspace conversion
<dj-death>
yeah making a buffer and memcpy into it would work
<dj-death>
then get the dmabuf and hand it over to GL
<Company>
"making a buffer"?
<dj-death>
a VkBuffer
<Company>
ah
<Company>
but that requires VUlkan
<dj-death>
yeah
<Company>
I want a GL-only solution
<DemiMarie>
Company: No expert here, but I thought most GPUs could not handle YUV. In any case, GL has stagnated so I would not be surprised if there is no GL solution.
<dj-death>
Company: yeah not sure
<dj-death>
Company: weston probably solved that problem at some point ;)
<Company>
somebody asked if we can handle regular buffers on top of dmabufs
<Company>
and that got me wondering how easy that is
psykose has quit [Ping timeout: 480 seconds]
<dj-death>
Company: oh... gbm
<Company>
yeah, that works for Weston I guess
crabbedhaloablut has quit []
pcercuei has quit [Quit: dodo]
psykose has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]