09:14 <rellla> anarsoul: oh yes. i missed the gitlab issue ...

09:59 <mardikene193> now the dependency resolution is done manually by the compiler in both utgard to midgard but also on later bifrost GPUs, on AMD they are managed for memory operations with s_waitcnt and lgkm counters, which act as barriers/fences kind of for memory in the shader.

10:00 <mardikene193> it appears scoreboard blocking the source operands and destinations only when the write is performed, it delays the blocking so, unless fences like those are used on AMD

10:01 <mardikene193> however if scoreboard feed happens manually like in MALI case, you can do however you want, blocking any of the operands as needed or not

10:02 <mardikene193> MALI gpus are actually all quite well designed, I am reasonably suprised in a good way.

10:03 <mardikene193> my friend has one brand new flagship smartphone which has some g7x gpu

10:04 <mardikene193> and he showed me the raw performance without much of the optimizations i have suggested on it -- but binary driver was in use

10:04 <mardikene193> it seemed to work very well somehow

10:11 <mardikene193> So yeah AMD has the worst design

10:12 <mardikene193> on GCN, vliws are fine

10:13 <mardikene193> it is because the barrier does not have or consume issue queue entries, they need to be decoded i.e branched to

10:14 <mardikene193> however they offer also setgreg which bypasses scoreboard alltogether

10:22 <mardikene193> but as GCN is sm5.0 GPU they would use different code to do indirections

10:22 <mardikene193> instead of what i talked for vliws anyways, so...

10:25 <mardikene193> so in my opinion SIMD is just inherently bad arch.

10:30 <mardikene193> there is a way to index the destination register out-of-bounds only, so sm2.0-sm3.0 true SIMD gpus are the ones that can not do the needed in any way.

10:33 <mardikene193> even though SIMD gpus are all unified architectures, constant indexing from out-of-bounds returns zeros

10:47 <mardikene193> now that i think about probably there is a way , it's so perverse, you'd have to consume at least 2.5 warp lines to do LSU ops and redirect to lower rows/lines

10:58 <mardikene193> it is because texture operations on a second line can't run unless they are ready, they will be ready if offset is adjusted again only

12:06 <mardikene193> So it'd be more sane to make changes to the driver to allow more ALU instructions, if less LSU/memory operations are in use, for instance 64 vs 32 respecitvely on sm2.0 -- if i were to use only 16 or 17 memory laods then 80 or 79 alus could be used! Hw should allow this.

12:15 <mardikene193> why limitations exists is probably cause that time cache sizes were not that big, and fallback to memory due to pretty big transistors and hence bigger FO4 paratemets or and gate delays would had made the pipeline far too slow

12:16 <mardikene193> however they should be fine trading LSU/mem loads in favor of more ALU ops.

12:23 <mardikene193> however yeah well mali 400mp one core version should come with 256 (which is out of any spec), and two core version allready 5215 for shared mem/LSU and alu usage.

12:23 <mardikene193> *512

16:33 <warpme__> indeed. https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/dma-buf/dma-resv.c?id=7fbd0782bf94d46993a7e5c08c0feda8dcab1f76 fixes issue!