63 Mesa Patches For Wiring Up One OpenGL 4.3 Extension

[phoronix]

Phoronix: 63 Mesa Patches For Wiring Up One OpenGL 4.3 Extension

Sixty-three patches were published on the Mesa mailing list this morning for wiring up the ARB_internalformat_query2 extension as needed by OpenGL 4.3...

http://www.phoronix.com/scan.php?pag...-Format-Query2

[Adriannho]

Why just intel? If it's not done by intel why wouldn't they also be targeting the gallium drivers?

[Michael]

Why just intel? If it's not done by intel why wouldn't they also be targeting the gallium drivers?

Intel likely contracted Igalia to work on it, similar to Intel contracting Collabora for different work too.

[zanny]

Intel likely contracted Igalia to work on it, similar to Intel contracting Collabora for different work too.

Gotta love two independent driver stacks in Mesa... Intel, and everyone else.

[microcode]

Making things extra stupid, TransGaming is now known as GameTree, and transgaming.com puts you in a redirect loop.

[tarceri]

Gotta love two independent driver stacks in Mesa... Intel, and everyone else.

Your joking right? Intel pays to add this support, 59/63 patches to core Mesa and your complaining?

[zanny]

Your joking right? Intel pays to add this support, 59/63 patches to core Mesa and your complaining?

Contracted to do work that does not well benefit the Gallium drivers because Intel insists on having their own entirely separate driver stack independent of what everyone else is using. You can simultaneously thank Intel for releasing free software patches for Mesa and simultaneously criticize them for continuing to keep their driver independent of the established ecosystem in Gallium that every other driver is using, thus creating more work for developers to port their work to its architecture.

Its their choice not to invest the time and money necessary to make the i915g as capable as i915. But I can still be critical of that choice for the long term consequences that decision has on development of free graphics implementations.

[bakgwailo]

Contracted to do work that does not well benefit the Gallium drivers because Intel insists on having their own entirely separate driver stack independent of what everyone else is using. You can simultaneously thank Intel for releasing free software patches for Mesa and simultaneously criticize them for continuing to keep their driver independent of the established ecosystem in Gallium that every other driver is using, thus creating more work for developers to port their work to its architecture.

Its their choice not to invest the time and money necessary to make the i915g as capable as i915. But I can still be critical of that choice for the long term consequences that decision has on development of free graphics implementations.

Just as an FYI, Intel had developed and tuned their driver well before Gallium was even thought of. Why would you expect them to throw away years of their money and hard work to jump on the new bandwagon? If it ain't broke, don't fix it.

[GreatEmerald]

Your joking right? Intel pays to add this support, 59/63 patches to core Mesa and your complaining?

Haah, I just read this sentence as-is, and it's hilarious. Joking rights, and Intel paying to add zanny's complaining to core Mesa!

We appreciate your work on Mesa, but do try to work on proper grammar too

[zanny]

Just as an FYI, Intel had developed and tuned their driver well before Gallium was even thought of. Why would you expect them to throw away years of their money and hard work to jump on the new bandwagon? If it ain't broke, don't fix it.

You would not. But you must also recognize that all the work they do now is throwing away the money and time of developers in this ecosystem because all the work they do, trailblazing as it is, is often not drop-in functional in the gallium stack.

If AMD implements Clover compute shaders, those will be available to Nouveau, Freedreno, Lima, VideoCore, etc with barely any code changes as long as the winsys layer supports it. Intel implemented compute shaders, and now Gallium developers must also implement them independently of Intel's work. Every time that happens cost the community effort for the same reasons libva and ffmpeg are expensive, or gcc and clang are expensive, or vaapi and vdpau (and openmax) are expensive - having multiple implementations of the same thing for different vendors or just general forks cost developer hours maintaining. They are a necessary part of free software development but it is also the job of the community to criticize these forks when they exist for no other reason than NIH syndrome or a lack of cooperation. i915g existed, and was actually fairly mature back in 2012, but has atrophied due to the lack of interest by Intel and now we just continue to accrue technical debt of Intel keeping their own driver and CL stack independent of Gallium going forward, and it just sucks to witness, because it means the advancement of free graphics is slowed as a result.