AMD Planning To Enable GLAMOR By Default For R600 & Newer GPUs

[bridgman]

R600 being touched? Impossible. What's next? Fedora 26 not being delayed at all?

The r600 driver actually gets touched quite a bit:

https://cgit.freedesktop.org/mesa/me...m/drivers/r600

[droste]

Every time GLAMOR is discussed, I wonder if there is anything (any 2D operation, etc.) that simply can't be implemented efficiently with OpenGL. Also I wonder if it would be useful to have Gallium3D state tracker that would do 2D, so it could do a little more than the OpenGL state tracker can when it's needed (well it probably would not need to do everything that OpenGL can). Then again, Mesa could always expose a new OpenGL extension to use with GLAMOR to speed it up, so maybe these are not issues at all. I know fairly little about 3D or OpenGL programming. I don't know if either of these were addressed in XDC2016, so I may be asking something that has already been answered...

There was an OpenVG (accelerated 2D) state tracker, but nobody used it or was interested in it so it got removed. It's still in git if you care

[agd5f]

Every time GLAMOR is discussed, I wonder if there is anything (any 2D operation, etc.) that simply can't be implemented efficiently with OpenGL. Also I wonder if it would be useful to have Gallium3D state tracker that would do 2D, so it could do a little more than the OpenGL state tracker can when it's needed (well it probably would not need to do everything that OpenGL can). Then again, Mesa could always expose a new OpenGL extension to use with GLAMOR to speed it up, so maybe these are not issues at all. I know fairly little about 3D or OpenGL programming. I don't know if either of these were addressed in XDC2016, so I may be asking something that has already been answered...

Glamor actually accelerates more X operations than EXA ever did. There's nothing that old 2D hw engines did that can't easily accelerated on on 3D engines. The main problem is that core X graphics operations and the X render extension were designed prior to wide GPU availability so a lot of operations do not translate well to GPU hardware in general. Fortunately, not many of those old X operations were ever used and relatively few of them are now. You can reduce the overhead slightly by natively translating between the X API and the hw rather than going through an intermediate interface (OpenGL in this case), but it's not really worth the effort in the vast majority of cases used by modern applications.

[Tomin]

Glamor actually accelerates more X operations than EXA ever did. There's nothing that old 2D hw engines did that can't easily accelerated on on 3D engines. The main problem is that core X graphics operations and the X render extension were designed prior to wide GPU availability so a lot of operations do not translate well to GPU hardware in general. Fortunately, not many of those old X operations were ever used and relatively few of them are now. You can reduce the overhead slightly by natively translating between the X API and the hw rather than going through an intermediate interface (OpenGL in this case), but it's not really worth the effort in the vast majority of cases used by modern applications.

Alright, thank you!

There was an OpenVG (accelerated 2D) state tracker, but nobody used it or was interested in it so it got removed. It's still in git if you care

Totally forgot that. I won't be resurrecting it though.

[slacka]

GPUs before Southern Islands had dedicated 2D hardware, which is used by the EXA backend. It's faster than using GLAMOR, and the only option on very old cards.

Performance isn't the only issue with GLAMOR. In my testing with Sandy Bridge, GLAMOR also uses more power than the dedicated 2D hardware.

[timofonic]

Performance isn't the only issue with GLAMOR. In my testing with Sandy Bridge, GLAMOR also uses more power than the dedicated 2D hardware.

That's interesting. Could you make some benchmark and provide results?

I wonder if GLAMOR can be optimized to be more efficient and performant. Would it work at +120fps a very complex 2D 4K game engine using tons of tiles, sprites and whatever?

[darkbasic]

Every time GLAMOR is discussed, I wonder if there is anything (any 2D operation, etc.) that simply can't be implemented efficiently with OpenGL. Also I wonder if it would be useful to have Gallium3D state tracker that would do 2D, so it could do a little more than the OpenGL state tracker can when it's needed

It probably would be wiser to start VLAMOR (Vulkan-GLAMOR) instead...

[Mystro256]

It probably would be wiser to start VulkAMOR instead...

Honestly, XOrg looks like it's on its way out, so I think this may be a wasted effort.

[pal666]

Performance isn't the only issue with GLAMOR. In my testing with Sandy Bridge, GLAMOR also uses more power than the dedicated 2D hardware.

how is it relevant considering that amd has no dedicated 2d hardware ?

[blackiwid]

Honestly, XOrg looks like it's on its way out, so I think this may be a wasted effort.

Yes only this way will take forever, when will there be a Wayland emacs version 2020 with emacs version 27?

To the topic how is kodi affected from that or is it at all?