The Current State Of The Intel "Crocus" Gallium3D Driver

[lorn10]

Also from my side a BIG THANKS to the devs for their superb work in this matter!

That may be now somewhat the wrong place to post that "feature request" but it would be really GREAT if these awesome Crocus devs could also implement (sometime in the feature) the blitImage function into the new driver. (So far this is not already the case.)

That function is missing in the classic i965 driver and it will be probably never added. As a consequence of this it is not possible to switch on multi-GPU systems to another GPU. More information about that long-standing issue can be found here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4368

[mannerov]

That may be now somewhat the wrong place to post that "feature request" but it would be really GREAT if these awesome Crocus devs could also implement (sometime in the feature) the blitImage function into the new driver. (So far this is not already the case.)

blitImage is implemented by gallium, so all gallium drivers should advertise support for it.
Maybe you Crocus wasn't loaded for your card for some reason (did you use the env var to overload driver selection ?)

[Aryma]

as 7gen user i thankful for them and i don't hope or ask for more performance i only went fix for tearing and better dithering for Banding Removal just like windows driver

and remove texture flickering in desktop and opengl program

[lorn10]

blitImage is implemented by gallium, so all gallium drivers should advertise support for it.
...

Thanks mannerov for this information. So you effectively solved that point. The "blitImage feature" is part of gallium, so any gallium driver includes it, - also Crocus. And that's also the reason why the i965 classic driver will most likely never get support for it.

However, until now i didn't test Crocus, I am still on i965 and r600. But i will for sure test Crocus when it is somewhat more "applicable" also for normal Linux users.

[airlied]

Why is this a forked driver and not part of Iris? Are the architecture too different to have them in one driver?

The batchbuffer submission is just too different. The big line is gen8+/iris can rely on softpin, ppgtt and 48-bit address space, whereas prior hw can't. Most of the code is shared anyways via blorp, compiler, isl etc so the crocus code itseif isn't a major amount of code, but there is no way we want it in iris.

[moriel5]

airlied, would there be any interest in the future in writing an OpenCL driver for Intel's iGPUs?
Intel has left Beignet in a broken state (the driver is unable to find it's own libraries due to what appears to be a spelling mistake in the code), and their new NEO stack is incompatible with pre-Broadwell hardware.

I personally can attest that I really need OpenCL in my workflow, however my hardware's support for it is broken (Radeon HD6950 on R600g, with OpenCL being developed, by not yet ready, i5-4570 with Beignet unable to to find it's own libraries), and I currently am not in a financial situation where I can upgrade (even what I have, is nearly all 2nd or 3rd hand, even via dumpster diving (the i5, for example, came from a dead Dell Inspiron miniPC that someone threw out)).

[QwertyChouskie]

airlied, would there be any interest in the future in writing an OpenCL driver for Intel's iGPUs?
Intel has left Beignet in a broken state (the driver is unable to find it's own libraries due to what appears to be a spelling mistake in the code), and their new NEO stack is incompatible with pre-Broadwell hardware.

I personally can attest that I really need OpenCL in my workflow, however my hardware's support for it is broken (Radeon HD6950 on R600g, with OpenCL being developed, by not yet ready, i5-4570 with Beignet unable to to find it's own libraries), and I currently am not in a financial situation where I can upgrade (even what I have, is nearly all 2nd or 3rd hand, even via dumpster diving (the i5, for example, came from a dead Dell Inspiron miniPC that someone threw out)).

I suspect that this being Gallium-based, it should be pretty easy to wire up some basic form of Clover support, though I suspect things may be hardware-limited here.

[Aryma]

airlied, would there be any interest in the future in writing an OpenCL driver for Intel's iGPUs?
Intel has left Beignet in a broken state (the driver is unable to find it's own libraries due to what appears to be a spelling mistake in the code), and their new NEO stack is incompatible with pre-Broadwell hardware.

I personally can attest that I really need OpenCL in my workflow, however my hardware's support for it is broken (Radeon HD6950 on R600g, with OpenCL being developed, by not yet ready, i5-4570 with Beignet unable to to find it's own libraries), and I currently am not in a financial situation where I can upgrade (even what I have, is nearly all 2nd or 3rd hand, even via dumpster diving (the i5, for example, came from a dead Dell Inspiron miniPC that someone threw out)).

they even leave intel-vaapi-driver broken state again and move with Intel Media Driver with Broadwell (2014) and newer only

god I hate this company i will move to AMD next time i have money to upgrade

even intel driver in windows get dropped after one year after they released the hardware and keep bump the version number and fix some security issues you can check Haswell and Ivy Bridge drivers still have windows 8.1 name in it

[Aryma]

I suspect that this being Gallium-based, it should be pretty easy to wire up some basic form of Clover support, though I suspect things may be hardware-limited here.

it work fine in windows tho so I don't think this is hardware limited problem

[geearf]

The batchbuffer submission is just too different. The big line is gen8+/iris can rely on softpin, ppgtt and 48-bit address space, whereas prior hw can't. Most of the code is shared anyways via blorp, compiler, isl etc so the crocus code itseif isn't a major amount of code, but there is no way we want it in iris.

Thank you for the explanation!