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

unsolo · Post by **unsolo** » Wed Jan 16, 2008 4:49 am

we are working on a 2d driver in spu-medialib that supports EXA not to much work left to make it work the right way.. there is also a "unstable" but working(64 bit ppc userland) spu acellerated Xv driver in that lib.

currently im a bit side tracked as im looking into a general purpose "message/fifo" thing for the spe's but they will be completed (help is also wanted)

eddd · Post by **eddd** » Wed Jan 16, 2008 10:10 pm

I can try and help! I don't know how much use I would be, I did 2 years of C/C++ in my engineering degree but not very experienced in applied programming, but I want to learn! Pretty hot with Linux in general though, and I've got all sorts of things working on Fedora with PS3. Feel free to drop me a PM!

pfvdr · Post by **pfvdr** » Fri Jan 18, 2008 4:02 pm

Hi there, great to hear some people have this (2d EXA at least) working on 2.10 now. I am late to the party it seems:-)

I've tried to set up my system using:
* 2.6.23-20071219 from geoff's CELL-Linux-CL_20071220-ADDON (has ps3fb-fix-gpu-cmd-buff-size-2.10-linux-2.6.23-20071023.diff patched)
* ps3rsx checked out from GIT on 2008.01.14

The module builds fine but in its unaltered form from GIT, a segmentation fault is thrown when insmod'ing it (see logs below)

For the suggested fix from Glaurung (1ULL<<60 trick in ps3rsx module), the system allways locks with seemingly a lot of harddrive access ongoing. This happens whether I am in X or when X is not running. I can also not see any new console output to indicate the problem.

Is there now a definite way around loadign the ps3rsx module in 2.10 yet that I maybe missed in the thread?

Thanks for any help!

FYI: The commands and relevant part of dmesg for unaltered ps3rsx is probably not interesting but I post it anyway.

Code: Select all

>uname -a
Linux pyps3 2.6.23-ppc64 #1 SMP PREEMPT Sun Jan 13 22&#58;27&#58;08 SAST 2008 ppc64 ppc64 ppc64 GNU/Linux
>insmod ps3rsx.ko
Segmentation fault
>dmesg
...
ps3rsx&#58; PS3 RSX access module, 1.0.0
ps3rsx&#58; reserved XDR memory is @c000000000c00000, len 9437184
ps3rsx&#58; lv1_gpu_memory_allocate failed&#58; -17
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address&#58; 0xc0000000001c5a34
Oops&#58; Kernel access of bad area, sig&#58; 11 &#91;#1&#93;
PREEMPT SMP NR_CPUS=2 NUMA PS3
Modules linked in&#58; ps3rsx ppp_deflate zlib_deflate bsd_comp ppp_async crc_ccitt ppp_generic slhc snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device binfmt_misc sd_mod loop sr_mod cdrom usb_storage snd_ps3 snd_pcm snd_page_alloc snd_timer snd soundcore cdc_acm hci_usb bluetooth sg ps3rom scsi_mod
NIP&#58; c0000000001c5a34 LR&#58; d0000000001ac1d0 CTR&#58; c0000000001c5a0c
REGS&#58; c0006c005e61b820 TRAP&#58; 0300   Not tainted  &#40;2.6.23-ppc64&#41;
MSR&#58; 8000000000008032 <EE,IR,DR>  CR&#58; 22022222  XER&#58; 00000000
DAR&#58; 0000000000000000, DSISR&#58; 0000000040000000
TASK = c0006c005ef1cd90&#91;8659&#93; 'insmod' THREAD&#58; c0006c005e618000 CPU&#58; 1
GPR00&#58; d0000000001ac1d0 c0006c005e61baa0 c0000000004a2f68 0000000000000000
GPR04&#58; 0000000000000000 ffffffffffffffff c0000000004c8058 0000000000080000
GPR08&#58; c0000000004c8580 c0000000004be1d0 0000000000004578 c0000000001c5a0c
GPR12&#58; d0000000001acd80 c000000000426d00 0000000000000061 d000000000175ae0
GPR16&#58; d0000000001ade08 000000000000fff1 000000000000fff2 0000000000000061
GPR20&#58; d0000000001752ee 0000000000000000 0000000000000000 000000000000001e
GPR24&#58; 000000000000001e 0000000000000001 4000000000000000 c0000000004101d8
GPR28&#58; d0000000001af4b0 c000000000b5c800 c000000000454b60 0000000000000000
NIP &#91;c0000000001c5a34&#93; .unregister_framebuffer+0x28/0x104
LR &#91;d0000000001ac1d0&#93; .cleanup_ps3rsx+0x88/0xc0 &#91;ps3rsx&#93;
Call Trace&#58;
&#91;c0006c005e61baa0&#93; &#91;0000000000000001&#93; 0x1 &#40;unreliable&#41;
&#91;c0006c005e61bb40&#93; &#91;d0000000001ac1d0&#93; .cleanup_ps3rsx+0x88/0xc0 &#91;ps3rsx&#93;
&#91;c0006c005e61bbc0&#93; &#91;d0000000001acc90&#93; ._ps3rsx_init+0x25c/0x82c &#91;ps3rsx&#93;
&#91;c0006c005e61bc70&#93; &#91;c0000000000767c4&#93; .sys_init_module+0x16d4/0x1844
&#91;c0006c005e61be30&#93; &#91;c000000000008534&#93; syscall_exit+0x0/0x40
Instruction dump&#58;
ebe1fff8 4e800020 7c0802a6 fbc1fff0 fbe1fff8 fb81ffe0 fba1ffe8 ebc2b0c0
f8010010 f821ff61 7c7f1b78 e93e8010 <eba30002> 7ba01f24 7c09002a 2fa00000

