-
Notifications
You must be signed in to change notification settings - Fork 286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
3D Textures not working with uint8 type #388
Comments
Here is the working example of both one and four channels. Is this really the right approach?
|
What format comes out of |
@inducer Yes, the line is taken from the test example, right? I would expect it to simply contain the type of one element since we can also provide number of channels etc. It is this in the first code I posted:
Output:
I expected the descriptor to deal with the alignment since we need to set all the attributes. Where is the problem? Is the second example I posted the way it should be used? Why can't I access the elements in kernel as |
That looks OK. Could you reference the Nvidia docs on how this is intended to work? It's been years since I've directly worked with textures, I don't remember. |
Hmm it seems like the plain Cuda way is slightly different, looking here and here. What I would expect in pycuda is this:
We have a texture of Here:
I would expect the classic RGBA texture. Right now, it seems like the My concern or misunderstanding is about the combination of |
I have edited the test example and changed the type from
float
touint8
, expecting to use it asunsigned char
in the kernel. The output values are, however not the same, they seem to be bit-shifted or misaligned when being read from the memory. Below is the code, the expected result is that the printed values at the end are the same (simplified to copying of just the first value). Now I am getting the expected 20 and the wrong 161. I apologize if this is my lack of understanding but I haven't found anything regarding this topic in the docs and thus I consider this a bug.This seems to be related to the memory alignment rules. When the descriptor is set to
uint32
(descr.format = drv.dtype_to_array_format(np.uint32)
) instead of the input array type, the right values can be obtained when accessed asunsigned char
in the kernel. This is a workaround, or a correct solution? In case of 4 8bit channels, it would be necessary to pass the values reinterpreted as an array of integers?The text was updated successfully, but these errors were encountered: