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 quit [Ping timeout: 480 seconds]
mripard has joined #lima
mripard has quit [Quit: WeeChat 4.6.1]
linkmauve has joined #lima
dsimic is now known as Guest14843
dsimic has joined #lima
Guest14843 has quit [Ping timeout: 480 seconds]
<anarsoul|2> > So you can do "vec4 out = vec4(in.x, in.y, 0, -1);" in one go.
<anarsoul|2> it certainly does. It would improve texture swizzles *a lot*
<anarsoul|2> e.g. for R, RG formats
<anarsoul|2> sarbes: ^^
<sarbes> Texture swizzles are not inferred from the texture format?
<sarbes> Oh yeah, there are only L/A/LA formats, not R and RG.
<anarsoul|2> they are lowered in nir, and e.g. SWIZ(X, 0, 0, 1) can be expensive, since it requires 2 movs
<anarsoul|2> or SWIZ(X, W, 0, 1)
<anarsoul|2> I think these are the only formats that are emulated
<anarsoul|2> and technically if shader doesn't use components with 0 or 1 these will be dropped in dce pass
<sarbes> How would a lowering look in this case? Not being much familiar with the compiler, I would try:
<sarbes> 1. look for a mov with a constant as a source, containing the values 0/1/-1, and fold both into a swizzle.
<sarbes> 2. if there is a parent mov with a single successor and no outmod, merge it into the swizzle.
<sarbes> There is also 0x12: "dest.xyzw = vec2(arg0.x + arg0.y + arg1.x, arg0.z + arg0.w + arg1.y).xyxy", but this seems even more exotic.
<sarbes> maybe the arguments are the other way around.