Feature: Mark some unsupported features as unsupported by hardware

[RobinMcCorkell]

As posted by schmidtbag on the Phoronix forums, the colour used for unsupported features should be different depending on hardware support. What about a clear/near-transparent colour for such non-features?

[MightyCreak]

That's an idea, but how can I know which feature is compatible with which hardware?

[RobinMcCorkell]

@MightyCreak Yeah, that's the problem. Perhaps have a max supported GL version for each driver?

[MightyCreak]

Apparently the problem is that even if some feature aren't compatible with previous version of OpenGL, others can still be in later versions (I asked in the dev mailing list: http://lists.freedesktop.org/archives/mesa-dev/2014-September/067312.html).

It seems like I should get or write a driver matrix that would allow to know which GL feature is compatible with which driver. But I'm not sure of where to begin with ;)

[RobinMcCorkell]

That might be a bit overkill :laughing:

Is it really necessary to know exactly which features are supported by which hardware? Hardware is marketed as 'OpenGL vX.X compatible', and I think the matrix should represent that. Features in later GL versions implemented in such drivers will still be marked as green, but before they are implemented they will show as 'unsupported' (transparent?) rather than 'not implemented' (red).

[dro123]

This is a little bit more difficult than it seems to be. Just because it's supported by a driver, doesn't guarantee that it is working with all hardware the driver supports (just look at the "only gen8+" comments from intel).

So right now it's just saying what is implemented in the driver, not what is doable with every hardware out there that is supported by the driver. I think this is good enough even though some of the red bars never turn to green.

[MightyCreak]

Seems like the most doable solution would be to create a hardcoded list of the features that some drivers will never have. In the end, once this list is done, we won't have to modify it... just add lines if more drivers come or more GL versions comes in.

The hard part would be to know what will never work.

[MightyCreak]

For more information, see the email in the ML: http://lists.freedesktop.org/archives/mesa-dev/2015-July/090054.html

[MightyCreak]

Based on https://secure.freedesktop.org/~imirkin/glxinfo/glxinfo.js (see UNSUPPORTED object).

List of unsupported extensions (WIP):

• R600
  • GL_ARB_gpu_shader5
  • GL_ARB_tessellation_shader

[dro123]

This is the real hardware R600 not the driver r600!

The driver will support both gpu_shager5 and tessellation because there's hardware which are driven by this driver that support these. Just the oldest hardware supported by the driver (the hardware that gave the driver the name) can't support these.

[MightyCreak]

Yep... I've just had a talk with the devs and it seems more and more impossible to flag some mesamatrix drivers extensions as unsupported since 'r600' (for instance) is not one driver but a group of drivers supporting a group of different hardwares.

I'll try to find extensions that are unsupported for all the drivers in the same driver category. Might not be a lot of them....

[dro123]

Like I said before: "This is a little bit more difficult than it seems to be." ;-)

It's actually one driver not a group of drivers. But one driver can support more than one piece of hardware. And what makes it difficult is that depending on the hardware the driver is running on, it will report different capabilities.

The thing you see in GL3.txt just says that for this driver there exists at least one piece of hardware where this feature will be reported and is working.

[MightyCreak]

Thx, it's a bit clearer! ;)

But what is the difference between r600 and r600g then?

[dro123]

Nowadays? No difference :-)

You have to go back in time a little bit to understand this.

Traditionally in mesa there was no gallium middle layer. Gallium is a layer in the mesa driver that is doing a lot of work that was originally done inside every driver with a driver specific implementation.

When gallium was introduced there were two drivers for R600,R700, EG, ... hardware: 1) The classic r600 driver not using gallium and implementing a lot of stuff in the driver but was proven working and was tested more thoroughly 2) The r600 gallium driver (short r600g) that used the gallium infrastructure but was new, had more bugs and was more or less untested

You had to decide during build time which driver you wanted to use (either-or), because the libraries had the same name: dir/r600_dri.so. By default you would get the classic version.

At some point in time the gallium driver (r600g) became the default driver for R600,R700, EG, ... hardware and the classic driver not using gallium was removed.

So nowadays people just call the r600 gallium driver 'r600' because there's no other.

[MightyCreak]

Thanks a lot for all these explanations. It's quite crystal clear now :)