AMD Open-Sources "Addrlib" From Catalyst

[carewolf]

Forgive my naive and uneducated question, as mesa and 3d graphics driver development is a completely untouched territory for me. I am a developer though, and I was wondering what in a "texture addressing and alignment calculator" needs 22k+ codelines?

It is ugly C code with tons of boilerplate and inane comments. It uses a 100 lines of code for every accessor of a property of their structs.

Fuck C code.

[agd5f]

It's a centralized place to deal with alignment requirements for various buffers on the GPU (textures, render buffers, depth buffers, metadata buffers, etc.). These requirements can get really complex and have a number of corner cases that are hard to handle properly.

[ermo]

It's a centralized place to deal with alignment requirements for various buffers on the GPU (textures, render buffers, depth buffers, metadata buffers, etc.). These requirements can get really complex and have a number of corner cases that are hard to handle properly.

Honest question: Is this you suggesting that AMD releasing this particular piece of code under a FLOSS license is definitely a Good Thing™ which will benefit you and your fellow radeon FLOSS developers now and especially in the future?

Do you already have a good idea of a few specific cases where this might help you guys in particular?

[agd5f]

Honest question: Is this you suggesting that AMD releasing this particular piece of code under a FLOSS license is definitely a Good Thing? which will benefit you and your fellow radeon FLOSS developers now and especially in the future?

Do you already have a good idea of a few specific cases where this might help you guys in particular?

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.

[jrch2k8]

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.

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)

[Ericg]

Honest question: Is this you suggesting that AMD releasing this particular piece of code under a FLOSS license is definitely a Good Thing? which will benefit you and your fellow radeon FLOSS developers now and especially in the future?

Do you already have a good idea of a few specific cases where this might help you guys in particular?

In an ideal world it'll make the lives for the developers easier since there's a little abstraction (deal with addrlib, not with the alignments directly, as Alex said), since its probably been 'battle-tested' out the ass the code is -probably- pretty bug free.

As far as whether or not its worth it... Merge it to a branch, hook up radeonsi & r600g to use it, compile, benchmark vs non-merged master, and see if it boosts performance at all by being smarter about the allocations. You could alternatively just benchmark the 285 vs whatever-the-highest-card-that-radeonsi-supports but there the hardware differences might hide any gain or loss relative to eachother.

[agd5f]

In an ideal world it'll make the lives for the developers easier since there's a little abstraction (deal with addrlib, not with the alignments directly, as Alex said), since its probably been 'battle-tested' out the ass the code is -probably- pretty bug free.

As far as whether or not its worth it... Merge it to a branch, hook up radeonsi & r600g to use it, compile, benchmark vs non-merged master, and see if it boosts performance at all by being smarter about the allocations. You could alternatively just benchmark the 285 vs whatever-the-highest-card-that-radeonsi-supports but there the hardware differences might hide any gain or loss relative to eachother.

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

[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.

[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.

[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