OedipusRSX PS3 RSX Reality Synthesizer Documentation Surfaces

[oVERSoLDiER]

Sure, it's from edepot.

[PS3 News]

Following their OedipusRSX PS3 RSX Reality Synthesizer Documentation, today daxgr via Gitbrew has released a PS3 RSX driver for FreeBSD via OtherOS++ CFW which is essentially a Linux kernel module.

Download: http://git.gitbrew.org/~glevand/ps3/linux/ps3rsx.tar.gz / http://gitbrew.org/~glevand/ps3/freebsd/livecd/ps3_freebsd_livecd.iso (1920x1080 Resolution) / PS3 FreeBSD LiveCD iSO (Mirror)

To quote: Well I am pleased to announce that RSX Driver for FreeBSD is released. The RSX driver is the product of hard work by durandal and glevand, who gave up many hours to accomplish this. So here you go, the link for the RSX driver: http://git.gitbrew.org/~glevand/ps3/linux/ps3rsx.tar.gz

On a side note, may I add that contrary to public belief for 5 YEARS, the RSX doesnt not rely on DMA to process graphics, but rather uses PPU instructions to push objects to RSX VRAM. So… yeah another breakthrough by the team who scammed everyone…. Gitbrew.

PS: To all those who started complaining about this noble effort to enable RSX on OtherOS(/++) , such as “gitbrew is a scam” or “they are just SDK samples”, check out the date of the file.

Gitbrew was always about developing things for developers AND users alike. Sadly, users don’t always appreciate the effort, a simple omission to include the release URL, that was due to durandals medical condition and glevans personal issues, seems to be enough…

Well keep that in mind, Gitbrew gave their word to release a RSX driver and succeeded; anyone who had cared to browse glevands directory WITHIN 24 HOURS of the donations would have seen it.

Source Code:

/*
 * PS3 RSX
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License as published
 * by the Free Software Foundation; version 2 of the License.
 *
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License along
 * with this program; if not, write to the Free Software Foundation, Inc.,
 * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 */

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/io.h>
#include <linux/delay.h>

#include <asm/abs_addr.h>
#include <asm/cell-regs.h>
#include <asm/lv1call.h>
#include <asm/ps3.h>

#define RSX_FIFO_CMD_BUF_SIZE   (1 * 1024 * 1024)

#define RSX_MEM_SIZE        (32 * 1024 * 1024)

#define RSX_GPU_IOIF        (0x0e000000ul)

#define RSX_FIFO_CTRL_SIZE  (4 * 1024)

struct rsx_fifo_ctrl {
    u8 res[0x40];
    u32 put;
    u32 get;
};

static u32 *rsx_fifo_cmd_buf;
static u64 rsx_fifo_cmd_buf_lpar;

static u64 rsx_mem_handle, rsx_mem_lpar;
static u64 rsx_ctx_handle;
static u64 rsx_fifo_ctrl_lpar;
static u64 rsx_drv_info_lpar;
static u64 rsx_reports_lpar, rsx_reports_size;

static struct rsx_fifo_ctrl *rsx_fifo_ctrl;

/*
 * FIFO program
 */
static u32 rsx_fifo_prg[] = {
    0x00000000, /* nop */
    0x00000000, /* nop */
    0x00000000, /* nop */
};

/*
 * ps3rsx_init
 */
