The hunt for HV's FIFO/Push buffer...

[ps2devman]

Magnificent!

[IronPeter]

valentijn_venus, Nouveau frontpage http://nouveau.freedesktop.org/wiki/ states: "Do not expect 3D support to work for anything other than glxgears, we do not need 3D bug entries yet." We can not speak yet about OpenGL 1.3 drivers for RSX. Only after nouveau success.

Nouveau project has 50+ developers, libps3rsx has 1-2.

Of course you will be able to use libps3rsx as DRI layer. I'm not very interesting in that.

OpenGL is not very good coding paradigm for consoles. It is abstraction layer with huge penalties. Small example:

Code: Select all

 
void glTexImage2D( GLenum target,
			     GLint level,
			     GLint internalformat,
			     GLsizei width,
			     GLsizei height,
			     GLint border,
			     GLenum format,
			     GLenum type,
			     const GLvoid *pixels )

This function does format-conversion from user-defined data. You must allocate data on the user side. You can not use raw GPU formats, driver does a lot of conversion. The next problem is sync-issues. It is hard as hell to update texture in background without GPU stall. Or without copying texture data into driver-side temp store.

Compare with:

Code: Select all

         int fd, size;
        void *file = map_file( "../../data/troll.dxt1", &fd, &size );

        if( size && file )
        {
                texture_desc_t *desc = file;
                memcpy( fbmem + tx_offset, sizeof( *desc ) + (uint8_t *)file, desc->length );
                int res = set_texture_2D( desc, tx_offset, 0, REPEAT, LINEAR, LINEAR_MIPMAP_LINEAR, fifo, Nv3D );
                unmap_file( file, fd, size );
                return res;
        }

        return 0;

Texture, from memory mapped file to videomemory. You can stream texture data in background ( it is better to decompress by SPU ). You can implement custom streaming and management schemes just by loading higher texture mips. It is good console style.

And it works on RSX, after week of coding. Mesa does not work on NV40, after years.

[mitran]

