forums.ps2dev.org

Single buffering issue. I'll fix that.

SPU is very good for dynamic geometry. You can generate your geometry on fly. Or at least reduce generation time.

I need any feedback from ps3rsx ( bug reports, feature requests etc ).

>The sxga (1280x1024 resolution) did not work

It is my working resolution. Works well with all kernels i used ( many - many different kernels :)).

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.

hmm...

Examples must work under running X server. Without any display corruption after exit.

Not hard job. I've just bundled old RSX module by glaurung.

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?

Hi.

I integrated glaurung kernel module into libps3rsx ( so theoretically you do not need to apply kernel patch ).

You only need to make fresh checkout of libp3rsx, run ./src/init/startup.sh and run examples.

Troll is animated now.

stinkymonkey, nothing interesting. I'am slowly writing some kind of techdemo.

No news about 3D access in FW 2.10

hmm... Probably you want to setup not valid or "foreign" context object.

Your fifo setup seems to be broken.

Here http://manwe.homelinux.org/~glaurung/ps3/20071015/ is old but working RSX analyze tool.

You need to call prepare_ramin_vram_copy function.

Peter.

the same dump as in FW 2.01.

Nothing 3D related.

Probably, I did not understand your words about 2d object. Can you do blit from the upper vidmem? Are your 2d subchannels working?

Pretty nice, can you make RAMIN dump? Sources are in this thread.

monolith42, did you run init script src/init/mknods.sh ?

Success of that initialization is 90% in memory access rights and limits for DDR context memory.

I've read this paper few pages ago.

Do not want to go into detailed discussion.

Glaurung, very nice gift. Rex_VF5, I did not try to run code at HV privilegies level or to hack HV. I see some possible holes. I do not think that RSX DMAs are protected at the bus level. RSX can be theoretically used as a share resource by different instances of OtherOS. In that case the stream of ...

Glaurung, nice finding with lv1_context_gpu_attribute fifo_setup.

One note - you promised to make libps3rsx patch :).

Happy Xmas and New Year to all.

>it is very likely that there exists an undocumented hypervisor call which creates the classes we need for accelerated graphics.

It is known that games and linux run over the same hypervisor. So we ( probably ) can use all HV functions called by PS3 game SDK. Without restrictions.

hermes, Ctrl1 e2014ac e201448 just means that DMA engine of RSX read FIFO buffer. Any advance in ctrl regs does not mean success of execution. The function prepare_ramin_read_line256 copies memory line from upper vidmem into CPU accessible area. I am pretty sure that RSX hangs up doing that copy. Yo...

d-range, any nontrivial push buffers. So you must memset( 0 ) fifo buffer, make lv1_gpu_context_attribute call, dump fifo bufer ( if there are any non zero values ). Any nonzero values are interesting for me. Push buffer after FB_SETUP in ps3fb.c is the first candidate to investigate. PS. FW 2.01 is...

Nice if somebody is able to test lv1_gpu_context_attribute entries. You can follow testing methodology from this page: http://wiki.ps2dev.org/ps3:hypervisor:lv1_gpu_context_attribute I very want to see push buffer after valid FB_SETUP call in FW 2.1. Just dump fifo buffer after that call in ps3fb.c ...

Use videomode 13 ( from my memory, not sure ).

It is for 1280x1024. I am using that resolution on 1680x1050 capable monitor.

Peter

jonwil, you do not understand. With this update Sony also breaks half of linux installations. PS3 linux code holder Levand Geoff did not know about these changes.

> official 3D isn't far off

I hope also. Nice thing is that fb offset is still 64K. fb and fifo alias in memory. Looks like bug or preparing to 2D driver.

RSX is blocked in some sense.

Some official kernels use the same gpu_mem_alloc( 0 ) call. I think, Sony halved linux install base. Nice XMas PR action.

It is for direct RAMIN access. I can init 3D only with this call ( but I am pretty sure that there are undocumented HV calls for 3D initialization ).

Test is very simple. Try in the kernel mode u64 a = 0, b = 0; lv1_gpu_memory_allocate( 0, 0, 0, 0, 0, &a, &b ); printk( "%8x %8x %8x %8x \n", (u32)a, (u32)(a>>32), (u32)b, (u32)(b>>32) ); It is better to try that call before any RSX stuff ( for example in the ps3fb.c ). Peter.

I do not know yet if is RSX blocked in FW 2.1

I know that many linux clean Geoff kernels do not boot with FW 2.1. I do not want to make FW upgrade to investigate this problem.

All fullscreen videomodes must work.

It is hard to fix bugs remotely but it seems like 3d initialization was not completed. You can try to tweak init.c file and investigate RAMIN after initialization.

From your log it looks like Sony fixed lv1 gpu memory allocate with size 0.

It means for example that old linux kernels are also incompatible with FW 2.1.

Not sure, it is hard to say something from these lines.

Peter.

>Yeah same problem here, the cmd suggests the IOCTL does not exist this means to me that these examples work (and someone please correct me if I am wrong) with the patched ps3fb, I think they will need to be changed to work with the new modules? Yes, Glaurung promised to make some patch to libps3rsx...