static int __init ps3rsx_init(void)
{
    unsigned long timeout;
    int res;

    /* FIFO command buffer must be allocated in XDR memory */

    rsx_fifo_cmd_buf = kmalloc(RSX_FIFO_CMD_BUF_SIZE, GFP_KERNEL);
    if (!rsx_fifo_cmd_buf) {
        printk(KERN_INFO"could not allocate FIFO command buffer\n");
        res = -ENOMEM;
        goto fail;
    }

    res = lv1_gpu_memory_allocate(RSX_MEM_SIZE, 0, 0, 0, 0,
        &rsx_mem_handle, &rsx_mem_lpar);
    if (res) {
        printk(KERN_INFO"lv1_gpu_memory_allocate failed (%d)\n", res);
        res = -ENXIO;
        goto fail_free_fifo_cmd_buf_mem;
    }

    res = lv1_gpu_context_allocate(rsx_mem_handle, 0,
        &rsx_ctx_handle, &rsx_fifo_ctrl_lpar, &rsx_drv_info_lpar,
        &rsx_reports_lpar, &rsx_reports_size);
    if (res) {
        printk(KERN_INFO"lv1_gpu_context_allocate failed (%d)\n", res);
        res = -ENXIO;
        goto fail_free_gpu_mem;
    }
   
    /* map FIFO command buffer into RSX address space */

    rsx_fifo_cmd_buf_lpar = ps3_mm_phys_to_lpar(__pa(rsx_fifo_cmd_buf));

    res = lv1_gpu_context_iomap(rsx_ctx_handle,
        RSX_GPU_IOIF, rsx_fifo_cmd_buf_lpar, RSX_FIFO_CMD_BUF_SIZE,
        CBE_IOPTE_PP_W | CBE_IOPTE_PP_R | CBE_IOPTE_M);
    if (res) {
        printk(KERN_INFO"lv1_gpu_context_iomap failed (%d)\n", res);
        res = -ENXIO;
        goto fail_free_gpu_mem;
    }

    /* map RSX FIFO control registers */

    rsx_fifo_ctrl = (struct rsx_fifo_ctrl *) ioremap(rsx_fifo_ctrl_lpar, RSX_FIFO_CTRL_SIZE);
    if (!rsx_fifo_ctrl) {
        printk(KERN_INFO"could not map FIFO control\n");
        res = -ENXIO;
        goto fail_free_gpu_mem;
    }

    /* PUT and GET offsets are in RSX address space */

    res = lv1_gpu_context_attribute(rsx_ctx_handle, 0x1,
        RSX_GPU_IOIF + 0x0 /* PUT offset */, RSX_GPU_IOIF + 0x0 /* GET offset */,
        0x0, 0x0);
    if (res) {
        printk(KERN_INFO"lv1_gpu_context_attribute(0x1) failed (%d)\n", res);
        res = -ENXIO;
        goto fail_unmap_fifo_ctrl;
    }

    /* copy FIFO commands to FIFO command buffer */

    memcpy(rsx_fifo_cmd_buf, rsx_fifo_prg, sizeof(rsx_fifo_prg));

    printk(KERN_INFO"GET offset (0x%08x) PUT offset (0x%08x)\n", rsx_fifo_ctrl->get, rsx_fifo_ctrl->put);

    /* kick FIFO */

    rsx_fifo_ctrl->put = RSX_GPU_IOIF + sizeof(rsx_fifo_prg);

    /* poll until RSX is done processing FIFO commands */

    timeout = 100;

    while (timeout--) {
        if (rsx_fifo_ctrl->get == rsx_fifo_ctrl->put)
            break;

        msleep(1);
    }

    printk(KERN_INFO"GET offset (0x%08x) PUT offset (0x%08x)\n", rsx_fifo_ctrl->get, rsx_fifo_ctrl->put);

    if (rsx_fifo_ctrl->get != rsx_fifo_ctrl->put) {
        printk(KERN_INFO"FIFO command buffer timeout\n");
        res = -ENXIO;
        goto fail_unmap_fifo_ctrl;
    }

    return 0;

fail_unmap_fifo_ctrl:

    iounmap(rsx_fifo_ctrl);


fail_free_gpu_mem:

    lv1_gpu_memory_free(rsx_mem_handle);

fail_free_fifo_cmd_buf_mem:

    kfree(rsx_fifo_cmd_buf);

fail:

    return res;
}

/*
 * ps3rsx_exit
 */
static void __exit ps3rsx_exit(void)
{
    iounmap(rsx_fifo_ctrl);

    lv1_gpu_context_iomap(rsx_ctx_handle, RSX_GPU_IOIF, rsx_fifo_cmd_buf_lpar,
        RSX_FIFO_CMD_BUF_SIZE, CBE_IOPTE_M);

    lv1_gpu_context_free(rsx_ctx_handle);

    lv1_gpu_memory_free(rsx_mem_handle);

    kfree(rsx_fifo_cmd_buf);
}

