Kodi Community Forum
Port XBMC to PS3 (PlayStation 3) to run on Linux ("Other OS") or natively on GameOS? - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: Port XBMC to PS3 (PlayStation 3) to run on Linux ("Other OS") or natively on GameOS? (/showthread.php?tid=21849)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38


- rodalpho - 2008-01-25

Yep. It's a shame, because 99% of these projects fail miserably when they realize how much work they've taken on. Their time would be much better spent porting XBMC to their platform of choice.


- d4rk - 2008-01-25

dizzey Wrote:...no one seems intrested in writing a non opengl backend for xbmc wich relies on the gpu library for the ps3...

libps3rsx (if that's what you're referring to) doesn't even work on firmware 2.10. Moreover, even if it did, its API is anything but finished. Committing to a pre-pre-alpha incomplete API isn't very wise since it will result in a rewrite down the road.


- trojanfoe - 2008-02-04

midgetspy Wrote:...

Unfortunately 99% of HD content is encoded in .mkv files, which the PS3 can't stream. So the streaming capabilities of the PS3 are 100% useless to me

...

If you're talking about H.264/AC3 then you have to remux (note: not re-encode) the .mkv files into a .m2ts or .vob file and then they play fine via local media or media server. See doom9.org.


- rodalpho - 2008-02-04

Yes, but that sucks. Running tversity sucks. What we really want is a simple streaming SMB mount and a player that plays everything.

Like XBMC!


Mesa3D to support Cell SPU - Gamester17 - 2008-02-05

It looks to me like things with the PS3 Cell SPU for graphics are progressing

https://sourceforge.net/mailarchive/forum.php?thread_name=47A15004.9060101%40us.ibm.com&forum_name=mesa3d-dev
Quote:[Mesa3d-dev] Shader VM on Cell SPU

I just finished pushing a ton of commits that get the shader VM running
on the Cell's SPUs. Right now it is only used for vertex
processing...and gears runs! Smile Since various other folks are busy
making changes to the fragment processing side of things, I don't intend
to implement fragment shaders.

My next Cell related work items are:

1. Implement a software cache for non-tile data. The way that uniforms,
attributes, and program instructions are currently fetched from main
memory is not good. A caching / prefetching mechanism would do wonders
for its performance.

Look at the existing fragment code, it seems like we should enhance the
tile cache to "microtile" as well. That is, rearrange the data on
upload / download so that the SPUs can access 2x2 quads linearly within
a tile. That would *greatly* simplify all the code that operates
directly on the framebuffer.

2. Implement a real-time assembler for the SPUs.

3. Start dynamically generating code for the post-fragment processing
part of the pipeline.

At some point someone needs to take a look at the SPU support in LLVM.
I know that some code was committed, but there was a long list of
caveats. It would be nice to know if the existing support there will
suit our needs. If not, it should be pretty easy to convert the VM
opcodes directly to SPU code. The SPUs have enough registers that we
wouldn't even need a register allocator!



LLVM to assit in porting software to Cell PPC (PowePC) processor architecture? - Gamester17 - 2008-02-05

By the way, could LLVM be used in anyway to speed the porting on XBMC to run on the Cell PPC (PowePC) processor architecture?
http://llvm.org
http://en.wikipedia.org/wiki/LLVM

The readon I ask is that I read this:
http://article.gmane.org/gmane.comp.compilers.llvm.devel/9841
Quote:From: Scott Michel <scottm <at> aero.org>
Subject: Cell SPU backend status
Newsgroups: gmane.comp.compilers.llvm.devel
Date: 2007-11-26 21:45:36 GMT (10 weeks, 12 hours and 20 minutes ago)

It's official: Aerospace has given me permission to release the code,
such as it is. I will be checking in pieces as I fix 80-col
violations and performing general cleanups.

PLEASE NOTE: I intended to check the code into the LLVM SVN
repository when the backend could generate a clean compile of llvm-
gcc-4.2, but due to a bug, I'm going to have to check in __broken__
code.

That said, some caveats:

- I know the code can be cleaned up.
- I know the code isn't complete. Things that need work:
- Branches, branch prediction instructions
- Double FP
- Intrinsics
- Test cases need fixing (will be checking those in incrementally)

OTOH, it's a start of something that will be a benefit to the LLVM
community-at-large.

