[HN Gopher] Coding Mistake Made Intel GPUs 100X Slower in Ray Tr...
       ___________________________________________________________________
        
       Coding Mistake Made Intel GPUs 100X Slower in Ray Tracing
        
       Author : sizzle
       Score  : 97 points
       Date   : 2022-07-25 18:18 UTC (4 hours ago)
        
 (HTM) web link (www.tomshardware.com)
 (TXT) w3m dump (www.tomshardware.com)
        
       | userbinator wrote:
       | Intel's GPUs have been exclusively UMA since the i740, so this
       | doesn't seem like a particularly rare mistake to make if it was
       | from someone used to all their previous ones.
        
       | Animats wrote:
       | GPU memory allocation in Vulkan seems to be a huge headache. That
       | seems to be the underlying cause of this ray tracing problem.
       | It's exposed to the higher levels, but in strange ways.
       | 
       | I use the Rend3->wgpu->Vulkan chain, and can't get any info about
       | how much GPU memory is available or left. If I load too many
       | textures into an NVidia 3070, they spill into main memory and
       | rendering continues, slowly. If I load too many meshes, I get a
       | fatal error from the Rend3->WGPU layer, because the allocation
       | that failed happens long after I made the request to load a mesh
       | and it's too late to just return an error for the request.
       | 
       | Can anyone explain why it's so hard to find out the memory
       | allocation situation in Vulkan?
        
         | yw3410 wrote:
         | Are you using the memory budget extension?
         | 
         | https://registry.khronos.org/vulkan/specs/1.3-extensions/man...
        
       | dathinab wrote:
       | Isn't a lot of the "arc is so bad judgement" quite per-mature.
       | 
       | I mean it's all based on the state of the driver used with pre-
       | release GPUs and often the worst GPU of the lineup.
       | 
       | You could say this are beta drivers, but that is somehow not
       | something people mention.
       | 
       | I mean sure there was a lunch of arc mobile GPUs but only in some
       | specific region which was neither the US nor EU, it's as far as I
       | can tell bit like a closed beta release from the dynamics
       | involved.
       | 
       | So shouldn't we wait until the "proper" market launch of the
       | dedicated gpus in the US before taking it apart as a catastrophe?
       | 
       | And sure older Games might not run as well, may some will never
       | (which doesn't mean they don't run good enough to be played
       | nicleye). Maybe except on steam because of the emulation of older
       | direct X versions being base on Vulcan, that will be interesting.
        
         | carry_bit wrote:
         | 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.
        
         | pathartl wrote:
         | 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.
        
         | wmf wrote:
         | 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.
        
         | kmeisthax wrote:
         | 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?
        
         | pdovy wrote:
         | 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.
        
       | cmroanirgo wrote:
       | For those interested, the (linked) source article from Phoronix,
       | which shows the code change:
       | 
       | https://www.phoronix.com/news/Intel-Vulkan-RT-100x-Improve
        
       | ncmncm wrote:
       | Bugs always travel in packs. If you don't see the others, it is
       | because you aren't looking right.
        
       | PaulsWallet wrote:
       | I'm not one to shy away from dunking on Intel and they very often
       | deserve it but I feel that Intel is getting a lot of undue shit
       | in regards to Arc. I'm actually very excited for Arc and will
       | probably buy one to play with if the price is right if for no
       | other reason that Intel's Linux support has in the past been
       | pretty solid.
        
         | babypuncher wrote:
         | 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.
        
           | xbar wrote:
           | Sure. But considering you can't buy them anywhere but China
           | makes the notion of "launched" rather limited.
        
           | PaulsWallet wrote:
           | > Launching with broken drivers certainly did not help.
           | 
           | I get what you mean but people seem to be forgetting that
           | Ryzen launched in an absolutely abysmal state and it took
           | them a few iterations to get to the industry leader that we
           | have today. I think Intel taking the loss leader perspective
           | on this and essentially using people willing to buy as beta
           | testers will pan out for them in the long run. They have been
           | more transparent about it than AMD was with Ryzen or than
           | Nvidia has been with literally anything which I appreciate.
        
       | speps wrote:
       | TLDR: some temporary memory used for ray-tracing was allocated
       | off-chip instead of on-chip, one flag was missing when creating
       | the allocation.
        
         | rayiner wrote:
         | 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).
        
         | MonkeyClub wrote:
         | 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?
        
           | fluidcruft wrote:
           | I think it's just the general trend of portraying intel as
           | incompetent (particularly in GPU).
        
           | Marsymars wrote:
           | > 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.
           | 
           | To note; a 100x speed up is a 9900% boost. A 100% boost is a
           | 2x speed up.
        
       | leeoniya wrote:
       | from the commit discussion:
       | 
       | > This is why there shouldn't be such a bit. :) Default
       | everything to local, have an opt-out bit!
       | 
       | yep. why was the default the slow path?
        
         | nemothekid wrote:
         | > _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.
        
       | mrtweetyhack wrote:
        
       | wnevets wrote:
       | Wouldn't it also be fair to say a driver update made ray tracing
       | 100X faster? Interesting how a negative title has shaped the
       | comments of this post.
        
         | parineum wrote:
         | 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.
        
         | wmf wrote:
         | 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.
        
       | oumua_don17 wrote:
       | Irrespective of this coding mistake, the bigger mistake is
       | shipping Arc a year too late.
       | 
       | In the midst of the pandemic, with the GPU (and chip) shortage on
       | one hand and Intel releasing a decent card with good enough
       | driver reasonably priced would have really given them a great
       | window of opportunity to catch Nvidia and AMD in the GPU blind
       | spot.
       | 
       | It's been so confusing a GPU story to follow that it shows that
       | there has been a lot of confusion and poor planning plus
       | prioritisation in shipping this discrete GPU from Intel,
       | ironically a story not different from their other product and
       | probably indicates a systemic failure. The next year or so should
       | tell us if Pat G can really turnaround Intel or not, most likely
       | not.
        
         | TingPing wrote:
         | The driver wasn't good enough though.
        
       | Heston wrote:
       | How does a massive company like Intel who's work heavily involves
       | code/compiler optimization not profile their drivers for
       | something this simple?
        
         | needusername wrote:
         | It's my general impression that software is not one of Intel's
         | strengths.
        
           | dathinab wrote:
           | I'm not sure about this.
           | 
           | This mistake could easily have been in other vendors Linux
           | GPU drivers, they in the end don't have nearly the same
           | priority (and in turn resources) as the Windows GPU drivers.
           | And it's a very easy mistake to find. And I don't know if
           | anyone even cared about ray tracing with Intel integrated
           | graphics on Linux desktops (and in turn no one profiled it
           | deeply). I mean ray tracing is generally something you will
           | do much less likely on a integrated GPU. And it's a really
           | easy mistake to make.
           | 
           | And sure I'm pretty sure their software department(s?) have a
           | lot of potential for improvement, I mean they probably have
           | been hampered by the same internal structures which lead to
           | Intel faceplanting somewhat hard recently.
        
           | actually_a_dog wrote:
           | Even so, the very first thing anybody learns about GPU
           | programming is to use the VRAM on the card whenever possible,
           | and to minimize transfers back and forth between VRAM and
           | main memory. This is a _super_ basic mistake that should have
           | been caught by some kind of test suite, at least.
        
           | gumby wrote:
           | A little concerning given how much software there is _inside_
           | their CPUs (not just microcode but the management processor
           | et al).
        
             | drfuchs wrote:
             | And how much software is used to generate what's inside
             | them; search for "Pentium FDIV bug".
        
         | pclmulqdq wrote:
         | 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.
        
         | wmf wrote:
         | 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.
        
           | [deleted]
        
         | cjbgkagh wrote:
         | In my circles Intel is a famously awful company to work for.
        
         | operator-name wrote:
         | > There was no local memory bit when you landed this so not
         | your fault ;)
         | https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17...
        
         | bri3d wrote:
         | 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.
        
           | [deleted]
        
             | beepbeepcabbage wrote:
        
           | gspetr wrote:
           | >Why _would_ you expect anything different to happen at a
           | massive company?
           | 
           | Because a massive company has enough money around to put the
           | processes in place and hire skilled people to do both deep[0]
           | testing and system[1] testing.
           | 
           | [0] https://www.developsense.com/blog/2017/03/deeper-
           | testing-1-v...
           | 
           | [1] The definition of "system testing" I'm using: "Testing to
           | assess the value of the system to people who matter." Those
           | include stakeholders, application developers, end users, etc.
        
             | Heston wrote:
             | Exactly what I was thinking. Not to mention the prior
             | experience with similar technologies.
        
           | henrydark wrote:
           | This reminds me of a line from Great Gatsby, where Jordan
           | says she likes big parties because they're so intimate
        
         | secondcoming wrote:
         | Just the other day, an Intel graphics-related driver (dwm or
         | something) was using 13GB of my laptop's memory.
        
         | coliveira wrote:
         | 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.
        
         | jussayonething wrote:
         | 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.
        
           | gspetr wrote:
           | Does the company have people whose job description includes
           | looking for deeper problems such as this one?
           | 
           | I don't know what your position or political standing in the
           | company is, but I assume that with the tech job market the
           | way it is, if you still work there you care about the company
           | to some degree. So perhaps bringing this issue up with (more)
           | senior management is the way to go.
           | 
           | And if they say there is no budget, or that it would take a
           | bureaucratic nightmare to make space for it in the budget,
           | ask them what the budget is for dealing with PR disasters
           | such as this one.
        
       | ldjkfkdsjnv wrote:
        
         | IntelMiner wrote:
         | The level of depth in your comment is comparable to a toddlers
         | swimming pool and the amount of vitriol a Trump rally
         | 
         | This isn't Reddit. Don't just leap in to make pithy comments,
         | try to add to the discussion
        
         | machinekob wrote:
         | Im not sure about waste of money. It is biggest US chip maker,
         | you can for sure point on better chip reusing companies (NVIDIA
         | and maybe AMD [they got a lot of good launches in past 4 years
         | but it can change very quickly]). If USA want to be independent
         | from China destroying/blocking Taiwan there is no other way
         | then manufature your own chips (China and Taiwan put a lot of
         | subsidized into lagging tech all the time and if it clicks it
         | is always big just like TSMC)
         | 
         | Also Tesla grow on US gov support so don't fanboy 2much about
         | that.
        
       | beebeepka wrote:
       | Intel PR machine appears to be in full swing. They sent shills to
       | every tech site and tuber.
       | 
       | Does anyone believe they deserve another chance? After how they
       | treated us, and all their notable competitors throughout their
       | history?
       | 
       | No, I do not believe intel entering the GPU market again is a
       | good thing for anyone but them
       | 
       | You may downvote now
        
         | oblak wrote:
         | To reiterate: impeccably timed fix steals the headlines. Not
         | the greatest deduction for anyone who has been following the
         | industry.
        
       ___________________________________________________________________
       (page generated 2022-07-25 23:01 UTC)