jimparis · Post by **jimparis** » Fri Jan 18, 2008 4:47 pm

I don't know what you're hearing but no, the ps3rsx does not work on 2.10. Also, there is a thread already dedicated to ps3rsx module support, no need to clog this topic. http://forums.ps2dev.org/viewtopic.php?t=9479&start=90

pfvdr · Post by **pfvdr** » Fri Jan 18, 2008 5:00 pm

Hi jimparis, sorry i did not mean to clog this topic.

In "PS3RSX Binary driver support" and in this topic (think around p13) there seemed to be some conflicting reports that it did work on 2.10 (esp after the 60<<ULL change it sounded promising) so I decided to give it another try.

If you, IronPeter or Galurung would like some testing to be done, I am more than willing to try help get dumps/logs. I think I will try out unsolo's SPE based driver next

Thanks, best regards
Pierre

mattruby · Post by **mattruby** » Wed Jan 23, 2008 4:57 am

unsolo wrote:we are working on a 2d driver in spu-medialib that supports EXA not to much work left to make it work the right way.. there is also a "unstable" but working(64 bit ppc userland) spu acellerated Xv driver in that lib.

currently im a bit side tracked as im looking into a general purpose "message/fifo" thing for the spe's but they will be completed (help is also wanted)

Any note on the status of the SPU drivers (X, MPlayer), and maybe a projected delivery date? And any discussion of what exactly people could help you with? Have you considered opening your project, maybe on SourceForge or just someone's SVN, even if you remain the sole committer?

IrquiM · Post by **IrquiM** » Fri Jan 25, 2008 2:28 am

mattruby wrote:Any note on the status of the SPU drivers (X, MPlayer), and maybe a projected delivery date? And any discussion of what exactly people could help you with? Have you considered opening your project, maybe on SourceForge or just someone's SVN, even if you remain the sole committer?

How about checking this: http://forums.ps2dev.org/viewforum.php?f=29 ?

mattruby · Post by **mattruby** » Fri Jan 25, 2008 3:36 am

IrquiM wrote:
mattruby wrote:Any note on the status of the SPU drivers (X, MPlayer), and maybe a projected delivery date? And any discussion of what exactly people could help you with? Have you considered opening your project, maybe on SourceForge or just someone's SVN, even if you remain the sole committer?
How about checking this: http://forums.ps2dev.org/viewforum.php?f=29 ?

There is SVN access, as that thread indicates. But I'd love to see a status report on it (an ETA would be beautiful, however vague or uncertain) and maybe some more specific requests for help that could get some specific people to help.

chrisPrice · Post by **chrisPrice** » Sun Jan 27, 2008 4:50 pm

ATTENTION Mr Glaurung

can you please post your ps3fb.c and ps3fb.h
whole rather than the diffs. They do not match the
original file in his current site.

chrisPrice · Post by **chrisPrice** » Sun Jan 27, 2008 7:40 pm

