Intel Preps More Xe2 Lunar Lake & Battlemage Driver Code For Linux 6.12

[phoronix]

Phoronix: Intel Preps More Xe2 Lunar Lake & Battlemage Driver Code For Linux 6.12

Intel's open-source Linux graphics driver engineers continue feverishly working on the Xe2 graphics support both for imminently-launching Lunar Lake laptops and then the Battlemage discrete graphics cards. This week more "missing bits" were addressed in new Intel Linux graphics driver code on its way to DRM-Next ahead of the upcoming Linux 6.12 merge window...

https://www.phoronix.com/news/Intel-Preps-More-Xe2-Linux-6.12

[sophisticles]

Really looking forward to this new hardware from Intel.

Preliminary benchmarks have Intel's Arrow Lake dominating AMD Zen 5 and Lunar Lake is supposed to be something special as well.

Load up on the Intel stock people, at under $21 a share it's a bargain.

When these product hit the market and the benchmarks hit you will see Intel jump at least $10 a share and I would not be surprised if it close to $100 this time next year.

[lyamc]

I hope they deliver in the areas that they missed with the Alchemist GPUs, cause I really like the A770, but there's some stuff about it that leaves so much to be desired.

The most heartbreaking is that it has 16GB of VRAM but due to driver stuff it can only allocate 4GB at a time, requiring workarounds in things like pytorch to make stable diffusion work

https://github.com/intel/compute-runtime/issues/627

A lot of workarounds result in other fun bugs, like not freeing up memory and causing frequent crash/restarts

[sophisticles]

I hope they deliver in the areas that they missed with the Alchemist GPUs, cause I really like the A770, but there's some stuff about it that leaves so much to be desired.

The most heartbreaking is that it has 16GB of VRAM but due to driver stuff it can only allocate 4GB at a time, requiring workarounds in things like pytorch to make stable diffusion work

https://github.com/intel/compute-runtime/issues/627

A lot of workarounds result in other fun bugs, like not freeing up memory and causing frequent crash/restarts

If you read through the comments in that link you will note that the so-called 4gb issue was caused because support for greater than 4gb is not enabled by default, but if you pass the correct flag to the compiler and also modify the code slightly, you can allocate greater than 4gb with no problem.

This is not a problem with Alchemist, it's the way they designed the driver.

[pong]

If you read through the comments in that link you will note that the so-called 4gb issue was caused because support for greater than 4gb is not enabled by default, but if you pass the correct flag to the compiler and also modify the code slightly, you can allocate greater than 4gb with no problem.

This is not a problem with Alchemist, it's the way they designed the driver.

Their DGPUs were released 2 years ago. They've got issues with this across their driver and higher level (opencl, IPEX etc) stack -- there's also this:

https://github.com/intel/intel-extension-for-pytorch/issues/325

They come out with a "flagship" DGPU with 16 GBy VRAM and you can't trivially MAKE USE OF IT by allocating a 16 GBy sized data structure.

And yet based on the same & related architectures they sell enterprise / data center GPUs; I'm guessing they either don't have these problems with their SW for those OR they really just blew it in the SW / architecture / specifications for these; any way it's unacceptable at launch, even more so 2 years on without a SW fix which should have been "critical" day 1.

In comparison NVIDIA seemingly has much more flexible memory handling:

https://developer.nvidia.com/blog/unified-memory-in-cuda-6/

https://developer.nvidia.com/blog/unified-memory-cuda-beginners/

https://developer.nvidia.com/blog/simplifying-gpu-application-development-with-heterogeneous-memory-management/

And here 2 years after launch you can't even monitor voltages / temperatures, have usable controls for fans / clocks / power / video interface configurations & settings / LEDs / power management on their supported LINUX platform while one can do all that on MSW; there are no usable APIs and HW level documentation to even DIY the CLI / GUI application to do these.

It's pathetic and inexcusable.

And if you can't even allocate / use more than 4GB data structures with ARC seamlessly, what exactly is their plan to release even MORE "capable" GPUs with 24GBy, 32 GBy, etc.?

Is this 1990 with segmented addressing and having to combine small chunks at the application level?! It should all be unified virtual GPU + host + cross-GPU memory!

[Eirikr1848]

And here we were worried about the GPUs with all the layoffs - but it looks like open source stuff for it is sticking around!