Mesa 12.1-dev Is Off To The Races

[bridgman]

I'm sort of the opposite of an expert on this, but my first thought is that it would be safe to set them system-wide.

[smitty3268]

It's needed for >3.3, but only if you have religious objections to using Mesa's existing over-ride mechanism to force the extension on. To the best of our knowledge no games actually *use* the fp64 extension, it's just a checkbox requirement for GL 4.0.

I'm not sure if a similar over-ride is required for GL_ARB_vertex_attrib_64bit - if it is then it might be easier to force the GL level rather than forcing both extensions.

It would be to provide 4.2 support, but you most likely don't want that because r600g is also missing several other 4.2 extensions, such as image support and atomics. Until that gets committed, adding GL_ARB_gpu_shader_fp64 is enough to reach OpenGL 4.1 and that's all the driver is ready to support.

[dragon321]

Hmm, I wonder when my HD7670M(Turks) get OpenGL4.x.

Now i have OGL 3.3.

[bridgman]

It would be to provide 4.2 support, but you most likely don't want that because r600g is also missing several other 4.2 extensions, such as image support and atomics. Until that gets committed, adding GL_ARB_gpu_shader_fp64 is enough to reach OpenGL 4.1 and that's all the driver is ready to support.

I thought GL_ARB_vertex_attrib_64bit was a requirement for 4.1, not for 4.2... can you check ? I looked in the GL spec as well as mesamatrix.

Hmm, I wonder when my HD7670M(Turks) get OpenGL4.x.Now i have OGL 3.3.

Same answer as everyone else, I think -- for now, when you use the over-ride mechanism as described above, since all the functionality that games actually *use* is already implemented AFAIK. You should be able to go as far as GL 4.1 today

In the longer term when someone has time to implement emulation support for 64-bit operations in the shader compiler you won't need the over-ride.

[dragon321]

Same answer as everyone else, I think -- for now, when you use the over-ride mechanism as described above, since all the functionality that games actually *use* is already implemented AFAIK. You should be able to go as far as GL 4.1 today

In the longer term when someone has time to implement emulation support for 64-bit operations in the shader compiler you won't need the over-ride.

Well, I'm only interested in this. I don't care about OGL4.x support, because my card is pretty old and weak, so I can't run recent games with good framerate. All other games, that I have and I can run with this card doesn't need OGL4.x, 3.3 is enough.

I would very happy if they improve PRIME switching, because tearing(when i use dedicated card) is annoying.

[smitty3268]

I thought GL_ARB_vertex_attrib_64bit was a requirement for 4.1, not for 4.2... can you check ? I looked in the GL spec as well as mesamatrix.

Whoops, you are correct. And 4.1 is actually nice to have over 4.0 as there are some games that require it.

[Azpegath]

Plus there's still the r600g driver (and its radeon kernel part, assuming in the above amdgpu replaces it for cards using radeonsi).

You're right, I confused them. I meant that the old kernel driver matching those cards using RadeonSI would be fully replaced by a more performance AMDGPU driver. I actually did mean the FOSS-drivers and not the proprietary ones, since I know the latter would never be done at this day and age.

The reason mainly being that I have an r290 and would like it to be maintained for a couple of years longer. Plus, it would get the big performance boost it needs.

[geearf]

You're right, I confused them. I meant that the old kernel driver matching those cards using RadeonSI would be fully replaced by a more performance AMDGPU driver. I actually did mean the FOSS-drivers and not the proprietary ones, since I know the latter would never be done at this day and age.

The reason mainly being that I have an r290 and would like it to be maintained for a couple of years longer. Plus, it would get the big performance boost it needs.

I don't think AMDGPU.ko is supposed to be faster than radeon.ko.

[bridgman]

I don't think AMDGPU.ko is supposed to be faster than radeon.ko.

Right... in general performance enhancements come from userspace drivers (radeonsi in your case), although there may be kernel driver changes required to let the new userspace drivers do <whatever new thing they are doing>.

There is one known exception -- the amdgpu driver's GPU scheduler seemed to be providing a performance improvement in some cases where I don't think we were necessarily expecting it -- but normally enhancements are being made in both kernel drivers if they apply to the supported hardware generations.

[geearf]

Right... in general performance enhancements come from userspace drivers (radeonsi in your case), although there may be kernel driver changes required to let the new userspace drivers do <whatever new thing they are doing>.

There is one known exception -- the amdgpu driver's GPU scheduler seemed to be providing a performance improvement in some cases where I don't think we were necessarily expecting it -- but normally enhancements are being made in both kernel drivers if they apply to the supported hardware generations.

Good for the scheduler!

I do hope it'll fix my system from freezing when playing one game, but that may be more in user code than kernel... Oh well hoping is good