AMDGPU Increasing Fragment Size For Performance

[phoronix]

Phoronix: AMDGPU Increasing Fragment Size For Performance

Christian König of AMD yesterday sent out an AMDGPU kernel patch for boosting the default fragment size for GCN graphics cards pre-Vega...

http://www.phoronix.com/scan.php?pag...-GFX6-FS-Boost

[schmidtbag]

So the real question is: does this have any measurable performance loss, and if so, how often?

I wonder if perhaps this would have a greater impact on low-end hardware, where they have finite resources and [usually] lower clock speeds. I don't fully understand how it all works, but I wonder if perhaps 64KB inevitably uses up more clock cycles, since more chunks need to be sent. I imagine a whole clock cycle is used for each 64KB "packet", or if not that, another core. Either way, that could be a more noticeable loss on the cheap products.

[agd5f]

Nothing to do with clocks or transfers, it affects how the TLB entries are used in the page tables.

[Ziple]

Why is it called fragment size and not page size if it relates to TLB entries?

[CrystalGamma]

Why is it called fragment size and not page size if it relates to TLB entries?

Yeah I was wondering why this doesn't seem to have anything to do with fragment shaders …

[bridgman]

Definitely has nothing to do with fragment shaders... more like "fragments of the maximum range potentially covered by a TLB".

IIRC what happens is that a single TLB ends up covering multiple pages within a range.

Fragments are not the same as pages either though.

[Kraut]

So just TLB cache optimization. Do you cut down big page entries that are in use if you start to run low on memory?

[bridgman]

I'm not sure (Christian knows this code about 50x better than me) but my impression is that (a) we only use large pages when allocation is bigger than the page size, (b) large fragments do not consume any additional memory. So probably no...

[Marc Driftmeyer]

Large page will be a boon even for Polaris and earlier OpenCL kernels.