Next gen lighting technologies - voxelised, traced, and everything else *spawn*

Yes. If your pay increased by doubling, you'd call that a massive pay rise! 10% improvement is significant. 25% is lots. 50% more is a Big Deal. Twice as much is massive. I think these are defined in one of the later IEEE standards...
Can you find some sources? I mean, likely there is no 'Bid Deal' or 'Massive' words in IEEE standarts :), but i'd like to know seriously...
I do not remember where my own requirement of 'FF has to be an order of magnitude to be worth it' comes from. I think i've heard it often, but could not find anything. (Of course it depends anyways, and yep i mean decimal here :) )

So tried to look op early benchmarks of first GPU vs. software rendering. But that's hard to find!
All i found was a quote from John Carmack (http://fabiensanglard.net/fd_proxy/doom3/pdfs/johnc-plan_1996.pdf):

"2.8 The rendition 3d accelerated version of Quake looks very good. (Aug 22, 1996)
The image quality is significantly better than software - dithered, bilinear interpolated textures, and subpixel, subtexel polygon models.
It is faster than software even at 320*200, and at 512*384 it is almost twice as fast.
We do take a bit of a hit when we have to generate a lot of 16 bit surfaces, so occasionally the framerate gets a bit uneven, but overall it is a very solid improvement."

So just twice as fast? Poor!
But we should not forget: Software renderer has no bilinear filter! Considering this i guess the 10 times speedup was there - at least. (IIRC Unreal was the first that implemented fake bilinear filter with dithered texture coords - still a LOT cheaper than doing it fully.)

So, tell me what you want but a speed up of 2.5 is poor, and i am not impressed.
 
Can you find some sources?...So, tell me what you want but a speed up of 2.5 is poor, and i am not impressed.
This train of discussing loose, subjective definitions is fruitless. Whether you label 2x improvement massive or not, the point is the fixed function hardware provides this level of acceleration. To determine if it's worth it, compare the size of that silicon to the size of silicon needed to achieve the same results without that. As I vaguely understand it, the FF units are guessed to be 10% of the 2070, so some 45 mm² to double performance raytracing. The value of software acceleration given more flexible hardware is impossible to determine until we have software algorithms running on compute to compare.
 
Does a doubling of score in 3dmark actually translate in to a halving of frame times? I'd genuinely like to know, because I hate these arbitrary scores.

If that's true then the improvement is pretty incredible, especially when you'd be comparing a 2070 to a TitanV. You're talking about a card with half the shading power, half the texel rate, and 74% of the fill rate getting roughly 1.46x the performance?


RTX 2070
shading units 2304
tmus 144
rops 64
pixel rate 103.7 Gpixel/s
texture rate 233.3 Gtexel/s
FP32 7.465 TFLOPS

TitanV
shading units 5120
tmus 320
rops 96
pixel rate 139.7 GPixel/s
texture rate 465.6 GTexel/s
FP32 14.899 TFLOPS
 
Does a doubling of score in 3dmark actually translate in to a halving of frame times? I'd genuinely like to know, because I hate these arbitrary scores.

If that's true then the improvement is pretty incredible, especially when you'd be comparing a 2070 to a TitanV. You're talking about a card with half the shading power, half the texel rate, and 74% of the fill rate getting roughly 1.46x the performance?


RTX 2070
shading units 2304
tmus 144
rops 64
pixel rate 103.7 Gpixel/s
texture rate 233.3 Gtexel/s
FP32 7.465 TFLOPS

TitanV
shading units 5120
tmus 320
rops 96
pixel rate 139.7 GPixel/s
texture rate 465.6 GTexel/s
FP32 14.899 TFLOPS
Would be lovely for them to provide a proper graph on what hardware is actually doing each frame.
Should be a lot easier to see bottlenecks which compute based RT would have in comparison and possible differences in hardware or drivers in general.
 
@jlippo One of the things I don't really get about PC benchmarks is what you're really bench-marking is how well the software maps to the hardware. It's not how well the hardware runs the software, it's how well the software runs on the hardware. I think benchmarks really should be providing more detail about utilization, stalls, bottlenecks to make them more useful. Usually a player is trying to upgrade their performance in a particular game they like, so the way sites offer benchmarks ends up being useful in a practical way. But for trying to understand the hardware, the way bench-marking is done leaves a lot to be desired.
 
what you're really bench-marking is how well the software maps to the hardware. It's not how well the hardware runs the software, it's how well the software runs on the hardware.
But that's how the industry works, isn't it?
  1. You get an abstract API, with a clean design principle
  2. Performance of the API implementation is garbage for real life use cases on real life hardware
  3. Software is adapted to match real hardware and behavior of specific API implementation
  4. Software now deviates significantly from the API design principles
For the whole DXR stuff, that pretty much means you *can* use the API as intended. But then you get a rather "cinematic" experience. Easily 3-4x slower than it would be practical. With an awful utilization.

It's not even just the hardware. It's how well the software is tailored to a specific driver.
I think benchmarks really should be providing more detail about utilization, stalls, bottlenecks to make them more useful.
What would you care about performance counters?

The benchmark in whole is pretty useless, unless it was actually to represent a well document "best practice" conformant usage of the tested API.
Even if you had the performance counters, it's still a black box so even if it was to hit a specific bottleneck, you wouldn't know which implementation detail in the benchmark triggered that bottleneck.

Benchmarks do have a use, if they represent naive / common use cases of a vendor / architecture independent API.
And only then provide you with performance counters for parameterized variations of common use cases.
While the vendors don't have an motivation to micro-optimize for a specific test case, optimizations which fail to apply outside of isolation.

The big commercial ones, or using a game which is prominent in the media, certainly do not match that description. They are not expected to advance the technology, they are just about advertisment.
You don't get more than an abstract score, because the rest is indistinguishable anyway.
And for a benchmark it needs to be a non-synthetic mess, because you otherwise see hardware vendors taking unrealistic shortcuts wherever they can. Vendor of a commercial tool can't have that, because they need to claim to be "neutral" or they won't sell.
This isn't an ecosystem built on trust. This is just about marketing and sales.


If you really want a meaningful benchmark, start writing one yourself. Make it open source, so it can be used with ordinary debugging tools.
Be naive in the use of the APIs. Use them as the design documents intend you to.
If there is an edge case which performs badly, it stays part of the benchmark. Put the responsibility back on the vendor to provide a well optimized and sufficiently adaptive implementation.
 
@Ext3h The only reason I mentioned something like performance counters is just for the curiosity of people that are really trying to evaluate hardware. It's not what the average consumer may necessarily want. They just want to know that the game they play all the time is going to run faster when they upgrade. You are definitely right that without insight into algorithms and data layout and access patterns, you really can't make an informed judgement of efficiency.
 
Digital Foundry found out that you can have comfortable 1080p performance with Medium DXR on the 2060, fps were comfortably in the range of 70. They can also play 1080p60 with Ultra DXR but with small dips every now and then.

The secret to that, is dropping texture quality from Ultra to High, as DXR heavily consumes VRAM, the 6GB of the 2060 is not enough to hold Ultra textures and DXR together.

Also DF predicts more DXR performance improvements in the next BF update, the one that will add DLSS.

 
Interesting. Would be nice if BFV had a way of reporting vram directly. One easy stat that helps you adjust your settings in a sane manner. I'd actually be really interested to see if it's just a vram limit or there are other performance implications in lowering texture resolution with rtx on. Would be cool to see a test on 2080. It's an 8GB card. Maybe a 4k/1440p test with rtx on with textures ultra to low.
 
The secret to that, is dropping texture quality from Ultra to High, as DXR heavily consumes VRAM, the 6GB of the 2060 is not enough to hold Ultra textures and DXR together.

Wow very impressive indeed, just from Ultra to High for just textures, thats still.... high :) Performance will only improve over time as new patches and drivers make their way. 2060 doing RT with everything ultra 60fps, thats nice to hear. Should do 4k with ease without DXR. Or you can mix, offcourse.

Nvidia is killing it!
 
I have played the one shot Resident Evil 2 demo and have come to the conclusion that SSR have no reason to exist anymore. They are looking really bad in RE2. Reminds me of Quantum Break. Remedy used them a lot and they have the same problems: Artefacts, low res and disappearing from the screen.

I have >100FPS in 1440p with a RTX2080TI. Frames dont matter when quality is this bad.
 
Last edited:
Back
Top