mesa-cell driver

YDL running on the Sony Playstation 3

Moderator: billb

Re: mesa-cell driver

Postby dan_f14 » 24 Feb 2010, 11:37

Ok, just so I can understand this and it may be going a little offtopic so I will keep it brief. As I understand it the geohot hack enables him to kick the 7th SPU which is the hypervisor. If he did that then the hypervisor wouldn't be running so it wouldn't be mimicking a standard pc which means that ydl or any other linux distro wouldn't work. And just as a side note how come the hypervisor didn't mimick a stadard arcitecture? It would be far easier configuring things such as flash.

Sorry this is a bit offtopic, feel free to move.

Dan
dan_f14
ydl beginner
ydl beginner
 
Posts: 34
Joined: 23 Nov 2009, 23:13

Re: mesa-cell driver

Postby ppietro » 24 Feb 2010, 12:46

dan_f14 wrote:Ok, just so I can understand this and it may be going a little offtopic so I will keep it brief. As I understand it the geohot hack enables him to kick the 7th SPU which is the hypervisor. If he did that then the hypervisor wouldn't be running so it wouldn't be mimicking a standard pc which means that ydl or any other linux distro wouldn't work. And just as a side note how come the hypervisor didn't mimick a stadard arcitecture? It would be far easier configuring things such as flash.

Sorry this is a bit offtopic, feel free to move.

Dan


Of course, nothing is ever quite that simple.

The 7th SPE is not actually the hypervisor, per se. According to geohot's blog post, "The hypervisor is complicated, it is written in C++ and is PPC" which means it's running on the PPE.

What the 7th SPE is doing is more interesting.

I'm going to post a link to an article:
http://www.ibm.com/developerworks/power ... lsecurity/

Now - this article is pretty technical. But - Kanna Shimizu is the architect of the Cell's security, and she summarizes the three main security features in the Cell:

1. "The Secure Processing Vault" - This means you can give an SPE some code to execute, then "lock" it away in a vault. Once it enters this "vault", it runs independently from the rest of the system - in hardware. There's no way to look at its local store (LS) memory or see what it's doing - you can only talk to it via its own interface or kick it out of the system.

As the article states: "Because of this hardware isolation, even the operating system and the hypervisor cannot access the locked up LS or take control of the SPE core"

This is what the 7th SPE does - it is running Sony encryption/decryption software locked in the Secure processing vault. This 7th SPE is providing the security for the GameOS.

2. "Runtime secure boot" - When an SPE enters isolation, it fetches a key from hardware and verifies the code is still encrypted correctly. It can do this multiple times, removing the ability to tamper and run unsigned code.

3. "Hardware Root Of Secrecy" - Finally, the master, root encryption key of the system is kept in hardware in the core of the Cell itself. It cannot be accessed via software and is invoked when an SPE enters isolation mode. A non-isolation SPE cannot access the root master key.

So - in summary - the 7th SPE is used by the system for encryption/decryption and the keys are contained within the Cell hardware. When Geohot says he can "kick" the 7th SPE, what he means is that he can take it out of Secure Processing Vault mode and make it available as a regular SPE to the system. He's not talking about the hypervisor per se. That's still running, but he can control it.

Finally - to clarify - the hypervisor does mimic a standard architecture - read the article in my previous post to see how much it makes the PS3 conform to standard Linux.

What you're really asking is "Why doesn't the hypervisor mimic an Intel processor?" Unfortunately, there would be a massive speed penalty for this - it would be translating x86 or x86_64 code into ppc code, like QEMU does. It would be far simpler to have Adobe release a native PowerPC version, than try to run an x86 linux in software emulation on a PowerPC.

Cheers,
Paul
User avatar
ppietro
Site Admin
Site Admin
 
Posts: 4965
Joined: 13 Sep 2007, 22:18

Re: mesa-cell driver

Postby Legendary_Agent » 24 Feb 2010, 19:08

dan_f14 wrote:Ok, just so I can understand this and it may be going a little offtopic so I will keep it brief. As I understand it the geohot hack enables him to kick the 7th SPU which is the hypervisor. If he did that then the hypervisor wouldn't be running so it wouldn't be mimicking a standard pc which means that ydl or any other linux distro wouldn't work. And just as a side note how come the hypervisor didn't mimick a stadard arcitecture? It would be far easier configuring things such as flash.

