forums.ps2dev.org

[ps2devman]

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]

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]

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]

[ps2devman]

Dark Alex's last words :

[StrontiumDog]

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]

[rapso]

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

[ps2devman]

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]

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]

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]

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]

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

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

[Jaapio]

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]

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]

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

[ragnarok2040]

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]

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

The repo contains some triangle rasterization SPU code.

[ps2devman]

Nice! Thanks a lot!

[ldesnogu]

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?
_________________
Laurent

[ps2devman]

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]

[vi_vid]

[ps2devman]

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.