async glReadPixels

[conversy]

Hi,

I created a glReadPixelsbranch in which I added some code to implement async glReadPixels using PBOs. First, I fixed regular, sync'ed glReadPixels to actually get data. Then I implemented an async version when using PBO, by leveraging on MTLBlitCommandEncoder. It's working (or so it seems).

However, to use MTLBlitCommandEncoder, I used an MTLBuffer that I attached to the Buffer mtl data:

    Buffer *ptr;
    ptr = glm_ctx->state.buffers[_PIXEL_PACK_BUFFER];
    ...
    id<MTLBuffer> buffer;
    ...
    buffer = [_device newBufferWithLength:bytesPerImage options: options];
    ptr->data.mtl_data = CFBridgingRetain(buffer);
    ...
    [blitCommandEncoder
        copyFromTexture:texture sourceSlice:0 sourceLevel:0
        sourceOrigin:MTLOriginMake(region.origin.x, region.origin.y, 0) sourceSize:MTLSizeMake(region.size.width, region.size.height, 1)
        toBuffer:buffer destinationOffset:0 destinationBytesPerRow:bytesPerRow destinationBytesPerImage:bytesPerImage];

Still, I know that ptr->data.mtl_data might contain a buffer allocated with vm_allocate, something completely different...

@guymadison could you please have a look at it, and maybe come with a better solution?

[guymadison]

Hi,

I had problems with read pixels, the use of a blitCommandEncoder made the frame rate a bit jerky so I decided to use PBO’s and a buffer transfer but I twiddled with it a but and I didn’t get it to work. I had long list of stuff to get to work to release it so I just felt I would get time to get back to it… which I didn’t.

I am on the water for the next couple of days, I had to haul my sailboat out to replace a thru-hull and the only yard that was available for a haul out was 6 hours away… so I replaced as many as time would allow, but I should be back late tomorrow to take a look.

Cheers

Mike

(A thru-hull… is just another word for a hole in the boat).

On May 2, 2022, at 5:20 AM, conversy @.***> wrote:

Hi,

I created a glReadPixelsbranch in which I added some code to implement async glReadPixels using PBOs. First, I fixed regular, sync'ed glReadPixels to actually get data. Then I implemented an async version when using PBO, by leveraging on MTLBlitCommandEncoder. It's working (or so it seems).

However, to use MTLBlitCommandEncoder, I used an MTLBuffer that I attached to the Buffer mtl data:

Buffer *ptr;
ptr = glm_ctx->state.buffers[_PIXEL_PACK_BUFFER];
...
id<MTLBuffer> buffer;
...
buffer = [_device newBufferWithLength:bytesPerImage options: options];
ptr->data.mtl_data = CFBridgingRetain(buffer);
...
[blitCommandEncoder
    copyFromTexture:texture sourceSlice:0 sourceLevel:0
    sourceOrigin:MTLOriginMake(region.origin.x, region.origin.y, 0) sourceSize:MTLSizeMake(region.size.width, region.size.height, 1)
    toBuffer:buffer destinationOffset:0 destinationBytesPerRow:bytesPerRow destinationBytesPerImage:bytesPerImage];

Still, I know that ptr->data.mtl_data might contain a buffer allocated with vm_allocate, something completely different...

o @guymadison https://github.com/guymadison could you please have a look at it, and maybe come with a better solution?

— Reply to this email directly, view it on GitHub https://github.com/openglonmetal/MGL/issues/37, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKYN3JZPPQNCW4K6YXNXYLVH7CCXANCNFSM5U32KAZA. You are receiving this because you were mentioned.

[conversy]

My measurements were not so bad with async glReadPixels with an MTLBuffer, much better than the sync'ed one of course, but I did not test it extensively. Let's see that when you're back...