-scooter
and this:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2006-August/006492.html
Quote:For those who are interested, Apple announced that they are using the LLVM
optimizer and JIT within their Mac OS 10.5 'Leopard' OpenGL stack (which
was distributed in beta form to WWDC attendees).

LLVM is used in two different ways, at runtime:

1. Runtime code specialization within the fixed-function vertex-processing
pipeline. Basically, the OpenGL pipeline has many parameters (is fog
enabled? do vertices have texture info? etc) which rarely change:
executing the fully branchy code swamps the branch predictors and
performs poorly. To solve this, the code is precompiled to LLVM .bc
form, from which specializations of the code are made, optimized,
and JIT compiled as they are needed at runtime.

2. OpenGL vertex shaders are small programs written using a family of
programming langauges with highly domain-specific features (e.g. dot
product, texture lookup, etc). At runtime, the OpenGL stack translates
vertex programs into LLVM form, runs LLVM optimizer passes and then JIT
compiles the code.

Both of these approaches make heavy use of manually vectorized code using
SSE/Altivec intrinsics, and they use the LLVM x86-32/x86-64/ppc/ppc64
targets. LLVM replaces existing special purpose JIT compilers built by
the OpenGL team.

LLVM is currently used when hardware support is disabled or when the
current hardware does not support a feature requested by the user app.
This happens most often on low-end graphics chips (e.g. integrated
graphics), but can happen even with the high-end graphics when advanced
capabilities are used.

Like any good compiler, the only impact that LLVM has on the OpenGL stack
is better performance (there are no user-visible knobs). However, if you
sample a program using shark, you will occasionally see LLVM methods in
the stack traces.



- Soulfly - 2008-02-11

Neil Wrote:Why is there such a large hoard of PS3 fans demanding an XBMC port when the PS3 is already a streaming media player? It plays at east DivX and h.264. Is it missing some crititally important codecs? Is the ui very crubmsy? Or is it more about gamers who already have a console and don't want to spend any money on another device.

Because XBMC is a much better program than the PS3 MP and because it's much harder to ask Sony for odd features than it is to write a Python script.


Gallium3D open source device driver and interface - Gamester17 - 2008-02-20

http://www.tungstengraphics.com/wiki/index.php/Gallium3D
Quote:Cell Driver

Tungsten Graphics is developing a Gallium driver for the IBM Cell processor (as found in the PS3) in conjunction with Lawrence Berkeley National Lab. Initially, the objective is to implement only basic OpenGL triangle rendering with texture mapping. The second phase of the project will produce a full-featured driver.

Status (as of January, 2008): The Cell driver is actively being developed. Some basic Mesa tests such as 'gears' are running.


Quick technical overview about the Gallium3D interface itself
http://www.tungstengraphics.com/wiki/index.php/Gallium3D
Quote:Gallium3D Technical Overview

Gallium3D is Tungsten Graphics' new architecture for building 3D graphics drivers. Initially supporting Mesa and Linux graphics drivers, Gallium3D is designed to allow portability to all major operating systems and graphics interfaces.

Compared to existing Linux graphics drivers, Gallium3D will:
  • Make drivers smaller and simpler.
    Current DRI drivers are rather complicated. They're large, contain duplicated code and are burdened with implementing many concepts tightly tied to the OpenGL 1.x/2.x API.
  • Model modern graphics hardware.
    The new driver architecture is an abstraction of modern graphics hardware, rather than an OpenGL->hardware translator. The new driver interface will assume the presence of programmable vertex/fragment shaders and flexible memory objects.
  • Support multiple graphics APIs.
    The OpenGL 3.0 API will be very different from OpenGL 1.x/2.x. We'd like a driver model that is API-neutral so that it's not tied to a specific graphics API.


The Gallium3D Interface
The public interface of a Gallium3D driver is described by the p_context.h header file. The pipe_context structure is an abstract base class with methods for:
  • Setting rendering state (texture sampler state, vertex array info, drawing surfaces, etc.)
  • Setting shader state, using the TGSI binary shader representation.
  • Vertex array and indexed vertex array drawing.
  • Region (memory) management for textures, renderbuffers, vertex buffers, etc.
  • Hardware queries (number of texture units, max texture size, etc).

