PS3 Linux: Cell optimized graphics library

Todd33

Veteran
Banned
I don't think there is any port of the VTK code itself, but if you use the ported MESA for the opengl then the VTK render window, which is opengl, should be much faster than a regular CPU. I have a little app that uses the software based vtkVolumeRayCastMapper class for 3D volume rendering. It would interesting to build it on the PS3 and see how fsat it is compared to my dual Xeon at work.
 

zed

Legend
I'm not familiar with Mesa, but is it anything like OGRE?
no orge is a rendering engine i believe
mesa is a 100% software opengl implementation
ie (under windows) it replaces opengl32.dll thus all gl calls get done with the mesa opengl.
normally when u make gl calls they go from opengl32.dll -> (the card markers dll) eg with nvidia its nvoglnt.dll (which does the drawing)
(there was hardware support in the old days on voodoo cards IIRC) more info at www.mesa3d.org
 

patsu

Legend
I emailed Terrasoft to request for more info about the optimized Mesa run-time. Also gave them the URL to this thread. Hopefully we will see some response from them.

Meanwhile (not sure if it has been posted before) I also found this:
http://forums.ps2dev.org/viewtopic.php?t=7209
The hardworking members at ps2dev created some simple example based on the vsync sample source code in Cell SDK 1.1 (I think).
 

patsu

Legend
Kai replied via Email. Apparently, the optimized Mesa library is available in the HPC Consortium wiki (opened to members only). They are in the process of doing a public interface for the wiki. Once that's done, we should be able to get our little hands on the new Mesa library.
 
720p

( i didnt view the video )
80x, no way. sure the cells fast (esp at stuff like this) but 80x

4 days does sound way to quick ( after all its meant to be difficult to get best performance out of cell, or so we've been told )
the intel x86 version has been around for years (constantly updated) so of the two, i assume the cell is gonna be the one that is not gonna be running at its peak power ( looking good for the future ).

with mesa the major slowdown are per fragment operations, thus a 80x speedup on these would be absolutely awesome, sounds to good to be true though, wheres the catch.
ive tried a lot a lot of stuff (mine + other ppls) in mesa over the years.
now if what is purported is correct, ild say thats enuf to run doom3 at 480p @ 60fps . purely in software!!

Or 720P at 26fps no? But how many SPE do they use for this and how much is AA?
 

popper

Newcomer
I guess past a certain point the framerate is bound by another part of the pipeline?

Interesting work, and definitely worth pursuing in the absence of RSX access. Does this project have a site somewhere? Is it an ongoing concern?

Also, using Rapidmind to port video decoding for various formats could be interesting. Lots of people are crying out for a Cell-optimised port of something like ffmpeg or whatever, and maybe Rapidmind could make that easier.


well Lu_Zero has done LOTS of PPC, Altivec and SPU work for everyones use, perhaps people should go and help him in his good work and we might get somewere far faster...
http://planet.gentoo.org/developers/lu_zero

http://search.virginmedia.com/results/?channel=homepage&q=Lu_zero+altivec&cr=
http://search.virginmedia.com/results/index.php?channel=other&q=Lu_zero+spu&cr=

http://forums.ps2dev.org/viewtopic.php?t=7180&sid=0a2e4129305935f0705e4790832e29a6
 
Last edited by a moderator:

popper

Newcomer
Kai replied via Email. Apparently, the optimized Mesa library is available in the HPC Consortium wiki (opened to members only). They are in the process of doing a public interface for the wiki. Once that's done, we should be able to get our little hands on the new Mesa library.

no sign of it appearing yet then patsu, i wonder if the source is there too,we might even get a working SDL svn like https://ssl.keshi.org/projects/ps3/trac.fcgi/browser/SDL/trunk Keshi started but never did anything else .
 

Titanio

Legend
I managed to get some more info out of Terrasoft on this. It looks like some of our assumptions were off-base..

First off, most importantly, the relative performance figures (7x the framerate, 80x the fragment rate) are comparing performance of their technique implemented with Rapidmind versus without Rapidmind. The idea of the project was to implement a system that takes OpenGL fragment shaders and turns the interpreter for them into a compiler that compiles them into SPE code, and offloads that code to the SPEs. They implemented it with and without Rapidmind, and the relative performance figures shown are comparing those implementations - not MESA's speed before and after. The figures by no means reflect the performance you would get in the general case going to this new version of MESA, not by a long shot. It wouldn't accelerate something like Q3 on the system since it's just addressing fragment shaders (which Q3 doesn't use)..and for apps using fragment shaders it would just make them go from being really really really slow to really really slow :p Their system also doesn't yet allow all operations in the fragment shaders, there are still some holes to be filled. In absolute terms it's all still quite slow apparently, they still have a lot of work to do to make this part run well, and comprehensively.

The guys working on this at the hack-a-thon haven't had a chance to get back into it since then either, so it's hard to tell if it's an on-going concern on their part or not. But it is something they think would require a lot more work if it were to be a generally accelerated version of MESA.
 

one

Unruly Member
Veteran
As long as Rapidmind is proprietary, it's not very likely MESA optimized for it appear in the open source world...
 
Top