module_init(ps3rsx_init);
module_exit(ps3rsx_exit);

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("PS3 RSX");
MODULE_AUTHOR("glevand");

Below is a guide from: portal.gitbrew.org/wikibrew/PS3:FreeBSD

PS3 FreeBSD

FreeBSD OtherOS++

FreeBSD can be run on PS3 Slim models from HDD with OtherOS++.

All the freebsd related files should be available here: http://gitbrew.org/~glevand/ps3/freebsd/

Cross-Compiling

You can skip this step and use my precompiled FreeBSD world and kernel:

http://gitbrew.org/~glevand/ps3/freebsd/ps3_freebsd_world.tar.gz
http://gitbrew.org/~glevand/ps3/freebsd/kernel/
http://gitbrew.org/~glevand/ps3/freebsd/loader-1080x1920.ps3

You need a running FreeBSD system to cross-compile your PS3 FreeBSD world and kernel, you don't need a PS3 for that, it may be a different architecture. Once this step is done and you have a running FreeBSD system on your PS3 , you can build FreeBSD world and kernel on PS3 itself.

# git clone git://git.gitbrew.org/ps3/ps3freebsd/freebsd.git
# cd freebsd
# make buildworld buildkernel installkernel installworld distribution TARGET=powerpc TARGET_ARCH=powerpc64 KERNCONF=PS3 DESTDIR=$HOME/ps3_world

When it's finished then you will have a complete FreeBSD world with kernel in directory $HOME/ps3_world.

Rebuilding Loader

If you want to recompile ONLY FreeBSD loader then after you finished compiling FreeBSD world and kernel, do this:

# cd freebsd
# make buildenv TARGET=powerpc TARGET_ARCH=powerpc64
# cd sys/boot
# make all install DESTDIR=$HOME/ps3_world

Rebuilding Kernel

If you want to recompile ONLY FreeBSD kernel then after you finished compiling FreeBSD world and kernel, do this:

# cd freebsd
# make buildkernel TARGET=powerpc TARGET_ARCH=powerpc64 KERNCONF=PS3
# make installkernel TARGET=powerpc TARGET_ARCH=powerpc64 KERNCONF=PS3 DESTDIR=$HOME/ps3_world

Installation

To install a FreeBSD world on your PS3, you will need a running Linux system first currently. Once i build a LiveCD for PS3 FreeBSD you won't need that anymore. I used Debian to install my FreeBSD on PS3.

First create UFS2 filesystem for your FreeBSD. I assume that there is already a free partition on the HDD of your PS3.

# apt-get install ufsutils
# mkfs.ufs /dev/ps3dd3

Then mount it on Debian and copy your PS3 FreeBSD world to this partition, like this:

# mount -t ufs -o ufstype=ufs2 /dev/ps3dd3 /mnt
# cd /mnt
# tar xvzf /root/ps3_freebsd_world.tar.gz
# cp /root/ps3_freebsd_kernel/kernel /mnt/boot/kernel/
# cp /root/ps3_freebsd_kernel/kernel.symbols /mnt/boot/kernel/
# cd
# umount /mnt

Booting

FreeBSD on PS3 is booted by the FreeBSD loader which can be executed by petitboot with kexec. The FreeBSD loader is built during cross-compiling of the FreeBSD world and kernel or you can use my precompiled version. It supports booting of FreeBSD from HDD. My precompiled version boots a FreeBSD kernel from ps3dd3. The HDD partition from which it boots a FreeBSD kernel is hardcoded, if you want to use another HDD partition then you have to change it in the loader and recompile it.

Store your FreeBSD loader on a Linux partition, i stored mine in Debian in /boot directory, and added a new kboot.conf entry on Linux, like this:

# cp /root/loader-1080x1920.ps3 /boot
# cat /etc/kboot.conf
...
...
...
freebsd_loader_hdd=/boot/loader-1080x1920.ps3
...
...
#

Now you can boot your PS3 FreeBSD. Boot petitboot first and choose FreeBSD loader in CUI. Once, you have a running PS3 FreeBSD system, you can build FreeBSD world and kernel or compile ports on your PS3 itself.

