ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
hexdump01 has joined #lima
hexdump0815 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #lima
yuq825 has quit [Remote host closed the connection]
yuq825 has joined #lima
Daanct12 has quit [Quit: WeeChat 4.6.3]
dsimic is now known as Guest18684
dsimic has joined #lima
Guest18684 has quit [Ping timeout: 480 seconds]
<sarbes>
I've rewritten my scalar constant multiplier MR to go the NIR route, but I got worse numbers on Shader DB. It looks like the ffma op prevents some optimization here.
<anarsoul>
sounds like your first approach to lower it in ppir is better :)
<anarsoul>
But ffma support in ppir is a hack. It's just a consequence of lacking corresponding optimization pass in ppir
<sarbes>
Yeah... I'll try to hack around the hack :)
<sarbes>
I'll break down the ffma if I can sneak a multiplier in.
<anarsoul>
or just handle constant multipliers in ppir?
<anarsoul>
ffma allows to save a register when passing mul result to add
<anarsoul>
so breaking down ffma may result in increased register pressure
<sarbes>
...or I'll add an ffma opcode which can accept two scalars. But this sounds even more hacky.
<sarbes>
But it is doable.
<sarbes>
On further thought, no.
<sarbes>
But it shouldn't be too hard to rearrange ffmas by hand, I think.
<anarsoul>
sarbes: there is nothing wrong in folding constant multipliers in ppir
<anarsoul>
it is utgard-specific feature, so I don't think that it will be useful for nir in general