Crocus: Working On Gallium3D For Old Intel Graphics

[oiaohm]

My gf has MacBook 2013 with Fedora and Intel Graphics HD 5000. It seems to be 5th generation…?

https://en.wikipedia.org/wiki/Intel_Graphics_Technology#Capabilities_(GPU_hardware)

No that is not a 5th generation. HD 5000 is a 7.5 Gen Haswell. Some of those work with the Iris driver some of those don't. Seams to be how the are firmware init is done if they work or not. A few people think the MacBook 2013 has to be a older generation of Intel chip that want it really is there because of the bug being there.

was through its history built by dozens of various compilers (specifically, various versions of GCC and Clang), possibility of such bug is very low.

This does not help. The common reason for old driver code breaking with newer compilers are compilers getting better at detecting coding defects and putting in runtime safe guard items to pick up buffer overflows and other issues. So a defect in the driver that was historically ignored by compilers turns into a error. So you can test with thousands of old compliers and the new compiler will still kick you ass for defects the old compilers would let slide. So there is a need for on going maintenance as static analyzation and runtime prevention of coding defects done by compilers gets better.

The risk of a new compiler ruining your day does not go down with age of the code base.

[oiaohm]

When i first moved to Linux i was on a laptop that has Ironlake igpu, i5 480M cpu.

I was able to play Medieval 2 Total War ( i still play it on a GTX 1050 Optimus laptop) on Windows with all low settings at close to 30 FPS ( since that is a strategy game high fps is not entirely needed) , but on Linux i faced two problems with it.

1-) Native Feral port of this game needs GL 3 , but that gpu got stuck at GL 2.1. So i wasn't able to run it.
2-) Windows version of it didn't work with Wine but even if it did probably i would be getting like 5 fps or so with probably broken graphics.

So while most users won't care about this aspect, users and use cases like this exist.

Which i have seen couple of setups on Proton Github tracker where people were not having good times with Wined3d with those hardware. Slow+broken

Ironlake igpu, i5 480M that is Westmere 5.5Gen this is a i915 driver not covered by the Crocus work.

https://en.wikipedia.org/wiki/Intel_Graphics_Technology#Capabilities_(GPU_hardware)

This here pays to look at notice how Windows had dx 10.1 on Westmere. Wined3d is needing something opengl 3.x to do that.

Native Feral port recommendation of GL3 was basically because they were using a Wined3d route.

Yes the i915 driver for the 2 non vulkan supporting families of Intel graphics under Linux is not great. Sandy Bridge where you get 3.3 opengl does Wined3d start being able to-do something decent. 2.1 opengl forces insane about of CPU emulation to do Dx9 stuff this results in horrible bad wined3d performance.

The reality is the Westmere generation Intel hardware the Linux driver is not much chop at all. There are hardware features that are not exposed to opengl that were exposed to Windows Dx 9 and 10. That effectively makes Wined3d screwed on them. The crocus work is not going to fix the Westmere due to the fact Crosus is targeting 7th gen and newer yes Westmere is 5.5Gen so not covered by Crosus work. This has been another problem with galluim nine. Items like Westmere you are screwed under Linux you have no galluim nine because you have no galluim you have no decent opengl and you have no vulkan.

It would be possible if Westmere got a proper galluim driver to expose some hardware features to galluim nine that are not suitable to expose to opengl or vulkan but we would need someone willing to take up the gen 5.5 and 6 problem .

[Leopard]

Ironlake igpu, i5 480M that is Westmere 5.5Gen this is a i915 driver not covered by the Crocus work.

https://en.wikipedia.org/wiki/Intel_Graphics_Technology#Capabilities_(GPU_hardware)

This here pays to look at notice how Windows had dx 10.1 on Westmere. Wined3d is needing something opengl 3.x to do that.

Native Feral port recommendation of GL3 was basically because they were using a Wined3d route.

Yes the i915 driver for the 2 non vulkan supporting families of Intel graphics under Linux is not great. Sandy Bridge where you get 3.3 opengl does Wined3d start being able to-do something decent. 2.1 opengl forces insane about of CPU emulation to do Dx9 stuff this results in horrible bad wined3d performance.

