Intel's Iris Gallium3D Driver Lands Support For Fast Color Clears

[phoronix]

Phoronix: Intel's Iris Gallium3D Driver Lands Support For Fast Color Clears

Intel's Iris Gallium3D driver may now see slightly better performance in some scenarios thanks to fast color clears support having landed...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-Iris-Fast-Color-Clears

[Apokalypz]

It still kinda sucks that the support cuttoff is Broadwell and newer. I have a laptop with a i7-4750hq that has an iris pro 5200 graphics chip (with the 128MB eDRAM/L4 cache). Since Haswell started the "Iris" GPU name (which autocorrect keeps trying to correct to ISIS.), you'd think the Iris driver support would start back at Haswell.

[Gusar]

Since Haswell started the "Iris" GPU name (which autocorrect keeps trying to correct to ISIS.), you'd think the Iris driver support would start back at Haswell.

The Haswell GPU works very differently compared to Broadwell and later. Even Broadwell wasn't initially supported, it was Skylake+. But because Broadwell works similarly, adding support was easy. Adding support for Haswell would not be easy, that's why you're not seeing it. It's not an arbitrary cut-off point just to piss off Haswell users, a big architectural change happened between Haswell and Broadwell.

[Kayden]

Yeah...sorry about that. If it were reasonable to support Haswell, I would have gladly done it. But Broadwell was a pretty major architectural improvement, and it just makes so much more sense for that to be the cut off point.

There are a ton of things I don't need to worry about in Iris because I dropped Gen7.x hardware support. For example...

• 32-bit pointers for a total of 4GB VMA
• Migrating buffers on the fly to meet VMA restrictions
• Faking ETC2 texturing support via shadow copies in a different format
• Emulating W-tile sampling via Y-tiled shadow copies of stencil buffers, and blitting between those
• A bunch of image load store workarounds
• HiZ buffer layout quirks and restrictions
• Batchbuffer growing instead of the much simpler chaining mechanism
• Kernel command parsers disallowing various things
• Tessellation shader resource management woes
• Double-precision shader and vertex upload differences
• vec4-based / align16 shaders and the associated compiler backend

And that's just to name a few that came to mind. The sheer number of complex issues I no longer have to think about - or add driver overhead to handle - confirms to me that it was the right thing to do. Broadwell is also around 5 years old at this point, and we really need to focus on the future rather than the past.

On the plus side, i965 does support GL 4.5 on Haswell and is pretty darn stable at this point.

[RussianNeuroMancer]

On the plus side, i965 does support GL 4.5 on Haswell and is pretty darn stable at this point.

I using i965 on Thinkpad Helix X1 (Haswell-based) and it's indeed stable. Kudos to Intel for that

[mlau]

Yeah...sorry about that. If it were reasonable to support Haswell, I would have gladly done it. But Broadwell was a pretty major architectural improvement, and it just makes so much more sense for that to be the cut off point.

There are a ton of things I don't need to worry about in Iris because I dropped Gen7.x hardware support. For example...
[...]

Do you give feedback to the hw designers on these points, and if so, do they take it? One of the best things in my previous job was
that the hw designers were sitting in the room next to mine. Occasionally they incorporated some feedback or even VHDL I had written
to make the drivers simpler.

[Kayden]

We're starting to do more of that these days. We've always wanted to, but back when we were catching up on GL features, trying to implement Vulkan, ensure tons of new workloads ran, improve performance, revamp the compiler, and still do hardware enabling...it was sort of all we could do to stay above water. Thankfully, most of the pain points we ran into were also pain points for Windows, so a lot of things got better. Nowadays, we're in a much better place, and have also developed better connections with the other teams. So I'm hopeful we can provide more feedback in the future.

The list above wasn't really meant to say that old hardware is bad. It's just always continually improving, and newer generations are almost always much nicer to work with.

[HyperDrive]

We're starting to do more of that these days. We've always wanted to, but back when we were catching up on GL features, trying to implement Vulkan, ensure tons of new workloads ran, improve performance, revamp the compiler, and still do hardware enabling...it was sort of all we could do to stay above water. Thankfully, most of the pain points we ran into were also pain points for Windows, so a lot of things got better. Nowadays, we're in a much better place, and have also developed better connections with the other teams. So I'm hopeful we can provide more feedback in the future.

The list above wasn't really meant to say that old hardware is bad. It's just always continually improving, and newer generations are almost always much nicer to work with.

I wonder, would it make sense, in the (far?) future, just to rip out support for Gen8+ from the classic i965 driver, once Iris stabilises? I could be wrong, but supporting Gen8+ on the i965 classic driver surely must be just as burdensome as supporting Gen4+ on Iris. Would separating the waters simplify the code (less conditionals and corner cases to deal with)?

[andrei_me]

Will this driver help to close (a little bit?) the perf gap between Intel vs AMD iGPU?

[gukin]

Such fun, I've got a 2400g and an 8259u all the fastested integrated GPUs. Strangely I still can't get a date.

The 8259u with the 655 graphics is a pretty impressive GPU, it won't outrun the vega 11 (eleven) GPU on my Raven Ridge but it's still pretty impressive.

Thanks Intel guys.