specifically geoff has put in ps3fb.c tar dated 20071219

in func ps3fb_probe before ps3fb_xdr_settings
code in geoffs kernel source says GPU command buffer
compared to yours is out of syn whether it is at start/end of
video memory.

Glaurung · Post by **Glaurung** » Mon Jan 28, 2008 1:43 am

Do not patch your kernel, use the ps3rsx module instead. For this to work you need FW <= 2.01.

I'm still looking at a way to workaround the video ram limit enforced in FW 2.1. Here is the current status:
- Calling lv1_gpu_memory_allocate with bits 52-63 set works and bypass the size check. However ps3rsx fifo_program crashes when programming offset 0x188 of 2D ContextSurface object (bound to subchannel 3), for unknown reason. Even skipping this step, blitting from/to upper vram does not work. Need to check with upload-to-screen and download-from-screen memory-to-memory objects instead of blit object.
- There is a new lv1_context_attribute call (0x603) in FW2.1, purpose yet unknown. Need to investigate accepted parameter values and their effect.
- DMA objects can be bound to FIFO subchannels, it is not yet known if they can be modified from there.
- Amusingly, lv1_gpu_context_attribute:display_flip is able to display the upper vram. Looking at RAMIN without being able to access it is somewhat frustrating :-)
- The "FIFO size must be 2MB" comment is not relevant for ps3rsx. This is a limitation in the lv1_gpu_context_attribute:fb_setup call, which we don't use. I suspect it is there to ensure there is enough FIFO room for HV supported FB calls. Hence the importance of investigating the new 0x603 call.

IronPeter and others, let me know if you've found anything else interesting regarding FW2.1, or if you have any ideas of what to investigate next. As you can see there are still have a few things to try, but fresh ideas/information is welcome.

ps2devman · Post by **ps2devman** » Mon Jan 28, 2008 1:56 am

@chrisPrice, we will try to fix your trouble in this tread :
http://forums.ps2dev.org/viewtopic.php?p=64103#64103
(linux ps3 forum is good place for support help requests)

"The hunting" thread should remain focused on new discoveries or ideas.

@glaurung, here is some hypothesis :
in fw<2.10, HV did a few settings, in order to minimize the number of calls to make to HV from Linux code.
in fw>=2.10, HV does a few less settings itself, so the rsx hack fails miserably... But these settings may still be needed later, for a more authorized code to run, or for testing internally at Sony. The new call that appeared may be that setting. On nv2A I often got GPU errors when I tried to draw things without the dma settings correctly set first. These settings removed in 2.10 may be dma settings, perhaps... Need to survey geoff's work to see if he's planning to add such settings in future too...
If something official appears, 3D related, it may be obfuscated I fear.

In fact, I know it's horrible, but I have the feeling Sony high ranks will never permit 3D through RSX on ps3 linux because they want highest game attach rate possible (so by discouraging ps3 purchases for linux thay might achieve that), whereas Sony engineers, enjoying a lot fully powered linux on ps3 for their own private usage, will keep on maintaining secret HV apis.... Bleh...

IronPeter · Post by **IronPeter** » Mon Jan 28, 2008 2:02 am

Hi, Glaurung, did you upgrade your firmware?

>programming offset 0x188 of 2D ContextSurface object

Hmm... The push buffer dump after FB_SETUP in FW 2.1 was published. It contains 0x188 tag setup.

Can you try to work with ps3fb's fifo context, not with your own?

Glaurung · Post by **Glaurung** » Mon Jan 28, 2008 4:02 am

First of all, no I did not upgrade, I'm still using 2.01. However a friend of mine (posting as tgnard here) has upgraded to 2.1 and is interested in getting the RSX back; so we can compare the behaviour of the HV on the two boxes.

@ps2devman, yes maybe the new call is a second part of some setup. Although the call itself succeeds, it crashes further ps3fb blits with a unusual value: LV1_WRONG_STATE (-11) instead of the usual LV1_HARDWARE_ERROR (-24). So, maybe it is a 'setup fb for 3D' call :-).

@IronPeter, indeed the FB_SETUP FIFO code is the same on FW2.1, so there is no reason calling it from another context would crash. It also seems that the ContextSurface objects are not that context-dependent. Anyway, testing with ps3fb context is a good idea, although slightly less practical (using 1UL<<63 instead of the true allocation may simply crash FB_BLIT on startup). I suspect the crash is due to the feed0000 object being not properly setup when using 1UL<<63 for the allocation. It probably starts at 0 but its limit may be incorrect.

