clCreateBuffer() not creating

Started by amcelroy, November 22, 2013, 23:15:08

Previous topic - Next topic

amcelroy

Howdy,

I've a lot of experience with OpenCL in C but am having to roll with Java on a project.  LWJGL has a gorgeous and easy OpenCL interface, so I decided to use that.

Everything has gone well so far: platform query, device query, creating a context, and creating a command Queue.  Everything is running without error until I go to create a buffer.

The buffer is allocated on the device using the following:

    public CLMem allocateMemory(long BytesPerElement, long Width, long Height, long Depth){
        long size = Width*Height*Depth*BytesPerElement;
        CLMem buffer = null;
        try{
            buffer = CL10.clCreateBuffer(mContext, CL10.CL_MEM_WRITE_ONLY, size, mErrorBuf);
        }catch(Exception e){
            int x= 0;
        }
        Util.checkCLError(mErrorBuf.get(0));
        mMemoryBuffers.add(buffer);
        return buffer;
    }


However, when this code executes, no memory is allocated on my device, in this case my CPU.  There is no Exception and
Util.checkCLError(mErrorBuf.get(0));
doesn't produce any errors.  Does anyone else have this issue and is it a bug?

Thanks in advance,
Austin

quew8

The code looks fine. How do you know that there is no memory being allocated? Also with the error, make sure the error buffer's position is 0 before you call clCreateBuffer() (Calling rewind is the easiest way). Otherwise the error won't be put in the 0th index.

By the way, I understand that you are a C programmer but, in Java it is the convention to start variable names with lower case. It doesn't particularly matter but when you ask for help at a Java forum it will help to avoid confusion.

amcelroy

Hey quew8,

I'm just watching the task manager and don't see a jump in used memory.  Going a little further, it looks like the memory allocates only when I perform a clEnqueueWrite().  Is this working as intended?

Thanks for the heads up on the error buffer, I'll update the code to handle that.  Also, any examples to be found about using events with lwjgl for doing event callbacks after a kernel finishes?  I'll open a new forum thread if needed.

Thanks,
Austin

quew8

That's an interesting way of doing things. I never would have thought of doing things that way. As for whether that is expected behaviour, I have no idea; it does sound plausible but personally if it works I let it do whatever it wants to.

As for OpenCL event examples, there are none that I know of. I have only ever seen the two examples on the LWJGL wiki (one of which I wrote) in fact there seems to be a general lacking of OpenCL tutorials in C/C++ as well (certainly in comparison to OpenGL). A long time ago I considered a follow up tutorial covering events but there seemed to be so few people using OpenCL in LWJGL (even I don't use it in production code so far) that it wasn't worth it.

If you are looking for assistance though I will certainly consider writing one. Might make for an interesting diversion.

spasi

Quote from: amcelroy on November 24, 2013, 03:44:51Also, any examples to be found about using events with lwjgl for doing event callbacks after a kernel finishes?

There is an example in the org.lwjgl.test.opencl.HelloOpenCL demo. It's used for a native kernel in this case, but it's the same code for any kernel.

amcelroy

@quew6 - Let me check out the HelloOpenCL demo and see if anything is lacking (probably not).

@spasi - Thanks!  Will check it out.

Also, thanks to the authors of lwjgl for doing such a nice job on packaging OpenCL, so much easier than C/C++ without calling a function to get the size, then calling the function to get the value.  Cuts down on coding :)

Austin