The reality is the Westmere generation Intel hardware the Linux driver is not much chop at all. There are hardware features that are not exposed to opengl that were exposed to Windows Dx 9 and 10. That effectively makes Wined3d screwed on them. The crocus work is not going to fix the Westmere due to the fact Crosus is targeting 7th gen and newer yes Westmere is 5.5Gen so not covered by Crosus work. This has been another problem with galluim nine. Items like Westmere you are screwed under Linux you have no galluim nine because you have no galluim you have no decent opengl and you have no vulkan.

It would be possible if Westmere got a proper galluim driver to expose some hardware features to galluim nine that are not suitable to expose to opengl or vulkan but we would need someone willing to take up the gen 5.5 and 6 problem .

https://gitlab.freedesktop.org/mesa/mesa/-/issues/4497#note_851672

https://patchwork.kernel.org/project/intel-gfx/patch/[email protected]/

https://gitlab.freedesktop.org/airlied/mesa/-/blob/crocus/src/gallium/drivers/crocus/crocus_todo.txt

Are you really sure about all that Crocus targeting Gen7 and newer theory?

[reba]

Output of vulkaninfo for an IvyBridge iGPU:

VkPhysicalDeviceProperties:
---------------------------
apiVersion = 4202641 ([B]1.2.145[/B])
driverVersion = 83898373 (0x5003005)
vendorID = 0x8086
deviceID = 0x0166
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = [B]Intel(R) HD Graphics 4000 (IVB GT2)[/B]

VkPhysicalDeviceDriverProperties:
---------------------------------
driverID = DRIVER_ID_INTEL_OPEN_SOURCE_MESA
driverName = Intel open-source Mesa driver
driverInfo = Mesa 20.3.5
conformanceVersion = [B]1.2.0.0[/B]

Loaded kernel module is i915:

user@debian:~$ sudo lspci -v
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
DeviceName: Onboard IGD
Subsystem: Samsung Electronics Co Ltd 3rd Gen Core processor Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 30
Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
I/O ports at f000 [size=64]
Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: [B]i915[/B]
Kernel modules: [B]i915[/B]

Loaded user mode driver is i965:

user@debian:~$ vainfo
va info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.10 (libva 2.10.0)
vainfo: Driver version: [B]Intel i965 driver for Intel(R) Ivybridge Mobile - 2.4.1[/B]
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD

Outut of glxgears with i965:

user@debian:~$ MESA_LOADER_DRIVER_OVERRIDE=i965 LIBGL_DEBUG=verbose glxgears
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
[B]libGL: Using DRI3 for screen 0
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
301 frames in 5.0 seconds = 60.066 FPS[/B]

I cannot decide if iris is actually working or not. Loading seems to fail but output is different to i965:

user@debian:~$ MESA_LOADER_DRIVER_OVERRIDE=iris LIBGL_DEBUG=verbose glxgears
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/iris_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL error: failed to create dri screen
[B]libGL error: failed to load driver: iris[/B]
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/iris_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL error: failed to create dri screen
libGL error: failed to load driver: iris
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
[B]7433 frames in 5.0 seconds = 1486.490 FPS[/B]

[Leopard]

Output of vulkaninfo for an IvyBridge iGPU:

VkPhysicalDeviceProperties:
---------------------------
apiVersion = 4202641 ([B]1.2.145[/B])
driverVersion = 83898373 (0x5003005)
vendorID = 0x8086
deviceID = 0x0166
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = [B]Intel(R) HD Graphics 4000 (IVB GT2)[/B]

VkPhysicalDeviceDriverProperties:
---------------------------------
driverID = DRIVER_ID_INTEL_OPEN_SOURCE_MESA
driverName = Intel open-source Mesa driver
driverInfo = Mesa 20.3.5
conformanceVersion = [B]1.2.0.0[/B]

Loaded kernel module is i915:

user@debian:~$ sudo lspci -v
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
DeviceName: Onboard IGD
Subsystem: Samsung Electronics Co Ltd 3rd Gen Core processor Graphics Controller
Flags: bus master, fast devsel, latency 0, IRQ 30
Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
I/O ports at f000 [size=64]
Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: [B]i915[/B]
Kernel modules: [B]i915[/B]