Sorry this is a bit offtopic, feel free to move.

Dan


According to Geohot he managed to "kick" the 7th spe out, altough theres no actual proof of that as he stated he doesnt know anything about c++ so he couldn try anything to test it out, the only thing we have atm is his word for it and the so called hack that isnt gonna do anything too, and possibly it will never do.

as to your question, x64 and x32 are strictly incompatible, even in x64 OS you will have a mode called run it in x32 mode to solve compatibility issues, but heres the catch, you need a processor compatible with both for that, and such processor would be called x86, a pc is almost always x86, infact ive never seen a x64 only home computer... the ps3 is 64bits only
Trying to mimmic 32 bits with 64bits cpu is totally different than "making" the hardware behave like a "PC", its mostly due incompatibility.
Legendary_Agent
ydl addict
ydl addict
 
Posts: 102
Joined: 03 Feb 2010, 18:35

Re: mesa-cell driver

Postby ppietro » 24 Feb 2010, 20:42

Legendary_Agent wrote:as to your question, x64 and x32 are strictly incompatible, even in x64 OS you will have a mode called run it in x32 mode to solve compatibility issues,


To clarify: from a processor standpoint, x86 (32-bit processor) code is forwards compatible with x86_64. The x86_64 architecture is an extension of x86. 32-bit code can run as-is on a 64 bit processor, however 64-bit code can not run on a 32-bit processor.

Wikipedia sums this up nicely:
The term x86-64 is the original naming of a 64-bit extension to the x86 instruction set specified by Advanced Micro Devices (AMD) and implemented by AMD, Intel, VIA, and others. It extends the virtual and physical address spaces, doubles the width of the integer registers from 32 to 64 bits, increases the number of integer registers, and provides other enhancements. It is fully backwards compatible with 32-bit code without any performance loss.


The x32 mode you're mentioning is Windows specific only, due to their "unique" architecture. :D Linux does not have that mode - x86 & x86_64 binaries can run simultaneously, linked against appropriate libraries.

Now - the other main Intel 64 bit architecture - Itanium or ia_64 - was completely incompatible with x86. That processor literally ran x86 applications in an emulator with a corresponding speed penalty. Luckily, outside of a few software vendors, most people didn't have to experience this. (I did though - ugh.)

Legendary_Agent wrote:the ps3 is 64bits only.


The PowerPC family treats 64 bit a little differently than Intel. Switching to 64 bit for PowerPC only increases the register width - it does not add extra registers or instructions like Intel. This lets you do 64 bit Integer math more easily, and increases the physical memory address space. However - 32 bit PowerPC code can still execute 64 bit operations.

Therefore, we compile most of our applications for the PS3 in 32 bit mode, since there is a performance increase for this due to smaller register size. Unless you need 64 bit integer math, or increased physical RAM address space, 32 bit code tends to be preferred for PowerPC targets like the Cell in the PS3.

Examples of this are the Firefox & mplayer builds I've been doing for the PS3. They're all 32 bit builds. :D

See my previous post here for a little discussion of performance gains between 32 & 64 bits for x86 and ppc:
viewtopic.php?f=4&t=3098&p=11887#p11892

Cheers,
Paul
User avatar
ppietro
Site Admin
Site Admin
 
Posts: 4965
Joined: 13 Sep 2007, 22:18

Re: mesa-cell driver

Postby Legendary_Agent » 24 Feb 2010, 22:11

ppietro wrote:
Legendary_Agent wrote:as to your question, x64 and x32 are strictly incompatible, even in x64 OS you will have a mode called run it in x32 mode to solve compatibility issues,


To clarify: from a processor standpoint, x86 (32-bit processor) code is forwards compatible with x86_64. The x86_64 architecture is an extension of x86. 32-bit code can run as-is on a 64 bit processor, however 64-bit code can not run on a 32-bit processor.

Wikipedia sums this up nicely:
The term x86-64 is the original naming of a 64-bit extension to the x86 instruction set specified by Advanced Micro Devices (AMD) and implemented by AMD, Intel, VIA, and others. It extends the virtual and physical address spaces, doubles the width of the integer registers from 32 to 64 bits, increases the number of integer registers, and provides other enhancements. It is fully backwards compatible with 32-bit code without any performance loss.


