Freezer 3D Graphics Engine for Cell BE

[ouasse]

I don't know about the current status of the Cell driver in Mesa 3D, but when it was first released (July 2009 IIRC), it was buggy and with poor performance (glxgears showed a speedup of about 2 compared to the use of the PPE alone). It certainly evolved since then, and perhaps now is faster, but even with a speedup of 10, I still would consider it slow.

Freezer was not designed to be a Mesa/OpenGL replacement. Being OpenGL compliant is a real challenge and would require much more work than what I did in Freezer. Maybe there are ways to use parts of Freezer in Mesa (if the licences are LGPL-compatible).

However, the main objective in Freezer was to build an engine that would be as fast and efficient as possible. I guess the objective in the Cell Mesa driver was OpenGL compliance, not speed and efficiency.

So if you want good performance, don't use Mesa. Mesa is useful to get (little) acceleration when running already-existing OpenGL programs. If performance is an issue, and you want to develop for the Cell processor, better use Freezer.

[Iguana]

Freezer was not designed to be a Mesa/OpenGL replacement. Being OpenGL compliant is a real challenge and would require much more work than what I did in Freezer. Maybe there are ways to use parts of Freezer in Mesa (if the licences are LGPL-compatible).

However, the main objective in Freezer was to build an engine that would be as fast and efficient as possible. I guess the objective in the Cell Mesa driver was OpenGL compliance, not speed and efficiency.

So if you want good performance, don't use Mesa. Mesa is useful to get (little) acceleration when running already-existing OpenGL programs. If performance is an issue, and you want to develop for the Cell processor, better use Freezer.

I have another general question about Freezer; About how far advanced and how compatable is it with the use of enabled 3D graphics?

For instance, if it were used for emulator purposes.... Ummm.... Ok lets start with this; since the ps3's graphics card is blocked by the hyporvisor (sony uses the hyporvisor as a security lock-down which also locks-down other hawdware features on the ps3's linux) this leaves the ps3's linux with a simple framebuffer, one ppu, and (I think) 6 spu's, and other hardware stuff... So, when using emulators' the framebuffer enables only 2D graphics and anything else beyond that point gets laggy, slow, choppy, and glitchy; for example on some emulators see this site ----->>> http://blogs.ydl.net/billb/2008/03/04/emulation-and-linux-gaming-on-the-ps3/

Also, I was wondering if Freezer would be compatable with the Zerogame Project (since Zerogame works with any ps3 linux compatable distrobution) or would it have to be added to the initial zerogame setup script? ----->>> http://thezerogameproject.com/ I was wondering.. Just so the project could be kept more alive with added support for 3D games and emulators...

P.S. All this is just becoming soo interesting for me and others to learn from, know, and think about...

[ouasse]

As the library has just been released, don't expect already existing projects to support it right now. However, as I said before, there might be a possibility to integrate parts of Freezer in a OpenGL driver, or even build a new OpenGL driver from Freezer. In such a case, OpenGL-enabled programs such as some Linux 3D games or emulators should be working with acceleration with no change.

That work is not done, and I don't have enough OpenGL experience to tell how much work is required. If anyone with experience in the OpenGL internals feels like doing it, I would be glad to provide as much support (on the Freezer side, not OpenGL) as required.

And moreover, I'm working on Freezer in my spare time, so I would be glad if some people contributed or started Freezer-based projects. If you want accelerated 3D stuff on the ps3, now there is a way for it.

[TheOneFallen]

I feel stupid for asking this but what exactly could it be used for, speeding up things on the Linux front or allowing 3D games/programs to be played, or even, dare I say it, both?

[Iguana]

I feel stupid for asking this but what exactly could it be used for, speeding up things on the Linux front or allowing 3D games/programs to be played, or even, dare I say it, both?

