forums.ps2dev.org

[Falcon]

Maybe i have to buy a new screen so that i can enjoy my ps3 more! ;-)

I will also play with the hardcoded values.

[Panajev2001a]

[Glaurung]

Hi,

Falcon, IronPeter, keep in mind that in non-fullscreen mode there are actually black borders in video ram to account for missing image parts on standard TV, therefore the pitch of virtual FB and video RAM FB may be different. The accelerated Xorg driver does not handle non-fullscreen mode properly yet either.

Also, a small update on the Xorg front: I've finally fixed the rendering bug with EXA Copy, using a dedicated ImageBlit object for this operation. Unlike the ScaledImage object, it handles blit in any directions properly (e.g right to left, bottom to top) and automatically. I still had to use a notifier to ensure proper rendering though, but performance looks good. There are still some tearing effects since I don't sync on vblank.

IronPeter, I don't know how to prevent X or the fb driver from rendering in the framebuffer when 3D operations is going on, perhaps we should check how it was done on older 3D cards. IIRC, there were some 2D/3D cards which could only work in exclusive mode. Anyway, I suspect they just allocated some of the video ram to X and gave the rest to 3D. Also, maybe we can use hugetlb pages if they are large enough (>1MB) and mix that with lv1_gpu_context_iomap() to get something closer to an AGP aperture.

[IronPeter]

Glaurung, great news from Xorg front. Sounds like victory :).

I think that there is a way to "stop X" and to "redraw X". Of course I can map some piece of XDR memory to GPU. But I already have one large piece.

[cnlohr]

For anyone who has been following this thread, but doesn't want to do this on their own PS3 yet, I took a video of IronPeter's demo (plus animation/vsyncing/double-buffering) in action.

http://youtube.com/watch?v=vuRLsB2q7QY

[Glaurung]

cnlohr, excellent video!

I've some news on the Xorg side. I've update the driver with basic SolidFill acceleration, fixed an synchronization issue with DownloadFromScreen/UploadToScreen, and added support for non-fullscreen video mode. There was also a patch from ReneR to fix driver crashing on 64-bit userland. I'm now quite satisfied with its current state and plan to move on digging the HV calls again so that we can have a truly independent DRM driver instead of the ps3fb driver hack. Feel free to test it, make a video of it :-) (try xcompmgr -c -f + mplayer ElephantDream.avi + transset and enjoy), and report bugs.

Code here, as usual:
http://mandos.homelinux.org/~glaurung/git/xf86-video-ps3.git

[Glaurung]

I've just noticed that since lpar_reports correspond to VRAM at address 254MB, DMA notifiers created by the HV are available from Cell. I've updated the wiki accordingly.
That means we don't need to create our own DMA notifier objects in RAMIN, we can just use the ones provided by the HV to monitor progress of our GPU operations.

[Glaurung]

Hi all,

I'm back looking at HV calls, here are the findings of the day:
- lv1_gpu_context_allocate has flags as second parameter, it creates some interesting RSX DMA objects when set to 4 and 8. In particular objects created by setting flag to 8 are very interesting as they target system memory:

[toqer]

Hi guys,

I don't own a PS3, but my friend does. He owns a little anime shop, does the import game thing, mods, etc. Since I installed linux on his PS3 he's had 2 customers ask him to install it on theirs.

Anyways, I've been lurking in these forums the past couple of days. I submitted this thread to slashdot.

http://slashdot.org/firehose.pl?op=view&id=381587

It's been in "Pending" limbo for the last few days but i'm sure the /. mods will pick it up soon considering how much progress you've made in the last week.

--toq

[IronPeter]

Glaurung, I think that the main problem now is hard setup.

User must:

1.) Install git
2.) Checkout and compile dtc ( head revision is broken )
3.) Checkout kernel sources
4.) Compile and install custom kernel
5.) Tame kboot, fstab, sysinit ( very untrivial thing )
6.) Install our driver

