Hello,
It could be interesting for an application to calculate the maximum theoretical bandwidth that a graphics card can achieve.
Some variables to perform this calculations are known/given by the cuda api, for example: Memory Clock Rate.
However some variables are also unknown like “Double Data Rate”. For now graphics cards use GDDR3 or some other double data rate memory chip. Intel however has a memory chip which does quad data rate.
Therefore perhaps in the future graphics cards might start using quad data rate. Therefore “hardcoding” computer programs to assume a multiplier of 2 could be wrong for the future.
To prevent computer programs from reporting incorrect theoretical bandwidth numbers in the future some more information from the cuda api is necessary to be able to tell what kind of memory is being used by the graphics card (this could even be turbo cache/main memory ram ?? for now I will assume onboard graphics memory).
A solution to this lack of information from the cuda api could be to add a new variable/attribute which gives this information, for example this attribute could be called: “Data Rate Multiplier”.
This multiplier would return 2 for GDDR-based memory, and perhaps 4 for future quad-rate-based memory.
Another solution could be to return a type(number) or a string to indicate what type of memory is being used by the graphics cards for example this variable could be called: “Memory Type”.
It could for example return: GDDR3 either in string or defined as a type… for example GDDR1=1, GDDR=2, GDDR3=3 and so forth.
Then the software can query this string and take it’s conclusions based on this string, which could allow the software to learn more information for future graphics cards memory types… for example “double data rate” + “dual channel” or “quad data rate” and so forth… or other properties yet unforseen…
So the string approach has an adventage and a drawback. The adventage is other properties could be derived from it, the disadventage is it would require a software update for the application.
The suggested “Data Rate Multiplier” would not require a software update for the application, and the application would automatically adjust it’s calculations… (The disadventage of “data rate multiplier” could be that it’s too limiting to describe future memory chip properties. “Data Rate Multiplier” is also a bit vague…) Perhaps there are better terms to describe the properties of a memory chip… “Data fetches per clock per channel” and “number of data channels” and so forth.
Bye,
Skybuck.