Loaded user mode driver is i965:

user@debian:~$ vainfo
va info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva error: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
libva info: va_openDriver() returns 1
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_8
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.10 (libva 2.10.0)
vainfo: Driver version: [B]Intel i965 driver for Intel(R) Ivybridge Mobile - 2.4.1[/B]
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264StereoHigh : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
VAProfileJPEGBaseline : VAEntrypointVLD

Outut of glxgears with i965:

user@debian:~$ MESA_LOADER_DRIVER_OVERRIDE=i965 LIBGL_DEBUG=verbose glxgears
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/i965_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
[B]libGL: Using DRI3 for screen 0
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
301 frames in 5.0 seconds = 60.066 FPS[/B]

I cannot decide if iris is actually working or not. Loading seems to fail but output is different to i965:

user@debian:~$ MESA_LOADER_DRIVER_OVERRIDE=iris LIBGL_DEBUG=verbose glxgears
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/iris_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL error: failed to create dri screen
[B]libGL error: failed to load driver: iris[/B]
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/iris_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL error: failed to create dri screen
libGL error: failed to load driver: iris
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so)
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/user/.drirc: No such file or directory.
[B]7433 frames in 5.0 seconds = 1486.490 FPS[/B]

Ivy Bridge is older than Haswell and both of them doesn"t/cannot run with Iris.

Crocus aims to change that.

[Hi-Angel]

https://en.wikipedia.org/wiki/Intel_...(GPU_hardware)
No that is not a 5th generation. HD 5000 is a 7.5 Gen Haswell. Some of those work with the Iris driver some of those don't. Seams to be how the are firmware init is done if they work or not. A few people think the MacBook 2013 has to be a older generation of Intel chip that want it really is there because of the bug being there.

Oh, you're right! It's just that google says HD5500 is a 5th gen, but apparently this is wrong:



Odd. Anyway, yeah, the card doesn't work with Iris. I remember I tried forcing Iris while experimenting and it was resulting in errors.

This does not help. The common reason for old driver code breaking with newer compilers are compilers getting better at detecting coding defects and putting in runtime safe guard items to pick up buffer overflows and other issues. So a defect in the driver that was historically ignored by compilers turns into a error. So you can test with thousands of old compliers and the new compiler will still kick you ass for defects the old compilers would let slide. So there is a need for on going maintenance as static analyzation and runtime prevention of coding defects done by compilers gets better.

The risk of a new compiler ruining your day does not go down with age of the code base.

That is the UB I mention You don't necessarily need a safeguard to get some memory corruption and/or a crash from a buffer overflow. IOW a buffer overflow will likely reveal itself disregarding a compiler version. Usually building with optimizations increases the chance of stumbling upon it, and distros do build drivers with optimizations.

[oiaohm]

https://gitlab.freedesktop.org/mesa/mesa/-/issues/4497#note_851672

Are you really sure about all that Crocus targeting Gen7 and newer theory?

I should explain better. Gen7 the Vulkan line time frame is when you can kind of expect features exposed in DX to line up to the features exposed in opengl. Before that things are messy,

That issue pointed to there has something. There is a side to this that is horrible, We need someone to take up gen 5.5 and 6 who target is gallium Nine or something like it Why?.

Simple opengl has a set of requirements to be useful that if you implement X feature you must implement Y feature dependency. So just because the hardware can do EXT_texture_integer does not mean you can expose this on the opengl interface in that issue. Fun point DX10 and DX9 both can use EXT_texture_integer feature and don't need NV_gpu_program4 or EXT_gpu_shader4 hardware to use texture Integer.

The opengl rules Crocus is trying to work to align with Intel Generation 7 or newer hardware to be able to expose all the hardware features in a usable way. The line that Vulkan support appears in Intel hardware.

Generation 6 there will be a few hardware features that help with game performance that cannot be exposed by opengl and be performance due to the dependany rules inside opengl. Generation 5.5 being stuck at opengl 2.1 will be very hard to get around. Gen 5.5 hardware has a lot of hardware acceleration not be exposed by opengl because its half features where you have 1 feature then not it dependency and you need both to expose the feature by opengl interfaces..

