mesa-cell driver

YDL running on the Sony Playstation 3

Moderator: billb

Re: mesa-cell driver

Postby vesh » 24 Jul 2009, 14:28

haha. I thought maybe because windows has alot more software available to it that there may be another type of opengl software thing out there that works on windows, so may work on windows 98 via ydl or maybe the mesa thing might work alot better with it.
Was that a better explanation haha? I lied when I said I don't know too much about this stuff. A more accurate thing to say should've been I know nothing haha
vesh
ydl addict
ydl addict
 
Posts: 155
Joined: 15 Oct 2008, 08:40

Re: mesa-cell driver

Postby billb » 24 Jul 2009, 15:50

vesh wrote:Was that a better explanation haha? I lied when I said I don't know too much about this stuff. A more accurate thing to say should've been I know nothing haha


If you'd like to learn more about why it doesn't work this way, I'd suggest starting with the QEMU Wiki (http://calamari.reverse-dns.net:980/cgi ... StartGuide). The way we run Windows on YDL is via the QEMU emulator which emulates an x86 processesor and virtual machine (meaning it also emulates a video card, sound card, etc.), while we're using a PowerPC CPU architecture on the PS3 / YDL.

So what Windows sees as the available hardware is the video card that QEMU is emulating, and Windows will use the driver for that video card. In this case it really would make no difference even if we had hardware accelerated OpenGL video on YDL/PS3 -- Windows wouldn't be accessing it directly.

Anyway, back to discussion of the mesa-cell driver. :D
PS3 60GB [CECHA01], FW 3.15, YDL 6.2, Samsung T260HD @ 1920x1200
Powermac G4 1.25 GHz x2, 2 GB RAM, YDL 6.2
User avatar
billb
Site Admin
Site Admin
 
Posts: 5522
Joined: 24 May 2007, 20:30
Location: Eastern NC, USA

Re: mesa-cell driver

Postby vesh » 25 Jul 2009, 02:06

ok lol
vesh
ydl addict
ydl addict
 
Posts: 155
Joined: 15 Oct 2008, 08:40

Re: mesa-cell driver

Postby ninjai » 29 Jul 2009, 21:51

So let me get this straight.... the mesa-cell driver is the driver for the PS3 CPU's, and the GPU still has no real driver. When we can get the mesa-cell driver working well, we will see a huge performance increase, and can use a chunk of the huge processing powers on the PS3 to run the graphics (I heard the CPU's are not much different than that found on modern videocards..)?

Edit: I'm having a hard time understanding what the difference is between the SPE's and the main cell processor, can someone clear this up for me? I know the PS3 has a 3.2GHz PPC CPU
ninjai
ydl beginner
ydl beginner
 
Posts: 32
Joined: 28 Jul 2009, 18:14

Re: mesa-cell driver

Postby ppietro » 29 Jul 2009, 22:33

ninjai wrote:Edit: I'm having a hard time understanding what the difference is between the SPE's and the main cell processor, can someone clear this up for me? I know the PS3 has a 3.2GHz PPC CPU


The Cell has 1 PPE and 7 SPEs, of which 6 SPEs are available to Linux. The PPE - Power Processing Element - is a moderately fast, single core, dual threaded, in-order execution PowerPC processor. Each SPE - Synergistic Processing Element - is a 128bit SIMD processor. Examples of SIMD processors are SSE or AltiVec - but the SPE is much more powerful.

More info here:
http://en.wikipedia.org/wiki/Cell_(microprocessor)

Cheers,
Paul
User avatar
ppietro
Site Admin
Site Admin
 
Posts: 4965
Joined: 13 Sep 2007, 22:18

Re: mesa-cell driver

Postby ninjai » 29 Jul 2009, 22:51



That's what I was reading and I got pretty confused lol. Too many acronyms I'm unaware of.
ninjai
ydl beginner
ydl beginner
 
Posts: 32
Joined: 28 Jul 2009, 18:14

Re: mesa-cell driver

Postby dan_f14 » 18 Feb 2010, 13:08

I've tried testing this out but Im pretty certain I have gone wrong somewhere. I am guessing it was when I had to install IBMs Cell SDK as it did not go particularly smoothly. Anyway this is what I get when I type in glxinfo

Code: Select all
[dan@localhost xdemos]$ 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

[dan@localhost xdemos]$



When I try glx gears its very jerky and not smooth at all yet it claims that it gets a relatively high fps
[dan@localhost xdemos]$ glxgears
628 frames in 5.1 seconds = 123.634 FPS
720 frames in 5.9 seconds = 122.266 FPS
720 frames in 5.7 seconds = 125.275 FPS
X connection to :0.0 broken (explicit kill or server shutdown).
[dan@localhost xdemos]$


