[atom]

Unfortunately, this post brings up the rest of the gui into question:

http://forum.xbmc.org/showpost.php?p=147...tcount=356

[speedway]

These guys rock the PS3-scene !!!
http://forums.ps2dev.org/viewtopic.php?t...sc&start=0

[atom]

That's some awesome work. Still doesn't meet the opengl requirement for XBMC...

[Bazzio]

man XBMC on PS3 would be amazing.
I know nothing of the processes, im just trying to read up on stuff. Ive been using XBMC for a while now and just got a PS3 and seems annoying going between the 2.
I started using TVersity for the ps3, but its not the same.

[dan_f14]

I too would love to see XBMC on the PS3. I am using tversity atm and it is no xbmc by any stretch of the imagination. I do not know too much about the workings of XBMC but from what I have read one of the reasons it has been such a big success is that the hardware being coded was a constant factor ie the xbox. I was therefore hoping that perhaps two linux versions could be produced, with one being based on the hardware settings of the ps3. I apologise in advance as my knowledge in this area is rather limited and I am unsure of whether it is possible/feasable. I just feel that if the idea has some merit and someone is willing then the ps3 could be the successor of the xbox for xbmc.

[FlappySocks]

one of the reasons it has been such a big success is that the hardware being coded was a constant factor ie the xbox.

Agree, plus the cost of the hardware. By the time you have built a capable set-top box PC, buying a chipped Xbox was a no briainer.

Now that PS3's have come down in price, it's in no-brainer territory again, when you consider what else your getting for the money.

[rodalpho]

Oh if it actually worked the PS3 would be absolutely ideal. Silent, low power, looks cool, and plays blu-ray disks-- you can't go wrong.

[ArtVandelae]

That's some awesome work. Still doesn't meet the opengl requirement for XBMC...

All of the required GPU functionality is now available on the PS3 but you would have to go through XBMC and convert the OpenGL calls to the rsx specific calls that the PS3 Linux acceleration uses. It probably wouldn't be much more difficult then adding the OpenGL and SDL render paths, but you would need someone who knows XBMC quite well and is willing to spend the necessary time to do the conversion.

The bigger problem is that right now getting Linux installed and configured with rsx access and Bluetooth support isn't really end-user friendly since it involves patching the kernel sources and/or compiling kernel modules. Before any serious homebrew use can get going some kind of easy solution is required. Some sort of minimal OS, Linux or otherwise, that boots quickly, has proper wireless controller support out of the box and features a graphical program launcher (maybe XBMC?) would be nice.

[vibe666]

ditto. Ubuntu is great and all (and my current OS of choice), but not what the PS3 needs to make the most out of XBMC.

a nice tight, fast linux install, just enough to be able to boot straight into XBMC (like the xbox version).

I'm actually surprised that more people aren't jumping on this, it looks like the perfect solution to give XBMC a new lease of life for the next 5 or 6 years (or 10 according to Sony, but then look at the PS1 & PS2 still going strong) that the PS3 could offer it.

HD video has well and truly landed at this stage and SD video is beginning to come to an end with terrestrial TV stations all starting to switch to digital HD content and streaming HD video and movies on disc moving to HDDVD & Blu-Ray.

let's see if we can't drum up some more interest in this.

[Gamester17]

I'm actually surprised that more people aren't jumping on this

lack of interest is not the problem; we said time and time again throughout this topic thread (and everywere else that the PS3 have been suggested) that the problem is XBMC requires OpenGL 2.0 support (or OpenGL 1.5 + OpenGL GLSL extension at the minimum) that features 24bpp or 32bpp for 3D hardware-acceleration support, which XBMC GUI need to run smoothly at an acceptable frame-rate. Without a device driver that enables hardware support you might get 1 or 2 frames-per-seconds displayed on the screen, ...try watching a movie at that rate, (a movie is made up of 24, 25 or 30 frames-per-seconds but your TV actually refreshes the screen even more often than that, more like 60 frames-per-seconds).

Again, it is not the CPU (Central Processor Unit) that is the problem in the PS3 but the lack of direct access and proper OpenGL device drivers under Linux.

None of Team-XBMC developers have the low-level skills required to make such OpenGL device drivers themselves, thus will have to wait and see if someone else produces them for Linux on the PS3.

[vibe666]

