I am new with CUDA and i take a look over the samples that came once with the install kit. I have playd a little whit project from NVIDIA Corporation\CUDA Samples\v8.0\2_Graphics\simpleTexture3D and i have seen that function
read from a file from data/Bucky.raw and i have seen that all the projects have data folders.
I try to see what is in ther but i think is binary code so i can’t understand.
Can anyone tell me for what are those file?
I have study this file from a while and i don’t understand how they have been created, because i have try to convert them to jpg or png but convertors dosen’t recognise the file.
I don’t understand how exactly looks the file from v8.0\v8.0\2_Graphics\simpleTexture3D\data[b]Bucky.raw[/b], and how is obtained the output from v8.0\v8.0\2_Graphics\simpleTexture3D.
It just works open in hex or binary view.
As I stated, the .raw file does not have to be an image, and it can be stored in any proprietary format the creator chose. If you want to understand what is stored in this file, I would suggest taking a look at the details of loadVolumeData(). I guess that function builds some sort of data structure from the file contents. The file itself would have been created by an inverse process that stores out such a data structure using a suitable algorithm.
Not very surprising, given that this is raw data. So loadRawFile() reads the data into an array of bytes, and a hypothetical corresponding storeRawFile() would store an array of bytes to a file.
To find out what this array of bytes represents semantically, you will have to dig through the code and see how the bytes from the array are being used in the code. The function name “loadVolumeData” suggests that the array contains volume data, e.g. density values on a rectangular grid, sometimes referred to as a “map”.
My hypothesis is that this question is an XY-problem, and the actual question is: “I want to modify the simpleTexture3D example code so it uses my own volume data instead of the Bucky dataset. How can I generate my own volume data in the format expect by the simpleTexture3D code?”
Note that the texture read mode is cudaReadModeNormalizedFloat, so the texture access returns a float in [0,1]. The multiplication with 255 then turns this back into an 8-bit grey-scale value. Since the source data is provided as 8-bit data in the case of “Bucky”, this dual conversion probably isn’t necessary, but it adds flexibility to the code, as it can be trivially modified to deal with different data formats than single-byte for input and output.
I have study a little bit farder and i have understand how it works, what i still don’t understand is this part:
uint x = __umul24(blockIdx.x, blockDim.x) + threadIdx.x;
uint y = __umul24(blockIdx.y, blockDim.y) + threadIdx.y;
float u = x / (float)imageW;
float v = y / (float)imageH;
// read from 3D texture
float voxel = tex3D(tex, u, v, w);
X and Y whill be a number (the number of the thread) and after that in u and v is stored that number divide by image width and height. This confuse me a little bit.
And this line also:
uint i = __umul24(y, imageW) + x;
What is the point to store in “i” something like thread_number + width_image+ thread_number;
i seems to be an element offset into the current image slice at z coordinate “w”.
Note that nowadays the use of _umul24() is not encouraged. Only Compute 1.x devices didn’t have a 32 bit integer multiply unit, that’s why the FP unit’s 24 bit multiplier was used. Hence on such devices the 24 bit multiplication had about twice the arithmetic throughput of a 32 bit multiplication.
But on today’s GPUs the 24 bit multiplication needs to be emulated with extra instructions, making it actually slower than 32 bit multiplications.
I don’t know whether __umul24() is a “well-known” operation to the compiler or is treated as a black box. It is likely the latter, in which case its use can interfere with optimizations such as strength reduction and induction variable creation.