I am using cellsdk version 3.1 which is the only one I could find on the IBM site. When I looked at the mesa-cell driver it said it supported cellsdk 2.1 and 3.0, could this be the issue? When I mounted the iso and went into the rpm folder to do yum localinstall cell* it came up with an error about eclipse as there was two different version. I copied the contents of the folder and deleted the i386 version and left the ppc version and it then seemed to install ok. I then installed the mesa driver and I get these errors at the end
Code: Select all
spu_funcs.c: In function 'spu_pow':
spu_funcs.c:74: warning: control reaches end of non-void function
make[6]: *** [spu_funcs.o] Error 1
make[6]: Leaving directory `/home/dan/source/mesa/src/gallium/drivers/cell/spu'
make[5]: *** [default] Error 2
make[5]: Leaving directory `/home/dan/source/mesa/src/gallium/drivers/cell'
make[4]: *** [subdirs] Error 1
make[4]: Leaving directory `/home/dan/source/mesa/src/gallium/drivers'
make[3]: *** [subdirs] Error 1
make[3]: Leaving directory `/home/dan/source/mesa/src/gallium'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory `/home/dan/source/mesa/src'
make[1]: *** [default] Error 1
make[1]: Leaving directory `/home/dan/source/mesa'
make: *** [linux-cell] Error 2


Are these normal?

Any help would be much appreciated.

Dan

EDIT: I do not appear to have any files in my /home/dan/source/mesa/lib folder. I am guessing that is why I am getting the jerky and unsmooth glxgears as it is not actually using the spu?!?!
dan_f14
ydl beginner
ydl beginner
 
Posts: 34
Joined: 23 Nov 2009, 23:13

Re: mesa-cell driver

Postby dan_f14 » 22 Feb 2010, 13:54

Is this topic dead due to the lack of recent posts? I've tried to get it working but to no avail. If I did get it to work would it improve performance of everyday tasks such as webbrowsing, internet, etc as the spu would help with the graphics and it not be all left to the main processor to deal with? Or are my expectations for this too high?
dan_f14
ydl beginner
ydl beginner
 
Posts: 34
Joined: 23 Nov 2009, 23:13

Re: mesa-cell driver

Postby billb » 22 Feb 2010, 16:13

dan_f14 wrote:Is this topic dead due to the lack of recent posts? I've tried to get it working but to no avail. If I did get it to work would it improve performance of everyday tasks such as webbrowsing, internet, etc as the spu would help with the graphics and it not be all left to the main processor to deal with? Or are my expectations for this too high?


I'd love to be proven wrong on this, but I'm assuming the project itself is dead -- the project page hasn't been updated for some time. Also see here. There have been new Mesa 3D releases but I haven't seen anything in the change logs re: the cell driver.

If it remains in the state it was the last time I tried it then no, it's not going to be of any use. In any case it wouldn't help with everyday tasks -- it is for 3D acceleration. If it were 100% working it would be nice so we could use many of the apps that require 3D acceleration, but as it stands I believe it only works with a handful of 3D demos and screensavers.
PS3 60GB [CECHA01], FW 3.15, YDL 6.2, Samsung T260HD @ 1920x1200
Powermac G4 1.25 GHz x2, 2 GB RAM, YDL 6.2
User avatar
billb
Site Admin
Site Admin
 
Posts: 5522
Joined: 24 May 2007, 20:30
Location: Eastern NC, USA

Re: mesa-cell driver

Postby dan_f14 » 22 Feb 2010, 23:26

Thats a shame as conceptually it was a great idea. I find it strange that people did not devote more time to the cell processor as the spus have been utilised to great effect in games like Uncharted 2, so there is fantastic potential with them.
dan_f14
ydl beginner
ydl beginner
 
Posts: 34
Joined: 23 Nov 2009, 23:13

Re: mesa-cell driver

Postby androvsky » 22 Feb 2010, 23:40

billb wrote:
dan_f14 wrote:Is this topic dead due to the lack of recent posts? I've tried to get it working but to no avail. If I did get it to work would it improve performance of everyday tasks such as webbrowsing, internet, etc as the spu would help with the graphics and it not be all left to the main processor to deal with? Or are my expectations for this too high?


I'd love to be proven wrong on this, but I'm assuming the project itself is dead -- the project page hasn't been updated for some time. Also see here. There have been new Mesa 3D releases but I haven't seen anything in the change logs re: the cell driver.

If it remains in the state it was the last time I tried it then no, it's not going to be of any use. In any case it wouldn't help with everyday tasks -- it is for 3D acceleration. If it were 100% working it would be nice so we could use many of the apps that require 3D acceleration, but as it stands I believe it only works with a handful of 3D demos and screensavers.


It's not dead, it's... pining for the fjords. Really. :) I've made a point to compile the latest Cell driver every once in a while just to see where they are with it. The best place to see activity on the Cell driver is on the mesa-commit mailing list. Just a search for "Cell" in your browser.

As you can see, there's been a bit of activity in February, but for at least six months prior, there's been very little beyond making sure it compiles after other parts of Gallium have been changed. The end result is still pretty sad, unfortunately. Almost nothing runs on it, what little that does run has rendering errors (glitches in glgears... seriously). And what does run correctly only runs at most twice as fast as the old PPC rasterizer. Which means going from 2 fps on something dirt simple to 4 fps. Glgears runs at around 150 fps (swapbuffers takes a long time now, so glgears is even more useless for performance measuring than it used to be).

EDIT: I do not appear to have any files in my /home/dan/source/mesa/lib folder. I am guessing that is why I am getting the jerky and unsmooth glxgears as it is not actually using the spu?!?!

That's correct, both that and the output of glinfo saying "SGI" is the render says that you're still using the default software OpenGL. It should say something like "OpenGL renderer string: Gallium 0.4, Cell on Xlib". Newer versions even report that you have direct rendering. Once you get the libraries built, you still need to tell the system to use them, as shown in this howto: http://www.mesa3d.org/cell.html

Another helpful link: http://www.mesa3d.org/install.html

Most of what you need from the Cell SDK are the extra header files and libraries in /opt/cell (iirc). I just did a fresh install of YDL 6.2 and the Cell SDK a week ago, and mesa-cell compiled with no fuss.

Also keep in mind that gallium is currently in heavy development, so the chances that any one snapshot or svn build will even compile the Cell driver aren't 100%.
androvsky
ydl newbie
ydl newbie
 
Posts: 5
Joined: 22 Feb 2010, 22:34

Re: mesa-cell driver

Postby dan_f14 » 23 Feb 2010, 12:38

So to confirm, it does still work. However its not worth losing sleep over for me to get it to work on my system as the improvements are negligible at best at this present time?
dan_f14
ydl beginner
ydl beginner
 
Posts: 34
Joined: 23 Nov 2009, 23:13

Re: mesa-cell driver

Postby androvsky » 23 Feb 2010, 16:32

dan_f14 wrote:So to confirm, it does still work. However its not worth losing sleep over for me to get it to work on my system as the improvements are negligible at best at this present time?


Correct. I'd call it a major step down since almost nothing runs properly. I've been thinking about putting some time into improving those drivers, but it's mainly for my own education, I don't expect to make a lot of progress. If there's some breakthrough I'm sure everyone'll find out one way or another.

Otherwise, check back in a year.

Actually, I should try Neverball again with the fixed gallium build. I was getting at least 5 fps, but the textures were completely messed up.
androvsky
ydl newbie
ydl newbie
 
Posts: 5
Joined: 22 Feb 2010, 22:34

Re: mesa-cell driver

Postby Legendary_Agent » 23 Feb 2010, 18:28

ninjai wrote:


That's what I was reading and I got pretty confused lol. Too many acronyms I'm unaware of.


in a more basic explanation:

PS3 CEll or CPU however you want to call it is different from the typical home computers we use in present or in past, its a combination of gpu+cpu if that would clarifiy you a bit better altough it is not the proper term.
It is combined like this: The "CPU" has 8 Cores:
1 is 3.2ghz normal CPU core
2 SPE core, can render graphics and physics much like a gfx card, it can do a few more things but atm its irrevelant
3 Another SPE core
4 and another
5 and another
6 and another...
7Another SPE core altough this one is used as "hypervisor" think of it like an antivirus, an antivirus doesnt let your pc get harmed when it detects malware codes, a "Hypervisor" is mostly to avoid hacking and piracy, which is what makes impossible playing pirated games on ps3, and will keep that way for a long time possibly forever)
8th core is not used, and according to some sources its useless as its more used for manufacturing errors (if factories creates a damaged spe core it uses the 8th so it wont have to discard the whole cpu just because 1 core)


So in general that Cell or CPU is able to run both graphics and general tasks at such speeds that it can replace a weak/average graphic card, please note tough it cannot compete with any modern gfx card such as ati4870 or 5870.

Did that answear your question?

EDIT: Wow i tought this was a recent thread... sorry guys...
Legendary_Agent
ydl addict
ydl addict
 
Posts: 102
Joined: 03 Feb 2010, 18:35

Re: mesa-cell driver

Postby ppietro » 23 Feb 2010, 22:15

Legendary_Agent wrote:"hypervisor" think of it like an antivirus, an antivirus doesnt let your pc get harmed when it detects malware codes, a "Hypervisor" is mostly to avoid hacking and piracy,


In this case, it is also used to translate the non-traditional architecture of the PS3 into something resembling a PC. It is for this reason that we can run a fairly stock YDL on the PS3 - the hypervisor layer makes the PS3 mimic a more traditional computer.

There's a good explanation and picture of that here:
http://www.kernel.org/pub/linux/kernel/ ... rview.html

Cheers,
Paul
User avatar
ppietro
Site Admin
Site Admin
 
Posts: 4965
Joined: 13 Sep 2007, 22:18

PreviousNext

Return to Playstation 3

Who is online

Users browsing this forum: No registered users and 14 guests

cron