The x32 mode you're mentioning is Windows specific only, due to their "unique" architecture. :D Linux does not have that mode - x86 & x86_64 binaries can run simultaneously, linked against appropriate libraries.

Now - the other main Intel 64 bit architecture - Itanium or ia_64 - was completely incompatible with x86. That processor literally ran x86 applications in an emulator with a corresponding speed penalty. Luckily, outside of a few software vendors, most people didn't have to experience this. (I did though - ugh.)

Legendary_Agent wrote:the ps3 is 64bits only.


The PowerPC family treats 64 bit a little differently than Intel. Switching to 64 bit for PowerPC only increases the register width - it does not add extra registers or instructions like Intel. This lets you do 64 bit Integer math more easily, and increases the physical memory address space. However - 32 bit PowerPC code can still execute 64 bit operations.

Therefore, we compile most of our applications for the PS3 in 32 bit mode, since there is a performance increase for this due to smaller register size. Unless you need 64 bit integer math, or increased physical RAM address space, 32 bit code tends to be preferred for PowerPC targets like the Cell in the PS3.

Examples of this are the Firefox & mplayer builds I've been doing for the PS3. They're all 32 bit builds. :D

See my previous post here for a little discussion of performance gains between 32 & 64 bits for x86 and ppc:
viewtopic.php?f=4&t=3098&p=11887#p11892

Cheers,
Paul


I dont understand why its called 64bits cpu then, just register width is not enough excuse for that, expecially considering the 256+256RAM in the system... not to mention it doesnt gives you any 64bits instructions, for me its a 32bits system with extended registry width, then as its much more similar to it than to a 64bits cpu.

Its like calling directx10.1 Directx11 because well it is better than dx10, and it supports plenty of stuff that dx11 does :P
Legendary_Agent
ydl addict
ydl addict
 
Posts: 102
Joined: 03 Feb 2010, 18:35

Re: mesa-cell driver

Postby ppietro » 25 Feb 2010, 00:34

Legendary_Agent wrote:I dont understand why its called 64bits cpu then, just register width is not enough excuse for that, expecially considering the 256+256RAM in the system... not to mention it doesnt gives you any 64bits instructions, for me its a 32bits system with extended registry width, then as its much more similar to it than to a 64bits cpu.


Traditionally in microprocessor design, the "bits" designation has referred to the Address Bus width and internal register sizes.

32 bit processors have a 32 bit Address bus - literally 32 pins - which gives the processor 232 memory locations = 4294967296 bytes = 4 gig.

64 bit processors have a 64 bit Address bus - 64 pins - which gives the processor 264 memory locations = 18446744073709551616 bytes = 17179869184 gig = 16 exabytes.

In addition, internal register widths are increased from 32 to 64 bits. This is most commonly expressed in integer math capability - 32 bit vs. 64 bit integer math.

The Cell's PowerPC core is a true 64 bit processor by these standards. If a program is compiled with the -m64 flag, it would attempt to use the 64 bit address space and 64 bit integer math.

Unfortunately, as implemented on the PS3, there's only 256 Megs of RAM. So - no real benefit there. The ppc Mac owners - if they had enough physical RAM - could see a benefit for the same binary. The only PS3 advantage for 64 bit would be integer math calculations. (And, as mentioned in my post above, there are some disadvantages to executing ppc64 code on some PowerPC 64 bit processors.)

It's a different story for Intel. In x86 vs x64, the 8 extra registers available to 64 bit code could theoretically yield some tangible speed benefits if the compiler technology supports them correctly.

Cheers,
Paul
User avatar
ppietro
Site Admin
Site Admin
 
Posts: 4965
Joined: 13 Sep 2007, 22:18

Re: mesa-cell driver

Postby Legendary_Agent » 25 Feb 2010, 00:50

ppietro wrote:
Legendary_Agent wrote:I dont understand why its called 64bits cpu then, just register width is not enough excuse for that, expecially considering the 256+256RAM in the system... not to mention it doesnt gives you any 64bits instructions, for me its a 32bits system with extended registry width, then as its much more similar to it than to a 64bits cpu.


Traditionally in microprocessor design, the "bits" designation has referred to the Address Bus width and internal register sizes.

