[libre-riscv-dev] Vulkanizing

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Feb 19 06:17:17 GMT 2020


On Wednesday, February 19, 2020, Immanuel, Yehowshua U <
yimmanuel3 at gatech.edu> wrote:

> > the CPU *is* the GPU.
> > the GPU *is* the CPU.
>
> Ummm…
>
> The GPU is following the design by Mitch Alsup right?


no, the *CPU* is following Mitch's design.  the CPU happens to have opcodes
that you would normally only find on a GPU.  atan2. cos. recip sqrt.
cuberoot. yuv2rgb. hypot.  CORDIC. normalise. dotproduct. crossproduct.

these are going INTO THE CPU NOT A SEPARATE GPU.

there is no GPU ISA plus a CPU ISA.

there is only "CPU ISA with extra opcodes normally only found on GPUs".

it's far, far simpler than you're imagining it to be, i am not sure why.

perhaps because of the dog's dinner mess that Intel, NVIDIA, MALI, Vivante,
Videocore IV, AMDGPU etc. have all made of this space because they all want
to sell separate "products".


> I’m familiar with CUDAs concept like warps and CUDA cores…


sigh these are buzzwords to make GPU designers sound more important and
clever so they can justify their salaries.

another part of the insanity of separate CPU GPU acxhitectures is that the
separate GPU is a bare metal design.

shader assembler comes in.

shader is executed.

shader data goes out.

by the time you get to multi core hyperthreaded GPU designs such as those
by NVIDIA the complete and total lack of even the most basic and primitive
OS on the GPU cores will have been driving them nuts.

consequently they will have started inventing their own buzzwords, writing
proprietary Microkernels and MicroOSes reinventing OS concepts from basic
computer science and generally confusing the crap out of everybody as to
whhhyyyyyy.

the only reason it's functional at all is because they will have thriwn a
bottomless pit of money at it.

we.... are ... NOT ... repeating... these... mistakes.

we haven't got time.




> So how does that compare with what we’re doing?


complete utter timewasting overkill.

fortunately, as long as CUDA csn compile to Vulkan, we're good.

everything goes through Vulkan.

Vulkan shader.

compiles to POWERISA.

execute.

done.

it's

that

siiiimmmple.



> Will we have compute cores that simultaneously execute the same thread on
> their own data space?


no: the Vulkan SPIRV shader literally gets JIT translated into (extended)
POWER ISA assembler and is literally executed, right there, right then,
*on* the CPU.

as POWER assembler.



> We need to get a clear write up on this…


it's already done.  it's so simple that it's just not sinking in.



>
> Which is one of the tasks one of our potential investors assigned me to…
> Him being familiar with CPUs and all - wants to get a clear idea of
> microarchitecture…


it's slready extremely clear and simple.  so simple that you're not getting
it.

this is not because of the,simplicity of what we are doing, it's because if
the complete insanity of what the rest of the industry is doing by having
to build entire RPC subsystems and Microkernels as part of the "package",
due to the twin (incompatible) ISAs.


google "GPGPU" and "Hybrid CPU GPU".

also look up ICubeCorp and the IC3128.

except bear in mind that they had an SGI compiler expert onboard and they
went a bit of a weird route.

now they have had to abandon the GPGPU benefits and position themselves as
a "networking accelerator" core.  bit of a pity, that.

l.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68


More information about the libre-riscv-dev mailing list