Impact of nVidia Turing RayTracing enhanced GPUs on next-gen consoles *spawn

Status
Not open for further replies.
I am curious to see the AMD with primitive shader or equivalent of Mesh shader with a GPU rasterizer using this AMD patent on one or multiple console or a PC, much more than current realtime raytracing. And it will be the logical continuation of rasterizer.

https://www.freshpatents.com/-dt201...FjAAegQIBhAB&usg=AOvVaw1W61MMRnH2aTdZSK_5Lpr8

Parallel micropolygon rasterizers

A parallel adaptable graphics rasterization system in which a primitive assembler includes a router to selectively route a primitive to a first rasterizer or one of a plurality of second rasterizers. The second rasterizers concurrently operate on different primitives and the primitive is selectively routed based on an area of the primitive. In some variations, a bounding box of the primitive is reduced to a predetermined number of pixels prior to providing the primitive...
Click to expand...

Normal mapping is a 1978 algorithm and micropolygon arrived in 1987 with REYES. Maybe this AMD 2008 GDC presentation will be a reality(tesselation + displacement) and not a fantasy.

https://developer.amd.com/wordpress/media/2012/10/Tatarchuk-Tessellation_GDC08.pdf
 
Last edited:
Shifty Geezer said:
I don't know. I wasn't discussing whether the BVH was a black box or not. I was just pointing out that the existence of a GPGPU use of the hardware does not prove it to be transparent and flexible. Neither does that prove it's a 'black box'.

I'm not arguing on the features because I don't know the specifics of the implementation. Others such as milk I think have spoken at length about what they'd like to see in the hardware regards accessible memory access hardware.

You're repeating the same argument instead of moving the discussion forwards. The discussion has proceeded thus far...

1) RTX's BVH is a black box that limits what devs can do.
2) Here's a use of BVH that isn't for raytracing, thereby proving the hardware isn't limiting.
3) Use of the hardware in ways it's not been designed for does not prove it's no limiting.

What we need now is either someone to show that this GPGPU implementation is actually enabled by a transparent implementation disproving point 3, or link to hardware docs etc. showing how the hardware works and is accessible, disproving point 1, or acknowledging yes, the hardware is restrictive but at least it's a first step.
Click to expand...
That's what we've been arguing for a while actually, good seeing you finally accept that point. Like I've previously stated, RTX is just the beginning and its most important contribution is to get the ball rolling. In fact I've also argued that whatever RT acceleration hardware consoles adopt is not going to be the same as RTX because 1) AMD, not NVIDIA, is designing the GPUs and 2) Consoles are still years away.

RT hardware won't be fully programmable for generations to come (if ever) just as has been the case for rasterization. Why? Speed > flexibility, specially in a post Moore's Law world.
 
it is starting to sound like a next gen feature that would definitely help change the rasterization landscape.
If compute shaders were to this gen, mesh shaders should be to next gen.
 
OCASM said:
You keep calling RTX a black box, but really, exactly what things does it prevent you from doing?
Click to expand...

Can you spawn ray casts in a shader on a per pixel or per texel basis, with variables such as distance, decal coverage, arbitrary artist driven material values etc deciding how many rays, how many bounces you use?

And can you guesstimate how many rays / bounces you're likely to use based on the previous frame's stats combined with something cleverish like g-buffer heuristics, so you can distribute a dynamically adjustable number of rays / bounces over changing reflective surface areas to manage performance in a similar way to dynamic resolution?

I honestly don't know. Seriously. I have no idea and no time to try and find out. I don't have time for fun things any more. Only work, hard liquor and tears.

If we didn't adopt it at least in the short term I can tell you what we would miss out on: fast triangle-intersecting ray tracing.
Click to expand...

Sort of like RTX 2070 owners? :p
 
function said:
Can you spawn ray casts in a shader on a per pixel or per texel basis, with variables such as distance, decal coverage, arbitrary artist driven material values etc deciding how many rays, how many bounces you use?

