Coding Mistake Made Intel GPUs 100X Slower in Ray Tracing

It was announced that the pricing would be based on the performance of tier-3 titles (the ones not receiving special attention), so it could be a good deal before the drivers improve.

I agree that we should wait for the final release to make any judgements but these drivers have been in development for three years or so. They're not going to magically improve in the next few months.

Yeah it seems pretty unrealistic to expect Intel to catch up to the NVIDIA and AMD duopoly on their first generation of (modern) cards.

Intel seems to have rightly recognized that the driver advantage is a huge moat for those guys - they have to instead compete on price and focus on having good support for titles that will get them the the biggest chunk of the market.

That said, man, if they could have released these a year ago the wind would have been at their back way more than it is now with GPU prices trending back towards MSRP.

Intel has literally sent out engineers to LTT and Gamers Nexus to make this exact point. That being said, the cards are already out on the market and people can still buy them, so it's not like tech reviewers can hold off based on promised future performance.

FWIW I've heard DXVK actually can run on Windows, but you can't use it in AppX containers. Perhaps Intel bundling it with Ark's drivers would be a better option moving forward?

In a similar vein I find reviews in general from most outlets are written only for the release day and are often either not revised if in written form, or not addressed in later videos.

Case in point Baldur's Gate Dark Alliance 2 just saw a re-release where the devs didn't do much but port it to other systems and render the game at a higher resolution. It had a release day bug that caused the game to crash so [some review sites pan the game](https://xboxera.com/2022/07/21/review-baldurs-gate-dark-alli...) giving it low scores of sub-5-out-of-10. The devs fixed it the next day. Now is that particular site going to revise their review? No. It sits at a 4/10 with a small note at the top saying the glitch has been fixed.

Court of public opinion is obviously a thing with Intel, and there's a lot of long-established fanboyism with "team green" and "team red", so there's a lot of people looking to Intel to fail.

Also I hope it's only a matter of time until companies embrace abstraction layers like dxvk.

What does UMA mean?

Launching with broken drivers certainly did not help.

Promising to price their GPUs based on their performance in "Tier 3"* games will certainly help them win a lot of consumer goodwill though, especially with Intel targeting the critically underserved low and midrange gaming GPU market.

* For those OOTL, Intel has grouped all games in to three tiers based on driver optimization and graphics API usage. Tier 1 is DX12/Vulkan titles they have specifically optimized for. Tier 2 includes all other DX12/Vulkan titles. Tier 3 is DX11/OpenGL/older DX. Nvidia and AMD have had a decade+ to optimize their drivers for higher level APIs like DX11, including hundreds of game/engine specific optimizations. The result is ARC GPUs performing notably worse in DX11 titles than equivalent hardware from Nvidia and AMD.

Intel's promised pricing structure means that Your $250 ARC GPU will perform about as well in most Tier 3 games as a $250 RTX or Radeon. Meanwhile, Tier 1 and 2 DX12/Vulkan software will likely outperform competing devices in the same price range.

Honestly, I like it. People are judging the products for how they work right now, which appears to be not very well. If Arc is eventually improved through software, I hope that a new round of reviews will come out then which tells the updated story. If reviews of Arc were undeservedly positive because because there's a chance that driver improvements will make Arc better in the future, that would have been pretty disingenuous to people who wanna buy the product now.

If you want good reviews at launch, then launch a finished product.

It’s my general impression that software is not one of Intel´s strengths.

In my circles Intel is a famously awful company to work for.

Intel's high-level software teams are okay, and their hardware teams are great, but their firmware teams are a bit of a garbage fire. I assume that nobody really wants to work on firmware, and the organization does not encourage it.

Maybe they did profile it and this fix is the result. Or maybe Vulkan raytracing on Linux for an unreleased GPU is lower priority and they just recently got around to noticing it.

Why _would_ you expect anything different to happen at a massive company?

It's not like the team who write the drivers are likely to know of the team working on optimizing compilers, profilers, or anything at all really.

My experience has been that especially in companies working in diverse disciplines across disparate codebases, very little is shared. A team of 8 in a tiny company is just as likely to make the same mistakes as the team of 8 in a bigger company. At large companies with more unified codebases and disciplines, maybe one person or team has added some process which helps identify egregious performance issues at some point in the past. But such shared process or tooling would be really hard at a company like Intel where one team makes open-source Linux drivers while another makes highly specialized RTL design software, for example.

Just the other day, an Intel graphics-related driver (dwm or something) was using 13GB of my laptop’s memory.

Massive companies are more prone to silly errors like this.

Source: I work for a similar massive company. You would not believe the amount of issues similar to this. This one is gettin attention because it happened in open source code.

> There was no local memory bit when you landed this so not your fault ;) https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17...

People working at big companies are ALWAYS worried about releasing lots of code that they need to fulfill some monthly or quarterly goals. These ideas that they have time to profile, improve, or check results are inconsistent with reality. When you see real code produced at big companies, it is barely good enough to satisfy the requirements, forget about any sense of high quality.

Not just Intel but programmers in general have got to demand better tools and use the tools they have. This is an obvious problem if you can see it. It needs to be on every programmers checklist to profile.

I'm not sure it seems like something you'd easily find through profiling? The change was changing a memory allocation to use GPU memory rather than system memory. Allocating system memory probably isn't noticeably slower than allocating GPU memory, so the line that's at fault wouldn't show up when profiling. Instead, memory access in GPU-side raytracing code is just a bit slower when accessing the allocated memory.

So you would have to profile GPU-side code, which is probably really hard; and you'd have to find slow memory accesses, not slow code or slow algorithms, which is even harder. And those memory accesses may be spread out, so that each instruction which uses the slow memory won't stand out; the effect may only be noticeable in aggregate.

When looking at drivers or OSes, the hardware provides performance and the software takes it away. You should consider the ideal performance of the hardware as the baseline and measure the overhead relative to that.

I imagine there was an advertised performance that they were under. I think that's should be the baseline.

This being a mistake/bug, I think it's obviously underperforming rather than being optimized.

Fair indeed, but I suspect the result would likely be the same. It's a bit like making a mess and cleaning it up - good on 'you', but don't expect praise

The article jumps right into that:

> This is something to be celebrated, of course. However, on the flip side, the driver was 100X slower than it should have been because of a memory allocation oversight.

Maybe this is where the phrase "It's a wash" comes from

Anyway, I'm hopeful things mature quickly - having worked with Intel people, I'm cautiously hopeful

>yep. why was the default the slow path?

Only thing I can think of is that they reused to code from their integrated graphics drivers which likely don't support GPU memory. So the default is the option that works on the millions of "GPUs" they have already shipped.

Are you using the memory budget extension?

https://registry.khronos.org/vulkan/specs/1.3-extensions/man...

The driver wasn't good enough though.

I don't blame them but it shouldn't be an easy oversight to make. Profiling should be mandatory. And good profiling tools should exist. We are all flying blind when we code without profiling.

Thanks for the summary, I popped in just for that.

I got intrigued though, and indeed you can read the thing both ways: an optimization gave a 100% boost, or an oversight missed out a 100% boost.

Curiously, Tom’s went with the scare tactic, and got me thinking: is it because clickbait, or do they consciously support the responsibility in software engineering movement?

Not quite. The buffer has been allocated in system memory. The fix was to allocate it in GPU memory (which isn’t on chip, but the local GDDR VRAM).

To reiterate: impeccably timed fix steals the headlines. Not the greatest deduction for anyone who has been following the industry.