This procedure takes 6 hours for me.

The partial solution is: to strip hv1call.h, ps3fb.h, ps3fb.c from kernel sources and combine it in the kernel module. This module will stop ps3fb driver and will init the second context with FIFO control. This module will need only kernel devel package ( with any kernel version ) to be installed.

10 minutes to install and run. 2 days to write.

[Panajev2001a]

[Glaurung]

I agree we need a separate module for easier setup. I would prefer to have a totally independent second context with its own fifo, but we don't know how to do that yet. The second call to lv1_gpu_context_allocate does provide a different dma_control area but the values are all zero. A call to lv1_gpu_context_attribute:fb_setup returns -EBUSY. Writing my own values in dma_control[0x40/0x44] seem to have some effect but currently it crashes the GPU. So that's why I wanted to look at the HV calls a bit more before writing such a module; to have a cleaner approach. Besides, we'll need to understand context switching if we are to accelerate the mtd driver for swap over video RAM, as it will need its own context.

However, to be more pragmatic and for people who want to test early, we can indeed write an external module for GPU access that reuses the ps3fb FIFO, just as we do now. Actually all the code for this is already there in the kernel/ section of ps3gpu test code. I won't have time for ps3dev today but I'll look into it eventually.

Concerning the black borders; they are currently controlled in the Xorg driver in a very simple and basic way: we ask the fb its current mode (as does the ps3videomode utility) and have a database of corresponding fullscreen resolutions. Then we ask the fb its resolution (as does the fbset utility) and subtract the obtained width and height from the fullscreen width and height to obtain the black borders size. This could be overridden by an option in xorg.conf, but most probably ModeLines are made for this, I need to learn how they work :-) Concerning the linux framebuffer black borders, I don't know if we can do much without recompiling.

[IronPeter]

Glaurung, did you try to call FB_SETUP after fifo trap is setted? I think it can return BUSY in that case ( some notifier is disabled ).

[Glaurung]

Hmm, yes, maybe that's the problem. Did you manage to setup a fully working second context?

[IronPeter]

Glaurung, I think I was able to make that setup. Not sure, need to retest.

Also I want to test graphic interruption with different masks ( via dinfo->irq.mask ). Do not want to restart Linux at any RSX 3D hangup.

[Glaurung]

Yes that's be nice :-) I didn't look into interrupts yet, there is probably some valuable info there.

So, I just retested FB_SETUP before fifo is trapped, and I still get the busy return code. Maybe I'm doing something wrong, so if you manage to have a second context, I'll be interested to know how. I'll continue looking into it on my side too.

[Panajev2001a]

[Glaurung]

IronPeter, I've been looking at the separate module option and I don't think that's the best approach finally. Recently the call to lv1_gpu_memory_allocate in ps3fb.c has been changed to:

[IronPeter]

>Doing a second lv1_gpu_memory_allocate(0, ...) will not open the RAMIN DMA hole again

Why? I see no reason for that. It is independent memory region, idependent DMA object.

I'll test the second context creation at home.

[IronPeter]

heh, I've tried fb setup for the second context. Fail with busy. Another thing to fix :).

[boxbuilder]

Excellent work!

I have gotten the patch to work and put ps3X in the startx script, and got multiple copys of "mplayer -vo x11" to play translucent on top of each other (cpu hog!?) (have not patched mplayer yet)

When I run ./ps3gpu I get:
vram 264241152 fifo 65536 ctrl 4096
Segmentation Fault

and when I try to recompile it, it dosn't know the size of the variable type "info".

I'm not looking for a walkthrough, please keep writing code instead, But it would be nice to hear from somebody who has it working as to their firmware version, kernel version (and where from), gcc version, device tree compiler version (and versions of any other software you think is important)

I would like to help in any way I can, unfortunitly my coding ability are nowhere near your level, so I would be happy to make a help page for people like me who want to put on the your software (I would just need some hosting somewhere)

