<idr>
Oh the joys of having to "see through" fneg and fabs. :(
<alyssa>
idr: jekstrand told me you spent a lot of time on this for Intel, maybe we should just move the intel ffma pass back to core and add flags for the funny intel bits (2 constant cases maybe?)
<alyssa>
though maybe that was flrp, not ffma
bmodem1 has joined #dri-devel
bmodem has quit [Read error: Connection reset by peer]
bmodem1 has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
MrCooper_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
MrCooper has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
luben has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: oh wow... wondering why we don't catch that already
<alyssa>
shrug
<alyssa>
MR up
<alyssa>
testing wanted
<idr>
alyssa: I spent a lot of time on ffma and flrp... I won't say that I got a lot for that time, though.
<alyssa>
idr: woof :-(
<idr>
I have several branches where I was trying to improve the various ffma heuristics. Everything helped a bunch of shaders by a lot... and hurt a bunch of other shaders by a lot. :(
<alyssa>
"got a lot" in terms of shaderdb or actual app fps?
<idr>
Either.
<idr>
When shader-db was basically a wash, I didn't even bother running apps.
<idr>
With some of the other work that you and anholt have done, it might be worth revisiting some of that.
<idr>
And... it might be different on drivers that... eh... have better schedulers.
<alyssa>
I still want to review noltis
<alyssa>
just do not have the brainpower right now
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
mvlad has joined #dri-devel
Wallbraker[m] has quit [Remote host closed the connection]
Wallbraker[m] has joined #dri-devel
devilhorns has joined #dri-devel
Company has joined #dri-devel
Wallbraker[m] has quit [Remote host closed the connection]
idr has quit [Ping timeout: 480 seconds]
Wallbraker[m] has joined #dri-devel
anarsoul|2 has joined #dri-devel
anarsoul has quit [Remote host closed the connection]
itoral has quit []
<karolherbst>
why is hw...
bmodem1 has quit [Ping timeout: 480 seconds]
<CounterPillow>
Verilog was created by Prabhu Goel, Phil Moorby, Chi-Lai Huang, and Douglas Warmke between late 1983 and early 1984.[3]
<CounterPillow>
This has widely been regarded as "a mistake".
apinheiro has quit [Ping timeout: 480 seconds]
Leopold has joined #dri-devel
idr has joined #dri-devel
<alyssa>
anholt: +1
<alyssa>
CounterPillow: that trakcs
<alyssa>
tracks
arisu has joined #dri-devel
Andy[m]1 has joined #dri-devel
aura[m] has joined #dri-devel
bluepqnuin has joined #dri-devel
bylaws has joined #dri-devel
chema has joined #dri-devel
RAOF has joined #dri-devel
cleverca22[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
Eighth_Doctor has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dafna33[m] has joined #dri-devel
dcbaker has joined #dri-devel
DemiMarieObenour[m] has joined #dri-devel
Anson[m] has joined #dri-devel
DrNick1 has joined #dri-devel
doras has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
Ella[m] has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
GeorgesStavracasfeaneron[m] has joined #dri-devel
frytaped[m] has joined #dri-devel
gallo[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
Guest4044 has joined #dri-devel
halfline[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
hch12907 has joined #dri-devel
heftig has joined #dri-devel
zzoon[m] has joined #dri-devel
jasuarez has joined #dri-devel
Jean[m]1 has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
kunal_1072002[m] has joined #dri-devel
KunalAgarwal[m][m] has joined #dri-devel
kusma has joined #dri-devel
Labnan[m] has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
masush5[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
michael5050[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
nielsdg has joined #dri-devel
eyearesee has joined #dri-devel
Nirvin[m] has joined #dri-devel
nyorain[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
onox[m] has joined #dri-devel
pac85[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
r[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
robertfoss[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
sjfricke[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
underpantsgnome[m] has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
Soroush has joined #dri-devel
viciouss[m] has joined #dri-devel
MatrixTravelerbot[m]1 has joined #dri-devel
Weiss-Fder[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
pmoreau is now known as Guest4054
macromorgan has joined #dri-devel
jkrzyszt_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
<kchibisov>
What is the preferred extension for _sync_control with GLX? The EXT one or MESA?
<kchibisov>
s/sync/swap/
Leopold has quit []
heat has joined #dri-devel
bmodem has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
jlawryno has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
jlawryno has joined #dri-devel
jkrzyszt_ has quit [Remote host closed the connection]
fab has joined #dri-devel
jlawryno has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
kts has joined #dri-devel
<tonyk>
what's the name of IGT IRC channel?
Duke`` has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
flibitijibibo has joined #dri-devel
<karolherbst>
jenatali: do you rely on readonly and writeonly images to have a split driver_location index?
<karolherbst>
uhm.. actually forget about that, we need it split
<jenatali>
What do you mean by split?
<jenatali>
IIRC we make them both 0-indexed
<karolherbst>
yeah...
<karolherbst>
it has to be like that, I simply forgot why while cleaning up my texture code
<jenatali>
Yeah, readonly are textures and writeonly (or readwrite) are images
<karolherbst>
I was thinking about having one index for order/format intrinsics, but that obviously wouldn't work :)
JohnnyonFlame has joined #dri-devel
<karolherbst>
I have to say.. I really like to use texture vars here. Makes some code more obvious about what's going on
kts has quit [Quit: Leaving]
djbw has joined #dri-devel
<deathmist>
any way I could help with solving https://gitlab.freedesktop.org/mesa/mesa/-/issues/7555 (freedreno: X11/XWayland on Adreno 540 freezes updating screen entirely)? robclark or tarceri perhaps? I've locally reverted 34e868d882c (freedreno/ir3: tidy up duplication of common nir options)
<deathmist>
wrong commit (I had another issue open), I meant 8192772c0ac (freedreno: Remap high/norm/low priorities)
<robclark>
deathmist: maybe track down what submitqueue priorities it used before/after? Is something keeping the GPU continuously busy causing starvation?
bmodem has quit [Ping timeout: 480 seconds]
guru_ has quit []
oneforall2 has joined #dri-devel
wvanhauwaert has joined #dri-devel
pochu has joined #dri-devel
<deathmist>
robclark: looking at https://gitlab.freedesktop.org/mesa/mesa/-/commit/8192772c0ac the priorities were hardcoded before, guess I'll add logging to check prio_low and prio_norm values it sets in fd_screen_create(); how would one check if something is "keeping the GPU continuously busy causing starvation"? I'd guess it's busy when it launches a new XWayland window under GNOME for
<deathmist>
example
<deathmist>
in my case I was testing Minecraft and simply trying to launch the game caused the display to stop refreshing before the window even becomes visible
<deathmist>
entering an X11 session of GNOME also causes a similar effect where the display stops refreshing before a frame of the desktop environment is rendered
<robclark>
what could be happening (and you should be checking for) is whether game ends up with higher priority (lower numerically) than the compositor (which I guess with x11 you need to care about both Xorg and gnome-shell processes)
jkrzyszt has joined #dri-devel
Guest3992 has quit [Ping timeout: 480 seconds]
frieder has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
jeeeun8413 has quit []
tursulin has quit [Ping timeout: 480 seconds]
vliaskov__ is now known as vliaskov
mszyprow has quit [Ping timeout: 480 seconds]
digetx is now known as Guest4091
digetx has joined #dri-devel
Guest4091 has quit [Ping timeout: 480 seconds]
devilhorns has quit []
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<idr>
alyssa: RE #7539... Intel GPUs have a 3-source compare-and-select that matches NIR pretty closely, but we also have issues generating those instructions for all the same reasons we have issues with ffma.
Akari has joined #dri-devel
jeeeun8413 has joined #dri-devel
iive has joined #dri-devel
columbarius has quit [Quit: columbarius]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
nchery has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has joined #dri-devel
mbrost has joined #dri-devel
Daaanct12 has quit [Read error: Connection reset by peer]
Daaanct12 has joined #dri-devel
jhli has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
<alyssa>
idr: Yeah, makes sense
<alyssa>
You think 3-src is bad, try 4-src...
alanc has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<karolherbst>
is there a IRC channel for v3d or something?
<alyssa>
yes
<alyssa>
but I do not remember the name (:
<alyssa>
semeingly #videocore
<karolherbst>
🙃
<karolherbst>
ahh
<karolherbst>
good enough
DrNick1 is now known as DrNick
Jeremy_Rand_Talos__ has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
<alyssa>
zmike: can i introduce u to something cool
<alyssa>
it's called gl_shader_stage_is_compute
<alyssa>
very cool
<alyssa>
"this was for supporting clover, but I don't care anymore" extremely-acked-by: alyssa rosenzweig <alyssa@collabora.com>
Haaninjo has joined #dri-devel
anarsoul|2 has quit [Read error: Connection reset by peer]
anarsoul has joined #dri-devel
mbrost has joined #dri-devel
srslypascal has quit [Quit: Leaving]
<zmike>
the rare eab
<jenatali>
zmike: Yeah... that image typing stuff is the same problem I ran into :(
<jenatali>
That test case I sent is the reason we potentially split the image into multiple vars if it's used that way
<zmike>
I might do that too, but probably not something I'm concerned with during initial bringup since it passes CTS like this
<karolherbst>
I am sure we'll have to do more fixes once we want to have valid spir-v
<karolherbst>
but from a quick look that MR already looks much better than the code you came up before
<zmike>
I helps that you're not feeding me complete trash anymore :p
<karolherbst>
:D
<karolherbst>
though I really have to fix the DCE stuff, because normally if sampler/texture derefs are lowered the shader can consider the variables to be dead :/
<karolherbst>
but it should also like not matter at all for images
lynxeye has quit [Quit: Leaving.]
danvet has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
leo60228- has quit []
leo60228 has joined #dri-devel
<alyssa>
jenatali: okay potentially dumb question
<alyssa>
I hear that dx12 and zink can't lower I/O, they need nir_variable's
<alyssa>
Why is that?
<alyssa>
Why can't they lower I/O and then translate lowered I/O into indexing into a big array?
<alyssa>
it's immaterial to my life, just curious
<airlied>
do you still have array bounds info after io lowering?
<jenatali>
alyssa: At least from the DXIL level, and I think SPIR-V is the same, the IR needs to upfront-declare what's going to be accessed, including which components will be int/uint/float, interpolation modes, system values, etc
<jenatali>
You could reconstruct all of that from the lowered I/O... but all that info is in the variables already, since that's how GLSL is structured, so why delete it and reconstruct it when we can just.. not delete it?
<jenatali>
It's simpler to iterate the variables first to generate those declarations, then iterate the IR independently
<jenatali>
Array bounds is a good one too
<alyssa>
jenatali: Oh, weird, okay
<alyssa>
I guess that makes sense? I guess if I were generating GLSL i'd have the same problem
<alyssa>
airlied: firm maybe(TM)
<alyssa>
io_semantics claims to have something for it
<jenatali>
alyssa: FWIW I switched us to lowered I/O a while ago instead of derefs, I just don't delete the vars afterwards
<jenatali>
In DXIL at least, you declare the vars and give them indices upfront, and then you reference them by indices later on, so it's simpler to just use the lowered I/O vals rather than computing them in the backend from derefs
JohnnyonFlame has joined #dri-devel
<alyssa>
sure
<alyssa>
jenatali: basically my concern is wanting to be able to run passes like lower_fragcolor after lowering I/O
<alyssa>
and that doesn't work when Zink uses them on non-lowered I/O
<jenatali>
Ack, makes sense
<alyssa>
without maintaining 2 code paths -.-
<jenatali>
Yeah...
<jenatali>
If it gets to the point that we're the only holdout on non-lowered I/O, I could probably reconstruct the I/O vars from the shader if I had to
<alyssa>
eh, Zink needs what Zink needs
<alyssa>
but it would be nice to do lower_fragcolor on lowered I/O
<alyssa>
because otherwise I can't lower I/O in pipe->finalize_nir
<jenatali>
And I'm thankful it exists to keep us from being the only one using non-lowered I/O :)
<jekstrand>
Ugh... Meta for NVK isn't going to be as nice as I'd hoped. :-/
<karolherbst>
why not?
<jekstrand>
Depth/stencil
Duke`` has quit [Ping timeout: 480 seconds]
<jekstrand>
Also, I think NV can do MSAA resolves in a single sample operation if I set magic image view bits.
<karolherbst>
probably
<jekstrand>
The question is how to take advantage of all that
jljusten has quit [Quit: WeeChat 3.6]
* karolherbst
builds the CL CTS on the pi4
<jekstrand>
For depth/stencil, I need to bind as a color image and render to it.
<karolherbst>
"fun"
<jekstrand>
None of it's that hard. It's just hard to do in generic code
mszyprow has quit [Ping timeout: 480 seconds]
<karolherbst>
I think that was also the reason we couldn't use u_blitter
akselmo has left #dri-devel [#dri-devel]
<airlied>
jekstrand: yeah generic resolve is messy, esp after looking at how much trouble it is on amd hw
<airlied>
the whole fixed fn hw vs compute path vs fragment path is a lot of not fun
<jekstrand>
Well, NV doesn't really need many paths. It just needs a bit of custom around depth/stencil
jljusten has joined #dri-devel
<jekstrand>
There's a bit of annoyance in dealing with blit regions but that by itself isn't worth common code
<jekstrand>
Yeah, I think I'm gonna pull this into nvk and vendor it. :-/
<jekstrand>
Makes me sad
<karolherbst>
:(
<karolherbst>
soo.. going to do my first CTS run soon, any bets?
imre is now known as Guest4108
imre has joined #dri-devel
Guest4108 has quit [Ping timeout: 480 seconds]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
JohnnyonFlame has joined #dri-devel
<alyssa>
jekstrand: "this" being resolves?
<alyssa>
or all of meta? o_O
wvanhauwaert has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
mszyprow has joined #dri-devel
<karolherbst>
uhhh.. that pi4 is so slow :(
<alyssa>
karolherbst: now you know why panfrosticl isn't conformant :(
<karolherbst>
I thought that's because of weirdo bugs :D
<karolherbst>
give me the hardware and I'll run it :P
<karolherbst>
though for a first try it's not even that terribly broken: "Pass 752 Fails 27 Crashes 806 Timeouts 0: 65%|"
<karolherbst>
something is totally bonkers with compute shaders though
<karolherbst>
alyssa: you were targeting EMBEDDED or FULL profile?
<alyssa>
Embedded, though there's a weirdo bug where rusticl won't pass CTS without int64
<alyssa>
so all full would add is more images/samplers
<alyssa>
which panfrost can and probably should do?
<alyssa>
Arm does the full profile
<karolherbst>
full profile CTS runs like 16 times as long though
<karolherbst>
but yeah... could be doable but maybe also very pointless
<karolherbst>
could pass embedded first and upgrade later
<alyssa>
Yikes!
<alyssa>
yes, that was another reason to avoid full profile :(
<karolherbst>
that's on iris: Test Conversions passed in 28495.6525979s
<alyssa>
O_O
<karolherbst>
second longest running test: Test Math passed in 10113.4281409s
<karolherbst>
the it's like "Test Half Ops passed in 2179.17991304s" and it quickly goes down
<jenatali>
karolherbst: That's 8 hours for conversions?
<jenatali>
Not bad
<karolherbst>
yeah
<karolherbst>
the full run is like 13 hours as you see
<jenatali>
Yeah that sounds about right
<jenatali>
I tried to do a full run on WARP... took ~3 days IIRC
<karolherbst>
there is one thing I wanted to try out: offloading callbacks
<jenatali>
Offloading?
<karolherbst>
atm I do that in the worker thread
<karolherbst>
so instead of calling into the callbacks synced in the worker thread, I just push that out into a callback thread
<jenatali>
I wouldn't expect that to make much of a difference
<karolherbst>
not sure how badly that messes up API promises though
<karolherbst>
ohh.. it's mostly for making sure the GPU has enough stuff to work through
<HdkR>
karolherbst: This is why I only ever recommend pi if you enjoy pain. It's just /way/ too slow. They could at least give us the courtesy of a Pi5 with like ten A510 cores or something :P
<karolherbst>
and it might or might not speed up the CTS
mszyprow has quit [Ping timeout: 480 seconds]
<HdkR>
If I read the CL spec correctly then the callbacks can happen on whatever thread, so if CTS breaks then CTS is broken :D
<karolherbst>
right...
<jenatali>
Yeah, callbacks can happen wherever
<karolherbst>
but the rpi4 is at least at 100% load.. should have built mesa in release mode...
<HdkR>
Which is why I funnel them through a tube, so I can control the damn things
<jenatali>
I think I'm almost done with this CL interop extension
<karolherbst>
HdkR: when is it ready tho
<karolherbst>
ohh, saw your message oops
<HdkR>
hah
<karolherbst>
though my rpi4 doesn't display anything once the GPU driver loads...
<alyssa>
HdkR: this is why I recommend tau instead
<alyssa>
much less pain
<karolherbst>
the CTS turned around, yay "Pass 877 Fails 35 Crashes 838 Timeouts 0: 71%|"
<karolherbst>
more passes than fails
<karolherbst>
but why do compute shaders not work :( ... ohhhh
<karolherbst>
duh
<karolherbst>
because they are kernels
<karolherbst>
MESA_SHADER_KERNEL was a mistake
<alyssa>
karolherbst: agreed, kill it with fire
<alyssa>
sequel to the drawoverhead MR
<karolherbst>
some drivers want to know it though :(
<karolherbst>
like zink
<alyssa>
then those drivers are wrong ~~and should be deleted~~
* karolherbst
grabs 🍿🍿🍿
<alyssa>
at the very least make "is opencl?" a shader_info bit?
<alyssa>
instead of a duplicate shader stage
<karolherbst>
mhhhh
<karolherbst>
that might be a good compromise indeed
<alyssa>
I can't even tell what parts of the tree actually care because there's so much "compute || kernel" duplicatio
<karolherbst>
yeah....
<karolherbst>
though I think earlier the goal wasn't to make them as close as possible, because of $reasons
<HdkR>
Obviously since kernels would be written in SPIR
<karolherbst>
obviously
<HdkR>
If I had to accept SPIR I would have also tried removing from the codebase as much as possible as well :D
<jenatali>
Not for the writer, but the reader they do try
<jenatali>
For things like SPIR
<karolherbst>
alyssa: what was that name of that handy is compute/kernel function?
<HdkR>
huh, TIL
<karolherbst>
ohh wait.. I know a weirdo trick
<HdkR>
Wonder how often that breaks, because it sounds like constantly.
<jenatali>
Yeah, dunno
<jekstrand>
alyssa: both, a bit?
<jekstrand>
alyssa: I'm starting to get an idea how I can handle it, though.
<karolherbst>
huh...
srslypascal has joined #dri-devel
<jekstrand>
alyssa: Basically, a pair of functions, one of which translates the API format to the "real" format you want to use and another which takes the API format, color, depth, and stencil components and packs them all into a color thing however the driver wants.
<jekstrand>
IDK if that's general enough, though.
<karolherbst>
why can't v3d deal with 64 bit uniforms :(
<alyssa>
jekstrand: Hm. I was really looking forward to vk_meta, idk
<jekstrand>
alyssa: I think it's probably still possible
<alyssa>
Meta is the most frustrating part of panvk to me, whereas there's 0 meta stuff in our gl driver because u_blitter can do everything we care about.
<jekstrand>
Sure
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<jekstrand>
Hrm... Another option would be to make the driver handle all that stuff in vkCreateGraphicsPipeline if it sees a depth/stencil format bound as a color attachment.
<jekstrand>
That could work, too.
<jekstrand>
That actually doesn't sound insane...
<jekstrand>
At least, no more insane than anything else I'd do. :joy:
<alyssa>
:grin:
<alyssa>
:ship-it-parrot:
<jekstrand>
Hrm... But how would that work. :-/
<alyssa>
jekstrand: What does colour rendering to Z/S even mean? I'm lost.
<alyssa>
What's prompting this?
<jekstrand>
alyssa: blits and resolves of Z/S
<jekstrand>
Depth you can do by just setting gl_FragDepth. Stencil requires magic.
<jekstrand>
Either EXT_shader_stencil_export (which NV doesn't have) or you have to bind stencil as a regular old render attachment
<alyssa>
All of my hardware has EXT_shader_stencil_export so I've avoided that one thus far.
<jekstrand>
That makes everything easier. :)
<alyssa>
What's wrong with binding the stencil image as R8_UINT?
<alyssa>
Compression/tiling fun?
<jekstrand>
Well, for one thing, "stencil image" isn't a thing... NVIDIA does interleaved depth/stencil. :sweat_smile:
<alyssa>
...Delight.
<karolherbst>
it makes perfect sense :P
<alyssa>
Yes, I see why blits of Z24S8 are problematic.
<alyssa>
Apple solves that by not support Z24 or interleaved (-:
<jekstrand>
Very sensible. :P
<alyssa>
:-D
<jekstrand>
In any case, it's all very implementable. It just takes a bit of work.
ybogdano has joined #dri-devel
<alyssa>
I still haven't manage to convince myself whether emulating Z24 as Z32F is conformant or not.
<alyssa>
Z24 does have better precision near 1 than Z32F
<jekstrand>
And it takes some thought to figure out exactly how to architect all the driver knobs to make it work.
<alyssa>
But can you ever observe that extra precision?
<alyssa>
If a few ulps fall in a forest and nobody's instruments are fine enough to observe them, is that conformant?
<karolherbst>
ohh.. figured out why v3d breaks.. it's full 32 bit.. delight
<alyssa>
:-p
<alyssa>
(...But what if we throw fp64 emulation in the arena?)
<airlied>
alyssa: just don't expose Z24 for vulkan :-)
<alyssa>
u_transfer_helper stuff seems to work ... I think
Danct12 has quit [Remote host closed the connection]
<alyssa>
karolherbst: So there's this great Rusticl merge request someone did that makes load_kernel_input go away entirely, consider giving it a try? :-p