IronPeter · Post by **IronPeter** » Mon Jan 28, 2008 4:11 am

Bad formed video-memory object can crush blits, of course.

We need fifo dump after 603 call.

Also we need to check list of objects inside driver_info.

tgnard · Post by **tgnard** » Mon Jan 28, 2008 7:23 am

The fifo seems unchanged after the 603 call.

Same for the objects list.

stesmi · Post by **stesmi** » Fri Mar 14, 2008 3:07 pm

Now to see who will test stuff using 2.17 that's just out.

JPedro · Post by **JPedro** » Fri Mar 14, 2008 8:14 pm

I have upgraded to 2.17, I'll just need to get my Linux install running again and I can do any tests you like :)
Hopefully I got some time this weekend

gigi · Post by **gigi** » Thu Mar 27, 2008 7:44 pm

Just to add a little contribution to this topic , the lv1_gpu_device_map ( see wiki ) is different between fw releases , i should update the wiki with my findings a day , for now from my kernel module:

Fw 1.9.3 ( asking to map device 9,10,11 ):

[ 193.304459] *Video RAM at offset 0x0ff10000*******
[ 193.304466] OK MAP_DEVICE8_GPU_R3_STAT, hex = 300000035000
[ 193.304474] OK MAP_DEVICE8_GPU_R4_ADDR, hex = 1000
[ 193.304481] OK MAP_DEVICE8_GPU_R5_SIZE, hex = 0
[ 193.304491] ************************
[ 193.304497] ILLEGAL LV1_MAPDEVGPU9_UNKNOWN_R3, hex = 0
[ 193.304505] ILLEGAL LV1_MAPDEVGPU9_UNKNOWN_R4, hex = 0
[ 193.304512] ILLEGAL LV1_MAPDEVGPU9_UNKNOWN_R5, hex = 0
[ 193.304520] ILLEGAL LV1_MAPDEVGPU9_UNKNOWN_R6, hex = 0
[ 193.304530] ************************
[ 193.304536] ILLEGAL LV1_MAPDEVGPU10_UNKNOWN_R3, hex = 0
[ 193.304544] ILLEGAL LV1_MAPDEVGPU10_UNKNOWN_R4, hex = 0
[ 193.304552] ILLEGAL LV1_MAPDEVGPU10_UNKNOWN_R5, hex = 0
[ 193.304560] ILLEGAL LV1_MAPDEVGPU10_UNKNOWN_R6, hex = 0
[ 193.304570] ************************
[ 193.304576] ILLEGAL LV1_MAPDEVGPU11_UNKNOWN_R3, hex = 0
[ 193.304584] ILLEGAL LV1_MAPDEVGPU11_UNKNOWN_R4, hex = 0
[ 193.304592] ILLEGAL LV1_MAPDEVGPU11_UNKNOWN_R5, hex = 0
[ 193.304600] ILLEGAL LV1_MAPDEVGPU11_UNKNOWN_R6, hex = 0

Fw 2.1.0 ( asking to map device 9,10,11 ):

Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU9_UNKNOWN_R3, hex = 3000000B9000
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU9_UNKNOWN_R4, hex = 1000
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU9_UNKNOWN_R5, hex = 0
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU9_UNKNOWN_R6, hex = 0
Mar 18 13:44:22 ps3 kernel: ************************
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU10_UNKNOWN_R3, hex = 3000000B9000
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU10_UNKNOWN_R4, hex = 1000
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU10_UNKNOWN_R5, hex = 0
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU10_UNKNOWN_R6, hex = 0
Mar 18 13:44:22 ps3 kernel: ************************
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU11_UNKNOWN_R3, hex = 3000000B9000
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU11_UNKNOWN_R4, hex = 1000
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU11_UNKNOWN_R5, hex = 0
Mar 18 13:44:22 ps3 kernel: DENIED LV1_MAPDEVGPU11_UNKNOWN_R6, hex = 0

Fw 2.1.6 ( asking to map device 9,10,11 ):

