PlayStation 4 (codename Orbis) technical hardware investigation (news and rumours)
- Thread starter Love_In_Rio
- Start date
- Status
I've been looking for news on eye also, but it seems that Sony have pushed it to the back with regards to PR so it's difficult to find any information regarding its performance.
Maybe. But the point stands. There is such a layer available that makes DirectX project migration really easy (but isn't great for performance). I haven't found the interview yet, but that's how they started for Assassin's Creed 4 - first ported it to that layer, but then decided they would need more performance and control. Then they went low level, and found they really needed to also mind the method of accessing memory (with or without cache, basically). There was a whole discussion afterwards where Shifty wondered if this wasn't just as bad as having a split memory pool, if I remember correctly.
They said they are not ready to talk about it yet. Still working on stuff.
One thing I noticed is silhouette recognition in Playroom. Maybe it's not very accurate, but it does the trick.
So how does this coherent access work on the PS4?
Let's say I have a shared buffer between the CPU and GPU, the CPU modifies a value in that buffer (so that value is in the CPU L1 now), I assume the simplest method for coherency would be to invalidate corresponding addresses in the GPU caches and force them to refetch from memory? Unless there's another port and bus that allows a fast copy from one cache to the other, otherwise I don't see the performance gain.
I think the biggest gain would be in terms of software development, it certainly simplifies that.
Let's say I have a shared buffer between the CPU and GPU, the CPU modifies a value in that buffer (so that value is in the CPU L1 now), I assume the simplest method for coherency would be to invalidate corresponding addresses in the GPU caches and force them to refetch from memory? Unless there's another port and bus that allows a fast copy from one cache to the other, otherwise I don't see the performance gain.
I think the biggest gain would be in terms of software development, it certainly simplifies that.
Isn't that what onion is for?
Onion+?
Anyway, they reference C't. I like that magazine, and will see if I can get the German C't that contains the full article somewhere. Been a while since I bought one of them, but they're always pretty good.
To me at least, from the vgleaks description, it would seem that Onion would invalidate the CPU caches when writing to memory, the data would still have to be pull back in from main memory as it doesn't say anything about forwarding/updating the data.
I always assume a system that really utilized a coherent system would need a large shared L3 cache to help with coherency.
AFAIK "Onion" means that the GPU cache fetches the data via the CPU cache (and then writes changes back via the CPU cache).
Betanumerical
Veteran
So Onion means that changes made to the cache on the GPU are reflected in the CPU caches?.
AFAICT, yes. But it's a rather 'narrow' bus that vgleaks quotes around 20GB/s I think.
http://www.eurogamer.net/articles/digitalfoundry-how-the-crew-was-ported-to-playstation-4
(a surprisingly candid & detailed interview)
Given that the gpu can write to the cpu caches through onion, why not?
Was it AC4? Thought it was something else.
But anyway, I know what your talking about.
I like you believe that they have a translator, that converts most of the dx11 code, and then you may have to do some tweaks for a couple things that don't get converted.
It's to make porting easy. But obviously there is probably a performance hit.
The performance problem was due to them putting the graphic data in the wrong bit of memory.
This is what made people wonder, as thought that didn't matter any more.
Probably did matter due to memory having to be marked as coherent etc though?
Hopefully all made sense, bit to busy to write it better.
Love_In_Rio
Veteran
I think it was "The crew":
http://www.eurogamer.net/articles/digitalfoundry-how-the-crew-was-ported-to-playstation-4
Yea thanks (especially for the link), thought it was that but wasn't sure.
Going by that AMD interview how does that tally with the issues the crew devs had.
Or are they different issues/use of memory.
IIRC, our own T.B. did something similar to translate/transmute/emulify DirectX for Sacred 2, and he went on to work for SCE ATG, though don't know if he's still there. Ah, LinkedIn says yes, he's a PS4 engineer. We won't be hearing from him then. 
Actually Valve has already ported (a major subset of) DirectX 9/10/11 API to Linux (https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Porting Source to Linux.pdf). Their DirectX API uses OpenGL internally to drive the GPU. This allows Valve to write all their games using DirectX. They can use identical code base on both platforms (pure DirectX on Windows and their own wrapper DirectX API in Linux builds). That's quite handy. Would help a lot in porting games to Steam Box (Linux). And of course they could easily extend their DirectX wrapper to support more platforms in the future (like PS4).
There's also a middleware company (forgot the name), that was developing DirectX 11 API for Linux and PS4. There was some discussion about that in some other thread (~ half year ago). Need to dig that up.
I wouldn't be surprised if several other game developers had also created wrappers for small subsets of DirectX to speed up their porting to other platforms (such as Linux and non-Microsoft consoles). DirectX is the most used API in game graphics programming after all. It's quite handy to have around, even if you plan to optimize time critical parts later to a low level hardware API.
- Status