32 bit processors have a 32 bit Address bus - literally 32 pins - which gives the processor 2 memory locations = 4294967296 bytes = 4 gig.

64 bit processors have a 64 bit Address bus - 64 pins - which gives the processor 264 memory locations = 18446744073709551616 bytes = 17179869184 gig = 16 exabytes.

In addition, register widths are increased from 32 to 64 bits. This is most commonly expressed in integer math capability - 32 bit vs. 64 bit integer math.

The Cell's PowerPC core is a true 64 bit processor by these standards. If a program is compiled with the -m64 flag, it would take advantage of the 64 bit address space and 64 bit integer math.

Unfortunately, as implemented on the PS3, there's only 256 Megs of RAM. So - no real benefit there. The Mac owners - if they had enough physical RAM - would see the benefit for the same binary. The only PS3 advantage for 64 bit would be integer math calculations.

It's a different story for Intel. In x86 vs x64, the 8 extra registers available to 64 bit code could theoretically yield some tangible speed benefits if the compiler technology supports them correctly.

Cheers,
Paul


Yes that is true but when it comes to CPus, intel and other brands always associated 8-16-32-64bits cpus with more optimizations and specific instructions, where this ps3 cpu lacks all of them except the obvious useless width :P, false advertising ftl...
Anyways enough of that for now lol, just found it shocking to know that it doesnt have 64bits instruction support, which is kinda the point of having a 64bits cpu.
Legendary_Agent
ydl addict
ydl addict
 
Posts: 102
Joined: 03 Feb 2010, 18:35

Re: mesa-cell driver

Postby ppietro » 25 Feb 2010, 00:59

Legendary_Agent wrote:Yes that is true but when it comes to CPus, intel and other brands always associated 8-16-32-64bits cpus with more optimizations and specific instructions, where this ps3 cpu lacks all of them except the obvious useless width :P, false advertising ftl...


Remember, though, Intel's x86 is a relative latecomer to 64 bit and is the exception to the rule here. Other processor families, including POWER (with PowerPC), MIPS, SPARC and PA-RISC made the jump to 64 bit exactly as I described above long before AMD did with x86-64.

AMD took advantage of the fact that Intel was busy trying to establish Itanium as a new 64 bit processing paradigm, and created x86-64 to fix some of the "bugs" that Intel had carried forward in x86 designs throughout the years.

See here for a good timeline:
http://en.wikipedia.org/wiki/64_bit#64- ... r_timeline

Cheers,
Paul
User avatar
ppietro
Site Admin
Site Admin
 
Posts: 4965
Joined: 13 Sep 2007, 22:18

Re: mesa-cell driver

Postby Legendary_Agent » 25 Feb 2010, 01:34

yep, i supose thats true, still Cell is relativelly new but i must admit it does its true job, giving us decent graphics at decent performance so its not like it matters in the end, except AA and lack of 1080p titles but weve discussed that before.
Off topic it kinda makes me wonder if those 100ghz ibm cpus also have an extreme lack in instructions now that i think of it...
And back to your mplayer install guide, couldnt make it work before because i didnt have the time to install the 160mb of dev tools, im doing it now, also hopefully it wont take me 8 hours to compile as it did with gnash xD
Legendary_Agent
ydl addict
ydl addict
 
Posts: 102
Joined: 03 Feb 2010, 18:35

Re: mesa-cell driver

Postby ppietro » 25 Feb 2010, 01:38

Legendary_Agent wrote:And back to your mplayer install guide, couldnt make it work before because i didnt have the time to install the 160mb of dev tools, im doing it now, also hopefully it wont take me 8 hours to compile as it did with gnash xD


Luckily - no - it takes about 10 minutes or so. Much easier to play around with. :D

Cheers,
Paul
User avatar
ppietro
Site Admin
Site Admin
 
Posts: 4965
Joined: 13 Sep 2007, 22:18

Re: mesa-cell driver

Postby ACEFOMIQUZ » 27 Jul 2011, 18:08

My questions is:can it be used normal,today or in the future?
藍與紅如同水火不容,正藍者必憎紅!
User avatar
ACEFOMIQUZ
ydl addict
ydl addict
 
Posts: 101
Joined: 27 Oct 2008, 17:40

Previous

Return to Playstation 3

Who is online

Users browsing this forum: No registered users and 10 guests

cron