Maybe i have to buy a new screen so that i can enjoy my ps3 more! ;-)
I will also play with the hardcoded values.
The hunt for HV's FIFO/Push buffer...
-
Panajev2001a
- Posts: 100
- Joined: Sat Aug 20, 2005 3:25 am
I believe they are properly protected:IronPeter wrote:sigbus, you are of course 100% right.
We can not damage inner hypervisor structures with RSX RAMIN access ( if RSX DMAs are properly protected ).
http://preview.tinyurl.com/2locyt
(Drawing #2, FIG. 1 for an overview of the covered areas)
Code: Select all
United States Patent Application 20070208885
Kind Code A1
Otsuka; Katsushi September 6, 2007
Methods And Apparatus For Providing
Independent Logical Address Space And Access Management
Abstract
A memory access control apparatus executes memory access
after the apparatus has determined whether access to memory is granted or not.
A command receiver receives, from an external memory access requesting entity,
a command with which to access data in memory, together with an address
to be accessed and IOID to identify the memory access requesting entity.
Based on the IOID, an access decision unit determines whether or not an access is one from a memory access
requesting entity to which an access to a region designated as an access destination is to be permitted.
The access decision unit determines whether access of the memory access requesting entity is permitted or not,
for each page that serves as a basic access unit in memoryI did not check the RSX wiki out first, as it seems to me that what I stated is a very well known fact:
http://wiki.ps2dev.org/ps3:rsxps3:rsx wrote:Since the Cell FlexIO interface controls all transactions from any external IO device to system RAM, a window to system memory is opened for the GPU
:(.
quick update
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.
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.
Youtube'd video
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
http://youtube.com/watch?v=vuRLsB2q7QY
X update
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/g ... eo-ps3.git
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/g ... eo-ps3.git
quick thought on dma notifiers
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.
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.
hypervisor doc update
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:
I believe this targets somewhere in the HV memory, but I've not tried to use this DMA object for blitting yet (and we need to discover the corresponding address in FlexIO space, just as GPU_IOIF is used for standard blits using the 0xfeed0001 object).
- lv1_gpu_device_map device 8 actually reflects video RAM at offset 0x0ff10000. This region is referenced by DMA objects created by the HV but I don't know what it is used for.
I've updated the wiki on hypervisor accordingly, including previous findings we made in this thread (so that's a lot of changes). Please check for grammar :-)
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:
Code: Select all
key 63a handle 13378086 engine 1 offset 040170
DMA Class 3D
access RW,present,linear to PCI
address 8f03f000 limit 00000fff
- lv1_gpu_device_map device 8 actually reflects video RAM at offset 0x0ff10000. This region is referenced by DMA objects created by the HV but I don't know what it is used for.
I've updated the wiki on hypervisor accordingly, including previous findings we made in this thread (so that's a lot of changes). Please check for grammar :-)
Slashdot
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
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
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.
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
- Posts: 100
- Joined: Sat Aug 20, 2005 3:25 am
IronPeter, I know it is early for a feature request, but it would be a very nice icing on the cake ;) if you could consider this for your kernel module:IronPeter wrote: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.
A lot of us cannot use fullscreen modes because of overscan problems and dislike "windowed" mode with black bars because those black bars are a bit too conservative.
As you can see here ( http://forum.beyond3d.com/showthread.php?t=43859 ) and in countless other threads I am sure, those black borders are under some form of control. If you edit them properly before compiling the kernel you can properly reduce them and get a nice full-screen picture.
Since the kernel module would replace the old fb driver, the idea would be to use the pre-processor defines to help the user (if they want to) to easily change and optimize the black borders around the picture.
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.
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.
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.
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
- Posts: 100
- Joined: Sat Aug 20, 2005 3:25 am
It was so fun doing that during PS2's Linux days... oh GS ;).IronPeter wrote: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.
Well, maybe it was not that fun hehe.
ps2dev kernel branch
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:
That means if we want an external kernel module we have to free the context, free the memory and reallocate everything back, based on assumptions of the handles returned by the HV to ps3fb. Doing a second lv1_gpu_memory_allocate(0, ...) will not open the RAMIN DMA hole again, so I don't see any other option.
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'm thinking of new fb driver (including support for black borders adjustements), gpu access, game controller and remote drivers, etc... We could provide precompiled kernels for 'lazy' people too :-)
What do you all think of this?
For now I'll just get back to the HV calls.
Code: Select all
status = lv1_gpu_memory_allocate(ps3fb_videomemory.size, 0, 0, 0, 0, ...)
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'm thinking of new fb driver (including support for black borders adjustements), gpu access, game controller and remote drivers, etc... We could provide precompiled kernels for 'lazy' people too :-)
What do you all think of this?
For now I'll just get back to the HV calls.
-
boxbuilder
- Posts: 15
- Joined: Sat Nov 17, 2007 3:13 pm
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
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 ... 9643041382
Vote Ron Paul for freedom!
watch http://video.google.com/videoplay?docid ... 9643041382
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.
http://www.everfall.com/paste/id.php?u0aqjuh432st
recompile from source.
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.
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.
small libps3rsx update
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 :).
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 :).
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.
>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.
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)
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)
Last edited by ps2devman on Sat Nov 24, 2007 9:56 pm, edited 1 time in total.
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.
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
- Posts: 2
- Joined: Thu Nov 15, 2007 1:56 am
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.
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.
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.
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.