From my understanding it would be used fo both reasons, but it'ld mainly focus on speeding up 3D applications such a games and 3D programing and even more 3d related stuff..
Theres a 3d driver that works on the ps3 called mesa cell (p.s. search it up using the board's search feature) and it's based on Open GL(a 3d graphics renduring software utility) and mesa cell is an all software 3d accelerating program without the need of any 3d hardware acceleration(though I think the bad thing about the messa cell driver is that it puts more lode on the framebuffer and spus'/ppu).. Also, freezer isn't based on Open GL, freezer is more of a custome 3d program thats all software based just like mesa cell, but it's designed more for speed (and making a program run faster) on executing 3d programs, because it doesn't force too much work on the framebuffer, ppu, and spus'..
Oh, and if freezer were implied with Open GL, then maybe we could have as close to full 3d acceleration on the ps3 then we could ever have... But, even with all this, there would still be a killer amount of work to do for support and improvement on 3d acceleration for the ps3's linux....

[ppietro]

I feel stupid for asking this but what exactly could it be used for, speeding up things on the Linux front or allowing 3D games/programs to be played, or even, dare I say it, both?

If you're writing a game from scratch, you could include the Freezer libraries to add some fast 3D to your game.

As the developer of Freezer mentions earlier in this very thread:

I insist on the fact that the library is mostly dedicated to developers, and I guess non-developers won't find much of interest in it, except for trying and running the (very simple) sample programs.

As for the PS3 and how it fits in the world of Linux, here's the quick (!) summary:

Linux is designed to support many different types of graphic displays. Like Windows, it accomplishes this via video drivers. Also like Windows, most Linux games are written using some sort of 3D library. In Windows, there's two main libraries - Direct3D and OpenGL. Direct3D is Windows proprietary, but OpenGL is cross platform - Linux, Mac, Windows. For the purposes of this discussion, we'll focus on OpenGL, but most of this applies to Direct3D as well.

Modern video drivers have an interface that lets you access the video card's powerful 3D and 2D acceleration. OpenGL is written to use this interface - and by extension - the 3D and 2D acceleration. So - you - as a programmer - can write a game in OpenGL, and the underlying software quickly translates your code into powerful 3D graphics.

It is for this reason that most 3D games in Linux are written using OpenGL.

Now - when you write a game in OpenGL, you don't actually include OpenGL with your game. Instead, you write the game using a published set of application programming interfaces - or what we call "APIs". A game that uses OpenGL APIs would load a local OpenGL library at runtime, and talk to it via these known and published interfaces. This OpenGL library can be optimized for your computer hardware and your operating system, including low level hooks to your 3D card hardware.

The beauty of this is that you don't have to know anything about how your video card handles 3D - or even which video card you have. If you write to the OpenGL API - to the published specifications - your system libraries will handle the rest.

Early on, 3D cards were pretty rare. Most cards were non-accelerated 2D bitmapped displays. A group of folks wrote a complete OpenGL rendering library using software only; no 3D hardware was required. This rendering library was called Mesa. This allowed OpenGL programs that weren't too graphic intensive - e.g. a 3D chart graphing application - to run on *any* Linux box. (Also - OpenGL had some copyright issues that Mesa was able to work around to truly provide an open source alternative.)

Most Linuxes include some form of Mesa by default, since it's open source, and it runs completely in software.

This brings us to the PS3.

Although the PS3 has a nVidia graphics "card" called the RSX - with corresponding 3D & 2D acceleration - the Sony hypervisor prevents access to it. Instead, PS3 Linux sees the display as a very simple CPU-driven framebuffer display. This means that the same CPU that is running your program must also draw every pixel on the screen.

The Cell processor in the PS3 has a Power Processing Element (PPE) core and 7 Synergistic Processing Element (SPE) sub-processors. Unfortunately - Linux can only directly use the PPE core - which is a moderately fast single core, dual threaded, in-order execution PowerPC processor. There are 6 SPEs are available - one is always held in reserve, even in the GameOS - but no normal Linux program will take advantage of them.

Since the PS3 presents only a framebuffer display, none of the accelerated OpenGL rendering libraries will work. They all depend on having access to the 3D accelerated hardware of the video card.

So - we fall back to the default software-only Mesa library.

What this means is that any OpenGL-based Linux game that is expecting accelerated 3D hardware will fail when the OpenGL rendering library (mesa) announces its feature set.

If you have OpenGL (mesa) installed in YDL, you can see this yourself by issuing the "glxinfo" command.

Code: Select all

[ppietro@localhost ~]$ glxinfo
name of display: :0.0
display: :0  screen: 0
direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose)
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method,
    GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe,
    GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_MESA_copy_sub_buffer
client glx vendor string: SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory,
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control,
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control,
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync,
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer,
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap
GLX version: 1.2
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context,
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer,
    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample,
    GLX_SGIX_fbconfig, GLX_EXT_texture_from_pixmap
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.4 (2.1 Mesa 7.1)
OpenGL extensions:
    GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program,
    GL_ARB_fragment_program_shadow, GL_ARB_imaging, GL_ARB_multisample,
    GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_point_parameters,
    GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shadow_ambient,
    GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
    GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle,
    GL_ARB_transpose_matrix, GL_ARB_vertex_program, GL_ARB_window_pos,
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate,
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
    GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements,
    GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays,
    GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_point_parameters,
    GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color,
    GL_EXT_separate_specular_color, GL_EXT_shadow_funcs,
    GL_EXT_shared_texture_palette, GL_EXT_stencil_wrap, GL_EXT_subtexture,
    GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp,
    GL_EXT_texture_env_add, GL_EXT_texture_env_combine,
    GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias,
    GL_EXT_texture_mirror_clamp, GL_EXT_texture_object,
    GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels,
    GL_ATI_draw_buffers, GL_ATI_texture_env_combine3,
    GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3,
    GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate,
    GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square,
    GL_NV_fragment_program, GL_NV_light_max_exponent, GL_NV_point_sprite,
    GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_NV_vertex_program,
    GL_NV_vertex_program1_1, GL_SGI_color_matrix, GL_SGI_color_table,
    GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
    GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture,
    GL_SGIX_shadow, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays

2 GLX Visuals
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x21 24 tc  1 24  0 r  y  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0x3a 32 tc  1 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None

16 GLXFBConfigs:
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x3b  0 tc  1 24  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x3c  0 tc  1 24  0 r  y  .  8  8  8  0  0  0  8  0  0  0  0  0 0 None
0x3d  0 tc  1 24  0 r  y  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0x3e  0 tc  1 24  0 r  y  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0x3f  0 tc  1 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x40  0 tc  1 24  0 r  .  .  8  8  8  0  0  0  8  0  0  0  0  0 0 None
0x41  0 tc  1 24  0 r  .  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0x42  0 tc  1 24  0 r  .  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0x43  0 tc  1 32  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x44  0 tc  1 32  0 r  y  .  8  8  8  0  0  0  8  0  0  0  0  0 0 None
0x45  0 tc  1 32  0 r  y  .  8  8  8  0  0 32  0  0  0  0  0  0 0 None
0x46  0 tc  1 32  0 r  y  .  8  8  8  0  0 32  8  0  0  0  0  0 0 None
0x47  0 tc  1 32  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x48  0 tc  1 32  0 r  .  .  8  8  8  0  0  0  8  0  0  0  0  0 0 None
0x49  0 tc  1 32  0 r  .  .  8  8  8  0  0 32  0  0  0  0  0  0 0 None
0x4a  0 tc  1 32  0 r  .  .  8  8  8  0  0 32  8  0  0  0  0  0 0 None

[ppietro@localhost ~]$

That's a lot of information, but what we're concerned with here is the "direct rendering: no" line at the top. Basically, this means no hardware accelerated 3D graphics.

So - what does this all mean?

Mesa is OpenGL in software. This won't work for most games that require OpenGL to have hardware accelerated 3D support.

The PS3 has a framebuffer display. We can't write a 3D OpenGL driver to use the nVidia RSX since it's "hidden" by the hypervisor.

Also - although the PS3 has a Cell processor, we're only using the PowerPC core.

A group of folks tried to re-write Mesa to accelerate some of the functions using the unused SPEs in the Cell. This project lost steam and seems to have ended. It works - somewhat. Not enough of this mesa-cell library was finished to realistically work with OpenGL-based 3D games.

Freezer is a separate 3D library that you can use. It is not an OpenGL replacement, so most 3D games can't use it, and won't see it. A game would have to be written specifically to utilize Freezer. You can't "post fix" a game to use it, without altering the source code of the game and regenerating the binaries.

This is beyond the scope of most folks, I'd guess - myself included.

Freezer does not access the RSX directly, since it's locked out via the hypervisor. Instead, sorta like the Mesa-cell driver, it uses the SPEs to provide 3D acceleration for the framebuffer display.

This won't accelerate general PS3 Linux programs - nor will it provide any additional access to the RSX. Instead, it will simplify the writing of fast 3D programs on the PS3 with a library you can use.

In the future, Freezer could be used to accelerate OpenGL, which would translate to faster graphical applications on the PS3. This would basically work like Mesa-Cell does right now, but probably a lot better. However - someone would have to "connect" OpenGL to Freezer - and that might not be an easy lift. (I certainly won't be doing that! I can barely program Java. )

I hope this helps set your expectations a little more realistically.

Cheers,
Paul

[billb]

Tried building freezer today but ran into a < version problem with autoconf ...

./bootstrap
configure.ac:20: error: Autoconf version 2.65 or higher is required
configure.ac:20: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
aclocal: autom4te failed with exit status: 63

rpm -q autoconf
autoconf-2.59-12

I guess we'll have to update autoconf?