And can you guesstimate how many rays / bounces you're likely to use based on the previous frame's stats combined with something cleverish like g-buffer heuristics, so you can distribute a dynamically adjustable number of rays / bounces over changing reflective surface areas to manage performance in a similar way to dynamic resolution?
Click to expand...
As I understand it, yes. You call for rays inside shaders, so can program how the hardware is used. However, I think (very unsure) that you feed it parameters and don't know what it's doing to return data, which is where some are calling for more openness and flexibility such as creating and maintaining ones own data structure instead of using the RTX-created BVH tree. Or something.
 
Shifty Geezer said:
As I understand it, yes. You call for rays inside shaders, so can program how the hardware is used. However, I think (very unsure) that you feed it parameters and don't know what it's doing to return data, which is where some are calling for more openness and flexibility such as creating and maintaining ones own data structure instead of using the RTX-created BVH tree. Or something.
Click to expand...

Well that's at least pretty good news for a first shot at RT. If you can control when, where, how you cast rays it means you can freely mix SS reflections, spherical reflection maps and RT reflections for the best mix of effect and performance.

Eg. in a racing game SS reflections for most of the floor / bonnet, viewport for rear view, spherical for cars at a distance, ray traced for the inside of your car and photo mode.

Would also allow for giving AI players the ability to spot you in reflections. Fast calculation of ricochets, rebounds and penetration through solids / destruction based subdivision would be awesome if you could get the data out of the system to feed back into your physics engine.
 
function said:
Can you spawn ray casts in a shader on a per pixel or per texel basis, with variables such as distance, decal coverage, arbitrary artist driven material values etc deciding how many rays, how many bounces you use?

And can you guesstimate how many rays / bounces you're likely to use based on the previous frame's stats combined with something cleverish like g-buffer heuristics, so you can distribute a dynamically adjustable number of rays / bounces over changing reflective surface areas to manage performance in a similar way to dynamic resolution?

I honestly don't know. Seriously. I have no idea and no time to try and find out. I don't have time for fun things any more. Only work, hard liquor and tears.



Sort of like RTX 2070 owners? :p
Click to expand...
1) Who knows? At this point maybe not even most developers :p

2) Well, performance would certainly be much worse without hardware acceleration.
 
function said:
Well that's at least pretty good news for a first shot at RT. If you can control when, where, how you cast rays it means you can freely mix SS reflections, spherical reflection maps and RT reflections for the best mix of effect and performance.
Click to expand...
The current concern seems to be about how parallel these workloads are. The drop in watts while raytracing shows lots of idle silicon as Sebbbi has pointed out. The denoising step is also apparently forced on at the end of rendering as a post effect, so when and where you can combine the RT results with other results is uncertain to me.

OCASM said:
1) Who knows? At this point maybe not even most developers :p
Click to expand...
nVidia have some excplanations posted. I haven't time to check them out properly, but one of the presentations I'm pretty sure you linked to explained how to incorporate raytracing into your existing engine including reference to the shader program. I'm surprised you're unable to contribute such info yourself.

2) Well, performance would certainly be much worse without hardware acceleration.
Click to expand...
Performance of raytracing, definitely. However, as mentioned above, concerns at that RT stalls the rasterising pipeline. It's early days and no conclusions should be made, but from an architecture POV, if creating a GPU for professional imaging that's all about raytracing, you wouldn't care about hybrid performance, so it's definitely a possibility that RTX has some notable bottlenecks. Nothing should be assumed at this point, and there are still lots of unanswered questions when it comes to viability of RT hardware in next-gen consoles.

Edit: This seems like an all-round summary. I haven't time to digest any of it but someone else here with time on their hands could actually get the knowledge to answer all our questions. :)

https://devblogs.nvidia.com/practical-real-time-ray-tracing-rtx/
 
Shifty Geezer said:
The current concern seems to be about how parallel these workloads are. The drop in watts while raytracing shows lots of idle silicon as Sebbbi has pointed out. The denoising step is also apparently forced on at the end of rendering as a post effect, so when and where you can combine the RT results with other results is uncertain to me.

