ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
vstehle has quit [Ping timeout: 480 seconds]
hl`` has joined #panfrost
camus has joined #panfrost
hl` has quit [Ping timeout: 480 seconds]
JulianGro has quit [Ping timeout: 480 seconds]
camus has quit []
camus has joined #panfrost
tris_ has quit [Server closed connection]
tris_ has joined #panfrost
remexre has quit [Server closed connection]
remexre has joined #panfrost
jekstrand has quit [Server closed connection]
jekstrand has joined #panfrost
jkl has quit [Server closed connection]
jkl has joined #panfrost
kenzie35 has quit [Server closed connection]
kenzie35 has joined #panfrost
davidlt__ has joined #panfrost
ezequielg has quit [Server closed connection]
ezequielg has joined #panfrost
krh has quit [Server closed connection]
krh has joined #panfrost
tlwoerner has quit [Server closed connection]
tlwoerner has joined #panfrost
davidlt__ has quit [Ping timeout: 480 seconds]
vstehle has joined #panfrost
Daanct12 has joined #panfrost
anholt has quit [Server closed connection]
anholt has joined #panfrost
Daanct12 has quit [Remote host closed the connection]
anarsoul has quit [Server closed connection]
anarsoul has joined #panfrost
pch has quit [Server closed connection]
pch has joined #panfrost
soreau has quit [Server closed connection]
soreau has joined #panfrost
atler has quit [Server closed connection]
atler has joined #panfrost
cphealy has quit [Server closed connection]
cphealy has joined #panfrost
Major_Biscuit has joined #panfrost
davidlt__ has joined #panfrost
Major_Biscuit has quit [Ping timeout: 480 seconds]
pjakobsson has quit []
atler has quit [Quit: atler]
camus1 has joined #panfrost
camus has quit [Read error: Connection reset by peer]
camus has joined #panfrost
Daanct12 has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
ckeepax has quit [Server closed connection]
ckeepax has joined #panfrost
camus1 has joined #panfrost
camus has quit [Read error: Connection reset by peer]
camus has joined #panfrost
camus1 has quit [Read error: Connection reset by peer]
MajorBiscuit has joined #panfrost
rkanwal has joined #panfrost
erlehmann has quit [Ping timeout: 480 seconds]
erlehmann has joined #panfrost
SolidHal81 has quit [Server closed connection]
SolidHal81 has joined #panfrost
camus1 has joined #panfrost
camus has quit [Remote host closed the connection]
camus has joined #panfrost
rasterman has joined #panfrost
camus1 has quit [Ping timeout: 480 seconds]
wicastC has quit [Server closed connection]
wicastC has joined #panfrost
erlehmann has quit [Ping timeout: 480 seconds]
erlehmann has joined #panfrost
tolszak has joined #panfrost
rcf has quit [Server closed connection]
rcf has joined #panfrost
erlehmann has quit []
bluebugs has quit [Server closed connection]
bluebugs has joined #panfrost
Daanct12 has quit [Remote host closed the connection]
robher has quit [Server closed connection]
robher has joined #panfrost
tortoise has quit [Server closed connection]
tortoise has joined #panfrost
ChanServ changed the topic of #panfrost to: Panfrost - FLOSS Mali Midgard & Bifrost - Logs https://oftc.irclog.whitequark.org/panfrost - <macc24> i have been here before it was popular
camus has quit []
tchebb_ has quit [Server closed connection]
tchebb has joined #panfrost
rkanwal has quit [Read error: No route to host]
rkanwal has joined #panfrost
alyssa has joined #panfrost
Lyude has quit [Server closed connection]
Lyude has joined #panfrost
JulianGro has joined #panfrost
atler has joined #panfrost
rkanwal has quit [Quit: rkanwal]
rkanwal has joined #panfrost
pjakobsson has joined #panfrost
tris_ has quit [Server closed connection]
tris_ has joined #panfrost
jekstrand has quit [Server closed connection]
jekstrand has joined #panfrost
nlhowell has joined #panfrost
jkl has quit [Server closed connection]
jkl has joined #panfrost
kenzie35 has quit [Server closed connection]
kenzie35 has joined #panfrost
robmur01 has quit [Server closed connection]
cphealy has quit []
robmur01 has joined #panfrost
JulianGro has quit [Remote host closed the connection]
krh has quit [Server closed connection]
krh has joined #panfrost
tlwoerner has quit [Server closed connection]
tlwoerner has joined #panfrost
tolszak has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
jambalaya has quit [Server closed connection]
jambalaya has joined #panfrost
JulianGro has joined #panfrost
guillaume_g has quit [Server closed connection]
guillaume_g has joined #panfrost
Danct12 has quit [Remote host closed the connection]
soreau has quit [Server closed connection]
soreau has joined #panfrost
alyssa has quit [Server closed connection]
alyssa has joined #panfrost
Danct12 has joined #panfrost
JulianGro has quit [Remote host closed the connection]
davidlt__ has quit [Remote host closed the connection]
cphealy has joined #panfrost
vstehle has quit [Server closed connection]
vstehle has joined #panfrost
tolszak has joined #panfrost
`join_subline has quit []
`join_subline has joined #panfrost
tolszak has quit [Ping timeout: 480 seconds]
* alyssa
running !15365 through piglit
<alyssa>
looks like we had some unrelated piglit regressions since then, that's not good..
rasterman has quit [Quit: Gettin' stinky!]
rkanwal has quit [Ping timeout: 480 seconds]
<jekstrand>
bbrezillon: Looking at v3dv a bit, they actually do some stuff on the CPU as part of command buffer execution. Seems a bit insane to me but I guess it could be done if we really wanted CPU handling of indirect and index buffers.
<alyssa>
T_T
<jekstrand>
Yeah, I'm very unsure about this hole thing.
<jekstrand>
*whole
<jekstrand>
But they are Vulkan 1.1 conformant with it and some people say get decent perf
<jekstrand>
They're not doing it for anything as granular as index buffer walks, though.
nlhowell has quit [Ping timeout: 480 seconds]
<icecream95>
jekstrand: kbase (for v10) has a queue for doing jobs on the CPU in the context of the kernel driver. I don't know what the advantage of that over a userspace thread is
<jekstrand>
idk
<alyssa>
in general trying to understand kbase is a losing battle
<HdkR>
Implement the feature in kbase so that one day it can be open sourced </s>
<HdkR>
:D
* alyssa
tries to figure out the least worst way to handle 64-bit BIR
<icecream95>
alyssa: What I wonder is how you are going to handle the component masks for texture instructions
<alyssa>
in what sense?
<icecream95>
The components might not be in .rgba order any more, maybe g is the first component and a is the second...
<alyssa>
right. that..
<alyssa>
Undecided.
<alyssa>
Bifrost has the same thing fwiw
<icecream95>
Really?
<alyssa>
Yeah
<alyssa>
`mask = 0xF` in bi_emit_texc
<icecream95>
Only for TEXC or does TEXS have it as well?
<alyssa>
Semantics are identical IIRC
<alyssa>
just TEXC
<icecream95>
Ah.
<alyssa>
Conceptually, Valhall's texturing instructions are "TEXC, but with the texture operation descriptor inline, with no TEXS"
<icecream95>
..And with some reordering, it appears
<alyssa>
The simple way would be emitting a pile of moves after the TEX to put things back where they belong, and hoping copyprop makes the intermediate vector go away
<alyssa>
I suspect that won't perform well, though
<alyssa>
The 'right' way probably requires handling this in the original NIR.
<icecream95>
But the VAR_TEX instructions have more differences, for example how 16-bit vs 32-bit is selected (f32f16 isn't supported for dual texturing)
<alyssa>
jekstrand: Mind if we take 4-bits in nir_tex_instr?
<alyssa>
yes, I said 'conceptually'
<jekstrand>
alyssa: Uh... why? I mean, nir_tex_instr is pretty big so it likely won't hurt
<alyssa>
jekstrand: "channels read from the texture"
<alyssa>
so then we can compact the output
<alyssa>
(if only .a is used, we want tex to return a scalar)
* jekstrand
feels like he just had this conversation somewhere
<alyssa>
Yes
<alyssa>
You said to use nir_ssa_def_components_read
<jekstrand>
I don't think I'd mind too bad, so long as it's well-defined, validated, and defaults to 0xf for drivers that don't ask for it.
<jekstrand>
s/ask for it/ask for compaction/
<alyssa>
But that's only one piece of the puzzle, we also need to rewrite users to avoid relying on backend copy prop
<alyssa>
(Which doesn't work in general, since we go out-of-SSA in NIR)
<jekstrand>
But, also, at least 2-3 other drivers have implemented this optimization without extending nir_tex_instr
<alyssa>
how do they handle the non-SSA case?
<jekstrand>
They get MOVs
<alyssa>
right.
<alyssa>
float t = ...; if (..) { t = tex(...).a; }
<alyssa>
conceptually I think handling that (correctly / efficiently) is a lot easier before going out of SSA
<jekstrand>
Sure
<jekstrand>
And I suspect the Intel drivers might benefit a tiny bit from doing it in NIR while still in SSA
<jekstrand>
But I seem to recall there being weirdness around when we can and cannot use it which made doing it in NIR a pain
<jekstrand>
I seem to recall posting a link to a branch
<alyssa>
right..
<alyssa>
intel seems not to do the hard form of this optimization, only the easy form
<alyssa>
(the easy form being trimming unused components off the end)
<jekstrand>
today, yes. I've got a branch for the hard form.
<alyssa>
ack
<jekstrand>
Actually, I'm starting to remember... I think maybe Intel can usually do it for real. It's the stupid EOT texture op thing which we no longer use that didn't allow it.
* alyssa
wires up shared memory
<icecream95>
alyssa: Another problem.. How to RA if we have one dual texture instruction to nodes a and b, then a second instruction for nodes b and a?
<icecream95>
AFAICT, the two sets of registers have to be contiguous on Valhall
<alyssa>
They do have to be contiguous on Valhall, yes
<alyssa>
vec8 woot woot?
<icecream95>
..Or, if you do a dual-texture with a single component, then write to the second component of the first node
<icecream95>
I guess only do the optimisation for SSA dests then?
<icecream95>
That reminds me.. who thought that interleaving SSA and register nodes was a good idea, because you are *definitely* going to have a similar number of each
<alyssa>
Ooh, I know that one
<alyssa>
It was me!
<alyssa>
Hmm. is it worth keeping a lot of IR complexity for a minor Bifrost-only optimization
<alyssa>
thinking no..
<alyssa>
(Being able to specify low/high of 64-bit addresses that don't form a register pair)
<robmur01>
what, you mean NIR doesn't already have segmented addressing support for running shaders on your 286? :P