Noone doubts its technically possible, Im pretty sure Nvidia could could cook up a driver without much effort. Whats doubtfull is that it will be secure enough, theres no such concern with the ZEGO (doesnt have to securely seperate 2 OSes, even if, then not having DDR-Ram might help isolating OSes through Cell).
Ps3 linux: RSX 3d chip situation
- Thread starter MrCarrefour
- Start date
Yup ! The ps3vdram driver speeds things up quite a bit.
On Sony's open source effort, I think they should open source their media manager first (The one running on PC to sync with PSP). Followed by official Lua player for both PS3 and PSP (as part of Home SDK for users). Might as well rail those PSP mods folks in and back it up with a business model. Some of their work looks great.
Hardcore linux stuff can come slightly later as long as they accelerate the development of the Gallium SPU-OpenGL driver.
Panajev2001a
Veteran
It does has such a method of protection (and HW based too), you could try to break it (mark all memory areas as accessible by your unit) and some could succeed (they have not yet), but it is there:
http://appft1.uspto.gov/netacgi/nph..."+AND+denied&RS=AN/"Sony+Computer"+AND+denied
Nice picture to give you a good full look on the whole set-up and components mentioned in this patent:
http://aiw2.uspto.gov/.aiw?docid=us...S=AN/%2522Sony%2BComputer%2522%2BAND%2Bdenied
Last edited by a moderator:
People who are interested in SPU can still use them without OpenGL-SPU acceleration... unless you're into visualization. The SPUs can accelerate many other tasks like media processing, security researches, scientific computing and assorted optimization techniques.
People who are interested in GPGPU work may be interested in how the "hybrid" Cell can help in GPU work (hence, improve the Gallium OpenGL driver or OpenCL
)The RSX Linux driver may or may not come, but I am not willing to plan my activities based on it. I have heard both side of the rumors/news before.
Panajev2001a: Thats some unreadable patent-gibberish.. though I think I got what the idea is.
And the problem I have with that is that RSX cant easily switch states, you have the Sony-Context and you have the Linux-Context (for a lack of better terms).
Now under Sony-Context you have shaders running that can access Region A in XDR Ram and Region B in DDR-Ram. Under Linux-Context you shouldnt be allowed to access those regions.
How do you atomically switch Context on pre-DirectX 10 Hardware? Dumping the whole state to Ram (probably not possible at all)? Waiting till arbitrary long shaders complete? Redo the last possibly expensive operation (and hope you can restart without sideffects)?
What will happen if you run a long shader and the context-switch made the Region you are fetching from invalid? Will the GPU halt to some sort of exception? Will it return garbage? What if the content is already cached - are the security-measures implemented at that low level?
Unless RSX can safely dump its state (like DX10 are just beginning to do), I cant think of a secure (and somewhat predictible) way to switch Context.
And the problem I have with that is that RSX cant easily switch states, you have the Sony-Context and you have the Linux-Context (for a lack of better terms).
Now under Sony-Context you have shaders running that can access Region A in XDR Ram and Region B in DDR-Ram. Under Linux-Context you shouldnt be allowed to access those regions.
How do you atomically switch Context on pre-DirectX 10 Hardware? Dumping the whole state to Ram (probably not possible at all)? Waiting till arbitrary long shaders complete? Redo the last possibly expensive operation (and hope you can restart without sideffects)?
What will happen if you run a long shader and the context-switch made the Region you are fetching from invalid? Will the GPU halt to some sort of exception? Will it return garbage? What if the content is already cached - are the security-measures implemented at that low level?
Unless RSX can safely dump its state (like DX10 are just beginning to do), I cant think of a secure (and somewhat predictible) way to switch Context.
Panajev2001a
Veteran
That particular patent at least seemed clear to me... you try to access a memory area from the I/O device (in this case the GPU) and a Hardware unit on the CELL BE checks if it is accessing a valid page.
When you start Linux, which sits above the Hypervisor, the Hypervisor sets access rules for that HW unit and quite likely marks XDR areas with data you should not have access from either the PPU/SPU side or the GPU side as not accessible by those physical devices. You try to read that area of memory, the DMA access is denied and only the Hypervisor can decide which memory area you can access and which one you cannot.
RSX, with a Linux driver giving you access to it, would function normally, it just could not DMA to/from an area the Hypervisor has protected.
Switching context? Maybe I am being dense here...
From the way you are explaining those contexts it seems like one is the "environment" set-up for the Game OS and the other one for Linux, but the two OS do not run side-by-side/concurrently and Linux does not even run really directly close to the metal but on top of the Hypervisor.
You want to run Linux? Game OS says "ok, have it your way...", it starts the reboot process and the boot flag is changed so the boot-loader can start the "Other OS"...
This is not like executing Linux inside a VM running as a fully privileged application on the Game OS.
Last edited by a moderator:
unless the hypervisor kicks in and then RSX might have access to memory it shouldnt see.. or rather you shouldnt see. Copying that Memory to DDR would then make it accessible for Linux.
Not gameos, whatever thingy that runs in the background serving Linux virtual drivers. Not sure if this is Part of Hypervisor or if Hypervisor is just delegating request to a own Sandbox handling drivers.
Panajev2001a
Veteran
Why would the hypervisor need to allow such a nasty thing
?I am not seeing how the hypervisor would be granting access to unsafe memory areas... it does not run GPU code, at best it runs code from an isolation mode SPU that touches XDR and/or GDDR3... if needed it can have RSX load data (if it needs to read from VRAM) into a safe XDR area writing a series of commands into RSX's command buffer and then read it from there... I might be losing myself in my own example here
, but I fail to see how the Hypervisor could grant access to restricted memory areas to RSX and thus to dangerous homebrewers.A way for the hypervisor to cause trouble would be if it needed to make RSX access an XDR memory area that is restricted and that under normal conditions it should be blocked to RSX, but I do not see the reason why this would absolutely have to be the case.
Say SPU A in isolation mode or the PPU running the Hypervisor (so trusted resources) need some data from VRAM into memory area AA, modify it and send it back... and they do not want to read at 16 MB/s...
RSX writes into BB, SPU A/PPU copies data from BB to AA, ... processing..., SPU A/PPU copies data from AA to BB, RSX reads from BB... not incredibly fast, but not incredibly slow...
Also, I'd like to know MS's secret sauce for not making all of this a security concern with Xbox 360's XNA program
.
Last edited by a moderator:
Also, I'd like to know MS's secret sauce for not making all of this a security concern with Xbox 360's XNA program
Huh? I thought that was rather clear? XNA is a completely virtualised library, isn't it? There's nothing going direct at all.
As for RSX, I'm as disappointed as anyone, but even without it, people managed to get some access to it albeit briefly, and even that hole was quickly plugged. So to me it's clear that security has taken a strong priority here and it's holding things back. In that respect the PS3's anti-piracy success is a curse to us homebrewers for now - they'll become paranoid about it, being the only console this generation (and in a long time) to survive the onslaught this long.
I think the total collapse of security on PSP has had a role in making them paranoid for PS3
People got access to the RSX indefinitely if they don't care for video games (like me) and am willing to not upgrade the firmware beyond version 2.01.
I have the 2D access to the RSX and it works very well, making the PS3 a very pleasant platform to use. Formerly, there were nasty redrawing artifacts when moving windows and clicking on a window (with lots of windows on the screen) could take 10+ seconds for a response to register. Now, the screen is very snappy so long as one doesn't use too much memory (then scrolling gets sluggish). The RSX hack also frees up 20+ Mb of memory. My strongly preferred window manager is Wmaker, which in addition to being very nice to use has a very small footprint (I really can stand the Windows-like window managers).
I am completely disgusted with Sony and will be reluctant to ever give them my business, but the RSX hack has at least rendered the machine useful to me for writing physics demo apps which use the SPUs and for general use (so long as I don't need Flash). The PPU is not that fast - I have run many apps on it and it is about as fast as a 1.5 GHz G4, which is OK for most things (I use it for Latex typesetting and web surfing in addition to programming). For my fairly simple apps, the software rendered OpenGL is adequately fast for me (in fact, I would have no benefit from hardware acceleration in that area). Again, I am not a game user or programmer, so my needs are modest.
Well, if only the hack had been discovered a little later, I'd have been able to buy one.....
6 SPEs and full pixel pumping power of RSX by using libps3rsx would have made for such a great platform for scientific calculations and cool visualizations, a bit less RAM nonetheless. Plus it would have been great fun and learning challenge to write a RSX compiler for GLSL using LLVM. I don't think that there is any support for optimizations in the current libps3rsx. Is there?
Not the ideal thread to post this.
I found a CorePy presentation online:
http://sti.cc.gatech.edu/Slides/Mueller-070619.pdf
(Python + Cell programming)
More here: http://www.corepy.org/wiki/index.php?title=CorePy_Basics
Warrenn I'm not sure I follow you here; I can understand wishing there was full openness, but at the same time the product is not sold or marketed as a Linux platform, it's simply an add-on benefit. What Sony as a corporation you feel has done to slight you, I just don't get. Sony isn't HP or IBM; it's not like you bought a purposed workstation or server and are suddenly being locked out of some feature. You bought a game console which was never intended to allow open GPU access, but which enabled access to the CPU. We can discuss in these threads how we'd like Sony to allow access, what we'd do if we had it, and the detriments of not allowing it... but as far as Sony's dealings and representations, it's clearly all above board and obviated in this regard.
I think why he (and to an extent other homebrewers) feel "cheated" is because Sony shut down a working system. The hack let you do things, it was taken away. Those who bought a system assuming the hack and unknowingly upgraded the firmware were definitely screwed(their small numbers admitted). Yes, Sony was above board, but an element of emotion is always there in human actions, even if it is only partly right.
When I say I don't get it, it's not because I don't actually get the source of frustration, but because I'm more surprised that folk which are obviously outside the range of 'fanboyism' and its ill effects on rational thought can get so upset about something that seems like such an expected outcome. Now it's fair to say that those that bought it assuming the hack and may not have been as familiar with Sony's absolute mission to keep the PS3 'hack-free' and history of crusade against PSP homebrewers might have been blindsided, but these were known quantities all the same.
My own thoughts on the matter are of course that it's confusing - and obviously there's mixed views/feelings within Sony - with regard to the whole open/closed system situation. However it has settled out, the GPU has been deemed a no-fly zone apparently. Hopefully once the hardware itself becomes profitable that will change, or maybe the relationship with NVidia IP makes it murkier... I hope not.
But outside of the Linux situation, one at least does have to recognize with some admiration what a secure system they have created, and on the console piracy front certainly they must be proud of themselves.
Yes, certainly, keeping off pirates is indeed an achievement. And I am all for using whatever tools available to fight them. But yes, please Sony, don't try to fool us into believing that PS3 is an open platform. It is a 3D castrated with only text based console practical, but which is not very usable.
But then, who knows, someone may find a hack that enables it and is hard to shutdown. As I understand it, to date, no console has survived piracy in it's life cycle.