************************
DENIED LV1_MAPDEVGPU9_UNKNOWN_R3, hex = 300000029000
DENIED LV1_MAPDEVGPU9_UNKNOWN_R4, hex = 1000
DENIED LV1_MAPDEVGPU9_UNKNOWN_R5, hex = 0
DENIED LV1_MAPDEVGPU9_UNKNOWN_R6, hex = 0
************************
DENIED LV1_MAPDEVGPU10_UNKNOWN_R3, hex = 300000029000
DENIED LV1_MAPDEVGPU10_UNKNOWN_R4, hex = 1000
DENIED LV1_MAPDEVGPU10_UNKNOWN_R5, hex = 0
DENIED LV1_MAPDEVGPU10_UNKNOWN_R6, hex = 0
************************
DENIED LV1_MAPDEVGPU11_UNKNOWN_R3, hex = 300000029000
DENIED LV1_MAPDEVGPU11_UNKNOWN_R4, hex = 1000
DENIED LV1_MAPDEVGPU11_UNKNOWN_R5, hex = 0
DENIED LV1_MAPDEVGPU11_UNKNOWN_R6, hex = 0
**************************************

This -may- be related to the main problem.

Hope it helps

Ciao
gg

bongo · Post by **bongo** » Wed Apr 16, 2008 8:02 am

anything happening here?

moreno · Post by **moreno** » Thu Jun 12, 2008 5:12 am

demiurg_hg · Post by **demiurg_hg** » Sat Jun 14, 2008 12:09 am

Interesting, how hypervisor restricts access to RSX:

1) hypervisor "think" as: When I run GameOS, I should provide access to RSX,
and when I run OtherOS, I should restrict access to RSX

OR

