Re: [9fans] Drawterm GPU (was: Software philosophy)

[sirjofri <sirjofri+ml-9fans@sirjofri.de>]

Good morning,

GPUs are SIMD processors. The hundreds of cores are great for highly 
parallel calculation.

In GLSL/HLSL I can write a program which is calculated for a very small 
set of pixels (usually 2x2 or 1x1). So if you have  a resolution of 10x10 
the program is basically run 5x5=25 or 10x10=100 times in parallel. Boost 
the resolution to more real values like 1080p you see how the many cores 
benefit the whole calculation.

This high parallelization can only really happen because most stuff is 
independent. For example, when raytracing each ray is (almost) 
independent of other rays.

Still, the 2x2 matrix is often calculated dependently because for 
texturing (and mip mapping) you need the "distance" between two pixels in 
a fragment shader. This is why (for texturing) you may end up having 
slower programs and some waiting time between some threads, because 
sometimes you need the value of the neighbor thread and have to wait 
until it's calculated.

Well, these are very language-specific details that are important for 
graphics, but apply similarly to other use cases. I can imagine that for 
neural networks you can just write the code for one node nad execute it 
500 times for 500 nodes in parallel. Imagine having this beast on the CPU 
with just 4 cores...

I hope this helps you understand how GPU cores ("shaders") work.

Vulkan would indeed be interesting. Since we are only interested in the 
compute part it might even make our programs really small, the "hello 
world" part of drawing triangles would be the "client" side (writing a 
rasterizer, raymarcher, tracer, whatever). It could still be a lot lines 
of code, but maybe we still benefit from the 10% speedup.

I still have to understand how all this "shader compilation" stuff works. 
In webgl it's like, "here's my code, make a shader from it, then I tell 
you it's a fragment shader". Shader compilation happens automatically. In 
UE shader compilation takes a long time, and I believe also in blender 
shaders are stored in a precompiled binaries.

sirjofri

23.08.2021 06:13:53 Bakul Shah <bakul@iitbombay.org>:

> Don't high end GPUs have thousands of "cores"? Even high end CPUs don't 
> have more than a few dozen cores to 128 or so. While each kind's cores 
> are very different, seems to me GPU/CPU paths have diverged for good. 
> Or we need some massive shift in programming languages + compilers. I 
> lack imagination how. Still, the thought of the CPUs gaining the 
> complexity of the graphics engine scares me!
>
> -- Bakul
>
> On Aug 22, 2021, at 12:09 PM, Paul Lalonde <paul.a.lalonde@gmail.com> 
> wrote:
>
> I'm pretty sure we're still re-inventing, though it's the CPU's turn to 
> gain some of the complexity of the graphics engine.
>
> Paul
>
> On Sun, Aug 22, 2021, 12:05 PM Bakul Shah <bakul@iitbombay.org> wrote:
>> Thanks. Looks like Sutherland's "Wheel of 
>> Reincarnation[https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland-design-of-display-processors.pdf]" 
>> has not only stopped but exploded :-) Or stopped being applicable.
>>
>> -- Bakul
>>
>> On Aug 22, 2021, at 9:23 AM, Paul Lalonde <paul.a.lalonde@gmail.com> 
>> wrote:
>>
>> It got complicated because there's no stable interface or ISA.  The 
>> hardware evolved from fixed-function to programmable in a commercial 
>> environment where the only meaningful measure was raw performance per 
>> dollar at many price points.  Every year the hardware spins and 
>> becomes more performant, usually faster than Moore's law.  With 3D 
>> APIs hiding the hardware details there is no pressure to make the 
>> hardware interface uniform, pretty, or neat.  And with the need for 
>> performance there are dozens of fixed function units that effectively 
>> need their own sub-drivers while coordinating at high performance with 
>> the other units. 
>> The system diagrams for GPUs look complex, but they are radical 
>> simplifications of what's really on the inside.
>>
>> Intel really pioneered the open driver stacks, but performance 
>> generally wasn't there.  That might be changing now, but I don't know 
>> if their recently announced discrete product line will be 
>> driver-compatible.
>>
>> Paul
>>
>>
>> On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah <bakul@iitbombay.org> 
>> wrote:
>>> The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting 
>>> the "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 
>>> 200K+ lines of source code. drm/amd over 2M lines of code. Intel's 
>>> i915 seems to be about 1/10th the amd size. AIUI, this is linux GPU 
>>> driver code, more or less unchanged (FreeBSD has shim code to use 
>>> it). How did the interface to an SIMD processor get so complicated?
>>>
>>> …
>>>
>>>
>>>
>>> -- Bakul
>>>
>
>
> *9fans[https://9fans.topicbox.com/latest]* / 9fans / see 
> discussions[https://9fans.topicbox.com/groups/9fans] + 
> participants[https://9fans.topicbox.com/groups/9fans/members] + 
> delivery options[https://9fans.topicbox.com/groups/9fans/subscription] 
> Permalink[https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-Me78513510ae4df2da186c73a]

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M40ea45711a1551fd53807b84
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription