Doubling console performance has gone from $250 2.7 years into a generation to $800 4 years into a generation. This is not at all comparable to the 1060.They both launched at $250 (except 1060 FE was $300)
Doubling console performance has gone from $250 2.7 years into a generation to $800 4 years into a generation. This is not at all comparable to the 1060.They both launched at $250 (except 1060 FE was $300)
Technically, rasterising is just the mathematical process of transforming triangle (or HOS) geometry to a flat screen-space or buffer. Back in the early days of CG and drawing flat triangles, we either raytraced them or rasterised them. Rasterising was faster and how GPUs were designed to work, and so everything they did became 'rasterising' regardless how complicated the process became. We can include texture sampling and shading in that process, but things like projecting shadows probably doesn't come under that. Calculating LOD probably doesn't come under that.I do agree that there’s a terminology problem at play. Just in case I’m not helping: when I personally say I want “more raster”, I literally mean more innovation in how we feed and program the actual hardware rasteriser in the modern graphics pipeline, and what happens in the hardware and software as a result of that pipeline stage, and how its role and functionality evolves and results in better graphics now and in the future.
Technically, rasterising is just the mathematical process of transforming triangle (or HOS) geometry to a flat screen-space or buffer.
That's my point: people use the "rasterization" word as if it means "everything which isn't RT h/w" while "rasterization" is just one step of traditional rendering pipeline in h/w with most of other steps (again, in h/w) being used even for pure PT. So the whole division is misleading, RT won't work without general purpose FP32 processing units whatever you'd call them, it won't work without memory load/store units, without the very same caches, even without texture filtering h/w (you could do the same calculations via shaders of course but this again won't be "RT h/w").You’re free to run some shaders to compute an image using your ray tracing, but you still haven’t rasterised. This is effectively the whole communication problem (that I have, not saying you do) in a nutshell. Earlier in the thread we all played fast and loose with the word raster and it didn’t help, but now we’re being specific and using the definition in the graphics pipeline and we’re still a bit stuck.
The lack of agreed precision in the terminology is part of why I think it can often be problematic to discuss ray tracing. Maybe it’s (genuinely) just a problem I have and everyone else is following along with each other.
I'm not sure I understand that line of thought that led to the conclusion in this post ...I find it ironic that the IHV that markets RT the hardest and dedicates the most die space to RT hardware also has the most die space dedicated to specific rasterization tasks. Nvidia's PolyMorph engine handles tessellation, vertex fetch, and other tasks. AFAIK AMD doesn't dedicate HW for that, which is forward-looking if mesh shaders or software rasterization take off since they don't utilize that dedicated HW. If future generations of Nvidia cards ditch the PolyMorph engine in response they could dedicate even more die space to RT. So paradoxically, new rasterization techniques like mesh shaders and SW rasterization could push ray tracing further. I think there will be a point at which most games will be using mesh shaders or SW rasterization for primary visibility and RT for lighting (with neural rendering techniques potentially added), and it will stay that way for a very long time.
Take for example ray marching techniques, used nowadays to renders stuff like volumetrics (clouds, fog, smoke، god rays, ... etc), used also for advanced shading, screen space shadows, screen space reflections and others, people still classify them under rasterization, despite them having very little to do with rasterisation!It doesn’t make sense to me to bucket workloads under “raster” when those workloads are equally applicable to a fully raytraced implementation
Why would DLSS cause stuttering lolA lot more than the GTX 760.
Did you bitch about the GTX 1060's price?
Did you say that about the 9800GTX?
You can only drop prices so much before it's not worth making the product anymore. And without knowing exactly the cost of each GPU it's impossible to know how much their prices can be dropped, so yes, it's not that simple.
AMD have to drop prices to force sales, they have always done this.
Sure that's not DLSS?
Funny, I've never had an issue with either of those game, at native 4k.
Why would DLSS cause stuttering lol
Btw 960 was 200, 1060 was 250.
I don’t care that neither of these cards did 4k, as even top end cards didn’t do 4k.
I understand liking Nvidia hardware but this generation was universally considered overpriced and that’s why the Super refreshes came out.
They both launched at $250 (except 1060 FE was $300)
Frame generation specifically, not DLSS, and it is a result of a bad implementation which can be fixed - and is usually fixed with game patches.DLSS does cause stuttering
DLSS does cause stuttering, just like it did in The Witcher 3 next gen update.
...
Only Founders Edition, MSRP for the rest was $249 like 7601060 6GB was $299
NVIDIA is pricing the GeForce GTX 1060 at a surprising $249 price point, which is just $20 more than the Radeon RX 480 8 GB. Its Founders Edition reference-design SKU, which we are reviewing today, is priced at a $50 premium, at $299.
I'm not claiming specialized HW is inherently faster for a given task. Just that the current trend with games - including Nvidia-sponsored titles - is that the vertex shader pipeline is becoming less important and therefore the HW Nvidia dedicates to it will have less and less value but RT HW will only increase in value.Just because a particular IHV implements a lot of special HW states for specifically accelerated pipelines (GFX/compute/RT), it doesn't necessarily mean that they'll always have fastest implementation for those certain sets of pipelines. Developers will use those features if it makes sense (RT pipeline/texture sampling/etc) for their use case or other more programmable features (bindless/compute shaders) as well and IHVs can't force developers to use API/features that they don't like such as vertex buffers or tessellation ...
More specialized HW implementations aren't always better since it can make it harder for them to do work balancing/distribution compared to more flexible HW implementations as we saw in the past before the advent of unified shading pipelines or more recently async compute. At the end of it all, competitive hardware design isn't purely about mutually exclusively subscribing to diametrically opposed philosophies between special hardware acceleration or dynamic repartitioning schemes for hardware resources since in the real world IHVs are forced to find the optimal balance to match common API usage patterns ...