<alyssa>
PIPE_CAP_DEST_SURFACE_SRGB_CONTROL seems like it's just begging to be deleted
<alyssa>
seems to exist only so virgl can do EXT_sRGB without EXT_framebuffer_sRGB on particular host drivers
<alyssa>
which really seems like a niche within a niche
boqun_home has joined #dri-devel
<cphealy>
I've always been curious how dithering works with the GL API. Seems pretty unclear. Would be nice to have available for cases where one wants to use an RGB565 render buffer (to reduce RAM usage) but want to minimize banding.
boqun_home has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
boqun_home has joined #dri-devel
bluetail96 has joined #dri-devel
bluetail9 has quit [Ping timeout: 480 seconds]
<robclark>
alyssa: type more native-context drivers and then we don't have to care about virgl (except blob drivers, grmbl)
Zopolis4_ has joined #dri-devel
<robclark>
but I think currently PIPE_CAP_DEST_SURFACE_SRGB_CONTROL is probably not a thing that can be removed
<alyssa>
robclark: probably not
<alyssa>
but it is begging to be deleted nonetheless ;)
<zmike>
alyssa: the point of PIPE_CAP_DITHERING is to improve cache hits for drivers that won't dither
<alyssa>
zmike: yeah, I got that
<alyssa>
is it actually load bearing and not just another cap though
<zmike>
shrug
<alyssa>
zmike told me at xdc to delete caps like that one
<zmike>
no I said delete the ones I'm not using
boqun_home has quit [Ping timeout: 480 seconds]
<alyssa>
oh
<alyssa>
robclark: sorry PIPE_CAP_DEST_SURFACE_SRGB_CONTROL has gotta go, zmike's not using it
<zmike>
ab
<robclark>
kinda don't think it works that way ;-)
<zmike>
oh do I have to start using it?
<zmike>
ok
<alyssa>
zmike 2024
boqun_home has joined #dri-devel
alyssa has quit [Quit: leaving]
alarumbe has quit [Ping timeout: 480 seconds]
alarumbe has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
<i509vcb>
I assume there is a way to generate the docs locally for mesa?
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
<Lynne>
99% sure the validation layer is faulty when using descriptor buffers
<Lynne>
such a waste of time
<Lynne>
on less crashy GPUs it reports descriptor indices are null when it's impossible for them to be null, I know, I've checked
<Lynne>
on more crashy drivers it just, you know, crashes the GPU
<zmike>
descriptor buffer is great as long as you don't have any bugs
<jenatali>
That's just Vulkan in general isn't it?
<zmike>
oh right
boqun_home has joined #dri-devel
<Lynne>
descriptor buffers really are great
<Lynne>
it was such a mess before with regular descriptors if you wanted to fully parallelize your pipelines
<Lynne>
you had to allocate multiple descriptor sets from the pool, one for each command buffer, which sounds simple, unless you had multiple descriptor sets used in shaders
<jenatali>
Lynne: Doesn't descriptor_indexing also just solve that?
<Lynne>
I was not aware of it at the time, and I would've hated to go back and mess with the code again to fit that in
<jenatali>
Fair
minecrell has quit [Read error: Connection timed out]
minecrell has joined #dri-devel
<Lynne>
besides, it's ugly and an afterthought, descriptor buffers should've been the standard, nothing's more reliable than raw addresses
<Lynne>
sure, it wouldn't have been able to support bindless hardware, but I think some people behind the spec lack hardware standards when it comes to writing standards
<Lynne>
*fixed binding hardware
<jenatali>
The descriptor set model looks a lot like what D3D12 ended up with, where our binding tiers kind of match, tier 1 is like Vulkan's stock model, tier 3 is like descriptor indexing enabled
<jenatali>
Some different caveats though
boqun_home has quit [Ping timeout: 480 seconds]
Zopolis4_ has quit []
mohamexiety has quit []
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
flto has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
Zopolis4_ has joined #dri-devel
boqun_home has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
<Lynne>
d3d12 has a much better encoding API than vulkan, I'm jealous
rmckeever has quit [Quit: Leaving]
boqun_home has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
krushia has quit [Quit: Konversation terminated!]
boqun_home has joined #dri-devel
heat_ has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
lemonzest has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
Guest9315 is now known as samuelig
Danct12 is now known as Guest9468
Danct12 has joined #dri-devel
Guest9468 has quit [Ping timeout: 480 seconds]
boqun_home has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
elongbug_ has quit [Read error: Connection reset by peer]
boqun_home has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
danvet has joined #dri-devel
pcercuei has joined #dri-devel
alanc has quit [Remote host closed the connection]
jaganteki has joined #dri-devel
alanc has joined #dri-devel
fab has quit [Quit: fab]
Company has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
boqun_home has joined #dri-devel
fab has joined #dri-devel
tzimmermann has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
rszwicht has joined #dri-devel
boqun_home has joined #dri-devel
ahajda has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
fab has joined #dri-devel
mvchtz has quit [Quit: WeeChat 3.5]
mvchtz has joined #dri-devel
boqun_home has joined #dri-devel
mvlad has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
ceyusa has joined #dri-devel
lynxeye has joined #dri-devel
godvino has joined #dri-devel
ice9 has joined #dri-devel
boqun_home has joined #dri-devel
junaid has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
boqun_home has joined #dri-devel
smilessh has quit [Ping timeout: 480 seconds]
boqun_home has quit [Ping timeout: 480 seconds]
junaid has quit [Remote host closed the connection]
boqun_home has joined #dri-devel
Haaninjo has joined #dri-devel
mvchtz has quit [Quit: WeeChat 3.5]
boqun_home has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
bmodem has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
mvchtz has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
shashanks_ has quit [Remote host closed the connection]
boqun_home has joined #dri-devel
devilhorns has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
boqun_home has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
heat_ has joined #dri-devel
boqun_home has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
kts has quit [Quit: Konversation terminated!]
godvino has quit [Read error: Connection reset by peer]
boqun_home has quit [Ping timeout: 480 seconds]
ceyusa has quit []
vjaquez has joined #dri-devel
sarahwalker has joined #dri-devel
boqun_home has joined #dri-devel
jfoshea has joined #dri-devel
vjaquez has quit []
boqun_home has quit [Ping timeout: 480 seconds]
vjaquez has joined #dri-devel
vjaquez has quit []
vjaquez has joined #dri-devel
boqun_home has joined #dri-devel
fab has quit [Read error: Connection reset by peer]
vjaquez has quit []
vjaquez has joined #dri-devel
godvino has joined #dri-devel
kts has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
godvino1 has joined #dri-devel
godvino has quit [Ping timeout: 480 seconds]
pochu has joined #dri-devel
<columbarius>
Do gpus have a preferred internal buffer format? The usecase is a filter chain, where each filter would apply sth. to the buffer and pass it on to the next.
boqun_home has joined #dri-devel
<emersion>
i don't think there's a generic concept like this, it depends on the use-case
junaid has joined #dri-devel
kts has quit [Quit: Leaving]
<columbarius>
hmm. The goal is to find a usable dsp format for videostreams in pipewire, such that the stream could be converted once at the start and the end of some filterchain, such that filters prefferably write their transformations with this format in mind.
Zopolis4_ has quit []
<columbarius>
and it should also be efficient on the used gpu, but I guess the answer is: it's complicated and not generalizable ^^`
boqun_home has quit [Ping timeout: 480 seconds]
godvino has joined #dri-devel
junaid has quit [Remote host closed the connection]
smilessh has joined #dri-devel
<emersion>
do filters really need to be format-specific?
Danct12 has quit [Read error: Connection reset by peer]
<emersion>
the format that everybody uses everywhere is ARGB8888
Danct12 has joined #dri-devel
<emersion>
but for HDR you want 10-bit or fp16
godvino1 has quit [Ping timeout: 480 seconds]
<columbarius>
I don't know. The question is, if it is benefficial to propose a common/prefered/cannonical format, which might also work with hdr and is efficiently supported by compute units on the hardware, or if the whole idea is pointless and each filter will formatconvert anyways
boqun_home has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
heat_ has joined #dri-devel
<columbarius>
the current guess would be float16/32 RGBA
pcercuei has quit [Quit: leaving]
<emersion>
float32 is overkill
<emersion>
float16 should be good enough, but may not be supported by all hw
boqun_home has quit [Ping timeout: 480 seconds]
<emersion>
though you target vulkan so maybe it is
<columbarius>
thanks
<emersion>
fp16 might use more power/resources than ARGB888
<emersion>
8
<hays>
is there a 1:1 substitution for GL/gl.h and GL/glx.h using GLES/EGL?
<hays>
im struggling to understand how these headers interrelate
<columbarius>
so gpus are actually optimized for argb8888?
jfoshea has quit [Remote host closed the connection]
boqun_home has joined #dri-devel
<zamundaaa[m]>
columbarius: fp16 simply has twice the amount of data per channel vs argb8888
<HdkR>
How efficient output is usually just comes down to how many bits are being output these days. Unless you hit some really ugly edge case in some hardware :P
godvino has quit [Read error: Connection reset by peer]
Jeremy_Rand_Talos has joined #dri-devel
Danct12 has quit [Quit: WeeChat 3.8]
rasterman has quit [Quit: Gettin' stinky!]
<columbarius>
and there is no intermediate format I guess, so the gpu works on argb8888 or fp16 directly. Precission errors are just accepted/not significant?
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
Jeremy_Rand_Talos has joined #dri-devel
<emersion>
if you want precision, you need to use more power/resources and pick fp16
<emersion>
it's a tradeoff
flto has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
<columbarius>
ok, so the format in use is definded by the shader without the gpu or graphics api converting it to any intermediate thing(don't want to write representation, since this is already taken).
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
<HdkR>
columbarius: The shader output is still a vec4 per colour attachment, but the ROPs give you "free" reinterpretation of that data.
<columbarius>
ROP?
<HdkR>
hardware blend units on the GPU
<HdkR>
(Or software on some GPUs, lets not fall in to the weeds)
<columbarius>
thx
<HdkR>
I would still love an ivec4 for integer colour outputs but that won't ever be a thing
boqun_home has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
boqun_home has quit [Ping timeout: 480 seconds]
Zopolis4_ has joined #dri-devel
boqun_home has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
boqun_home has joined #dri-devel
bbrezill1 has quit []
bbrezillon has joined #dri-devel
fab has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
bmodem has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
boqun_home has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
robmur01 has quit [Remote host closed the connection]
robmur01 has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: WeeChat 3.8]
JohnnyonFlame has joined #dri-devel
camus1 has quit []
boqun_home has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
godvino has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
boqun_home has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
bmodem has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
pochu has quit [Quit: leaving]
bmodem has joined #dri-devel
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
boqun_home has joined #dri-devel
Zopolis4_ has quit []
kzd has joined #dri-devel
efpwcdo^ has quit [Remote host closed the connection]
boqun_home has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
boqun_home has joined #dri-devel
camus has joined #dri-devel
ice9 has quit [Ping timeout: 480 seconds]
devilhorns has quit []
boqun_home has quit [Ping timeout: 480 seconds]
godvino has quit [Read error: Connection reset by peer]
boqun_home has joined #dri-devel
godvino has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
godvino has quit [Remote host closed the connection]
boqun_home has joined #dri-devel
godvino has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
godvino has quit []
fab has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
ice9 has joined #dri-devel
boqun_home has joined #dri-devel
fab_ has joined #dri-devel
fab_ is now known as Guest9504
fab has quit [Ping timeout: 480 seconds]
boqun_home has quit [Ping timeout: 480 seconds]
ice9 has quit [Read error: Connection reset by peer]
fxkamd has quit []
ice9 has joined #dri-devel
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
<gfxstrand>
Ugh... create_passthrough_gs has been through a lot....
<gfxstrand>
It really should be zink_create_passthrough_gs at this point.
boqun_home has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<zmike>
I had the same thought when I saw the ci runtimes for the changes
<zmike>
if you want to move you have my ab
<gfxstrand>
I'm more annoyed that it used to be useful for NVK and now it's not. :P
<zmike>
you had ample time to review and opted not to :P
boqun_home has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
boqun_home has joined #dri-devel
* gfxstrand
madly types a GS builder for vulkan/meta
<cmarcelo>
Venemo: seems fine, but you likely want to say "dispatch is known to be linear at compile time" or something like, right?
fab has quit []
fab has joined #dri-devel
<Venemo>
cmarcelo: I can extend the comment to include that
Haaninjo has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
sivileri has joined #dri-devel
sivileri has quit []
<Lynne>
shader_object looks pretty nice
boqun_home has joined #dri-devel
<Lynne>
I like how there's a layer to convert objects to pipelines too
<jenatali>
Will be interesting to see which drivers want to support it
<Venemo>
who doesn't wanna support it?
krushia has joined #dri-devel
<jenatali>
I don't have any data one way or another, it just seems like it wouldn't be a win in all cases
<jenatali>
Dozen won't support it until/unless D3D does something similar FWIW
<Venemo>
well, it basically trades off some GPU bound performance (of having all info in a PSO) for some CPU bound performance (thanks to not needing to recompile the same shader between different pipelines)
<jenatali>
I guess. Seems like there could've been other solutions for not recompiling, like GPL for example
<Lynne>
they say in the blog post that there should be no measurable difference between objects and pipelines on any platform, so I'm on board
<gfxstrand>
jenatali: GPL is horrible
<Lynne>
"Dispatch calls using compute shader objects must not be measurably slower than dispatch calls using compute pipelines"
<Venemo>
GPL still keeps the pre-rasterization stages together so you still had to recompile those + it still had the state in the pipeline object, which shader objects don't need anymore
<gfxstrand>
Lynne: Well, that's "no measurable difference" is probably a stretch.
<gfxstrand>
The more linking we're able to do the faster you'll go
<jenatali>
Yeah, a compute pipeline is a compute shader so it makes sense there that there's not going to be a difference
<karolherbst>
well, unless I missed anything, at least on Nvidia hardware it should be all the same in the end, just that pipelines objects might use more memory?
<gfxstrand>
karolherbst: Yes, this is ideal for NVIDIA
<gfxstrand>
It's serious work for just about everyone else.
<karolherbst>
are we even deduplicating shaders in nvk? :D
<gfxstrand>
Most of the engineering work for Intel on the compiler side is done. I had to do the horrible MSAA madness for GPL.
<gfxstrand>
karolherbst: No, we don't pipeline cache at all.
<gfxstrand>
karolherbst: My plan is to rework all that stuff once NAK is ready
<karolherbst>
might be something nvk could do, so that reusing the same shader in multiple pipelines is also for free basically
<karolherbst>
ahh
<karolherbst>
fair
<Lynne>
NAK?
<gfxstrand>
But, yeah, we don't even pipeline cache right now.
<gfxstrand>
Lynne: New nouveau compiler
<karolherbst>
:)
<jenatali>
FWIW D3D does the shader de-duplication inside pipelines for drivers already. We just still require a pipeline to link them
<gfxstrand>
Nvidia Awesome Kompiler
<qyliss>
GPL and NAK apparently referring to software makes this a very confusing conversation to follow for casual idlers such as myself :D
<karolherbst>
gfxstrand: though I meant if you have the same fp shader, but everything else is different across pipelines, would the pipeline cache stuff figure that out? Or is that too nvidia specific?
<gfxstrand>
hehe
<zmike>
xdc memes are timeless
<Venemo>
NAK = Not Actually a Kompiler
<gfxstrand>
karolherbst: Depends on how you set up your keys
<karolherbst>
okay
<gfxstrand>
karolherbst: If you make the keys orthogonal, you get deduplication.
<karolherbst>
nice
<Venemo>
I hope you guys manage to find a better name for it before it gets merged
<Lynne>
what does nvk currently use then?
<karolherbst>
but you also only upload the shader stage once, right? or would that be per pipeline?
<gfxstrand>
The big thing with shader object is that there is an 1:1 (almost) mapping from SPIR-V to client-accessible binaries.
<gfxstrand>
karolherbst: Once.
<gfxstrand>
karolherbst: vk_pipeline_cache
<karolherbst>
ahh
<karolherbst>
nvm then, then it's all the same for us
<gfxstrand>
Yeah, the long-term plan for NVK is that it will be 100% ESO internally.
<karolherbst>
kinda lucky we have this super dynamic inter stage configuration thing
<gfxstrand>
Maybe do some cross-stage linking stuff if it's useful later.
<Venemo>
easy to do this now
<gfxstrand>
karolherbst: Yeah, NVIDIA really is the only hardware where all this is easy. Even there, though, MSAA is aparently a bit of a pain.
<karolherbst>
MSAA is always pain, so that's expected
<gfxstrand>
I don't think it's as much of a pain as the NVIDIA engineers have been claiming it is on the Khronos calls but it's not zero like everything else.
boqun_home has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah.. dunno
<jenatali>
Seems odd to me that an extension would be designed that's difficult for other hardware to handle, but 🤷
<gfxstrand>
jenatali: It's going to be interesting to see how it plays out. We've done the brain work to be pretty sure it's implementable on AMD, Intel, and NVIDIA.
<karolherbst>
some applications are really doing a lot of ad-hoc linking
<gfxstrand>
It's easy on NVIDIA
<karolherbst>
so pipelines were never a good fit
<Venemo>
it's difficult for drivers because they were designed to work with pipelines not shaders. it's just a matter of refactoring
<gfxstrand>
The biggest pain point on Intel will be the fact that patch control points is now dynamic.
jfoshea has joined #dri-devel
<gfxstrand>
Oh, and mesh inputs to FS are different. I don't think anyone has a plan for that yet.
<karolherbst>
ah yeah...
<jenatali>
Yeah, I'll be following along with great interest
<Venemo>
gfxstrand: how are mesh->fs different on intel?
<gfxstrand>
Venemo: I don't remember the details, I just know the FS input interface is different.
<Venemo>
ah, that must be painful
<Venemo>
it is also different on AMD but the difference can be accounted for in register programming
<gfxstrand>
Venemo: Worst case, we compile them twice. How bad could that be? It's not like we compile every FS 3x already or anything horrible like that. ;-)
<gfxstrand>
Between ESO and descriptor buffer, we've now managed to make Vulkan hell for everybody. :)
<Venemo>
oh wow
<zmike>
ideally nobody will notice the common contributor to all of these great specs
<Venemo>
:D
boqun_home has joined #dri-devel
<gfxstrand>
hehe
<Venemo>
even it's hell for driver devs though, these things addressed real feedback from the audience, so I think that's a good thing
Cyrinux9 has quit []
Cyrinux9 has joined #dri-devel
<karolherbst>
I wonder if applications like dolphin-emu will also make use of this
boqun_home has quit [Ping timeout: 480 seconds]
rszwicht has quit []
boqun_home has joined #dri-devel
boqun_home has quit [Ping timeout: 480 seconds]
agd5f has quit [Read error: Connection reset by peer]
agd5f has joined #dri-devel
boqun_home has joined #dri-devel
CME_ has quit [Read error: Connection reset by peer]
CME has joined #dri-devel
kts has quit [Quit: Leaving]
boqun_home has quit [Ping timeout: 480 seconds]
bluebugs has quit [Read error: Connection reset by peer]