nVidia have some excplanations posted. I haven't time to check them out properly, but one of the presentations I'm pretty sure you linked to explained how to incorporate raytracing into your existing engine including reference to the shader program. I'm surprised you're unable to contribute such info yourself.

Performance of raytracing, definitely. However, as mentioned above, concerns at that RT stalls the rasterising pipeline. It's early days and no conclusions should be made, but from an architecture POV, if creating a GPU for professional imaging that's all about raytracing, you wouldn't care about hybrid performance, so it's definitely a possibility that RTX has some notable bottlenecks. Nothing should be assumed at this point, and there are still lots of unanswered questions when it comes to viability of RT hardware in next-gen consoles.
Click to expand...
1) But is that a problem of RTX or of BFV's implementation?

2) I've seen such presentations but I'd rather not answer super specific questions like those myself. Could get some things wrong.

3) As with any new technology, it takes time for developers to learn how to best make use of it.
 
DavidGraham said:
At the very least, NVIDIA made a working demo for it. AMD still hasn't to this very moment.
Click to expand...

Nvidia seems to be far ahead of AMD regarding this tech, and about any other tech perhaps. This isnt good for the market really, as long as nvidia is so far ahead prices sure wont come down anytime soon.
On the other hand, their RTX series and in special the 2080Ti is to me the most impressive GPU ever released, it has a bunch of power for normal rasterization but much of new tech as well, that seems to work very well considering.
 
function said:
Can you spawn ray casts in a shader on a per pixel or per texel basis, with variables such as distance, decal coverage, arbitrary artist driven material values etc deciding how many rays, how many bounces you use?

And can you guesstimate how many rays / bounces you're likely to use based on the previous frame's stats combined with something cleverish like g-buffer heuristics, so you can distribute a dynamically adjustable number of rays / bounces over changing reflective surface areas to manage performance in a similar way to dynamic resolution?

I honestly don't know. Seriously. I have no idea and no time to try and find out. I don't have time for fun things any more. Only work, hard liquor and tears.



Sort of like RTX 2070 owners? :p
Click to expand...
How and when rays are cast is pretty much in the hands of the devs, as well as what to do once you get your hit. That part is pretty open, which is nice.
The black boxy part is the BVH acceleration structure. As it is right now, You just hand in your world geometry to the DX12, and it creates a BVH as the vendor's driver views best, and you have no control over it nor even know what it looks like.
This might seem like a detail, but in the world of Ray tracing optimization, the way you build your acceleration structures is one of the richest areas of study, hence why I'd personally like to see more devs experimenting with that.
My other concern is with how performant mixing different primitive types within your trace (triangle mesh/sdf volume/heightfield/ss g-buffer/shadow maps) is in real world. As of now I know of no info regarding that.
 
Last edited:
BF:V RTX deep dive. It seems not every reflective surface is reflected or correctly reflected. Lower res reflection in the final game than the demo, very noisy water reflection, RTX off in final game looks better than the demo with RTX off.
Their conclusion is the visual gain with RTX is not worth the performance, resolution and AA sacrifice.
 
Theres also people who think RT looks nice and 1080p 60fps suffice. 30fps with 1440p and dxr is also possible.
Pc gamers tend to be very much on the fps thingy, and for mp i can understand.
 
Status
Not open for further replies.

Similar threads

R
State of GDeflate *spawn
2
Replies
25
Views
2K
Remij
R
F
Dedicated gaming GPUs bottom of the priority list?
2
Replies
34
Views
3K
Seanspeed
S
D
AI Desktop Tools - Training and Inferencing
2
Replies
37
Views
6K
Deleted member 2197
D
L
ARM based Game Consoles on the way?
2 3 4
Replies
73
Views
8K
Lurkmass
L
A
Understanding game performance through profiler trace graphs *spawn
2 3 4
Replies
66
Views
4K
XboxKING
X
Back
Top