2) Simply, we dont know about necessary hypervisor`s calls?

jimparis · Post by **jimparis** » Sat Jun 14, 2008 12:59 am

Either is possible, but many suspect that #2 is closer to the truth.
edit: To be clear, #2 is definitely true, we don't know which hypervisor calls to use. #1 might be true but we don't know.

IronPeter · Post by **IronPeter** » Tue Jun 17, 2008 12:55 am

Vote for #2

cyberfix · Post by **cyberfix** » Tue Jun 17, 2008 1:09 am

jimparis wrote:Either is possible, but many suspect that #2 is closer to the truth.
edit: To be clear, #2 is definitely true, we don't know which hypervisor calls to use. #1 might be true but we don't know.

I thought there was a post by MC about locations have just changed on newer firmware versions. Was this ever verified and does this mean that newer firmwares may still have hope? This thread used to be so busy and I enjoy reading about all of the findings. Is there another thread that is updated with new ideas and theories?

Thanks!

IronPeter · Post by **IronPeter** » Mon Jul 14, 2008 5:46 pm

I have an idea about possible test.

there is lv1_gpu_open function with 1 parameter. There is lv1_gpu_device_map function and LV1_ILLEGAL_PARAMETER_VALUE return code for device 0 and 4.

http://wiki.ps2dev.org/ps3:hypervisor:l ... device_map

Can somebody test

Code: Select all

for&#40; int i = 0; i < 64; ++i &#41;
&#123;
  lv1_gpu_open &#40; 1 << i &#41;;
  lv1_gpu_device_map&#40;...&#41;;//get iomapped dumps here.
  lv1_gpu_close&#40;&#41;;

&#125;

IronPeter · Post by **IronPeter** » Sat Jul 19, 2008 6:54 am

I used some code to probe lv1_gpu_context_attribute subfunctions with LV1_ILLEGAL_PARAMETER_VALUE return value;

Refer http://wiki.ps2dev.org/ps3:hypervisor:l ... _attribute

Code: Select all


u64 tbl&#91;&#93; = &#123; xdr_lpar, 0x200, 0x201, 0x100, 0x101, 0x102, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, GPU_IOIF, &#40;u64&#41;&#40;-1&#41;, 1UL << 63, 1UL << 62, 1UL << 61, 1UL << 60 &#125;; 
int s = sizeof&#40; tbl &#41;/ sizeof&#40; tbl&#91;0&#93; &#41;;

for&#40; i0 = 0; i0 < s; ++i0 &#41;
for&#40; i1 = 0; i1 < s; ++i1 &#41;
for&#40; i2 = 0; i2 < s; ++i2 &#41;
for&#40; i3 = 0; i3 < s; ++i3 &#41;
status = lv1_gpu_context_attribute&#40;ps3gpu.context_handle, i, tbl&#91;i0&#93;, tbl&#91;i1&#93;, tbl&#91;i2&#93;,  tbl&#91;i3&#93; &#41;;

Subfunctions 0x108 and 0x300 work ( LV1_SUCCESS ) with some key combinations.

fordfairmont · Post by **fordfairmont** » Thu Jul 24, 2008 1:56 am

OK guys im gonna come across as the biggest nub about now as i have no coding or programming experience. Feel free to scoff and snigger, I dont mind if i get some answers

I have been searching for info on getting pc games to run on my ps3 with linux and ended up here. From what i have gathered so far u guys are trying to open up the RSX (main graphics processor for the ps3, correct me if im wrong.)

How far have u guys actually got with it and how do i apply what u guys have made to my ps3?

My main question is though what sort games can i run thru linux before i have to start modding?

What would b say the max system specs i could get before i had to modify it?

ps2devman · Post by **ps2devman** » Thu Jul 24, 2008 7:05 pm

I'll try to answer you by gathering what have been done so far :

Thanks to IronPeter, you get control over 70% of the power of a Nv40 GPU (named RSX) on PS3's with firmwares < 2.10 (if you have 2.10 or above you have no GPU under your control, only a 2D space that is sent to screen every frame by Hypervisor itself through your authorized call).

http://wiki.ps2dev.org/ps3:rsx is where are gathered RSX related infos.

http://ps3rsx.googlecode.com/svn/trunk/ is IronPeter's 3D sample
(Control over GPU is useful for 2 things. One is Hardware Accelerated 3D)

http://mandos.homelinux.org/~glaurung/ps3/ is Glaurung's kernel patch
(Other thing is kernel control of 2D bitblits with specific properties.)

IronPeter's last 3D samples are tuned to run with Glaurung's kernel mod.

If you run Linux or OtherOS software (Mc made one) and use Glaurung's method to open RSX to regular kernel control, you obtain 2D hardware acceleration in a compatible enough way so all 2D ports you do will get accelerated. 3D ports is another affair. There is no friendly OpenGL port or similar made to take advantage of IronPeters's discoveries. So you can do accelerated 3D but by programming it at very low level. So no direct 3D ports are possible. Also the lack of TILE and ZCOMP access reduces by 30% the performance and the number of PS3's with firmware<2.10 is probably low on the planet at the moment...

So that's the current situation.

I assume lastest posts you see above in this thread are the lastest attempts to unlock RSX on firmwares >= 2.10 (failed so far).

There are projects in progress for firmwares >= 2.10 involving SPE's to replace a GPU by a set of several SPE's (CPU is named Cell, holding 1 PPE and 6 free to use SPE's). Also, no OpenGL or similar yet for taking advantage of SPE's.

Thus, this thread is still very interesting to survey...
(Note that my own firmwares are <2.10 and I don't plan to upgrade them!)

About performances :
fw>=2.10 : All direct ports will be slow (until SPE based mod works).
fw<2.10 : 2D direct ports will be fast (if you apply Glaurung's mod).
3D direct ports will be slow (won't use RSX unless recoded entirely).

JimParis pushed a mod that should work on all firmwares under Linux.
It's the ability to use 252Mb of gpu-side ram as an extension of the limited 256Mb cpu-side ram. I guess this extra ram is seen as a fast media storage. Still a 2D direct port that needs 500Mb will fail (or be very slow), for example. Needs to rewrite a few to take advantage of the extra 252Mb because, even if 'swapping' is possible (as said in JimParis' ps3nvram driver description, I doubt it will do any good to a piece of software that didn't expect to have only 256Mb of physical ram... So it's better to reduce the amount of memory a software port needs and switch manually at proper -chosen- time).

IrquiM · Post by **IrquiM** » Tue Aug 05, 2008 8:26 am

fordfairmont wrote:My main question is though what sort games can i run thru linux before i have to start modding?

Short answer is: As long as it compiles and runs under linux on a pentium or pentium 2, you probably will be able to run it. If it's games for MS Windows, you'd be lucky to get Ducktales and Aladdin up and running. Games made for Windows requires an emulator to run on the PS3 hardware.

Sorry ps2devman, your answer was a great recap of this project ;)

forums.ps2dev.org

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

ps3rsx kernel module loading on 2.10

small idea

lv1_gpu_attribute probe