ps. if all 256MB can be DMA'd with the crack, can't we just put on bochs, and windows and try the geforce7800 driver? Just a dream ;-)

-cabe
_________________
______________________________________________________________
Vote Ron Paul for freedom!
watch http://video.google.com/videoplay?docid=-8327695139643041382

[IronPeter]

if your patch is applied correctly file $(LINUX)/include/asm-powerpc/ps3fb.h contains definition of this structure:

http://www.everfall.com/paste/id.php?u0aqjuh432st

recompile from source.

[Glaurung]

Also note you cannot mix both the Xorg accelerated driver and the ps3gpu test program yet.
The reason is we share the same FIFO and hardware context for now. The hardware has capability for 8 differents contexts so we could allocate for example one for Xorg, one for libGL and one for swap over VRAM, but we don't know how to do that yet.

So if you want to play with IronPeter's amazing 3D stuff, run it from the framebuffer console or from unaccelerated X.

Also, mplayer -vo xv would better use the capabilities of the RSX (hardware YUV->RGB conversion and scaling) than -vo x11.

[IronPeter]

I coded DXT textures support. With toolchain for compression and with binary layer. Check ps3rsx repo.

Texture setup is relative high level function: http://www.everfall.com/paste/id.php?507se1jlqzml

My plan is to write high level functions for everything ( buffers, states, render target setup ).

Enjoi.

Peter.

PS. And I very-very want to have textured penguin 3D model for demo :).

[IronPeter]

Just noted comment.

>I'm starting to think the best approach might be to fork a ps2dev kernel branch from geoff's tree and put every enhancement we are interested in there

I think about other thing. I want to make small linux distro on boatable CD. Like "devkit environment". Custom linux kernel with command line ( and probably basic X ). 50-200 Megs of iso disc image.

People can boot from this disc, try 3D demos. Homebrew games can be distributed on bootable CD. "Inject CD into PS3 and play game".

It will be great if somebody is able to make this stripped linux distro.

PS. I think, there are many people with broad-band connection and small amount of free time. "Download LiveCD, inject it and play with 3D in 10 minutes" - it is good idea.

[ps2devman]

I wonder what happened to the ps3link project.
Source directory is still empty...
Anybody knows?
It would be the natural competitor of your Linux LiveCD distro idea.
(Boot OtherOS ps3link, upload homebrew game from PC, play it)

[emoon]

ps3sdk, ps3link and ps3client is on ice for a while more as im really uber busy at work currently.

I do plan to work on it afterwards. Some stuff to mention that is running:

* Basic framebuffer (based on OtherOS demo, but much cleaned up)
* Basic network driver
* Uses lwip for tcp/ip support
* You can telenet from PC. to ps3 and it will echo back what you send from the PC side.
* All linux code has been rewritten/redesigned from scratch so its 100% BSD now and no GPL.
* Some more stuff that I have forgot about.

[evocallaghan]

IronPeter: I am already working on my own Linux distro for the PS3.
I got a custom kernel I built but I need help with my installer as I don't yet know how to partition the HDD with Python or Perl ?

I do also plan to have a NetBSD or FreeBSD based version as well.
As soon as I get my loader working.

Keep up the great work!
Ed.
_________________
--
http://sourceforge.net/projects/ps3-bsd-loader/
`Of course it runs NetBSD`

[ps2devman]

emoon, I think that would help IronPeter if you just publish (or let him look at) your partial work (even if nothing works).

There is the possibility that the current design in progress by IronPeter can link itself somehow later to EITHER Linux or ps3link (at some intermediate API level).

We shouldn't miss this opportunity (i.e we should avoid having IronPeter know about ps3link internals too late, after all his design is finished).

Linux is nice for a coder but is frightening for just a game player.

[IronPeter]

do not worry, ps3rsx project will have RSX core and tools. Core does not depend from anything. You need only mmap or any other service for resource loading.

Tools need linux environment of course.