Yes, exactly this.
I think they did both.
Not exactly -- there are much worse performance tradeoffs for branching, so (particularly older) shaders are heavily annotated to create new permutations that can be organized and dispatched together rather than one big shader with all of the code. We're moving away from this to an extent, but there are still performance tradeoffs and authoring challenges. (Sometimes when you guys post a "bad" gpu occupancy graph of a game with less stutters you're probably looking at the other side of this tradeoff)
Eh, there's a reason why people are criticizing his approach. Framing the lack of real criticism as "outrage and anger" I think skirts the root of people's criticism. Richard says "I find it hard to get angry about a product you don't have to buy" but in the same vein finds it easy to get excited about a product you don't have to buy(RTX 4090, RTX 3080, etc).... Looking at the whole segment on value in the RTX 5080 review, the MSRP was used to compare value of products... Unfortunately, we knew the msrp was a lie so that comparison doesn't hold water. Even more frustrating is that in today's market, consumers are faced with the reality of determining value based on actual market prices and this should be kept in mind when reviewing a product... On that aspect, DF often misses the mark.
I don't agree with your basic premise that there is a conflict of interest.
DF are like the elite of technology and it's only usually nVidia who offers something different. I can't discern the complicated from the simple.
AIBs have come out to say that the current msrp is too tight and have claimed it's "Equivalent to a charity". Source. In fact, I expect pricing to be highly elevated for the whole generation as Nvidia will tightly control the supply. The margins they gain by redirecting those chips to datacenter are far higher than selling it to gaming customers.
Yea, comments from other reviewers would contradict this....
I don't quite agree. The title suggests an equivalence between the price increase and the performance increase which we know is not true. A more correct title would be "Big Price, Small Performance Increase".
Yes they do but others test more games, examine the history and pricing of the x80 series, do more comprehensive testing like GN on things like cooling dynamics both in and outside of a case. Testing like the 12vhpwr testing to ensure reliability, transient testing, etc.
Yes, I've seriously thought about it and there are lots of reviewers who pay for their products. Some even after receiving a review sample will purchase the product and give it away for free to their userbase. It's a lot different when you have skin in the game. As it stands, there's an uneasy dynamic between reviewers and manufacturers. To continue receiving products, the manufacturer has to be satisfied with your review. We saw this play out with HUB where they were blacklisted by Nvidia for a period of time. We've seen this with other manufacturers where they only send products to people who are likely to give favorable reviews to control the narrative. There's a lot of money at stake with these products and you can't have people torpedoing your sales with bad reviews. So yes, reviewers should pay for their product to address the coercive nature of this relationship.
You can't call it a lie yet. No matter what rumors you've been listening to or what you expect.
Who is saying DF is getting preferential treatment? And also, what could be the motivation for such claims?
It isn't actually a case of correct or not correct. It's about emphasis and tone. Either way, they thought it was worth highlighting in the actual title itself.
Different choices, then, and some of those end up in standalone articles, not the review - appropriately so. But that's just more in line with what you're looking for, not necessarily 'more robust'. DF spends more of their time on image quality, and it's good someone does. I reckon there are more than enough videos that actually take the time to speak a list of percentage differences in 25+ games out loud.
Yeah, no, this isn't sustainable at all. HUB doesn't buy the 50 motherboards in their line up either. That'd be insane. But go ahead and give extra props to reviewers who buy their stuff if you feel like it, it is meaningless to me. The integrity of the reviews themselves and the reputation of the media organization is the skin in the game.
I can call it a lie because I can't purchase the product at msrp. When apple launches their latest macbook, iphone, etc and list the msrp, I can purchase it at msrp on day 1, if not shortly there after. The same is true for a whole host of other manufacturers.
Now you're changing the content of the comment. You said "I see no reason to assume DF gets cards significantly earlier than other reviewers, if at all". However, other reviewers, specifically smaller ones have indicated that they've received review samples late leading to a rushed review cycle for them. Some didn't even receive samples even though Nvidia indicated that they may receive samples. Meanwhile, DF has GPUs early enough to release an early preview weeks in advance....
It's certainly more robust by definition as other reviewers cover far more areas of testing than just image quality, fps, and light power testing.
I do not recall framing my comments to account for what's meaningful to you. You're free to judge by your own metrics as you are your own individual. I'm merely pointing out what is obvious and I understand if it's an uncomfortable topic for you to discuss. As for HUB, they've taken a different approach which is to play chummy with the aib's. It's why you always see sponsored content from aib's on their channel. The benefit of that is that it solves their issue with major product reviews like the gpu and cpu. The downside of that is that it makes the reviews of products from their AIB sponsors subject to the same coercive relationship I referenced earlier. Every reviewer has their bias/slant/conflict of interests. The smart ones inform the audience so the audience can create the appropriate mental offset to interpret their comments/praises/critics. The not so smart ones pretend like it doesn't exist.
that's the issue with AMD, they are under huge pressure, and Intel to a lesser extent, too. AMD is nowhere near nVidia in many aspects. The best thing Intel did is opening Xess to everyone's GPUs. But other than that, they are like a very little nVidia, a duck against a peregrine falcon, no chance.
For GPUs this has been happening for as long as I can recall. Since long before any AI or crypto craziness, long before NVIDIA had 90% marketshare. IDK why it's done this way when like you said many other tech products are generally available when they are launched. But by your logic, many if not most GPU launch reviews were a lie.
Not at all, many reviewers accounted for current real world pricing of competing products when calculating the cost per frame. The 5090 and certainly the 5080 will not be available at anytime soon at the msrp for most people.
You shouldn’t be feeling confident at all. After Evga left, it was clear to see the game nvidia was playing. They started introducing competing reference cards while slowly scaling up their internal manufacturing capabilities. They started to attack the margins of aibs by charging aibs in a way that would make the msrp hard to hit.
Not sure if you are new to the GPU scene but reference cards are nothing new, in fact all IHVs have made them when introducing new products. IHV reference models have always been seen as setting the MSRP price floor. AIBs can choose to price their products as they please anywhere equal to or above the MSRP.
What makes you so sure that AIB's margins aren't tight?
I'm talking about the launch reviews that are written before official availability. It would be impossible to use real world pricing when the card being reviewed can't be purchased. You could compare the MSRP of the new card to the street price of existing cards and I do like when reviewers do this.
I mean shader JIT stutter was a problem even before DX12/Vulkan. In fact it was one of the main reasons that motivated making PSO creation explicit in those APIs because in DX11 and previous there was basically no way for an application to do anything about it even if it wanted to. Obviously there have been downsides to the amount of generality/leeway that was exposed in the newer APIs, but it is not an issue that is unique to them (although the name "pipeline state object" is from them).
The thing that makes it hard to manage is the combinatorial explosion of conceptually separate things that are required by GPUs to be baked down into unique inline programs. For instance in the Fortnite case, you might have a few materials on your fancy new skin (of which there are at least a few hundred/thousand), and for each of those you need a version for a few different rendering situations (base pass, z prepass, shadow, etc). You may need a few versions to handle differences in input (vertex streams, texture layouts and encoding, virtual textures vs. not virtual) and output formats (gbuffer layouts and BRDFs), and then you probably have a few factors related to scalability settings. And of course, the ugliest bit of all is that the graphics pipeline state you need to represent (say, render target formats, blend modes, rasterizer winding orders, depth modes, etc) further multiplies into this matrix so that the driver could have the flexibility to bake shader code based on those things, even if in practice it never does (but a future theoretical driver might). You can see how it's not very hard to get to hundreds of thousands of potential permutations when you multiply these together.
Exactly. Why is there not more of a push from people within the industry for this? Studios could utilize the functionality to basically crowdsource PSOs so much quicker. Before the game is launched, deploy a build of the game for the team to play with the specific purpose of building a cache, collecting as many PSOs as possible, then release the game and have the community very quickly build any remaining caches that were missed. Windows needs this functionality! IMO you can't really call yourself a gaming oriented OS if you don't. Not after SteamOS. It would be incredible to have DX9-12 games run through a layer which does this, and the community would very quickly solve this issue for a huge library of titles. It's the way to go about fixing this issue for the games already released.I mean shader JIT stutter was a problem even before DX12/Vulkan. In fact it was one of the main reasons that motivated making PSO creation explicit in those APIs because in DX11 and previous there was basically no way for an application to do anything about it even if it wanted to. Obviously there have been downsides to the amount of generality/leeway that was exposed in the newer APIs, but it is not an issue that is unique to them (although the name "pipeline state object" is from them).
The thing that makes it hard to manage is the combinatorial explosion of conceptually separate things that are required by GPUs to be baked down into unique inline programs. For instance in the Fortnite case, you might have a few materials on your fancy new skin (of which there are at least a few hundred/thousand), and for each of those you need a version for a few different rendering situations (base pass, z prepass, shadow, etc). You may need a few versions to handle differences in input (vertex streams, texture layouts and encoding, virtual textures vs. not virtual) and output formats (gbuffer layouts and BRDFs), and then you probably have a few factors related to scalability settings. And of course, the ugliest bit of all is that the graphics pipeline state you need to represent (say, render target formats, blend modes, rasterizer winding orders, depth modes, etc) further multiplies into this matrix so that the driver could have the flexibility to bake shader code based on those things, even if in practice it never does (but a future theoretical driver might). You can see how it's not very hard to get to hundreds of thousands of potential permutations when you multiply these together.
Aside: that last bit is probably the main case where you can argue that DX12/Vulkan went too far and should have been more aggressive on nailing down state that IHVs are not allowed to use to affect shader compilation. Recall however that at the time a big goal of these APIs was to work on previous hardware that was never designed with those constraints in mind. It's hard to perfectly guess how much longer it would have taken for these APIs to be accepted (if they ever were at all) if they had not worked on existing hardware, but I think the concern was probably valid, even if it's retrospectively a thorn.
Now in practice, the artists are not creating separate materials for even those fancy new skins or whatever - they are messing with parameters in some conceptual big base material. But because of how GPUs work, you are often punished heavily in performance if you include extra code - even if it is never called - or parameters in a shader, hence needing to separate out many of these parameters into static permutations.
As I noted in another thread - in modern games for the part of the engine that is sensitive to shader explosions you should not think about BRDFs and so on... it's really the code that is effectively doing procedural generation by combining textures, doing some math, and providing a variety of artist tweakable parameters that is the hard to handle bits, but it is also the part that gives significant power to the artists and allows a lot of material variety. Obviously it's a PITA as graphics engineers and I would love if for instance Unreal didn't have quite as powerful a material editor, but on the other hand who can say how much more restricted and graphically uniform games would be if it didn't.
Honestly though I'm sort of curious why no one has done a "fossilize" type thing for Windows yet. Obviously it's ideal if games gather their own PSO lists, but there's also no reason not to crowd-source it so that the damage is minimized across the player base even for games that don't.
