## Other
* The deadline is about 12-18 months.
-* It is highly recommended to use Gallium3D for the software stack.
+* It is highly recommended to use Gallium3D for the software stack
+ (see below if deciding whether to use Nyuzi or RISC-V or other)
* Software must be licensed under LGPLv2+ or BSD/MIT.
* Hardware (RTL) must be licensed under BSD or MIT with no
"NON-COMMERCIAL" CLAUSES.
----
-my feeling on this is therefore that the following approach is one
-which involve minimal work:
-
-* investigate the ChiselGPU code to see if it can be leveraged (an
-"image" added instead of straight ARGB colour)
-* OR... add sufficient fixed-function 3D instructions (plus a memory
-scratch area) to RISC-V to do the equivalent job
-* implement the Simple-V RISC-V "parallelism" extension (which can
-parallelise xBitManip *and* the above-suggested 3D fixed-function
-instructions)
-* wait for RISC-V LLVM to have vectorisation support added to it
-* MODIFY the resultant RISC-V LLVM code so that it supports Simple-V
-* grab the gallium3d-llvm source code and hit the "compile" button
-* grab the *standard* mesa3d library, tell it to use the
-gallium3d-llvm library and hit the "compile" button
+My feeling on this is therefore that the following approach is one which involve minimal work:
+
+* Investigate the ChiselGPU code to see if it can be leveraged (an "image" added instead of straight ARGB color).
+* OR... add sufficient fixed-function 3D instructions (plus a memory scratch area) to RISC-V to do the equivalent job.
+* Implement the Simple-V RISC-V "parallelism" extension (which can parallelize xBitManip *and* the above-suggested 3D fixed-function instructions).
+* Wait for RISC-V LLVM to have vectorization support added to it.
+* MODIFY the resultant RISC-V LLVM code so that it supports Simple-V.
+* Grab the gallium3d-llvm source code and hit the "compile" button.
+* Grab the *standard* Mesa3D library, tell it to use the gallium3d-llvm library and hit the "compile" button.
* see what happens.
-now, interestingly, if spike is thrown into the mix there (as a
-cycle-accurate RISC-V simulator) it should be perfectly well possible
-to get an idea of where performance of the above would need
-optimisation, just like jeff did with the nyuzi paper. he focussed on
-specific algorithms and checked the assembly code, and worked out how
-many instruction cycles per pixel were needed, which is an invaluable
-measure.
-
-as i mention in the above page, one of the problems with doing a
-completely separate engine (Nyuzi is actually a general-purpose
-RISC-based vector processor) is that when it comes to using it, you
-need to transfer all the "state" data structures from the main core
-over to the GPU's core.
-
-... but if the main core is RISC-V *and the GPU is RISC-V as well* and
-they are SMP cores then transferring the state is a simple matter of
-doing a context-switch... or if *all* cores have vector and 3D
-instruction extensions, a context-switch is not needed at all.
-
-will that approach work? honestly i have absolutely no idea, but it
-would be a fascinating and extremely ambitious research project.
-
-can we get people to fund it? yeah i do. there's a lot of buzz about
-RISC-V, and a lot of buzz can be created about a libre 3D GPU. if
-that same GPU happens to be good at doing crypto-currency mining there
-will be a LOT more attention paid, particularly given that people have
-noticed that relying on proprietary GPUs and CPUs to manage billions
-of dollars worth of crypto-currency, when the NSA is *known* to have
-blackmailed intel into putting a spying back-door co-processor in to
-x86, and that it miiight not be a good idea to trust proprietary
-hardware libreboot.org/faq#intelme
+Now, interestingly, if spike is thrown into the mix there (as a cycle-accurate RISC-V simulator) it should be perfectly well possible to get an idea of where performance of the above would need optimization, just like Jeff did with the Nyuzi paper.
+
+He focussed on specific algorithms and checked the assembly code, and worked out how many instruction cycles per pixel were needed, which is an invaluable measure.
+
+As I mention in the above page, one of the problems with doing a completely separate engine (Nyuzi is actually a general-purpose RISC-based vector processor) is that when it comes to using it, you need to transfer all the "state" data structures from the main core over to the GPU's core.
+
+... But if the main core is RISC-V *and the GPU is RISC-V as well* and they are SMP cores then transferring the state is a simple matter of doing a context-switch... or if *all* cores have vector and 3D instruction extensions, a context-switch is not needed at all.
+
+Will that approach work? Honestly I have absolutely no idea, but it would be a fascinating and extremely ambitious research project.
+
+Can we get people to fund it? Yeah I do. there's a lot of buzz about RISC-V, and a lot of buzz can be created about a libre 3D GPU. If that same GPU happens to be good at doing crypto-currency mining there will be a LOT more attention paid, particularly given that people have noticed that relying on proprietary GPUs and CPUs to manage billions of dollars worth of crypto-currency, when the NSA is *known* to have blackmailed intel into putting a spying back-door co-processor in to x86, and that it miiight not be a good idea to trust proprietary hardware:
+
+<http://libreboot.org/faq#intelme>
## Q & A
That would be fantastic as it would demonstrate not only competence but also commitment. And will have taken out the "risk" of being "unknown", entirely. So that works perfectly for me :) .
> Q:
+>
> Is there any guarantee that there would be a sponsorship for the GPU?
A:
projects / libreriscv.git / blobdiff