If you goal is to run the old games using Linux on 5.5 and 6 gen hardware and get them to perform decently like windows performance this can only happen one way. A developer steps forwards who working on the galluim Nine and to bring back a galluim 10.

Gen 4 and 4.5 you are going to be stuck without the hardware to accelerate lot of these features. So 5.5 fairly much comes a hard line in the sand.

I should have been more exact the problem in 5.5 and 6 generation hardware resulting in poor opengl support leading to poor wined3d performance and not being able to run particular games because you don't have high enough opengl are not really going to be fixed by Crocus work.

The different mix of features between opengl and DX start in the i915 time frame.

EXT_gpu_shader4 is a mandatory feature for OpenGL 3.0 that everything with opengl 3.0 and newer has it. Of course when it was a option feature in the Opengl 2.X time frame hardware did not have to include the feature parties like Intel and ATI(at the time now AMD) would not include the feature because it was not covered by the patent agreement of Khronos.

Know how you had a ported game mandating opengl 3 that was to have texture integer. Wined3d on gen 5.5 hardware due to those features not being exposed is forced to software render or in other words be the slowest snail you ever met. Wined3d you are really in a lot of cases looking for at least opengl 3.0 supported by hardware if you don't want to risk being really slow.

This brings us back to another problem.

https://en.wikipedia.org/wiki/Intel_Graphics_Technology#Capabilities_(GPU_hardware)

Look at the link closely at the 5.5 the DX is 10.1

https://en.wikipedia.org/wiki/High-Level_Shading_Language

Its DX 10 where you get integer shader language in Direct X. Horrible but you have integer textures in dx9 without any matching gpu shader. So EXT_texture_integer feature should be exposed to DX applications when it should to be to Opengl applications. Converting to floating point textures when you should be using integer textures creates at times graphical artefacts.

You wrote "Medieval 2 Total War" -"Windows version of it didn't work with Wine but even if it did probably i would be getting like 5 fps or so with probably broken graphics."
You right but a new Crocus work is unlikely going to fix this. Particular the broken graphics bit. Because the broken graphics and poor performance is going to come from the integer texture problem. The port mandating 3.x opengl was for a required feature so the game looks right and does not have graphical artefacts from texture conversion from integer to float.

Gen 5.5 Intel has you in a very annoying problem space. Of course it gets worse when you work out that the miss match there really does mean you need something like galluim 9 but for DX10 as well if you wish to support 5.5 and 6.0 in a nice working way.

For game support the current Crosus work is basically Gen 7 or newer because to fix the game support problem opengl is not going to be the solution in those generations of gpu just due to their hardware configurations. Now if we are lucky Gen 6 intel might be able to expose all it can do by Opengl. Problem here is gen 5.5 absolutely cannot and really will need a developer to go in with a different objective particularly targeting these pains in but hardware from gen 5.5 and 6 time frame.

There are time frames of hardware like or not that to get the best out of them require special handling.

[Leopard]

I should explain better. Gen7 the Vulkan line time frame is when you can kind of expect features exposed in DX to line up to the features exposed in opengl. Before that things are messy,

That issue pointed to there has something. There is a side to this that is horrible, We need someone to take up gen 5.5 and 6 who target is gallium Nine or something like it Why?.

Simple opengl has a set of requirements to be useful that if you implement X feature you must implement Y feature dependency. So just because the hardware can do EXT_texture_integer does not mean you can expose this on the opengl interface in that issue. Fun point DX10 and DX9 both can use EXT_texture_integer feature and don't need NV_gpu_program4 or EXT_gpu_shader4 hardware to use texture Integer.

The opengl rules Crocus is trying to work to align with Intel Generation 7 or newer hardware to be able to expose all the hardware features in a usable way. The line that Vulkan support appears in Intel hardware.

Generation 6 there will be a few hardware features that help with game performance that cannot be exposed by opengl and be performance due to the dependany rules inside opengl. Generation 5.5 being stuck at opengl 2.1 will be very hard to get around. Gen 5.5 hardware has a lot of hardware acceleration not be exposed by opengl because its half features where you have 1 feature then not it dependency and you need both to expose the feature by opengl interfaces..

