Virtual GPU project

ps2devman · Post by **ps2devman** » Wed Jul 18, 2007 6:24 pm

With the recent potential threats coming from Sony, it may become risky to find and publish an exploit that would allow full access to RSX... Sadly.

But when I read that PS3 offers no hardware acceleration for homebrew, it's not really true... We have, legally, officially, the full screen BitBlt command.

There are 2 main methods when you are using a GPU :
a) Direct rendering into one of the final frame buffers ("front buffer")
- clear final frame buffer
- draw in it
- swap frame buffers address with vblank synchronization
b) Rendering into a "back buffer"
- clear back buffer
- draw in it
- either bitblt or render as an antialiased texture the back buffer into the front buffer

So we can stick to b) (even if no antialiasing can be done instead of bitblt)
The remaining task is to actually draw in the back buffer (that we call the frame buffer at the moment in ps3 related sources).

I think it's possible to use a few SPU's to recreate a virtual GPU, with its pipelines. You fill in vertices list to a SPU that acts like the part of a GPU that runs a vertex shader, and this one fills in data into another SPU that may act like the part of a GPU that runs a pixel shader.

This virtual GPU will be of course less powerful than RSX, but should be good enough for porting last gen homebrew and emulators.

Bad thing is you have to master fully SPU programming. Will take time...

rapso · Post by **rapso** » Wed Jul 18, 2007 6:40 pm

you could write a PPU version first keeping in mind that it will be ported to the SPUs and at first port it to just one SPU.

I think a deffered shading/rendering would be best, because "emulating" pixelshaders/fragmentprogramms would be kinda difficult. having it in two passes, first move the texturedata into framebuffers, and then call a shading programm, could not only be faster (due to saving of mathpower for overwritten pixels), but easier as well, as you could load custom (simple) shading-spu-jobs to handle the whole shading the way you want.

I think the most important thing would be to use a well known interface, like openGL (ES), nodoby disagrees on that I guess? :)

jimparis · Post by **jimparis** » Thu Jul 19, 2007 1:59 am

Regarding RSX, nobody has shown that our access from Linux is actually restricted. There are a number of lv1_gpu calls provided by the hypervisor that aren't being used at the moment. What's holding us back more is a lack of documentation, combined with a lack of anything that we could reverse engineer to figure things out ourselves.

Regarding a SPU-based rasterizer, Sauce has been working on one for months now. http://window.terratron.com/ps3linux/rasterizer

StrontiumDog · Post by **StrontiumDog** » Thu Jul 19, 2007 9:52 am

ps2devman wrote:With the recent potential threats coming from Sony, it may become risky to find and publish an exploit that would allow full access to RSX... Sadly.

Can you be specific about what recent threats?

ps2devman · Post by **ps2devman** » Thu Jul 19, 2007 5:40 pm

Dark Alex's last words :

I’ve decided to cease OE development, and leave PSP scene.
The reasons are various.
One of them is the time it consumes, which i’m losing from other things.
The other is related to my security. I didn’t like Sony menaces to PS3 hackers.
I think it is better to leave now rather than end paying the consequences.

(menaces = threats)

Sony may sue again and again (even if there is no chance to win in some countries). The longer you play with a lawyer (even if you win each time), the more money you pay and the more money he receives...
It's like in "War games". In order to win, don't play...

StrontiumDog · Post by **StrontiumDog** » Thu Jul 19, 2007 10:43 pm

Oh, is that all.

There is another way to win. Play somewhere that has NO laws.

Thats my choice.

To sue someone you have to be at least able to point to an ACT of law that is alleged to be transgressed. Where I live, No Copyright Law, No Patent Law and No Trademark law. Of any sort, so, I don't see how anyone in my country could get sued by Sony.

I actually feel sorry for the rest of you stuck in less progressive countries with oppressive regimes that do not protect the freedoms of their people.

:)

jimparis · Post by **jimparis** » Fri Jul 20, 2007 12:50 am

StrontiumDog wrote:Where I live, No Copyright Law, No Patent Law and No Trademark law. Of any sort, so, I don't see how anyone in my country could get sued by Sony.

Easy, they just sue you in a real country, and then arrest you as soon as you step foot in one.

Anyway, keep the illegal stuff far away from these forums and everyone here will be happy.

rapso · Post by **rapso** » Fri Jul 20, 2007 1:34 am

and maybe we could go on talking about that VGPU :)

ps2devman · Post by **ps2devman** » Fri Jul 20, 2007 2:05 am

The DirectX8 shader pseudo code is friendly I think.
There should be a way to upload SPU programs built dynamically from the reading of these pseudo codes. And to produce them we can stick to cgc.exe (Cg), psa.exe and vsa.exe (shaders assembler, in v1.1 mode).
We can re-use the parsers of pcode2mcode function from pbKit source.

StrontiumDog · Post by **StrontiumDog** » Fri Jul 20, 2007 7:07 am

Wouldn't it be more efficient just to code the shaders in SPU assembler and/or C and just define a shader dynamic loader and shader standard interface (basically a dynamic SPU shader plugin, loaded and unloaded on the fly), and able to run multiple shaders across multiple SPU's.

The work then is defining this interface, handling the load/unload. Rather than implementing a "interpreter" for a non native shader asm.

The advantage with this method, is if you really wanted to execute native nvidia shader asm, you could write a SPU shader using the above model that did that. But if you wanted raw speed, just write it in asm and/or c.