as the subject says i am a total noob when it comes to two things englsih lol and programing .
however i do understand a bit , first of will ther be some "rpm" installer for thies for uber nobbs like me ?
And or will it speed things up in Blender ?
cos i mostly use Linux on ps3 for two things one is pay my bills second is Blender ( and right now it renders slow ( lots faster then on my Mac G3 + HW support )
But still a bit slow ,
just asking cos id love to see some RSX in Blender even if it is "just" more grafix ram .
( I am useing Fedora core 6) right now ( can i self implment the new drivers in a easy way ?
thank you for any awnser i get :D
a noob in need of help

[androvsky]

Code: Select all

         int fd, size;
        void *file = map_file( "../../data/troll.dxt1", &fd, &size );

        if( size && file )
        {
                texture_desc_t *desc = file;
                memcpy( fbmem + tx_offset, sizeof( *desc ) + (uint8_t *)file, desc->length );
                int res = set_texture_2D( desc, tx_offset, 0, REPEAT, LINEAR, LINEAR_MIPMAP_LINEAR, fifo, Nv3D );
                unmap_file( file, fd, size );
                return res;
        }

        return 0;

Texture, from memory mapped file to videomemory. You can stream texture data in background ( it is better to decompress by SPU ). You can implement custom streaming and management schemes just by loading higher texture mips. It is good console style.

And it works on RSX, after week of coding. Mesa does not work on NV40, after years.

Man, I would have loved to have been able to do that on a PC with a 7800, I was having serious problems with the way OpenGL handles textures in a project I was working on last summer. I don't suppose the ps3rsx libraries could easily be adapted to work on an x86 system...? Ok, so I know it'll be a pain, and I don't want to take time away from the RSX project. Is anyone working on a jpeg2000 Cell port by any chance? ;)

[IronPeter]

androvsky, PC needs high level interfaces like OpenGL. And OpenGL drivers from NVidia are very stable and well supported.

Of course, you can run something like nv40_demo by Nouveau team on your NV40 : http://nouveau.cvs.sourceforge.net/nouveau/nv40_demo/

But you will not be able to ship your product, it will work on 0.1% of PC install base.

Game console does not need common GAPI abstraction layer. At least this abstraction layer must be modified ( like DirectX on Xbox 360 ) to reflect hardware. Custom GAPI can be very well tuned for custom hardware.

[MistaED]

Hmm it might be best to support the newer DRI systems like Gallium3D which is a restructure of how mesa and DRI mesh together, as in, it allows more than just opengl/mesa's API to talk to the video. Might be ideal to how you want to approach supporting the PS3's RSX chip.

http://www.tungstengraphics.com/wiki/in ... /Gallium3D
http://zrusin.blogspot.com/

I think nouveau are moving towards this approach in implementing their DRI module :)

[IronPeter]

MistaED, you can want to wait for Nouveau success with DRI module. Success = working Quake3. Nouveau project has 50+ developers, PS3 is just NV40 driven PPC computer from Nouveau's point of view... Very slow computer, with very limited memory.

You can wait year. You can wait for the second iteration of Gallium3D and for bugfix.

Alternatively you can checkout libps3rsx and write your code. Now. The keyword is "enabling RSX now".

[mickfromperth]

Hi Everyone. wow it is exciting to watch you guys explore the ps3 capabilities!

Glaurung, I had the xorg driver compile and installed (although I didn't really test it other than load X). And I've just installed your kernal model (everything seemed to compile and install OK). And installed the new xorg driver.

I updated my xorg.conf with the following changes I guessed at the options by browsing the ps3.c file in /src.

---
Section "Device"
Identifier "VideoCard0"
#Driver "spu_fbdev"
Driver "ps3"
#Option "ShadowFB" "false"
EndSection
---

I can use your script "ps3X" to run X, but I jus get the blank screen with a mouse pointer.

When I run X via GDM (running ubuntu) the login window is all garbled. You can see the text box, you can see the mouse pointer and move it, but it's icon is garbled. The background graphics are spli with many horizontal lines..

I've tried setting the ps3 fbdev resolution (i'm on PAL) to 576i, 720p, and 1080p all with the same result.

Is there some other Xorg options which we need to try the new driver out?

Mick

[androvsky]

androvsky, PC needs high level interfaces like OpenGL. And OpenGL drivers from NVidia are very stable and well supported.

Of course, you can run something like nv40_demo by Nouveau team on your NV40 : http://nouveau.cvs.sourceforge.net/nouveau/nv40_demo/

But you will not be able to ship your product, it will work on 0.1% of PC install base.

Game console does not need common GAPI abstraction layer. At least this abstraction layer must be modified ( like DirectX on Xbox 360 ) to reflect hardware. Custom GAPI can be very well tuned for custom hardware.

Thanks for the help. In my case, the software was only meant to be run on one computer, so working with other graphics cards isn't an issue.

[d-range]

androvsky, PC needs high level interfaces like OpenGL. And OpenGL drivers from NVidia are very stable and well supported.

Of course, you can run something like nv40_demo by Nouveau team on your NV40 : http://nouveau.cvs.sourceforge.net/nouveau/nv40_demo/

But you will not be able to ship your product, it will work on 0.1% of PC install base.

Game console does not need common GAPI abstraction layer. At least this abstraction layer must be modified ( like DirectX on Xbox 360 ) to reflect hardware. Custom GAPI can be very well tuned for custom hardware.

You're right about that, but a fully working, (partially) accelerated OpenGL interface is still very useful for software compatibility. There's lots of interesting OSS OpenGL stuff out there.

Anyway, I agree that OpenGL should not be a priority. I hacked Mesa when I graduated, to port pieces of it to dedicated DSPs. I know from experience that the amount of work involved to get a useful RSX Mesa would be insane.

[sigbus]

IronPeter wrote:

<<
Game console does not need common GAPI abstraction layer. At least this abstraction layer must be modified ( like DirectX on Xbox 360 ) to reflect hardware. Custom GAPI can be very well tuned for custom hardware.
>>

I think you are on a slippery slope here... If you start aiming at what a game console needs, and thus directly or indirectly aiming at supporting games in linux, you can pretty much guarantee that the very first thing Sony will do is find a way to shut you off, changing the hypervisor in ways that will prevent whatever linux is trying to achieve. You are basically on a direct confrontation course here.

On the other hand, if you aim at improving the linux desktop support (which mostly goes through things like EXA support, OpenGL to support things such as compiz, removing the 10 or 20M bolted kernel shadow buffer to get more RAM available, etc...), that may stay long enough under Sony radar. Nobody really fears the 2 or 3 linux games that might use it, and as you said, it would take quite some time to get the GL implementation to a state where it's useable for games anyway, and possibly never as sleek & efficient at gaming than what GameOS does, which is -just fine-. And has the added advantage of -not- being a direct confrontational path to Sony.

Just my 2 cents...

[bongo]

Actually I don't think Sony will bother at all. Any pros for ps3 linux is a pro for the console at whole. Even if they don't make money of it directly, it will still be an indirect gain as the customer base grows.
Personaly I just want to see the 3d dev going as far as to allow 3d accelerated n64 emulation. But that is a bit off topic though. But still, imagine using the ps3 for all your console needs? =)