If you goal is to run the old games using Linux on 5.5 and 6 gen hardware and get them to perform decently like windows performance this can only happen one way. A developer steps forwards who working on the galluim Nine and to bring back a galluim 10.

Gen 4 and 4.5 you are going to be stuck without the hardware to accelerate lot of these features. So 5.5 fairly much comes a hard line in the sand.

I should have been more exact the problem in 5.5 and 6 generation hardware resulting in poor opengl support leading to poor wined3d performance and not being able to run particular games because you don't have high enough opengl are not really going to be fixed by Crocus work.

The different mix of features between opengl and DX start in the i915 time frame.

EXT_gpu_shader4 is a mandatory feature for OpenGL 3.0 that everything with opengl 3.0 and newer has it. Of course when it was a option feature in the Opengl 2.X time frame hardware did not have to include the feature parties like Intel and ATI(at the time now AMD) would not include the feature because it was not covered by the patent agreement of Khronos.

Know how you had a ported game mandating opengl 3 that was to have texture integer. Wined3d on gen 5.5 hardware due to those features not being exposed is forced to software render or in other words be the slowest snail you ever met. Wined3d you are really in a lot of cases looking for at least opengl 3.0 supported by hardware if you don't want to risk being really slow.

This brings us back to another problem.

https://en.wikipedia.org/wiki/Intel_Graphics_Technology#Capabilities_(GPU_hardware)

Look at the link closely at the 5.5 the DX is 10.1

https://en.wikipedia.org/wiki/High-Level_Shading_Language

Its DX 10 where you get integer shader language in Direct X. Horrible but you have integer textures in dx9 without any matching gpu shader. So EXT_texture_integer feature should be exposed to DX applications when it should to be to Opengl applications. Converting to floating point textures when you should be using integer textures creates at times graphical artefacts.

You wrote "Medieval 2 Total War" -"Windows version of it didn't work with Wine but even if it did probably i would be getting like 5 fps or so with probably broken graphics."
You right but a new Crocus work is unlikely going to fix this. Particular the broken graphics bit. Because the broken graphics and poor performance is going to come from the integer texture problem. The port mandating 3.x opengl was for a required feature so the game looks right and does not have graphical artefacts from texture conversion from integer to float.

Gen 5.5 Intel has you in a very annoying problem space. Of course it gets worse when you work out that the miss match there really does mean you need something like galluim 9 but for DX10 as well if you wish to support 5.5 and 6.0 in a nice working way.

For game support the current Crosus work is basically Gen 7 or newer because to fix the game support problem opengl is not going to be the solution in those generations of gpu just due to their hardware configurations. Now if we are lucky Gen 6 intel might be able to expose all it can do by Opengl. Problem here is gen 5.5 absolutely cannot and really will need a developer to go in with a different objective particularly targeting these pains in but hardware from gen 5.5 and 6 time frame.

There are time frames of hardware like or not that to get the best out of them require special handling.

Omfg

1-) You don't read
2-) You don't admit you screwed
3-) You don't know difference between Gallium and Vulkan.

https://wiki.ixit.cz/d3d9

4-) You can use Gallium 9 in Wine

https://github.com/iXit/wine-nine-standalone

5-) Medieval 2 Total War is a DX9 game

6-) Again, Vulkan support and Gallium are completely different things

7-) Crocus in not upstream yet and WIP. Ping me when it is upstream and it doesn't work/crash all the time.

8-) Also why you still insist on your already debunked (Gen7 and newer) bullshit lmao

[oiaohm]

Ivy Bridge is older than Haswell and both of them doesn"t/cannot run with Iris.

Crocus aims to change that.

This is not as straight forwards as you will think Leopard. Early Iris driver use to work with 7Gen and newer as in Ivy Bridge and newer. Current one will work with some Intel boards with Ivybridge and haswell but this is due to firmware. Odds of you having one of those boards is slim. But since Iris will work with Gen 7 and newer hardware under very particular conditions exposing all hardware features this does mean the Crocus work should absolute be able to make it work without those exact conditions.