None of Team-XBMC developers have the low-level skills required to make such OpenGL device drivers themselves, thus will have to wait and see if someone else produces them for Linux on the PS3.

ah well, here's hoping.

even if it were possible to get it up to the speed of the old xbox running xbmc that would be quite something. I'd finally be able to retire my faithful old xbox and have one less box under the telly.

i know we expect the world of you guys and you get little thanks for it (thanks btw ) but it just feels (to the less techy of us) that it is so close to being possible. so close yet so far it would seem.

[wHack]

Actually you don't need Opengl and having an Opengl abstraction layer would be a resource waste. You don't need nearly all of the Opengl functionality. Only specific parts alot of which would probably be easily converted over to the rsx specific calls that these guys are using. Like scaling and alphablended overlays, and the other normar gui stuff. Some of which would require more work for instance de-interlacing. And colorspace conversion but these guys have already talked about including some colorspace conversion and mentioned it's not to dificult to code. It seems to me that if you guys aquired a few devs who understood how to write stuff at this lower level the conversion would be quite possible and much cleaner and more efficient than using a full featured OpenGL layer. However if you don't have those dev's it's probably a very very tricky task. But as it is they seem to have alot of the functionality you want from OpenGL already in place.

I could be wrong about this though as I don't know either XBMC's code nor their code very well but it just seems this way from what I've read of both.

[wHack]

Now that I think about it though I'm sure if the XBMC linux dev's had the time they could get pretty much all the info they needed from IronPeter and Glaurung as well as more specific support in the ps3 rsx driver code for some of the features XBMC needs. That might make it a little easier.

Just a thought.

[wHack]

On one last note waiting for someone to write full OpenGL for ps3 linux will likely take quite some time as IronPeter and Glaurung have no intention of even trying to do it. This is because they have largely based their code off of nouveau who is just barely scratching the surface of OpenGL, and who also aren't to concerned with it at the moment. /largely because it's a huge undertaking with a massive amount of work to be done, and they know that on the ps3 front alot of it can be achieved more clealy with direct calls. The whole point of OpenGL being to utilize one instruction set for various hardware platforms, and the ps3 being a very specific individual platform. The only reason to port OpenGL to ps3 rsx would be to simplify the porting of existing OpenGL apps for people who don't want to learn the direct calls. And their goal being to enable custom ps3 development optimized for the platform. The two goals jus don't meet. OpenGL is too much work for a non-optimal solution. Thus noone is even attempting to bring OpenGL to the ps3. I'm sure someone will try at some point but it's a long way off as the curent development is focused on the direct approach. It also seems this would be the best approach for XBMC if the devs where to make the move to ps3. Which I can only hope and pray they will decide to do.

[Gamester17]

It seems to me that if you guys aquired a few devs who understood how to write stuff at this lower level the conversion would be quite possible and much cleaner and more efficient than using a full featured OpenGL layer.

Again, we do not have any programmers with such skills, and simply aquiring a few developers with such skills is not a simple as you might think, (I refer to the fact that when we announced the Team-XBMC was looking for Linux developers and that news even got slashdottet we still only gained one new developer since then, from the very beginming of the Linux port project). You have to remember that all developers (and all other members) of Team-XBMC are unpaid volunteers who only work on XBMC in their spare time as a hobby for fun, and they only spend time on features/functions that interest them personally, ...they do not work on XBMC for you, the end-users of XBMC, they work on XBMC for themselves.

You and I can not force anyone on Team-XBMC to work on something, all we can do as non-programmers is try to lobby good ideas and hope that someone with the skills required find those ideas interesting enough for them to take a personal interest.

As for the technical side of the PS3 and the RSX (PS3 GPU); I suppose you are right that XBMC do not need full OpenGL support, what is 'only' really needed is for RSX hardware accelerestion via libSDL (SDL = Simple DirectMedia Layer) for all the things you mentioned like YUV to RGB colorspace conversion, scaling, alphablended overlays, deinterlacing, and non-power of two textures for the GUI (using NPOT saves a lot of texture memory) ...all of which could probably be achived via direct calls to the RSX from libSDL. So XBMC request what it needs from libSDL and libSDL and how libSDL provides that XBMC do not care, ...but again, I do not think that the Team-XBMC developers have the necessary low-level skills to add RSX support to libSDL, that someone else would have to do.

Feel free to try to lobby support RSX support for libSDL from third-party developers elseware