One of the advantages of FreeBSD on PS3 is write access to the GameOS HDD region and the possibility to create valid GameOS HDD partitions.

Ports

Ports allow us to install many useful programs on your FreeBSD.

Extracting ports:

# cd /root
# fetch ftp://ftp7.freebsd.org/pub/FreeBSD/ports/ports-stable/ports.tar.gz
# cd /usr
# tar xvzf /root/ports.tar.gz

Useful programs you will need first:

• wget
• git
• screen
• sudo
• elinks

Live CD

Compiling World

• Change screen resolution in loader and kernel before compiling
• Change frame buffer size in kernel if needed

# cd /usr
# git clone git://git.gitbrew.org/ps3/ps3freebsd/freebsd.git src
# cd src
# make buildworld buildkernel installkernel installworld distribution TARGET=powerpc TARGET_ARCH=powerpc64 \
       KERNCONF=PS3 DESTDIR=/root/ps3_world

Compiling Ports

# cd /root/ps3_world/usr
# fetch ftp://ftp7.freebsd.org/pub/FreeBSD/ports/ports-stable/ports.tar.gz
# tar xvzf ports.tar.gz

# mount -t devfs devfs /root/ps3_world/dev
# cp /etc/resolv.conf /root/ps3_world/etc/
# chroot /root/ps3_world /bin/csh
# cd /usr/ports
# cd shells/bash
# make install clean BATCH=yes

Configuring System

/boot/loader.conf

boot_cdrom="YES"

autoboot_delay="-1"

/etc/rc.conf

root_rw_mount="NO"

hostname="freebsd-livecd"

ifconfig_glc0="SYNCDHCP"

keyrate="fast"
keymap="us.iso"
#keymap="fr.iso"
#keymap="german.iso"
scrnmap="NO"
font8x16="iso15-8x16"
font8x14="iso15-8x14"
font8x8="iso15-8x8"

update_motd="NO"
syslogd_enable="NO"
newsyslog_enable="NO"
cron_enable="NO"
hostid_enable="NO"

sendmail_enable="NONE"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

cleanvar_enable="NO"
crashinfo_enable="NO"
virecover_enable="NO"

/etc/fstab

/dev/cd0        /       cd9660  ro      0       0

Changing Login Shell

# chroot ps3_world
# chsh

Creating ISO Image

• Exit chroot

# umount /root/ps3_world/dev
# cd ps3_world
# rm -f etc/resolv.conf
# mkisofs -R -l -ldots -allow-lowercase -allow-multidot \
   -V 'PS3 FreeBSD LiveCD' -volset 'PS3 FreeBSD' -hide boot.catalog \
   -o ../freebsd_livecd.iso .

Booting Live CD with OtherOS++

Installing FreeBSD on HDD from Live CD

Links

FreeBSD Handbook: http://www.freebsd.org/doc/handbook/
FreeBSD AvgLiveCD: http://wiki.freebsd.org/AvgLiveCD
FreeBSD LiveCD: http://www.secure-computing.net/wiki/index.php/FreeBSD/LiveCD
Gitorious - FreeBSD Wiki: http://wiki.freebsd.org/Gitorious
Setting Up A new FreeBSD System: http://users.rcn.com/rneswold/fbsd-init.html


More PlayStation 3 News...

[Neo Cyrus]

It was only a matter of time before an RSX driver rolled around. Too bad it's all a little more complicated than most would like. Though now I suppose the waiting game repeats, someone will make a simple installer sooner or later.

[shummyr]

this is great and an awesome step forward in making linux better for the ps3.

[Pcsx2006]

Atlast RSX drivers are released thanks to hard work by durandal, glevand and gitbrew.

[PS3 News]

Here is another brief update from glevand via Gitbrew stating that Wireless LAN is now working on Linux for the PS3 console: twitter.com/#!/gitbrew/status/112554073458343936

Wlan now working on slim ps3s. http://git.gitbrew.org/repos/?p=ps3/ps3linux/ps3-jupiter.git;a=summary Linux based for now. Freebsd and petitboot with wireless to come next.