For example, it would be neat to be able to go:

VGPU_SPUAssign(x); Where x is the number of SPU's the VGPU can use (minimum 1). Then an app can say, hey I only need 1 SPU, so VGPU, you can use 5 of them, and the VGPU gets faster accordingly. But an app with a heacy SPU requirement could just init the VGPU with 1 SPU available, which would be a lot slower, but enough for the app in question.

????

ps2devman · Post by **ps2devman** » Fri Jul 20, 2007 4:01 pm

Sure. Good idea.

Final goal is to expand the homebrewers family. The less complex programming tools are used, the more people will join us.

Cg is the kind of tool you can use to write things in a simple way with a high level language and which is able to produce very well optimized, short, simple pseudo mnemonics. I really enjoyed it on xb1 with pbKit.

rapso · Post by **rapso** » Fri Jul 20, 2007 5:27 pm

the ps 1.1 to 1.4 assembler code is really sick ;) and not compatible to VS 1.1 . using SM3 would make the converter from VS and PS assembler to SPU-assembler the same (not a separate one for PS and VS).

btw. I'm still for a seperate shading pass;), this would make a better use of the SPUs, e.g you can output more than one sample per shader.

ps2devman · Post by **ps2devman** » Sat Jul 21, 2007 1:24 am

Please teach me more about that "SM3"... I don't know it.

Edit: Nevermind... Shader Model 3.0 I guess...

Jaapio · Post by **Jaapio** » Wed Aug 01, 2007 9:53 pm

If I could help with making a vgpu, I would do so. But since I don't even have an idea on where to start I say.
My best bet to get some 3D graphics out of the ps3 would be... software renderring?

ragnarok2040 · Post by **ragnarok2040** » Wed Aug 01, 2007 10:21 pm

I don't own a ps3, but what about using a glide wrapper for a start. The only open source glide wrapper I know of is hacktarux's modified one posted on the emutalk boards.
http://emutalk.net/showthread.php?t=37658

The glide functions could be rewritten to use the SPUs or do what was posted above but I'm not sure if it's low-level enough to actually simulate a gpu though..

Jaapio · Post by **Jaapio** » Thu Aug 02, 2007 1:46 am

But doesn't it use openGL and there is no openGL(for now) on the ps3...

ragnarok2040 · Post by **ragnarok2040** » Fri Aug 03, 2007 4:38 pm

Yeah, now that I think on it, it's not low level enough to use as a base for a virtual gpu. Maybe you can use nouveau's source code and port it.

IronPeter · Post by **IronPeter** » Mon Aug 06, 2007 12:50 am

I've created snv repo http://spu-cell-rasterizer.googlecode.com/svn/trunk/

The repo contains some triangle rasterization SPU code.

ps2devman · Post by **ps2devman** » Mon Aug 06, 2007 12:56 am

Nice! Thanks a lot!

ldesnogu · Post by **ldesnogu** » Thu Aug 09, 2007 1:53 am

Rather than reinventing the wheel, take a look at this:

http://www.nabble.com/Mesa-on-Cell-plan-t4202805.html

And Mesa has an MIT license. So rather than starting from scratch why not help them?

ps2devman · Post by **ps2devman** » Fri Aug 10, 2007 4:58 pm

Nah... Mesa is still too high level for me.
Dunno when but I will just post a low level VGPU some day.
But it will be probably shaders model 1.1, involving Cg compiler, and compatible with ps3link (because it's the method I know and like the best, and xb1-ports-friendly).

Everyone is invited to create a VGPU, in team or alone!
(I'm sure, after 1 year or 2, we will be flooded with VGPU solutions!)

ldesnogu · Post by **ldesnogu** » Sat Aug 11, 2007 12:12 am

ps2devman wrote:Nah... Mesa is still too high level for me.
Dunno when but I will just post a low level VGPU some day.
But it will be probably shaders model 1.1, involving Cg compiler, and compatible with ps3link (because it's the method I know and like the best, and xb1-ports-friendly).

Everyone is invited to create a VGPU, in team or alone!
(I'm sure, after 1 year or 2, we will be flooded with VGPU solutions!)

Yes for sure, being low level is fun. But if you can get something "higher" level in a shorter amount of time why not use it?

And I don't see how you can say MESA is too high level while considering shaders and cg :)

Unless you definitely are after a kind of simulation of low level GPU mechanisms. In that case the Cell is the wrong target, it is too high level and doesn't have enough parallelism.

vi_vid · Post by **vi_vid** » Sat Aug 11, 2007 12:49 am

ps2devman wrote:But it will be probably shaders model 1.1, involving Cg compiler.

Why restrict yourself to sm1.1? FP32 is fast on SPU.
Also, existing APIs are not very good for software renderer.
GPU-like pipeline is nice for CELL though.

(I'm sure, after 1 year or 2, we will be flooded with VGPU solutions!)

I'll try to show my renderer within a month or two =)

ps2devman · Post by **ps2devman** » Sat Aug 11, 2007 5:19 am

I restrict myself because I've got a new job that is eating 6 out of 7 days a week... I won't have enough free time to learn new things... So I will try to help porting xb1 stuff, but I won't promise more. I will try to feed SPU's with code just if it was data (like Insomniacs suggest). So I will mainly code translators functions.

forums.ps2dev.org

Virtual GPU project

Virtual GPU project

Re: Virtual GPU project

cell-spu-rasterizer project