What happens if there's a data-dependency between frag 1 and frag 9? Would the 2nd thread skip and move onto the following thread?
EmmmaTao
I think the assumption of this parallel design is that the fragments are able to be processed independently, but regarding data dependency the next lecture discusses locality and data communication
john-b-yang
I think this diagram is pretty cool, reminds me of the pipelining issues that CS 61C discusses. In this case, with memory, some of the stalls could be branching or data related issues. For shaders, I would guess that more memory retrieval related stalls are probably a predominant issue.
bbtong
I think it depends on the purposes of whatever is running the shaders too -- rendering precise movies versus maintaining framerates for games has different needs, so gaming often has people encountering shader drops or artifacts from shader issues, i.e., 3D models and primitive geometry/color renders fine, but shaders crash and reset
fywu85
I think it is also important to note that the fact that those workarounds exit is the precisely reason why one should avoid i/o operations, data dependency, and if/else conditions when writing GPU programs.
hershg
This is exactly like with pipelining from cs61c we hide the latency of an instruction. In this picture we assumed no inter-fragment dependancies and were solely looking at hiding the latency (from a mem fetch for example), but in response to an above question, if frag 9 was dependent on frag 1 then we would need to stall that 'block' till after the first fragment set finished that dependency, and only then could we run frag 9 (unclear if just frag 9 would need to be delayed in lieu of another frag from diff block or we'd delay the whole block it comes with all together)
What happens if there's a data-dependency between frag 1 and frag 9? Would the 2nd thread skip and move onto the following thread?
I think the assumption of this parallel design is that the fragments are able to be processed independently, but regarding data dependency the next lecture discusses locality and data communication
I think this diagram is pretty cool, reminds me of the pipelining issues that CS 61C discusses. In this case, with memory, some of the stalls could be branching or data related issues. For shaders, I would guess that more memory retrieval related stalls are probably a predominant issue.
I think it depends on the purposes of whatever is running the shaders too -- rendering precise movies versus maintaining framerates for games has different needs, so gaming often has people encountering shader drops or artifacts from shader issues, i.e., 3D models and primitive geometry/color renders fine, but shaders crash and reset
I think it is also important to note that the fact that those workarounds exit is the precisely reason why one should avoid i/o operations, data dependency, and if/else conditions when writing GPU programs.
This is exactly like with pipelining from cs61c we hide the latency of an instruction. In this picture we assumed no inter-fragment dependancies and were solely looking at hiding the latency (from a mem fetch for example), but in response to an above question, if frag 9 was dependent on frag 1 then we would need to stall that 'block' till after the first fragment set finished that dependency, and only then could we run frag 9 (unclear if just frag 9 would need to be delayed in lieu of another frag from diff block or we'd delay the whole block it comes with all together)