PS3 Linux: Cell optimized graphics library
- Thread starter Shifty Geezer
- Start date
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.
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
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).
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).
ihamoitc2005
Veteran
No idea. The problem is that it's asking us to refer to the Wiki, but for my part, I can't find the Wiki!
Actually some of those other projects they ran look pretty cool as well.
were is the WIKI
has anyone found it yet?
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:
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 .
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 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.
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
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.