[sigbus]

Don't underestimate corporate paranoia when it comes to protecting exclusive licence based console developement.

[ps2devman]

Currently PS3 is the only console unharmed by piracy.
For a simple reason, hacking pressure is very low.
If they don't let us play with RSX and close the hole hacking pressure will rocket up.
Also it's obvious we won't get the caches of TILES, so we won't compete with GameOS games performances (we will be limited to 70% of it, in best case).

So, if Sony leaders are dumb, they will block us and obtain piracy appearance later. If they are smart they will let us play with the RSX toy.

[gorim]

I think you are on a slippery slope here... If you start aiming at what a game console needs, and thus directly or indirectly aiming at supporting games in linux, you can pretty much guarantee that the very first thing Sony will do is find a way to shut you off, changing the hypervisor in ways that will prevent whatever linux is trying to achieve. You are basically on a direct confrontation course here.

On the other hand,... And has the added advantage of -not- being a direct confrontational path to Sony.

Just my 2 cents...

The aim of console hacking (of the legal variety) is to explore and make the most of what is available in a console. That means things that were not originally intended to be made available by the vendor, to the extent it was discovered legally and even better if it doesn't enable piracy.

Your concern about Sony would seem premature in this case. Its not like piracy is enabled here, merely access to undocumented areas of the video card. This is little reason to believe any competition to Sony's own dev kits will occur remotely any time soon.

[IronPeter]

sigbus, commercial nextgen game costs:

1M$ for programming.
5M$ for art
10M$ for promotion
??M$ for IP

Nobody with this amount of money will target linux with HV hacks as platform.

libps3rsx is for small free-to-play-games. And I very glad to hear from you that OpenGL is bad platform for these games.

> This is little reason to believe any competition to Sony's own dev kits will occur remotely any time soon

Heh... not exactly. You can have license from Sony and use ps3 linux-boxes for development. ...Few days ago Sony halved price of ps3 dev kit.

[Panajev2001a]

Don't underestimate corporate paranoia when it comes to protecting exclusive licence based console developement.

Oh... and look how much good it did do to them acting that way with the PSP... ;).

In the end the really powerless ones are licensed software developers which are really locked down in user mode and cannot do much if anything at all to combat piracy on their own titles like they used to do on PS1 and PS2 for example.

[d-range]

libps3rsx is for small free-to-play-games. And I very glad to hear from you that OpenGL is bad platform for these games.

I beg to differ. There is really nothing 'bad' about OpenGL as a platform for anything 3D-related, if I'm correctly you even program GameOS games through the OpenGL API. I think the one -and only- reason to not start working on accelerated PS3 OpenGL right now is because it is so involved. It would slow down progress on the low-level stuff, and that's what people need *at the very least* to do anything 3D on the PS3 right now. As soon as the kernel module matures and stabilizes and more data about performance and the impossibilities of the FIFO workaround for real-world scenarios is known, work should definitely start on a Mesa port that uses it. It's all about the existing OSS software base out there that is built around OpenGL.

I might actually consider delving into this when the libps3rsx work matures. As I said, I already have ~1yr of experience hacking parts of Mesa, so I somewhat know where to start. Problem is that I tend to let these projects stall pretty quickly after I started them, as I have to do it all in the few hours of spare time I have each week. ATM I'm still playing with my video decoder pet project, but I will keep lurking this thread.

[Glaurung]

