Sony's PlayStation 4 Is Running Modified FreeBSD 9

[gamerk2]

Bullshit. You're talking about the GoldSrc engine (this is where Valve even dropped DirectX support on Windows!). The Source engine is a pure DirectX engine with no OpenGL bits at all! The engine even talks DirectX on Linux, the reason this works is the togl library which translates these DirectX calls to OpenGL on the fly (presenting itself as DirectX device to the game).

Funny, considering I can still select the OGL renderer on older source games (CS:S comes to mind). The engine supports OGL, Value simply chooses to stick exclusively to D3D on Windows. Which kinda makes my point about OGL.

[ChrisXY]

Heh: http://cvs.openbsd.org/images/43song.gif

"Rule 1: You cannot sell your code!"

Wat.

1. You can still dual license your code if you wish.
2. Whether you can or can not sell it is in no way regulated by the GPL.

[mrugiero]

Personally? I'd make a new API that actually reflects how the hardware works, and is easy to program with. OGL is NOT easy to program with, especially compared to D3D, and that makes porting titles very unattractive. I'm not even talking performance here, I'm talking ease to program.

Well, that's a contradiction in itself. If you reflect how the hardware works, you make it complex. That means, harder to program with. The whole point of using an API here is to abstract how the hardware works (I'd say portability of the code too, but you could just define a standard assembly language for GPUs to achieve that).

[chrisb]

Heh: http://cvs.openbsd.org/images/43song.gif

Wow, is that some kind of official OpenBSD anti-GNU comic strip?! Don't they realise that this kind of thing just comes across as being really unprofessional and immature?

[chrisb]

"Rule 1: You cannot sell your code!"

Wat.

1. You can still dual license your code if you wish.
2. Whether you can or can not sell it is in no way regulated by the GPL.

Yes, they beat up a strawman:

Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible ? just enough to cover the cost. This is a misunderstanding.

Actually, we encourage people who redistribute free software to charge as much as they wish or can. If this seems surprising to you, please read on. http://www.gnu.org/philosophy/selling.html

[Ikem]

Would also be interesting if at least Sony contributed anything back?

There will be no "back contributing". That's why they choosed BSD.

[artivision]

As always a lot of nonsense. First of all GLSL is a C dialect for graphics similar to OpenCL or HLSL or CG. With Unigine if you program with HLSL you have also source or bytecode extensions for GLSL to. Other engines use the back end system, they easy auto regenerate an OpenGL backend from a D3D one. Usually all those engines they don't use a 10% of the one api that has low efficiency with the other. Second for emulators we don't emulate edram and those things, only instruction sets and compatibility layers for firmwares. First we use recompiling like qEmu has. In this step you transform PPC instructions to qEmu instructions that are higher level and they almost represent the source, then you compile to x86. Today's efficiency(recompiler+output) is 40%, so you need 3 times the Cpu to emulate a PS3. Cell gives one thread with a 2dmips/mhz for general computing when a sse4.2 celeron has 8drystone and a sandybridge has 9.5drystone all per core, so emulation is possible. As for GPU we don't emulate that because we have shaders. With GLSL ES2 shaders of PS3, we can load them with our standard drivers/compilers, GLSL or CG. Then we can cut antialising, anisotropic and anything we want in order to run them with lower GPUs. In fact PS3 uses CG and offloads those shaders to GPU(200gflops) and the same time to 6 cell spes(1800Gflops): 1spe=8Vectors@128bit(4 issue)[email protected]. To make compatibility layer for OS is easy because PS3 has a lot of BSD open source libraries, from C for cell to network. I may try myself and with friends in the future.

[V10lator]

Funny, considering I can still select the OGL renderer on older source games (CS:S comes to mind). The engine supports OGL, Value simply chooses to stick exclusively to D3D on Windows. Which kinda makes my point about OGL.

So why does CS:S ship with the togl library (located at ~/.local/share/Steam/SteamApps/common/Counter-Strike Source/bin/libtogl.so) and why does Valve tell they use it: http://www.gdcvault.com/play/1017850/ ?

[gamerk2]

Second for emulators we don't emulate edram and those things, only instruction sets and compatibility layers for firmwares. First we use recompiling like qEmu has. In this step you transform PPC instructions to qEmu instructions that are higher level and they almost represent the source, then you compile to x86. Today's efficiency(recompiler+output) is 40%, so you need 3 times the Cpu to emulate a PS3. Cell gives one thread with a 2dmips/mhz for general computing when a sse4.2 celeron has 8drystone and a sandybridge has 9.5drystone all per core, so emulation is possible. As for GPU we don't emulate that because we have shaders. With GLSL ES2 shaders of PS3, we can load them with our standard drivers/compilers, GLSL or CG. Then we can cut antialising, anisotropic and anything we want in order to run them with lower GPUs. In fact PS3 uses CG and offloads those shaders to GPU(200gflops) and the same time to 6 cell spes(1800Gflops): 1spe=8Vectors@128bit(4 issue)[email protected]. To make compatibility layer for OS is easy because PS3 has a lot of BSD open source libraries, from C for cell to network. I may try myself and with friends in the future.

You aren't emulating an instruction set, you are emulating a system. Thats emulation 101.

For example, taking the case of the PS3, there is an instruction that requests data from the ERAM. So you have to maintain a 32MB data structure in order to service that instruction. And I'm sure, somewhere, someone did a really low-level optimization assuming some specific timing for that data to get fed into a register on a specific core, and knows due to program semantics that the data will be executed before its needed by some other core, so no software lock is necessary. And if you do nothing but emulate the instruction set of the hardware, boom, you blow up because your emulator clobbered some memory somewhere by doing things out of order. This is especially noticable when emulating multi-core systems.

[artivision]

You aren't emulating an instruction set, you are emulating a system. Thats emulation 101.

For example, taking the case of the PS3, there is an instruction that requests data from the ERAM. So you have to maintain a 32MB data structure in order to service that instruction. And I'm sure, somewhere, someone did a really low-level optimization assuming some specific timing for that data to get fed into a register on a specific core, and knows due to program semantics that the data will be executed before its needed by some other core, so no software lock is necessary. And if you do nothing but emulate the instruction set of the hardware, boom, you blow up because your emulator clobbered some memory somewhere by doing things out of order. This is especially noticable when emulating multi-core systems.

?????? An instruction that requests data from edram? A program is never compiled with such operations in mind (if they exist at all) and are not part of the recompilation. When you recompile, how the first processor uses its sources its not important, the second processor has its own way. Recompilation means that a game runs to the new processor like you had the source of this game.