Early Radeon DRM-Next Tests Ahead Of Linux 4.7, Mesa 11.3: Many Improvements, One Card Falls

[bridgman]

a simple questione: I own an hd3850 glxinfo shows I've opengl core as 3.3 level why the same information list issue that opengl versionis 3.0? thanks.

In the early days of OpenGL features were added but never removed, so the spec became what most people felt to be overly complex compared with "clean slate every time" APIs like DirectX. Starting with 3.1 (IIRC) the API started to be cleaned up, with old functionality being removed as new functionality was added. A "core profile" gives you "follow the spec" behaviour, and you are getting v3.3 support with a core profile.

One group of developers, however, (mostly workstation ISVs AFAIK) wanted to keep their existing application code but take advantage of a few new features. For those developers a "compatibility profile" was also introduced, where new features are added but all the old features are retained as well, with old and new features interacting in vendor-specific ways.

Mesa does not implement compatibility profiles so the highest non-core profile you see is 3.0, before any old features were deprecated.

Compatibility profiles were a decent idea at the time, but probably should have been killed off by now. The problem with them is that if a HW vendor convinces app developers to use compatibility profiles AND develop on their hardware they basically get vendor lock-in for free even though the developers believe they are following an open standard.

[bridgman]

This kinda confirms whats been happening with 290/390 hardware, AMD is just not paying attention to the regression so I doubt they will have it performing on par with NVIDIA any time soon (could take them years).

For clarity, the dpm issue on newer Hawaii parts is not an example of this.

[theriddick]

Citation. Phoronix.com, there you go! look at Micheal's benchmarks over the past 4months on AMD drivers and 290 hardware he has, users have been commenting on regression of performance, it has been up and down also.

I suggest AMD(you) to go buy a 290x and 390x and add it into their testing loop before pushing updates out that do this sort of performance regression!

[Azpegath]

My suspicion with the r9 290 being low would be DPM not working as intended.

Yeah, I was immediately thinking the same. Perhaps things would look different if he would have forced it to maximum performance. But AMD will probably notice the cause of the regression pretty quickly now that it has been unveiled.
Wow on the improvements on the 7950 and the 6950 card! I really hope the 290 has also gained some improvements...

[Azpegath]

Compatibility profiles were a decent idea at the time, but probably should have been killed off by now. The problem with them is that if a HW vendor convinces app developers to use compatibility profiles AND develop on their hardware they basically get vendor lock-in for free even though the developers believe they are following an open standard.

I've never heard anybody make that claim before, and the first thing I thought of is the fact that the OpenGL wiki recommends everyone to run "#version 3x0/4x0 compatibility" in their shaders (except perhaps during development), and that "#version ****** core" is only for pure development. Do you agree?

ps: I had to search for the source of my statement, but now I can't find it on the wiki. Either someone has changed it, or I'm just confused. But I'm SURE I've read it. :ds

pps: This might be what I was thinking of: https://www.opengl.org/wiki/Core_And...ty_in_Contexts. So perhaps it wasn't the shader's #version string but the context flags I was thinking of: dds

[bridgman]

I've never heard anybody make that claim before, and the first thing I thought of is the fact that the OpenGL wiki recommends everyone to run "#version 3x0/4x0 compatibility" in their shaders (except perhaps during development), and that "#version ****** core" is only for pure development. Do you agree?

Nope. If you do your development using core profiles then there's no reason not to request a core profile at runtime as well.

Compatibility profiles were simple and harmless back in the early 3.x days, but with every subsequent advance in the OpenGL API (and more opportunities for vendor-specific interactions between current and legacy functions) those compatibility profiles became a bigger and smellier problem. If you poke around the net a bit you'll find a number of QA exchanges along the following lines:

Q: Why should I ever use a core profile ?

A: So IHVs can get rid of compatibility profiles and start giving us drivers that behave consistently across different hardware

I expect historians will conclude that compatibility profiles were what killed OpenGL.

ps: I had to search for the source of my statement, but now I can't find it on the wiki. Either someone has changed it, or I'm just confused. But I'm SURE I've read it. :ds

pps: This might be what I was thinking of: https://www.opengl.org/wiki/Core_And...ty_in_Contexts. So perhaps it wasn't the shader's #version string but the context flags I was thinking of: dds