@mickfromperth, I noticed some corruption too when trying the module with the original Debian 2.6.16 kernel. In my case, it is due to the ps3fb driver not working the same at all as it does now. In particular, assuming the fb base is the same as what is seen by the RSX at GPU_IOIF is wrong. Can you try changing src/ps3_gpu.c around line 260 from

Code: Select all

	pPS3->iof_offset = 0x0d000000; /* GPUIOF */

to

Code: Select all

	pPS3->iof_offset = 0x0d000000 + 64*1024; /* GPUIOF */

What kernel version are you using BTW? Are you using fullscreen or non-fullscreen modes?

I'm not satisfied with the kernel module interfaces yet, I need to work on it more. I'm thinking of registering it as a fb driver and have a single mmap() with different offsets for the entities we need to access (vram, fifo, reports area, ioif region stealed from ps3fb, ...). The advantage of a fb driver is that is would register the /dev/fb1 entry automatically with any kernel version (using udev, no more mknod.sh crap), and it better represents the device (e.g. writting to /dev/fb1 would write to the screen, in video ram; with some work it could even replace ps3fb altogether). Also, getting access to region reserved in XDR by ps3fb (what I called the ioif region) in a portable way is very hard. So the code is going to change a lot again, do not rely too much on the current version.

Also, I'm all for using standard APIs (drm, Mesa GL, ..) as much as possible, but it'll take time to set up. The RSX provides many opportunities. My goal is to use it to improve desktop Linux usability on PS3.
IronPeter's approach with libps3rsx is not incompatible with this goal, so I think we can all work together to have a common low-level API for accessing the RSX hardware. Then people can build whatever they like with it, be it demos, 3D games, a mesa gl port, or OtherOS demos. I've no experience with 3D, so I'll probably stick to Xorg (which I've been learning these past two months), the mtd RAM driver (I've some experience with Linux kernel development), along with the rsx driver and the libps3rsx part for talking to it.

[IronPeter]

Glaurung, I'll try to resolve "busy" issue. It is hard to tweak existing ps3fb.

I am very happy with ps3rsx progress. Of course, there are many bugs, but the project seems to be successful. My roadmap is to clenup and refactor it to the New Year. And after that expose large 3D demo with high quality art.

[d-range]

Glaurung, I'll try to resolve "busy" issue. It is hard to tweak existing ps3fb.

I am very happy with ps3rsx progress. Of course, there are many bugs, but the project seems to be successful. My roadmap is to clenup and refactor it to the New Year. And after that expose large 3D demo with high quality art.

Cool, I'd like to see that! You a demo coder?

[Glaurung]

Just as a quick note, IronPeter, I got your (impressive) troll rendered from second context using new ps3rsx module (updated to /dev/fb1 API). I'll cleanup and post that tomorrow, time to sleep now.

[IronPeter]

d-range, I am professional PC-game developer.

Glaurung, nice.

[d-range]

d-range, I am professional PC-game developer..

That explains a lot ;-). Can't wait to see what you come up with. I used to follow the demoscene a bit a few years back, also went to a demoparty twice. Back then it was already amazing the stuff some ppl did with the xbox 1, or even more impressive the gameboy advance (think 5000+ textured poly models with animation and sound, in software, on a GBA). I can't even imagine what PS3 demos using libps3rsx could lead to in the future.

[Glaurung]

Hi,

I've just committed the updated ps3rsx module and Xorg driver:
git clone http://mandos.homelinux.org/~glaurung/git/ps3rsx.git
git clone http://mandos.homelinux.org/~glaurung/g ... eo-ps3.git

I've tested it under the following configurations:
- geoff's 2.6.24-rc3/gcc-4.2 1280x720p full
- Debian 2.6.16-1-ps3pf/gcc-4.1 1920x1080i full
- Debian 2.6.16-1-ps3pf/gcc-4.1 576x384 non-full

I've sent a patch to IronPeter for libps3rsx and successfully tested it (rendered the triangles and the troll) under all the configurations above. X was tested with wmaker, mplayer playing full HD video, Composite enabled and translucent video window.

So the kernel patch is not needed anymore, and this module should compile over a wide range of kernels. For people interested to try it, please let me know if you encounter any issue, and the version of your kernel (and distribution) and resolution you tested.
Note: there is a known limitation with X video modes: you have to use the same resolution in xorg.conf as the one the framebuffer is when X is started.

