[libre-riscv-dev] [Mesa-dev] NLNet Funded development of a software/hardware MESA driver for the Libre GPGPU

[Jason Ekstrand]

Drive-by comment: I don't think you actually want to base any decisions an 
a vec4 architecture. Nearly every company in the graphics industry thought 
that was a good idea and designed vec4 processors. Over the course of the 
last 15 years or so they have all, one by one, realized that it was a bad 
idea and stopped doing it. Instead, they all parallelize the other way and 
their SIMD instructions and on scalar values across 8, 16, 32, or 64 
invocations (vertices, pixels, etc.) Of the shader program.

That isn't too say that Mesa is there wrong choice or that there aren't 
other reasons why SwiftShader would be a bad fit. However, I would 
recommend against making major architectural decisions for the sole reason 
that it allows you to repeat one of the biggest architectural mistakes that 
the graphics industry as a whole managed to make and is only recently (last 
5 years) finally gotten over.

On January 8, 2020 18:35:16 Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:
> (if responding on mesa-dev please do cc me to help preserve the thread, i 
> am subscribed in digest mode, thanks)
>
> the NLNet funding application documented here was successful:
> https://libre-riscv.org/nlnet_2019_amdvlk_port/
>
> we therefore have money (direct payment of tax free, tax deductible 
> donations from the NLNet Foundation into your bank account [1]) available 
> for anyone, anywhere in the world, to help create a 3D MESA Vulkan 
> compliant driver for a hybrid hard-soft GPU.
>
> we considered starting from SwiftShader because it is, on initial 
> inspection, close to what we want. we could hypothetically have added deep 
> SIMD instructions, and the project would be 90% complete.
>
> however when it comes to predication and to vector types such as vec2, vec3 
> and vec4, the infrastructure in SwiftShader is unable to cope. thus, if we 
> add custom hardware opcodes which can accelerate vector-vector operations, 
> SwiftShader would have been an extremely bad decision as it would be 
> incapable of using such hardware without a drastic redesign.
>
> hence the reason for choosing MESA, because NIR can retain that critical 
> type information right up until it hits the hardware.
>
> as you know, a hybrid CPU/GPU does not have a separate CPU and a separate 
> GPU, they are *one and the same*.  therefore if starting from the Intel 
> MESA driver or RADV, the initial work needed is to make the chosen base 
> actually a *software* renderer, just like SwiftShader.
>
> this is a desirable goal and it will be important to have the code be 
> portable, unaccelerated, and run on at the minimum x86, and (later) the 
> Libre SoC.
>
> once that phase is completed, *then* we may move to adding custom 
> accelerated opcodes (Transcendentals, YUV2RGB etc). bear in mind that these 
> will be added *to the CPU*... because the CPU *is* the GPU.
>
> to be absolutely clear: there will be no marshalling of GPU data or 
> instructions, to be sent over to kernelspace IPC. the CPU will execute the 
> accelerated opcode (e.g atan2) directly and immediately.
>
> this is significantly simpler than standard GPUs, saving on power 
> consumption and drastically simplifying debugging and application developnent.
>
> if this is of interest please do get in touch, and feel free to ask questions.
>
> best,
>
> l.
>
> [1] your accountant, with assistance from Bob Goudriaans, an International 
> Tax Law Specialist and Director of NLNet, can help confirm that the 
> payments from NLNet are considered charitable tax deductible donations... 
> *to you*.  all the International Tax Agreements are in place and the 
> documents available for inspection by your accountant.
>
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev