AMD Open-Sources "Addrlib" From Catalyst

[agd5f]

Would this help with opengl 4? It does seem to have specific ways to account for the GPU and memory size and bus width.

Not directly. As I said before, it's just for buffer alignment which is board dependent (e.g. based on the memory config for example).

[toyotabedzrock]

It means not having to write and maintain code to deal with all of the alignment requirements directly. As an added bonus, the code is validated on other platforms as well so there is less chance for errors in alignment that can lead to GPU segfaults or hangs.

They actually left MacOSX and Windows compiler instructions in the code, looks like minimal cleanup was done.

Would this help with opengl 4? It does seem to have specific ways to account for the GPU and memory size and bus width.

[xeekei]

It's rare, but sometimes really good threads can happen in these forums. This was one of them.

[Ericg]

addrlib does not have anything to do with memory allocation or management or paging. It's purely for calculating the alignment requirements of buffers so the drivers can request that alignment when they allocate memory. E.g., if you are requesting memory for a 2D tiled texture with mipmaps, the base address of the mip tree needs to be 256 byte aligned at a minimum, plus a multiple of the memory channel width, plus a multiple of the tile size, plus etc., etc.. Next you need to align the stride of the buffer, and make sure the various tiling parameters are set correctly based on the size of the texture and the selected tiling format. If you don't get the alignment correct, you can get visual corruption, or GPU segfaults which may result in GPU hangs, etc.

Gotcha, okay, that makes more sense. Thanks for correcting me

And as always: Thanks go out to you and the rest of the team for all the hard work you guys do.

[ermo]

@bridgman/agd5f:

Thanks for chipping in. Sounds like this being open sourced is pretty damn good news then.

Does the code drop also cover pre-GCN GPU archictectures? The mention of radeon/radeonsi not using it yet suggests this to be the case? Is there any potential value to be had by porting radeon/radeonsi to use it as well at some point in the not-to-distant future?

In one of my rigs I'm rocking an old HD4850 512MB with a custom cooler and a modified BIOS (wanted to downclock and downvolt it when in the 'low' power state) and I also have a couple of HD7970s which will likely be promoted from my Windows box to a Linux box later this year, so I'm assuming that I would benefit from it if it were to happen...

EDIT: Ooops, missed this post:

It's only applicable to CI and VI on amdgpu at the moment. It could be extended to older asics, but we didn't want to potentially destabilize radeon while working on amdgpu.

[agd5f]

Alex correct me if I'm wrong, if the situation has changed, or if this isn't what i think it is, but I thought one of the disadvantages that the OSS stack had vs Catalyst was that the memory allocater and the texture allocater were not as smart as Catalyst's and therefore would run into issues with games that filled the gpu memory with textures. Is this not the catalyst texture allocater? If I am wrong then -please- correct me as I don't want to have the wrong information.

PS: is it allocater or allocator? Firefox hates both.

addrlib does not have anything to do with memory allocation or management or paging. It's purely for calculating the alignment requirements of buffers so the drivers can request that alignment when they allocate memory. E.g., if you are requesting memory for a 2D tiled texture with mipmaps, the base address of the mip tree needs to be 256 byte aligned at a minimum, plus a multiple of the memory channel width, plus a multiple of the tile size, plus etc., etc.. Next you need to align the stride of the buffer, and make sure the various tiling parameters are set correctly based on the size of the texture and the selected tiling format. If you don't get the alignment correct, you can get visual corruption, or GPU segfaults which may result in GPU hangs, etc.

[bridgman]

Right. There are a few areas of the HW that are really complex & fiddly, and that eat a lot of developer time for each new HW generation. Sharing the addrlib code means one less thing we have to implement twice.

[gens]

Alex correct me if I'm wrong, if the situation has changed, or if this isn't what i think it is, but I thought one of the disadvantages that the OSS stack had vs Catalyst was that the memory allocater and the texture allocater were not as smart as Catalyst's and therefore would run into issues with games that filled the gpu memory with textures. Is this not the catalyst texture allocater? If I am wrong then -please- correct me as I don't want to have the wrong information.

PS: is it allocater or allocator? Firefox hates both.

from what i understand, this is a bunch of functions to figure out a properly aligned address
on most cpu's that's easy, but i guess not on gpus

it has nothing to do with the actual managing of texture/vertex/bla buffers
(except, well, to give aligned addresses)


it's allocator

[Ericg]

I don't think it will affect performance at all. It's all about correctness and stability.

Alex correct me if I'm wrong, if the situation has changed, or if this isn't what i think it is, but I thought one of the disadvantages that the OSS stack had vs Catalyst was that the memory allocater and the texture allocater were not as smart as Catalyst's and therefore would run into issues with games that filled the gpu memory with textures. Is this not the catalyst texture allocater? If I am wrong then -please- correct me as I don't want to have the wrong information.

PS: is it allocater or allocator? Firefox hates both.

[agd5f]

As always first a big thank you for your awesome hard work, second will this library apply to radeonsi?, i suppose since this was in catalyst and it support at least GCN 1.0(current catalyst hardware support) so it should be able to handle radeonsi but as always i suspect it will need to be hooked into it. I ask since just last week i buyed an r9-280 OC card since offered better performance and was cheaper than the r9-285(maybe wasn't very smart of me tho)

It's only applicable to CI and VI on amdgpu at the moment. It could be extended to older asics, but we didn't want to potentially destabilize radeon while working on amdgpu.