The kernel module uses a lot of hacks to determine where the ps3fb linear XDR allocation and FIFO are located. I'm still not convinced a separate kernel module is the best solution compared to a full ps2dev-supported kernel tree, but let's try this way and we shall see if the module is hard to maintain or not.

[mitran]

wowwawia , man i realy love reding , any idee on how long time((if)) it will take befor noobs like me can pay you $$$ in order to get theis as an "rpm" or somthing like that so that i a standard linux user can use(Mplayer for 720p film and or speed up Blender lol .
( years week month s :P ) befor theis stuff finds it self out to non programes , ( art ppl like I are just out after the things you the programmers do )
so i gladly pay (£€$) for theis :)

[ps2devman]

Thanks a lot Glaurung! More people will be able to play with RSX now!

[Panajev2001a]

Cloned, configured, and compiled both git trees Glaurung... result of your load script (kernel module):

Code: Select all

ps3rsx: PS3 RSX access module, 1.0.0
ps3rsx: reserved XDR memory is @c000000002100000, len 18874368
ps3rsx: 254MB of DDR video ram at 0x700190000000 mapped at d000080080780000 handle 5a5a5a5b
ps3rsx: context 0x55555554 dma=440000381000 driver=4000001a4000 reports=4800006d0000 reports_size=10000
ps3rsx: ctrl=d00008008010e000 drv=d0000800905c0000 reports=d0000800804e0000
ps3rsx: version 2.11 RSX rev17 0MB RAM channel 1 core 500MHz mem 650MHz
ps3rsx: remapped XDR apperture at c000000002100000 size 18432kB to RSX

OS: Fedora 7

Kernel (using patched ps3fb.c/ps3fb.h) : 2.6.24-rc4-g934af6ff

GCC: version 4.1.2 20070925 (Red Hat 4.1.2-27)

fbset (non fullscreen):

Code: Select all

mode "1208x684-60"
    # D: 74.178 MHz, H: 44.957 kHz, V: 59.942 Hz
    geometry 1208 684 1208 684 32
    timings 13481 256 106 37 24 80 5
    bcast true
    accel true
    rgba 8/16,8/8,8/0,8/24
endmode

I did everything over ssh today, so I do not know how the screen looks heh :). Is the output from the "load" script ok ?

[mickfromperth]

@Glaurung: Sorry for the delay, I've had a busy week. Was planning on testing your suggested code change tonight and now this...

I'm using the latest standard ubuntu ppc kernel:
---
mick@mick-desktop:~$ uname -r
2.6.22-14-cell
---

fb is set to:
---
mick@mick-desktop:~$ ps3videomode
136
---
(50 hZ 720p fullscreen).

Just running make and make install over the top of the last version; I now get a working GDM login and working desktop. Great news! Yay!

Now, time to show how little I know..

I'm a xine user. I'm stuck with xine because it does two things I need: a head end to vdr; and a head end to dvbstreamer.

When I run xine with vo driver of Xv, it crashes X.
When I run xine with a vo driver of X11 it works. But.. it "feels" like performance is not *that* much better than the fb driver..

Now, onto compiz. In ubuntu gutsy it is installed by default (although cut down I assume). I go to system -> apearance -> Preferences and turn on "destop Effects" and I get an error straight away saying could not be turned on (Desktop effects could not be enabled)..

I played a bit with the info on this page:
---
http://ubuntu-tutorials.com/2007/10/04/ ... sy-gibbin/
---
(basically install compiz-manager to customise your settings). But still wasn't able to initialise.

Now, I would not expect such things to work at such an early stage; but you mentioned that a few posts / pages ago?? so i thought I'd just give it a go for feedback anyway..

Is this useful feedback?

Mick

[Panajev2001a]

Glaurung, could you go over the proper way to replace the fbdev driver and use the kernel module + your new Xorg driver ?

I seem to have some issues in starting X with your two new modules.

Update: Ok, sorry... solved the small problem loading the .ko module.

In /etc/rc.local I put a script which does simply this:

Code: Select all

cd /usr/src/ps3rsx_kmod/

insmod ps3rsx.ko

Should I leave fbdev in the Xorg.conf file as driver for Videocard0 or should I place ps3rsx in its place ?

Putting ps3rsx in the place of fbdev does not let the X server starts... I must be missing something...