The only recommendation I see there is to not use the "forward compatibility" option. It seems to have been written at a time when most implementations supported compatibility profiles, ie when there wasn't much difference between the two -- and so nobody realized what a mess the compatibility profiles would become over time.

I don't remember where I read it, but someone described compatibility profiles as a feature which lets you combine features that only made sense in the 1990s with features that only make sense in the 2010s, and which is best avoided

[Azpegath]

If you do your development using core profiles then there's no reason not to request a core profile at runtime as well. If you poke around the net a bit you'll find a number of QA exchanges along the following lines:

Q: Why should I ever use a core profile ?

A: So IHVs can get rid of compatibility profiles and start giving us drivers that behave consistently across different hardware

The only recommendation I see there is to not use the "forward compatibility" option. It seems to have been written at a time when most implementations supported compatibility profiles, ie when there wasn't much difference between the two -- and so nobody realized what a mess the compatibility profiles would become over time.

I don't remember where I read it, but someone described compatibility profiles as a feature which lets you combine features that only made sense in the 1990s with features that only make sense in the 2010s, and which is best avoided

We're actually using compatibility profile at the company I'm at, mainly because two things:

1) Our first lines of code are from 2004, and fixed pipeline stuff is sadly still a part of it. Some people at the company still thinks there's nothing wrong with using it, and that there is no "value in itself to replace it with pure OpenGL 3.x".
2) We're every-now-and-then a slave to our customer's hardware demands, and that might mean we have to support older hardware or virtualized environments with thin clients on servers.

But I'm working on porting it, piece by piece, every day...

[bridgman]

*bridgman bumps fists with Azpegath

Compatibility profiles are OK if you use them as they were originally intended -- 95% legacy OpenGL code with a couple of new features (eg the DX compatibility ones). The problem is that as you say business realities make it very hard to quit the compatibility profile habit once you start even though you know it's doing you more damage every year.

[Azpegath]

*bridgman bumps fists with Azpegath

Compatibility profiles are OK if you use them as they were originally intended -- 95% legacy OpenGL code with a couple of new features (eg the DX compatibility ones). The problem is that as you say business realities make it very hard to quit the compatibility profile habit once you start even though you know it's doing you more damage every year.

Hahaha, *bump*

Yeah, at the time that really isn't what we're doing, we're currently probably at 50-60% OpenGL3.2-3 and 50% at OpenGL2.1. Fixed-function combined with 2.1-shaders. We were using the matrix stack up until our last release, where I implemented keeping our own stack instead, which is then applied _IF_ rendering with the fixed-function pipeline, and sent to shaders if rendered using the "modern" shaders. We are still using lots of pushAttributes. We even have a couple of glBegin/glEnd left for things that render only a couple of vertices, but the mere fact pains me..

Porting the text rendering a couple of months ago (from oglft to my own shader implementation using FreeType) was a real nice bump in percentage of removing deprecated function calls. CodeXL is a nice tool to keep track of them.

[Azrael5]

In the early days of OpenGL features were added but never removed, so the spec became what most people felt to be overly complex compared with "clean slate every time" APIs like DirectX. Starting with 3.1 (IIRC) the API started to be cleaned up, with old functionality being removed as new functionality was added. A "core profile" gives you "follow the spec" behaviour, and you are getting v3.3 support with a core profile.

One group of developers, however, (mostly workstation ISVs AFAIK) wanted to keep their existing application code but take advantage of a few new features. For those developers a "compatibility profile" was also introduced, where new features are added but all the old features are retained as well, with old and new features interacting in vendor-specific ways.

Mesa does not implement compatibility profiles so the highest non-core profile you see is 3.0, before any old features were deprecated.

Compatibility profiles were a decent idea at the time, but probably should have been killed off by now. The problem with them is that if a HW vendor convinces app developers to use compatibility profiles AND develop on their hardware they basically get vendor lock-in for free even though the developers believe they are following an open standard.

Thank for reply very gentle. So assuming I can switch between 2.0 or 3.1 opengl standards on the kde environment, the system supports or not the 3.1 opengl standard? Question is the following: my system works on core 3.3 or on a general opengl 3.0 standard!?