From 61feebfdbd5c25a6907e2fdfba2a9b58adc947ae Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Wed, 27 Jun 2018 12:30:53 +0100 Subject: [PATCH] add mention of simple-v --- shakti/m_class/libre_3d_gpu.mdwn | 42 ++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/shakti/m_class/libre_3d_gpu.mdwn b/shakti/m_class/libre_3d_gpu.mdwn index 1d22554d4..432c74b71 100644 --- a/shakti/m_class/libre_3d_gpu.mdwn +++ b/shakti/m_class/libre_3d_gpu.mdwn @@ -115,3 +115,45 @@ but also committment. and will have taken out the "risk" of being works perfectly for me :) +## Design decisions and considerations + +whilst Nyuzi has a big advantage in that it has simuations and also a +llvm port and so on, if utilised for this particular RISC-V chip it would +mean needing to write a "memory shim" between the general-purpose Nyuzi +core and the main processor, i.e. all the shader info, state etc. needs +synchronisation hardware (and software). + +that could significantly complicate design, especially of software. + +whilst i *recommended* Gallium3D there is actually another possible +approach: a RISC-V multi-core design which accelerates *software* +rendering... including potentially utilising the fact that gallium3d +has a *software* (LLVM) renderer: + + + +the general aim of this approach is *not* to have the complexity of +transferring significant amounts of data structures to and from disparate +cores (one Nyuzi, one RISC-V) but to STAY WITHIN THE RISC-V ARCHITECTURE +and simply compile mesa3d (for RISC-V), gallium3d-llvm (for RISC-V). + +so if considering to base the design on RISC-V, that means turning RISC-V +into a vector processor.  now, whilst hwacha has been located (finally), +it's a design that is specifically targetted at supercomputers.  i have +been taking an alternative approach to vectorisation which is more about +*parallelisation* than it is about *vectorisation*. + +it would be great for Simple-V to be given consideration for +implementation as the abstraction "API" of Simple-V would greatly simplify +the addition process of Custom features such as fixed-function pixel +conversion and rasterisation instructions (if those are chosen to be +added) and so on.  bear in mind that a high-speed clock rate is NOT a +good idea for GPUs (power being a square law), multi-core parallelism +and longer SIMD/vectors are much better to consider, instead. + +the PDF / slides on Simple-V is here: + + +and the assessment, design and implementation is being done here: + + -- 2.30.2