ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Handy has joined #dri-devel
JohnnyonFlame has joined #dri-devel
Handy has quit []
<mareko> karolherbst: can you report it as an issue?
yann-kaelig has quit []
kts has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
rz_ has joined #dri-devel
rz has quit [Ping timeout: 480 seconds]
rz has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
rz_ has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
camus has joined #dri-devel
Company has quit [Quit: Leaving]
heat has quit [Ping timeout: 480 seconds]
laticlave has joined #dri-devel
Omax has quit [Ping timeout: 480 seconds]
laticlave is now known as oars
Omax has joined #dri-devel
kts has joined #dri-devel
crabbedhaloablut has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
Aura has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
bmodem has joined #dri-devel
Duke`` has joined #dri-devel
itoral has joined #dri-devel
sima has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
oars has quit [Ping timeout: 480 seconds]
kxkamil has quit []
kxkamil has joined #dri-devel
Daanct12 has joined #dri-devel
kts has joined #dri-devel
sgruszka has joined #dri-devel
sgruszka has left #dri-devel [#dri-devel]
glennk has joined #dri-devel
Haaninjo has joined #dri-devel
sgruszka has joined #dri-devel
jfalempe has joined #dri-devel
frankbinns has joined #dri-devel
pochu has quit [Quit: leaving]
frieder has joined #dri-devel
pcercuei has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
frankbinns has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
frieder has joined #dri-devel
rasterman has joined #dri-devel
<hakzsam> cwabbott: can you rebase https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25436 ? I can take a look at the radv changes again, thanks!
vliaskov has joined #dri-devel
flynnjiang has joined #dri-devel
mvlad has joined #dri-devel
hansg has joined #dri-devel
tursulin has joined #dri-devel
flynnjiang has quit [Read error: Connection reset by peer]
flynnjiang has joined #dri-devel
sarahwalker has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
kts_ has joined #dri-devel
flynnjiang has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
aravind has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
rz has quit [Remote host closed the connection]
frieder has joined #dri-devel
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #dri-devel
alyssa has quit [Quit: alyssa]
yyds has quit [Remote host closed the connection]
itoral has quit [Quit: Leaving]
Company has joined #dri-devel
alyssa has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
aradhya7 has joined #dri-devel
Danct12 has quit [Remote host closed the connection]
kts_ has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.1.1]
heat has joined #dri-devel
Peste_Bubonica has joined #dri-devel
yyds has joined #dri-devel
nekit[m] has left #dri-devel [#dri-devel]
Danct12 has joined #dri-devel
Danct12 has quit []
JohnnyonFlame has joined #dri-devel
kwizart_ has quit []
kwizart has joined #dri-devel
mripard has joined #dri-devel
i509vcb has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
frieder has quit [Ping timeout: 480 seconds]
mripard_ has joined #dri-devel
mripard has quit [Read error: Connection reset by peer]
frieder has joined #dri-devel
kzd has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Mangix has quit [Remote host closed the connection]
Mangix has joined #dri-devel
bmodem has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
yuq825 has left #dri-devel [#dri-devel]
cmichael has joined #dri-devel
hansg has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit []
aravind has joined #dri-devel
heat_ has joined #dri-devel
Danct12 has joined #dri-devel
heat has quit [Read error: No route to host]
<alyssa> airlied: did a C port of d3d tessellator
<alyssa> gcc compiles it 5x faster than the c++, lolz
kts has joined #dri-devel
mripard_ has quit []
mripard has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
JohnnyonFlame has joined #dri-devel
<Company> if there's one benefit to C over all the fancy modern languages (and C++), it's that it compiles insanely fast
<emersion> Go and Hare fast as well
<Company> a full GTK compile these days (with a hot disk cache) is 20s on my desktop, and somebody on an M2 did it in 5s
<Company> and we're somewhere between 500k-1M loc
<MrCooper> Company: layout transitions preserve image contents
<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
tobiasjakobi has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<karolherbst> :D
<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
<jenatali> What LLVM ver does that need?
<karolherbst> 17/18 or so I think
<karolherbst> ohh found it
<karolherbst> whatever faith said there
navin has joined #dri-devel
<jenatali> Great
pekkari has quit [Quit: Konversation terminated!]
<alyssa> have Faith
djbw has joined #dri-devel
tobiasjakobi has quit []
navin has quit [Killed (NickServ (Too many failed password attempts.))]
navin has joined #dri-devel
<karolherbst> alyssa: fyi, I'm planning to review your nir builder v2 MR :P
sarahwalker has quit [Remote host closed the connection]
<alyssa> karolherbst: thanks!
navin has quit []
rasterman has quit [Quit: Gettin' stinky!]
alanc has quit [Remote host closed the connection]
<alyssa> karolherbst: hopefully geom shaders land before i finish tessellation, ;P
<karolherbst> :D
alanc has joined #dri-devel
<karolherbst> I see, no preasure to get it reviewed :P
<alyssa> :P
<alyssa> the current MR is just like 2/n
bmodem has quit [Ping timeout: 480 seconds]
tobiasjakobi has joined #dri-devel
<alyssa> konstantin: thank youuuuu
tobiasjakobi has quit [Remote host closed the connection]
<alyssa> karolherbst: common code bits now reviewed. will hold off merge a bit to give you a chance but would be nice to merge this week
<HdkR> First the GS, then the TS, then the RT, all the things~
<airlied> alyssa: id be happy to move to C version, not like the one we have has ever really changed much
<karolherbst> alyssa: yeah, I plan to take a look on Wednesday the latest
<alyssa> airlied: ack. will cc you on the MR if I get around to writing it
<alyssa> karolherbst: :+1:
iive has joined #dri-devel
<jenatali> alyssa: looks like my top priority might actually be getting GLOn12 to 4.3 and then 4.5, hooray
<airlied> jenatali: what is missing for 4.3? buffer storage?
gouchi has joined #dri-devel
<airlied> or do you have to do compute shaders?
<alyssa> jenatali: >:)
<jenatali> airlied: it's just the texture view extension that's missing. Compute is done
<jenatali> The required format casting was only added to D3D in the last couple years
gouchi has quit [Quit: Quitte]
cmichael has quit [Quit: Leaving]
tobiasjakobi has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
aljazmc has joined #dri-devel
zf has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
zf has joined #dri-devel
<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]
simon-perretta-img has joined #dri-devel
<Kayden> cwabbott: thinking of using interval trees for a few more things, would be neat to see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22071 land
<Kayden> ah, for some reason gitlab didn't load the new comments, I see you're busily rebasing things
glennk has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<robclark> Company: if sw decoded data (linear yuv) just do the R8 + R8G8 trick that everyone's done forever.. no need to harm dmabuf's
<Company> robclark: but then I need to write a shader - with dmabufs I don't need to