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
icecream95 has joined #panfrost
camus1 has joined #panfrost
camus has quit [Read error: Connection reset by peer]
lyudess has joined #panfrost
bbrezill1 has joined #panfrost
Lyude has quit [Ping timeout: 480 seconds]
rkanwal has quit [Ping timeout: 480 seconds]
floof58 has joined #panfrost
guillaume_g has joined #panfrost
icecream95 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #panfrost
rasterman has joined #panfrost
rkanwal has joined #panfrost
rasterman has quit [Quit: Gettin' stinky!]
rasterman has joined #panfrost
atler has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
rkanwal has quit [Quit: rkanwal]
rkanwal has joined #panfrost
erle has quit [Ping timeout: 480 seconds]
erle has joined #panfrost
rasterman- has joined #panfrost
rasterman has quit [Read error: Connection reset by peer]
WoC has joined #panfrost
* alyssa
should get back to Valhall upstreaming, probbably
AreaScout_ has quit [Remote host closed the connection]
AreaScout_ has joined #panfrost
icecream95 has joined #panfrost
<Pu244>
I thought the phrase the kids these days used was "yeeting" when heaving code out of the boat?
nlhowell has joined #panfrost
<macc24>
yeeting?
<macc24>
o_o
lyudess has quit []
Lyude has joined #panfrost
rasterman- has quit [Remote host closed the connection]
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #panfrost
<Pu244>
"To lob, as though off a cliff"?
<Pu244>
Dunno.
<Pu244>
Terms I've heard.
<Pu244>
Took me a while to work them out too.
<macc24>
oh that meaning
* icecream95
gets back to trying to implement function call support
camus1 has quit [Remote host closed the connection]
camus has joined #panfrost
<alyssa>
jekstrand: ^^
<icecream95>
Hmm.. Unhandled Page fault in AS0 at VA 0x0000080006036000
* jekstrand
is trying to figure out WTF this test is bonkers
<icecream95>
This instruction (the first non-NOP in the clause) looks odd: +IADD.s32 r20:t1, r25, t
<icecream95>
Looks like RA didn't solve that node: br21 = IADD.s32 br23, 155
<icecream95>
alyssa: On the topic of RA, are you actually going to look at my RA speedup branch sometime?
nlhowell has quit [Ping timeout: 480 seconds]
WoC has joined #panfrost
<icecream95>
alyssa: It appears that Bifrost support for nir_op_pack_32_2x16 is buggy. I wonder who implemented that?...
megi has quit [Ping timeout: 480 seconds]
wolfshappen has quit []
wolfshappen has joined #panfrost
megi has joined #panfrost
<icecream95>
Hmm.. pack_32_2x16 *does* work correctly, but only because the vecN code ends up implementing it as just a 32-bit move
<icecream95>
I'm wondering whether to fix it properly (make it handle swizzles) or just do a MOV explicitly... swizzles do not seem to be valid for the opcode
* icecream95
notices UCP lowering and starts compiling Neverball
<alyssa>
icecream95: Looking through that MR is on my (long) todo list
<alyssa>
What's wrong with nir_op_pack_32_2x16 support?
<alyssa>
Oh. Swizzles. I see.
<icecream95>
The instruction gets lowered for GLSL anyway
<alyssa>
er, nir_op_pack_uvec[24]_to_uint I assume you mean
<icecream95>
Swizzles are broken for those as well
<icecream95>
(Well, "unsupported")
<alyssa>
I'm not seeing what's wrong with nir_op_pack_32_2x16
<alyssa>
unless er this is some confusion over _split vs not _split
<icecream95>
pack_32_2x16 has a dest size of 32-bit, so the bi_make_vec_to is 32-bit
<alyssa>
right ok.
<icecream95>
(But arguments are 16-bit components in a single source)
<alyssa>
so it should actually just become a swz_*? or a move if no swizzle?
<icecream95>
Hmm.. though swizzles are not used, I think that vectorisation can end up putting a swizzle on it?
<icecream95>
(pack_32_2x16 on vec2(b, a) if a single instruction is vectorised to return (a, b))
<alyssa>
let me know how neverball is on g72 with !16173
<alyssa>
there's still an issue with it on g57 but that might be a valhall specific bug
<alyssa>
(possibly relating to clipping/culling of large points)
<icecream95>
See !16181, though I may also fix pack_uvec instructions in that MR after getting pack from focusing on OpenCL
<icecream95>
Oohh.. large point clipping, I may get to put some of my knowledge of the tiler heap format to use
<alyssa>
Hehe
<alyssa>
I don't think the issue happens on my Midgard laptop
<alyssa>
and I don't remember seeing it on Bifrost
<icecream95>
I wonder if newer GPUs can support larger points, a size of 4095.9375 seems a little small /s
<icecream95>
Need to be able to actually see the points on your 32K screens
<alyssa>
Lol
<icecream95>
Are we and radeonsi the only drivers to actually set POINT_SIZE_GRANULARITY correctly? I don't believe that any hardware would actually have a granularity of 0.1