Could PlayStation 4 breathe new life into Software Based Rendering?

That's the tech, although I don't think that's the presentation I was thinking of. I distinctly remember a slide something like, "slow memory access, but on GPU we can use 3D textures!" and explicit mention of compute. I recall black pages too. Unsuccessful at a Google.

 

Any interesting sessions here? On my phone and haven't gone to translate it yet but I saw some compute and PS4 based stuff

http://cedec.cesa.or.jp/2014/session/ENG/index.html

 

I believe this is it:

http://bps12.idav.ucdavis.edu/talks/04_crassinVoxels_bps2012.pdf

page 14 is first mention of voxels stored in 3d textures.

Also, here is a new paper as a response to the issue of massive voxel requirements for very large scenes:

http://www.cse.chalmers.se/~kampe/highResolutionSparseVoxelDAGs.pdf

 

This is not software rendering though.

 

No, but once/if you get rid of rasterization for primary rays it gets hard to call it hardware rendering.

 

Every game is a piece of software, they are all software based rendering.

 

It's not raytracing the scene. It's still using triangle meshes and rasterisation. It's just the lighting model is using a compute method. Laa-Yosh is right that this isn't really software rasterising, but we're getting closer and closer. I doubt we'll go full software any time soon as triangle meshes are still the only reasonable choice for geometry in most games, but the flexibility of GPUs means the removal of fixed function pipelines and fixed rendering. Arguably, pixel and vertex shaders are software rendering - just not as adventurous as one would hope.

 

It's not that they didn't have 3D textures, in fact it's very likely that Epic's implementation used 3D textures to store the bricks (Cyril Crassin's original implementation did this). Rather the more recent trend has been to forego using sparse octrees and instead just store the raw voxel data in a 3D texture. The sparse octree setup potentially lets you save lots of memory, since you don't have to store data for empty areas of the scene. It can also potentially let you "skip over" large empty spaces when tracing. However it adds complexity and indirections to your tracing step, and so it can be much cheaper to just directly trace into the raw voxel structure.

 

Using pixel/vertex shaders or compute ALUs is still doing rendering on specialized hardware - hence, not software rendering.

 

Well I think the biggest advantage of the current hardware this gen is enough memory and compute to have PBS systems that ultimately help the artists get much more consistent results with materials and lighting. The Tomorrow Children and Wild really stood out graphically with their respective art styles among the "big boys".

With the SDK price wars I think the middle class will flourish this generation (at least Sony seems to think so) and find a better balance between creative freedom and economic viability.... Aaaaaaand hopefully change peoples views about software "quality" based on budget by shrinking the visual gap between giant studios and smaller leaner studios.

 

They're specialised processors in the same way SPUs were. They're fully programmable including branching. This fact has lead to the development of compute which is running algorithms that don't need to be graphics based. They can't get much more software based without becoming CPUs and losing their performance advantage for massively parallel workloads.

 

they don't lose the performance, it just gets really really really expensive. Larrabee is probably as close as we had ever gotten in recent year, and it didn't get any where.

 

I don't think you're quite reading that right. They saved 5 ms by moving to asynchronous compute. It's the same algorithm (the graphics processing is performed using compute shaders) but it's slotting into spare cycles. The lighting algorithm itself is compute based* so 'software rendering' if you like.

* How does one even classify 'compute based'? It's just shader programs accessing data structure, no matter what type of program it is.

 

25% more.of what they could have at first. I dont think they can even reach 100% efficiency, so 125% is an utopia.

 

Then why didn't you mention async compute? Because it's the async compute part that's saving 5ms, not the use of compute versus graphics pipeline.

I remember a conversation where some people posted that PS4 would be able to get 1.8 TF of graphics and a load more compute work as well.

That's a silly comparison. In this workload, there was lots of spare performance for async compute. In other workloads, the GPU could be pretty saturated at 1.84 TFlops and have little room for parallel compute workloads. So where technically right (The Tomorrow People would need a 2.3 TF GCN GPU to achieve the same results without async compute as a 1.8 TF GCN GPU using async compute), it's a nonsensical number. The purpose of any optimisation is to increase efficiency - there's no value in trying to turn that into a numbers comparison other than % improvement and time saved.

 

From the slides it looks like they moved some common GPU tasks to compute, something 'everyone should do'.

 

Since they moved some tasks to async compute, does this mean they added more frame lag?
Wouldn't these tasks use previous frame data, considering it's done in parallel instead of pipelined?