R600 Gallium3D Driver Lands Tesselation Support In Time For Mesa 20.1

[phoronix]

Phoronix: R600 Gallium3D Driver Lands Tesselation Support In Time For Mesa 20.1

One of the many new features coming in Mesa 20.1 is experimental NIR support for the vintage Radeon "R600g" driver. That NIR back-end isn't yet to feature parity but is now one step closer with tesselation support now being available along this code path...

http://www.phoronix.com/scan.php?page=news_item&px=Mesa-20.1-R600g-Tesselation

[RussianNeuroMancer]

Software fp64 implementation when? These GPUs is still stuck on 3.3 core profile by default.

[M@GOid]

While a useful resource, the tessellation performance on these older AMD cards is poor, compared to the Nvidia ones of the same period. But if this feature makes the difference between running a game or not, is better have it.

[You-]

While a useful resource, the tessellation performance on these older AMD cards is poor, compared to the Nvidia ones of the same period. But if this feature makes the difference between running a game or not, is better have it.

Has anyone tested this recently?

With many features it seems that nVidia initially takes a shortcut that gives them a massive lead but over time that is canceled out on the same hardware (maybe software utilising the feature more fully so that the shortcuts no longer apply?)

[StandaSK]

What actually works on the R600 NIR backend?

[ms178]

I still use my laptop with a 6770M from time to time but I haven't tested his branch yet. Any performance improvements are welcome though.

[tildearrow]

Isn't it "tessellation"?

[gerddie]

What actually works on the R600 NIR backend?

Most things OpenGL 3.3 should work by now, but things are not optimized for performance on the driver level and there may be rendering bugs. NIR gives a nice speed-up for tesselation shaders compared to TGSI, because the TGSI bitcode was not optimzed at all, but in general there is a lot room for improvement in the generated shaders. My roadmap is now first get feature parity with TGSI (the biggest thing missing is full compute shader support), then I'll take a look at softfp64, and then I'll look into adding some optimization in the backend. Currently I only have an Evergreen card (5450), so namely the Cayman based 6950 Michael put as a picture in the article is not supported.

[nuetzel]

Most things OpenGL 3.3 should work by now, but things are not optimized for performance on the driver level and there may be rendering bugs. NIR gives a nice speed-up for tesselation shaders compared to TGSI, because the TGSI bitcode was not optimzed at all, but in general there is a lot room for improvement in the generated shaders. My roadmap is now first get feature parity with TGSI (the biggest thing missing is full compute shader support), then I'll take a look at softfp64, and then I'll look into adding some optimization in the backend. Currently I only have an Evergreen card (5450), so namely the Cayman based 6950 Michael put as a picture in the article is not supported.

GREAT work Gert!
Greetings to Itally.

I'll dig for my 6670 (TURKS) if I find some spare time during this times...

[nanonyme]

Most things OpenGL 3.3 should work by now, but things are not optimized for performance on the driver level and there may be rendering bugs. NIR gives a nice speed-up for tesselation shaders compared to TGSI, because the TGSI bitcode was not optimzed at all, but in general there is a lot room for improvement in the generated shaders. My roadmap is now first get feature parity with TGSI (the biggest thing missing is full compute shader support), then I'll take a look at softfp64, and then I'll look into adding some optimization in the backend. Currently I only have an Evergreen card (5450), so namely the Cayman based 6950 Michael put as a picture in the article is not supported.

I'm curious, are you getting paid to do this stuff? Awesome work either way. Thank you a lot. (as someone with a still working desktop with one of these chips)