AMD R600g Tessellation Support Lands In Mesa Git

[Tomin]

So fp64 is necessary for OpenGL 4? Does that mean, the Windows driver also emulates in fp32?

Yes, it is required and yes it is emulated some way in Catalyst (or Radeon Software). I don't know how much of fp64 is implemented on those GPUs so I can't know how it could be done best but I think OpenGL spec allows to use 32 bits of precision for 64 bit floats (I could be wrong here).

[akincer]

And you have an AMD laptop from the same era that works flawlessly.
Jeez people, do you really buy hardware because of how it will be supported in 10 years? Support today means nothing to you?

Actually support down the road DOES mean something. I bought an AMD card about 6 or 7 years ago explicitly BECAUSE I knew it would continue to work just fine for many years to come for the gaming I (used to) do. It still works well for what I do. It can't possibly hope to keep up with the latest games, but that was mostly true of the latest games only a year or two after I bought it.

I suppose if you're constantly chasing the latest and greatest, this isn't something that matters to you. If you have a few oldie but goldie games you play and that's all you need, then support in 7 to 10 years is something that matters. This is especially true if Linux is your OS. With the open driver, you just install the latest distro and don't worry whether your graphics card will work because you KNOW it will.

[Ansla]

Catalyst driver -- which most posters want us to kill off in favour of the open stack anyways.

The old Catalyst, with proprietary kernel module and Xorg DDX, sure, kill it asap. I doubt many would mind. But the new Catalyst using the amdgpu kernel driver and DDX I'm pretty sure will gain popularity around here.
I haven't used Catalyst for the past 8 years, for a brief time I even experimented with llvmpipe because Kaveri 3D acceleration was not ready yet. But as soon as I get a card that will work with the new Catalyst (most likely one of the RX 400 Series when they will be released) I can see myself giving it another try.

[Nille_kungen]

I have the same issue with my 5850/Evergreen card. Something is definitely broken with the latest git code

So at least i'm not the only one.
It might be time for an bugreport.

[chithanh]

And you have an AMD laptop from the same era that works flawlessly.

I have another PC with a Radeon X1600 card and it works fine both in Linux (r300g) and Windows 7. I previously had a Radeon 9600 Pro in that PC but due to hardware failure I had to replace it. If it hadn't failed it would have been supported the same way as the X1600.

Jeez people, do you really buy hardware because of how it will be supported in 10 years? Support today means nothing to you?

Same as akincer, if it works with open source drivers then you can expect it to still work in 10 years.

NVidia FX5000 series however never worked properly with Linux open source drivers, giving very poor performance and graphical glitches. And the proprietary driver is EOL now. On Windows they don't support anything newer than Vista.

Intel Gen5 graphics run decently on Windows. But on Linux the same games that run fine on Windows are often a slideshow or don't run at all (there were some improvements recently though).

[fuzz]

Hmm, you're running out of arguments fast. What does some optional graphics feature got to do with drivers?
There are many graphics options that will kill performance on any card: hi-resolution soft shadows, huge viewing distances, grass/vegetation density, God's rays or tesselation. Hairworks is nothing but over the top (for the current hardware) tesselation, but then again so is TressFX.
I can enable hairworks for Geralt and with some trial and error get steady 30fps on my 660Ti (1920x1200), so I'm not even sure what you're trying to say here.

The older card is fully capable of good performance. It is proven that newer drivers cripple the card.

Open source is the only way to go.

I'd be hurt if the company I supported ignored open source, too.

[V10lator]

So at least i'm not the only one.

I might have the same issue with a HD 6950. Do you see
OpenGL error: invalid operation
spammed to the console of the benchmark?

//EDIT: Also I see a lot of
0:220(8): error: #version 150 layout qualifier `triangles' used
GLShader::compile(): can't link program
error: Tessellation control shader must be linked with tessellation evaluation shader

[Nille_kungen]

I might have the same issue with a HD 6950. Do you see
OpenGL error: invalid operation
spammed to the console of the benchmark?

//EDIT: Also I see a lot of
0:220(8): error: #version 150 layout qualifier `triangles' used
GLShader::compile(): can't link program
error: Tessellation control shader must be linked with tessellation evaluation shader

Yes i get the same.

http://pastebin.com/vNj3L7DS

http://pastebin.com/piGEUCuL

So we are 3 that can reproduce the same error so it's definitely an bug.
Are we all using DRI3? i will try dri2 just to be sure.

EDIT: Tried dri2 and it's the same.
The only thing that changed is that my radeonsi card is more fluent with dri2 then dri3, for some reason my radeonsi is real slow with dri3 my r600 is fluent i both dri2 and 3.
Dri3 gives really high fps with radeonsi but with dri2 when it's running more fluent the fps is much lower.
Looked at the logs and there's an core profile difference.

http://pastebin.com/c18AnsY9

[airlied]

Yes i get the same.

http://pastebin.com/vNj3L7DS

http://pastebin.com/piGEUCuL

So we are 3 that can reproduce the same error so it's definitely an bug.
Are we all using DRI3? i will try dri2 just to be sure.

EDIT: Tried dri2 and it's the same.
The only thing that changed is that my radeonsi card is more fluent with dri2 then dri3, for some reason my radeonsi is real slow with dri3 my r600 is fluent i both dri2 and 3.
Dri3 gives really high fps with radeonsi but with dri2 when it's running more fluent the fps is much lower.
Looked at the logs and there's an core profile difference.
http://pastebin.com/c18AnsY9

make sure drirc from mesa is where the driver is looking for it, sometimes /usr/local/etc/drirc, depending on how you configured mesa and run things.

Dave.

[V10lator]

make sure drirc from mesa is where the driver is looking for it, sometimes /usr/local/etc/drirc, depending on how you configured mesa and run things.

Dave.

That wasn't my problem but
rm ~/.drirc
fixed it for me.