One more update via gitbrew: twitter.com/#!/gitbrew/status/113546748210855936

Freebsd live cd now has a partial rsx driver http://gitbrew.org/~glevand/ps3/freebsd/livecd/ Supported resolution so far - 1920x1080.

Download: http://gitbrew.org/~glevand/ps3/freebsd/livecd/ps3_freebsd_livecd.iso

[PS3 News]

Following up on previous news and the PS3 Linux kernel module, this weekend PlayStation 3 developer gzorin (aka Alexander Betts) has made available RSXGL - the RSX Graphics Library for PS3.

Download: https://github.com/gzorin/RSXGL

To quote: RSXGL - The RSX Graphics Library

This library implements parts of the OpenGL 3.1 core profile specification for the PlayStation 3's RSX GPU. It's suitable for use in programs that have exclusive access to the RSX, such as GameOS software (and is likely unsuitable for implementing a multitasking desktop, as the library
doesn't arbitrate access to the RSX).

Please see the STATUS file for up-to-date information about the current capabilities of this library.

Briefly, the following OpenGL 3.1 features haven't been implemented yet (the RSX is capable of supporting most of them):

• Full GLSL support. Currently, GLSL and Cg shaders can be compiled offline and used with a OpenGL ES 2 style API.
• Instanced draw commands.
• Framebuffer objects and multiple render targets.
• glQuery*() objects.
• Point sprites.
• A variety of capabilities related to texture maps (rectangular and cube textures, the behavior of glPixelStore, copying from the framebuffer, mipmap generation, and texture formats, including compressed formats, that require conversion and/or swizzling).
• Client-side vertex array data. OpenGL 3.1's core profile specifically omits this, but it is specified by OpenGL ES 2 (as well as the OpenGL 3 compatibility profile), and is likely still widely used, particularly by smaller demonstration programs.
• Application object namespaces (another feature omitted by OpenGL 3.1, but used by earlier specs).
• Most glGet*() functions haven't been implemented. Some specified behavior of glEnable()/glDisable() likely needs to be implemented as well.

Further details follow:

• FULL GLSL SUPPORT

This is admittedly a large area of missing capability. Currently you can compile GLSL (and Cg) programs offline using NVIDIA's cgc compiler, and use them in an OpenGL program via an API that resembles the OpenGL ES 2 API - glShaderBinary() is used to load shader objects, and exactly two such shader objects (a vertex program and a fragment program) can be linked together by glLinkProgram().

This project certainly hopes to extend its implementation of GLSL further.

Intel contributed a standalone GLSL compiler to Mesa which can emit two intermediate representations that maybe could be translated to the NVIDIA microcode used by the RSX (maybe this compiler does this already; I haven't looked in a few months). Perhaps this compiler could be made to run from within a PS3 program.

Another longer avenue would be to explore writing an NVIDIA microcode backend for the LLVM compiler (my own brief investigation of this suggests that this might be hard, as LLVM possibly requires that its targets model some sort of heap, which the NVIDIA cards don't do).

There are opportunities to creatively implement other, recent OpenGL features. Uniform buffer objects could be supported, since both the vertex and fragment stages of the RSX can fetch from floating point textures. Transform feedback might be implemented by having the GLSL compiler factor out the program paths that compute vertices and generate a separate "fragment" program that renders to a buffer. Newer pipeline stages, like tesselation and geometry programs, could possibly be executed on the PS3's SPU's.

• TEXTURE FORMATS

The RSX can directly read from a handful of texture formats, but the OpenGL spec calls for many more besides. RSXGL currently implements only those formats whereby image data can simply be copied to the RSX's memory; other formats will require pixel-by-pixel type conversion and swizzling. The Mesa library appears to be able to perform many of these conversions.

• STREAMING, SYNCHRONIZATION, CACHING

Right now, RSXGL takes a conservative approach to handling data that streams to the GPU - if an application wants to write to an area of memory that the GPU is using, then the application will wait for the GPU to finish.

This library will implement other strategies. OpenGL specifies a few ways for an application to request synchronization behavior, but
affords implementations a wide latitude for interpreting such requests. Data stores might be partially or fully double-buffered, temporarily or for the entire lifetime of the memory area. Additionally, the PS3 itself makes two equally-sized memory areas available to the RSX, with different transfer speeds in each direction.

RSXGL takes a similarly greedy approach the flushing the GPU's vertex and texture caches - it does this every time a new glDraw*() command is sent by the application. The library will instead use the information it has available to it to determine if these caches really
ought to be flushed or not before drawing.

• COMMAND BUFFER FLUSHING

RSXGL performs the equivalent of a glFlush() when the framebuffer is flipped, and when the application needs to wait for the GPU to finish with a buffer before modifying its contents (in addition to the occasions when flushing is explicitly called for by a GL function
call).

I've noticed that whan a large-ish number of glDraw*() commands (on the order of several thousand) are submitted per frame without any additional flushing that performance degrades considerably. This particularly is the case if program uniform variables (such as an object's transformation matrix) are modified prior to each draw call. Therefore it's currently a good idea for the application to call glFlush() frequently.

Obviously this needs to be handled more transparently by the library itself, but I'm undecided as to a flushing policy - should it happen every draw call, or per a certain number of draw calls, or should it happen based upon the number of vertices being drawn, or the current size of the command buffer? (You can be assured that this will be an application-tunable setting.

I'm unclear as to how expensive an operation glFlush() is - it involves a small write by the PPU to the RSX's control register, allegedly a fast operation (reading from RSX memory by the PPU is not fast), but beyond that I don't know.

I haven't either tried to observe what happens when the command buffer's capacity is exceeded before the framebuffer is flipped (the libEGL implementation creates a command buffer with the capcity for 524288 commands, which is set in rsxgl_config.h and can be overriden at runtime by calling rsxeglInit() before initializing EGL).

• CLIENT VERTEX ARRAYS

The OpenGL ES 2 profile, as well as OpenGL profiles prior to version 3.1, allow an application to specify vertex data from the system's main memory, without specifically asking the library to create a buffer of some predetermined size. This usually requires the library
to implement some strategies to migrate client-side memory to the GPU, and there are likely many ways to try to perform this efficiently.

OpenGL 3.1 requires applications to create buffer objects for any vertex data (though not for index buffers; these can still be migrated
from client memory). This makes life easier for the library implementor, and is one reason why RSXGL implements GL 3.1 and not GL ES 2 (it also helps keep the data structures that the library allocates small).

Nonetheless, many existing programs depend upon the older spec, so it'd be good to support this in RSXGL (even if it's not super-efficient at first). Since supporting this older capability can potentially bloat RSXGL's data structures, this will likely be an
option specified when the library is configured.

Since client memory can be mapped into the RSX's address space, there will also be capability, implemented in the style of an OpenGL extension, for the application to promise that the client pointers submitted via glVertexArrayPointer are so mapped, eliminating a memcpy.

• APPLICATION NAMESPACES

OpenGL 3.1 requires that applications call glGen*() functions to create the names for objects that get created. ES 2 and previous GL
versions made this optional, allowing the application to come up with any unsigned integers it wanted to name objects with. This change was another reason to implement OpenGL 3.1, because it allows for a faster pool-style allocation of object data structures instead of potentially requiring a costly data structure like an associative map.

The older behavior will be supported as a configure option, too, for compatibility with existing programs.

• EXAMPLES

I'm interested in porting the [OpenGL Samples Pack] (http://www.g-truc.net/project-0026.html). They are small demonstration programs that are helpfully organized by the OpenGL profiles that they support.

INSTALL:

RSXGL uses the GNU autotools for its build system and is distributed with a configure script. It requires the following projects:

• [ps3toolchain](http://github.com/ps3dev/ps3toolchain)
• [PSL1GHT](http://github.com/ps3dev/PSL1GHT

NVIDIA's cgc shader compiler, from the Cg toolkit, is also required to use vertex and fragment GPU programs.

The RSXGL library depends upon a toolchain that can generate binaries for the PS3's PPU, and also upon parts of the PSL1GHT SDK. The sample programs also require a few ported libraries, such as libpng, which are provided by the ps3toolchain project. ps3toolchain recommends setting two environment variables to locate these dependencies:

export PS3DEV=/usr/local/ps3dev
export PSL1GHT=$PS3DEV

RSXGL's configure script will use these environment variables if they're set; if they aren't set, by default the script uses the above settings. The PORTLIBS environment variable may also be set to further control were the ported libraries can be found.

Anyway if these variables are set reasonably, then the following commands should build RSXGL and its samples:

./configure --prefix=/location/of/rsxgl
make
make install

(Sample programs are packaged into NPDRM packages, but those packages remain in their build locations; they don't get moved anywhere relative to RSXGL's install path).

By default, configure will create non-debug builds with low optimization settings (-O1). Other options are:

# Debug build, including assertions:
./configure --enable-debug

# Optimized build (-O3):
./configure --enable-ppu-optimize

The locations of the library's dependencies can be specified on the configure command-line, too:

./configure \
--with-ps3dev=/usr/local/ps3dev \
  --with-psl1ght=/usr/local/ps3dev/libpsl1ght \
--with-portlibs=/usr/local/ps3dev/portlibs

The configure expects to find versions of the gcc, g++, ar, ranlib, and ld programs that target the PS3's PPU. It tries to find these in $PS3DEV/ppu/bin, but the following environment variables can be set to provide full paths to these programs to the configure script:

PPU_CC Location of C compiler
PPU_CXX Location of C++ compiler
PPU_AR Location of the ar archive utility
PPU_RANLIB Location of the ranlib utility
PPU_LD Location of the ld linker

The following environment variables can also be set to further influence how headers and libraries are located:

PS3DEV_PPU_CPPFLAGS
PS3DEV_PPU_LDFLAGS
PSL1GHT_PPU_CPPFLAGS
PSL1GHT_PPU_LDFLAGS
PORTLIBS_PPU_CPPFLAGS
PORTLIBS_PPU_LDFLAGS

Currently two sample programs are built:

• src/samples/rsxgltest - A very simple test program whose contents and behavior will vary. This program is mainly used to try out various features of the library as they are developed.
• src/samples/rsxglgears - A port of an old chestnut, the "glgears" program that uses OpenGL to render some spinning gears. This port is based upon a version included in the Mesa library, which was itself a port to OpenGL ES 2 after being handed down throughout the ages.

The sample can print debugging information over TCP, in the manner of PSL1GHT's network/debugtest sample. src/samples/rsxgltest/main.c has symbols called TEST_IP and TESTPORT which specify the IP address and port number to try to connect to, and you can use "nc -l portnum" to receive messages.

TO DO:

• Instanced rendering
• Framebuffer objects
• x glMapBuffer* should block if an operation on the buffer is still pending.
• Better-performing glMapBuffer.
• Less conservative approach to buffer mapping & GPU cache invalidation.
• (Finish) object "orphaning" (Programs orphanable, Disposal of orphaned objects)
• x Handle timestamp overflow
• Integer vertex specification.

Textures:

• format conversion (take this from mesa).
• test mipmapping
• cube maps
• rectangular textures (x implement glTexStorage*())
• implement glCopyTexImage*() and glCopyTexSubImage*()
• proxy textures
• implement the effects of glPixelStore
• Support for GLES2-style client vertex data.
• Support for GLES2-style application object namespaces.
• Implement glGet*() functions.
• More GLSL support.
• Make it possible to work with non-EGL configured display.
• Move object storage from globals to context.
• Support multiple contexts with shared objects.
• __restrict keyword where appropriate.
• x Add libstdc++.a to libGL.a, so that client code doesn't need to use g++ to link.
• oglsamples
• Flushing and orphan cleanup policy
• Vertex program textures

More PlayStation 3 News...

[shummyr]

hopefully now that this is released, the devs will have an easier time with graphics and will make homebrew creation a little easier

[SuperSaiyen]

some progress on the RSX front! baby steps.. then walking, and hopefully then running full speed with Linux homebrew someday in the near future. Nice writeup Gzorin, tribute 2 the great work by all devs!

[Foo]

This was a lot to take in at one time. Then I finally relized what I had just read.

I can see this leading to lots of good things.