Intel's Open-Source Vulkan Driver For Ray-Tracing Gets "Like A 100x Improvement"

[phoronix]

Phoronix: Intel's Open-Source Vulkan Driver For Ray-Tracing Gets "Like A 100x Improvement"

Intel's Linux graphics driver developers continue to be very busy polishing the DG2/Alchemist graphics card support for forthcoming Intel Arc Graphics hardware... Merged today to the open-source Intel Mesa Vulkan driver was a ray-tracing focused fix that yields "like a 100x (not joking) improvement." Even more of a kicker? The change is one line of code for the massive improvement...

https://www.phoronix.com/scan.php?page=news_item&px=Intel-Vulkan-RT-100x-Improve

[rmfx]

What does it means in terms of overall performance though?
Was the algorithm impacting overall fps a lot, or what is bloating just a few percent ?

[cb88]

What does it means in terms of overall performance though?
Was the algorithm impacting overall fps a lot, or what is bloating just a few percent ?

Its not an algorithmic change... its a memory locality change, basically they were allocating from main system ram instead of local vram memory. Basically... they were doing it wrong, I wouldn't call this an optimization so much as merely programming the hardware correctly its very obvious.

[ms178]

I wonder how fast Intel can deliver on the much needed driver improvements. Arc is going to be a tough sell if they'd take too long, and the last reports point into the direction that much more of these big fixes need to land before even considering them for a gaming GPU.

[aufkrawall]

Apparently the Intel Windows driver could need some optimizations like that too.

[willmore]

I was wondering if this was going to be one of those "Oh, FFS, we forgot to turn the cache on!", but this one is funny, too. Reminds me of an issue I ran into a long time ago when we were porting linux to the WebPal. I was writing the flash programming routine and having a terrible time. A few words of the flash *just would not program*. Even a block erase left them with their original data. Turns out that we didn't clear the cache before disabling it (you need it disabled becuase the address data is how you send the programming commands to the flash chips, so you need all writes to really hit the hardware and there's no need for the cache when you're writing to the flash because the process is *so* slow. You spend 99% of the time waiting on the chip to do something. The actual code spents very little time outside of the busy loop which waits on the busy bit going away.) The problem was that turning off the cache doesn't turn off the cache, it just stops *putting* things in the cache. Anything in there is still used. *sigh* That was a tedious lesson.

[You-]

Until recently system memory WAS gpu memory for all intel graphics.

They will need to comb through the code and find all such assumptions as they go forward.

I am actually hopeful for intel graphics - the recent videos suggest that their weakness is in implementing older versions of direct X. On linux, the community has needed to code workarounds for years now so we may be in a better state than windows.

I hope a linux site gets its hands on a GPU relatively soon to test this assumption.

[cb88]

Until recently system memory WAS gpu memory for all intel graphics.

I wouldn't call drivers for a GPU that has been in development for years recent. They've had engineering samples for eons.

[theriddick]

Should do some comparisons at 1080p with RT demo/games prior and after this patch set. It be interested to see the results.

I'm not sure what Intel iGPU or dGPU can be tested atm. Does phoronix have access to the A380 and A770 cards yet? hopefully soon.

I've never had much luck with RT support under Linux with Mesa (even amdvlk/pro driver). Maybe Mesa 22.2 will change things, time will tell, still stuck on 22.1...

[coder]

I wouldn't call this an optimization so much as merely programming the hardware correctly

Yes, this should definitely be characterized as a bug fix.