The p_state.h header defines all the state objects (such as polygon rasterization options, blend modes, etc) and resources (drawing surfaces, textures, memory buffers). The pipe interface uses "constant state" objects. That is, state objects are created once and are immutable. State objects are put into effect by binding them. This allows Gallium3D drivers to create corresponding hardware state objects which can be quickly handled.

The p_defines.h header defines numerous constants and tokens (blend modes, texture wrap modes, surface formats, etc.

The p_winsys.h header defines the window system and OS facilities which Gallium3D drivers rely upon. For example, memory allocation is typically a service the OS provides while window size/position information is provided by the window system. Pipe drivers use the winsys interface to handle these things.

By abstracting OS and window system services, pipe drivers are portable to other platforms (e.g. embedded devices).


  • The State Tracker
    The state tracker is the piece which interfaces core Mesa to the Gallium3D interface. It's responsible for translating Mesa state (blend modes, texture state, etc) and drawing commands (like glDrawArrays and glDrawPixels) into pipe objects and operations.

    Traditional fixed-function OpenGL components (such as lighting and texture combining) are implemented with shaders. OpenGL commands such as glDrawPixels are translated into textured quadrilateral rendering. Basically, any rendering operation that isn't directly supported by modern graphics hardware is translated into a hardware-friendly form.

    Future state trackers will be created for OpenGL 3.0 and OpenGL-ES 2.x


  • Softpipe Driver
    The softpipe driver is a software implementation of the Gallium3D interface. It will be used as a reference implementation and as a fallback driver when a hardware driver isn't available. The softpipe driver will make extensive use of run-time code generation to efficiently execute vertex, fragment and rasterization operations.

    Status (as of January, 2008): The softpipe driver is nearly feature complete and runs most OpenGL programs. There is limited support for SSE and LLVM code generation, but that's still under development.

  • Simple i915 Driver
    The i915 Gallium3D Driver is an initial hardware driver implementation within the Gallium3D driver architecture. We expect that once complete this driver will have equivalent functionality and performance to the current Mesa i915tex driver, but from a much smaller codebase.

    Status (as of January, 2008): The i965 driver is under construction. The i915 driver runs most OpenGL programs, though there's still loose ends.

  • Failover Module
    The failover module acts as a selector between a hardware driver and the softpipe driver. When the hardware can't implement a particular rendering operation, the failover module will pass the request to the softpipe driver. This is a different solution to the "software fallbacks" scheme of previous Mesa drivers.

  • Ancillary Modules
    A number of ancillary modules are available to Gallium3D drivers:

    1. The Draw module provides point/line/polygon rendering services such as vertex transformation, polygon culling and clipping. It will be used by drivers for hardware which lacks vertex transformation (such as the i915/i945). It may also be instantiated and used directly by the state tracker to implement some API functionality that doesn't map well to hardware capabilities.

    2. The TGSI module provides a universal representation of shaders and CPU-based execution of shaders. All Mesa vertex/fragment programs and shaders are translated into the TGSI representation before being passed to the driver. In turn, the driver will convert the TGSI instructions into GPU-specific instructions. For hardware that lacks vertex or fragment shader support, the TGSI's executor can be used. The TGSI executor includes support for SSE code generation. Support for other processors (such as Cell) will be added in the future.


Current Gallium3D development TODO task list: http://www.tungstengraphics.com/wiki/index.php/Gallium_TODO


EDIT: Anyone who is futher interested in Gallium should check out this PDF:
http://www.tungstengraphics.com/wiki/files/gallium3d-xds2007.pdf

Big Grin


- Gamester17 - 2008-02-22

Article describing the Mesa Cell driver which part of the Gallium3D architecture:
http://www.mesa3d.org/cell.html

Quote:Mesa Cell Driver

The Mesa Cell driver is part of the Gallium3D architecture.

Tungsten Graphics is leading the project. Two phases are planned. First, to implement the framework for parallel rasterization using the Cell SPEs, including texture mapping. Second, to implement a full-featured OpenGL driver with support for GLSL, etc.

Source Code
The Cell driver source code is on the gallium-0.1 branch of the git repository. To build the driver you'll need the IBM Cell SDK (version 2.1 or 3.0). To use the driver you'll need a Cell system, such as a PS3 running Linux, or the Cell Simulator (untested, though).

To compile the code, run make linux-cell

To use the library, make sure LD_LIBRARY_PATH points the Mesa/lib/ directory that contains libGL.so

Verify that the Cell driver is being used by running glxinfo and looking for:

OpenGL renderer string: Gallium 0.1, Cell on Xlib

Status
As of January 2008 the driver supports smooth/flat shaded triangle rendering with Z testing. Simple demos like gears run successfully. Basic texture mapping should be working within a month. There's still unfinished work in the PPU-to-SPU communication facilities.

Contributing
If you're interested in contributing to the effort, familiarize yourself with the code, join the mesa3d-dev mailing list, and describe what you'd like to do.



Progress on port to PS3? - Calab - 2008-04-07

I really enjoy XBMC on my two old XBoxes... I am really excited to hear that there is a Linux port of XBMC under development. Hopefully this will work on the Playstation 3.

Is XBMC being ported to work on the PS3?

I would definately pay money for this application on my PS3.

Keep up the good work!!!


- spiff - 2008-04-07

no. blame sony


XBMC on linux on PS3 - NetNut404 - 2008-05-22

Hi, so I know this has been talked about alot.. but with all I have read I am curious what the status is on this.. Meaning is it dead and noone is looking into it or is it still being looked into? It's funny because I saw that xbmc is working linux and that linux has been installed on the ps3, so without looking much futher though.. if that's the case why cant I put xbmc on linux on my ps3.. only to find that there was more to that puzzle than I originally investigated, and I am still force to keep my old original xbox console plugged in for xbmc Sad

Anyway.. enought ranting for now.. just thought the ps3 could double as a awesome media center ..


- dustobub - 2008-05-22

Well there are several threads on this already, but the key reasons why nothing has happened yet is that the PS3's architecture is PPC not x86, and also there are no real 3d linux drivers for the PS3. So, it may happen one day, just not anytime soon.

Dustin


- QuiescentWonder - 2008-05-27

Quote:once you gone XBMC you never want to go back to using something that is anything less.

I won't delve deeply into the conversation, but this is entirely true. Out of all of the media-oriented software that I've used XBMC is by far my favorite regardless of the platform.


- Gamester17 - 2008-07-02

Looks like a project called spu-medialib has a collection of media library code optimized for the PS3's Cell processor.
http://wiki.ps2dev.org/ps3:spu-medialib
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-June/031349.html
http://forums.ps2dev.org/viewforum.php?f=29
http://svn.ps2dev.org/listing.php?repname=ps3ware&path=%2Ftrunk%2Fspu-medialib%2F&rev=0&sc=0

Quote:spu-medialib
A collection of spu programs to accelerate media related applications on the CELL BE Processor & Playstation 3.


project links:
svn repository
forum pages
mailing lists
Install

spu-medialib currectly consists of:
colorspace conversion yuv420 to ARGB
iDCT
bilinear yuv420/yv12 scaler
bilinear yuv420/yv12 scaler with integrated ARGB colorspace conversion that also downscales

spu-medialib is currently used in:
mplayer vo module mplayer-vo

Things that should be added to the project:
mpeg decoding
h.264 decoding
motion compensation
scalers bicubic b-spline, lancos
deblocking filters
other postprocessing filters
sound processing - liba52?
Things that are in work:
mpeg 1 & 2 Stream decoders
mpeg I frame vlc decoder

Things thats been done at current stage:
Test implemented colorspace conversion and scaler in a mplayer vo(”not a desired solution but it worked”Wink 1080p upscaled playback verified
example implementation of colorspace converter uing yuv420 source currently does 300 FPS @ 1080p
example implementation of yuvscaler using yuv420 source currently does 150FPS scaling @1080p
example implementation of yuvscaler + yuv2rgb converting using yuv420 source and two spu’s currently does 150FPS scaling @ 1080p
example implementation of yuvscaler + yuv2rgb converting on a single spe using yuv420 source and one spu currently does 85FPS scaling up to @ 1080p

Resources:
yuv samples

Current Project Participants are:
unsolo aka Kristian Jerpetjøn lead developer
John_k developer
wgarrett aka Bill Garrettinterface developer
Sauce aiding
lu_zero working on integration into libswscale/ffmpeg/mplayer

Where to find us:
Currently we are in #ps3dev, #ps3linux on irc.freenode.net
If combinied with Gallium (for the XBMC GUI rendering part) then this could maybe be usefull?

Huh