I cannot remember the exactly opengl feature that broken Iris from working on Gen 7 Ivy Bridge without a firmware workaround but it was also decided back then not to fix problem in general firmware or the Iris general driver because what is going classic driver now was supporting the hardware well enough back then. Hindsight from today says it was a bad choice. Back then it look like good optimisation of resources.

So the statement that doesn't/cannot run with Iris is wrong. Ivy Bridge and Haswell can but the odds of you having a right motherboard with the right firmware so it will work is insanely slim to the point that winning the loto may be more likely. We are talking the intel branded reference motherboards here for embedded hardware developers there are insanely rare motherboards because not a lot of them were made and then if you find one you need the right firmware version on it. At least in this rare case that it will work makes the Crocus work back to at gen 7 absolutely possible without question as it been possible to try out how that hardware would behave with a Iris driver for those with the rare hardware.

That is the UB I mention You don't necessarily need a safeguard to get some memory corruption and/or a crash from a buffer overflow. IOW a buffer overflow will likely reveal itself disregarding a compiler version. Usually building with optimizations increases the chance of stumbling upon it, and distros do build drivers with optimizations.

There is a difference between users random-ally stumbling on buffer overflow caused crashes and compiler saying no I am not building this or when I crash I will now state exactly what this problem is. Lot faults new versions of compilers find in drivers have been driving users nuts for years and developers having non reproducible bug reports so unable to fix the problem. So its more a question of how the fault is going to reveal itself. There are two major options for a fault to reveal itself.
1) as a simple to find diagnose and fix problem
2) as a complex pain in the ass hard to locate jackass of a problem.

Lot of the new features in compilers to detect code defects are to turn problems of type 2 into type 1. Unless something is coded perfect you are going to have type 2 stuff that will need to be removed for a long time to come.

[oiaohm]

5-) Medieval 2 Total War is a DX9 game

I did not say it was not a DX9 game. The issue here is DX9 does in fact have integer textures. Integer textures appear as usable in Opengl at 3.0 and that has requirements. So 2.1 opengl with that game with wined3d is going to equal screwed. Gen 5.5 intel hardware really going to be uphill battle to enable Opengl 3.0.

Would pay for you to go back and read more carefully.

Gallium Nine is also not setup for the case of Gen 5.5 hardware where you have the case of Integer textures and that needs a shader. There is a fun little color correction thing. Fun of Gen 5.5 was people running Windows XP on it and have color problems with dx 9 games/programs using integer textures yet fine on Windows Vista and 7.... What going on here the DX 10 shader the windows compositor was using made everything work right.

Generation 5.5 and 6 Intel is a ass in so many ways it not funny. Particular with the fun issue that come form using particular features without a shader and shader engine in those don't align to opengl that well.

Yes Medieval 2 Total War is a DX9 is right on horrible generations of hardware you will be needing DX10 features so it renders right because the operating system would have been using DX10 features as in a particular shader. Yes Gen 5.5 was also the machines where you would disable windows vista/7 compositor and your screen colours could go stupid.

This is why galluim Nine is not magical fix all. Some of the horrible hardware Intel does require DX10 features to render DX9 applications correctly. So there is in fact need for DX 10 support or at least enough understanding to create a DX10 equal shader for the GPU to make it render right this is not going to be a fun or easy process.

The idea that getting Crocus on 5.5 and 6 will fix them for games is wrong. The games that are having really bad time with Wined3d on 5.5 gen Intel hardware majority have 1 thing in common the darn usage of integer textures. Integer textures on gen 6 intel hardware is also has some fun defects if you don't load a shader this is level stupid stupid shader require a no operation shader that just refererence the integer texture now magically the colours come out right but if you don't the colours come out wrong. Gen7 is when intel hardware starts behaving as it should at least from Vulkan where you can use integer textures without a shader and nothing bad happens.

The reality is all Intel generations GPU of hardware are quirky to different levels of horrible. The reality is the quirky ness of 5.5 and 6 gen with Windows does not go just because we are on Linux because the reality is those generations of hardware are going to be trouble.