Blender crashes when reading to bgl.Buffer / gpu.types.Buffer #91828

New Issue

Christian Stolze · 2021-09-29T22:42:03+02:00

Christian Stolze commented

2021-09-29 22:42:03 +02:00

System Information
Operating system: macOS Big Sur (11.2.1)
Graphics card: Intel Iris Plus Graphics 1536 MB

Blender Version
Broken: 2.83+
Worked: Unknown if this ever worked

Short description of error
I use the "template" option of bgl.Buffer to read pixel data from an OpenGL texture to a numpy array in a fast way. To get a maximum speed, I want to read in RGB mode instead of RGBA mode because that reduces the amount of data to handle in the array. However, Blender crashes with a Segmentation fault: 11 when trying to read from an OpenGL texture to a bgl.Buffer in RGB mode instead of RGBA mode. The following crash log is generated:

# Blender 2.83.10, Commit date: 2020-12-07 14:09, Hash b439a155442b
bpy.ops.text.run_script()  # Operator
bpy.ops.text.run_script()  # Operator

# backtrace
0   Blender                             0x0000000108428067 BLI_system_backtrace + 55
1   Blender                             0x0000000101fd89f8 sig_handle_crash + 392
2   libsystem_platform.dylib            0x00007fff20661d7d _sigtramp + 29
3   ???                                 0x42ebbd3b2a2a83e0 0x0 + 4822155887838397408
4   libGLImage.dylib                    0x00007fff6cb99832 __glgProcessPixelsWithProcessor_block_invoke + 110
5   libdispatch.dylib                   0x00007fff204715dd _dispatch_call_block_and_release + 12
6   libdispatch.dylib                   0x00007fff204727c7 _dispatch_client_callout + 8
7   libdispatch.dylib                   0x00007fff2047520d _dispatch_continuation_pop + 543
8   libdispatch.dylib                   0x00007fff20474916 _dispatch_async_redirect_invoke + 887
9   libdispatch.dylib                   0x00007fff20481857 _dispatch_root_queue_drain + 326
10  libdispatch.dylib                   0x00007fff20481fb8 _dispatch_worker_thread2 + 92
11  libsystem_pthread.dylib             0x00007fff2061a453 _pthread_wqthread + 244
12  libsystem_pthread.dylib             0x00007fff20619467 start_wqthread + 15

The same thing happens, if I use the new GPU module API (gpu.types.Buffer etc.).

Exact steps for others to reproduce the error

Open Blender, enter the following code in the Script window and execute the script. It may be that you have to run the script two or three times until Blender crashes. If you change the IMAGE_COLORMODE = bgl.GL_RGB to IMAGE_COLORMODE = bgl.GL_RGBA you will see that everything works fine without crash.

import bpy, bgl, os
import numpy as np
import timeit

# returns a flipped view into the given numpy array
def from_image_to_numpy(image, ndarray):
    
    # prepare image for OpenGL use
    if image.gl_load(): raise Exception()

    # set image texture to active texture
    bgl.glActiveTexture(bgl.GL_TEXTURE0)
    bgl.glBindTexture(bgl.GL_TEXTURE_2D, image.bindcode)
    
    - then we pass the numpy array to the bgl.Buffer as template,
    - which causes Blender to write the buffer data into the numpy array directly
    print("Numpy shape", ndarray.shape)
    buffer = bgl.Buffer(bgl.GL_BYTE, ndarray.shape, ndarray)
    if IMAGE_COLORMODE == bgl.GL_RGB: bgl.glGetTexImage(bgl.GL_TEXTURE_2D, 0, bgl.GL_RGB, bgl.GL_UNSIGNED_BYTE, buffer)
    if IMAGE_COLORMODE == bgl.GL_RGBA: bgl.glGetTexImage(bgl.GL_TEXTURE_2D, 0, bgl.GL_RGBA, bgl.GL_UNSIGNED_BYTE, buffer)
    bgl.glBindTexture(bgl.GL_TEXTURE_2D, 0)
    
    # start time measurement
    start = timeit.default_timer()

- SOME TESTING CODE
- +++++++++++++++++++++++++++++++++
if __name__ == '__main__':

    - PREPARE THE IMAGE AND NUMPY ARRAY
    - +++++++++++++++++++++++++++++++++
    IMAGE_NAME = "Untitled"
    IMAGE_COLORMODE = bgl.GL_RGB # **<----------- use RGBA here to see that it does not crash!**
    
    # if no image with that name exists, create it
    if not IMAGE_NAME in bpy.data.images:
        bpy.ops.image.new(name='Untitled', width=819, height=455, generated_type='COLOR_GRID')
    
    # get an image from the Blender data blocks
    image = bpy.data.images[IMAGE_NAME]

    # create the numpy array
    if IMAGE_COLORMODE == bgl.GL_RGB: ndarray = np.empty((image.size[1], image.size[0], 3), dtype=np.uint8)
    if IMAGE_COLORMODE == bgl.GL_RGBA: ndarray = np.empty((image.size[1], image.size[0], 4), dtype=np.uint8)

    - SOME BENCHMARKING OF THE FUNCTION
    - +++++++++++++++++++++++++++++++++
    # define number of repeated executions to take the timing from
    EXEC_NUMBER = 100
    
    # test code to get the average execution time for from_image_to_numpy()
    print("Execution of from_image_to_numpy() takes %.3f ms (avergage of %i executions)" % (timeit.timeit("from_image_to_numpy(image, ndarray)", number=EXEC_NUMBER, globals=locals()) / EXEC_NUMBER * 1000, EXEC_NUMBER))

**System Information** Operating system: macOS Big Sur (11.2.1) Graphics card: Intel Iris Plus Graphics 1536 MB **Blender Version** Broken: 2.83+ Worked: Unknown if this ever worked **Short description of error** I use the "template" option of bgl.Buffer to read pixel data from an OpenGL texture to a numpy array in a fast way. To get a maximum speed, I want to read in RGB mode instead of RGBA mode because that reduces the amount of data to handle in the array. However, Blender crashes with a `Segmentation fault: 11` when trying to read from an OpenGL texture to a bgl.Buffer in RGB mode instead of RGBA mode. The following crash log is generated: ``` # Blender 2.83.10, Commit date: 2020-12-07 14:09, Hash b439a155442b bpy.ops.text.run_script() # Operator bpy.ops.text.run_script() # Operator # backtrace 0 Blender 0x0000000108428067 BLI_system_backtrace + 55 1 Blender 0x0000000101fd89f8 sig_handle_crash + 392 2 libsystem_platform.dylib 0x00007fff20661d7d _sigtramp + 29 3 ??? 0x42ebbd3b2a2a83e0 0x0 + 4822155887838397408 4 libGLImage.dylib 0x00007fff6cb99832 __glgProcessPixelsWithProcessor_block_invoke + 110 5 libdispatch.dylib 0x00007fff204715dd _dispatch_call_block_and_release + 12 6 libdispatch.dylib 0x00007fff204727c7 _dispatch_client_callout + 8 7 libdispatch.dylib 0x00007fff2047520d _dispatch_continuation_pop + 543 8 libdispatch.dylib 0x00007fff20474916 _dispatch_async_redirect_invoke + 887 9 libdispatch.dylib 0x00007fff20481857 _dispatch_root_queue_drain + 326 10 libdispatch.dylib 0x00007fff20481fb8 _dispatch_worker_thread2 + 92 11 libsystem_pthread.dylib 0x00007fff2061a453 _pthread_wqthread + 244 12 libsystem_pthread.dylib 0x00007fff20619467 start_wqthread + 15 ``` The same thing happens, if I use the new GPU module API (gpu.types.Buffer etc.). **Exact steps for others to reproduce the error** Open Blender, enter the following code in the Script window and execute the script. It may be that you have to run the script two or three times until Blender crashes. If you change the `IMAGE_COLORMODE = bgl.GL_RGB` to `IMAGE_COLORMODE = bgl.GL_RGBA` you will see that everything works fine without crash. ``` import bpy, bgl, os import numpy as np import timeit # returns a flipped view into the given numpy array def from_image_to_numpy(image, ndarray): # prepare image for OpenGL use if image.gl_load(): raise Exception() # set image texture to active texture bgl.glActiveTexture(bgl.GL_TEXTURE0) bgl.glBindTexture(bgl.GL_TEXTURE_2D, image.bindcode) - then we pass the numpy array to the bgl.Buffer as template, - which causes Blender to write the buffer data into the numpy array directly print("Numpy shape", ndarray.shape) buffer = bgl.Buffer(bgl.GL_BYTE, ndarray.shape, ndarray) if IMAGE_COLORMODE == bgl.GL_RGB: bgl.glGetTexImage(bgl.GL_TEXTURE_2D, 0, bgl.GL_RGB, bgl.GL_UNSIGNED_BYTE, buffer) if IMAGE_COLORMODE == bgl.GL_RGBA: bgl.glGetTexImage(bgl.GL_TEXTURE_2D, 0, bgl.GL_RGBA, bgl.GL_UNSIGNED_BYTE, buffer) bgl.glBindTexture(bgl.GL_TEXTURE_2D, 0) # start time measurement start = timeit.default_timer() - SOME TESTING CODE - +++++++++++++++++++++++++++++++++ if __name__ == '__main__': - PREPARE THE IMAGE AND NUMPY ARRAY - +++++++++++++++++++++++++++++++++ IMAGE_NAME = "Untitled" IMAGE_COLORMODE = bgl.GL_RGB # **<----------- use RGBA here to see that it does not crash!** # if no image with that name exists, create it if not IMAGE_NAME in bpy.data.images: bpy.ops.image.new(name='Untitled', width=819, height=455, generated_type='COLOR_GRID') # get an image from the Blender data blocks image = bpy.data.images[IMAGE_NAME] # create the numpy array if IMAGE_COLORMODE == bgl.GL_RGB: ndarray = np.empty((image.size[1], image.size[0], 3), dtype=np.uint8) if IMAGE_COLORMODE == bgl.GL_RGBA: ndarray = np.empty((image.size[1], image.size[0], 4), dtype=np.uint8) - SOME BENCHMARKING OF THE FUNCTION - +++++++++++++++++++++++++++++++++ # define number of repeated executions to take the timing from EXEC_NUMBER = 100 # test code to get the average execution time for from_image_to_numpy() print("Execution of from_image_to_numpy() takes %.3f ms (avergage of %i executions)" % (timeit.timeit("from_image_to_numpy(image, ndarray)", number=EXEC_NUMBER, globals=locals()) / EXEC_NUMBER * 1000, EXEC_NUMBER)) ```

Christian Stolze commented

2021-09-29 22:42:03 +02:00

Added subscriber: @regcs

Christian Stolze commented

2021-09-29 22:50:36 +02:00

Added subscribers: @GottfriedHofmann, @fclem, @brecht, @ideasman42, @mano-wii

Germano Cavalcante commented

2021-09-30 00:09:10 +02:00

Removed subscribers: @ideasman42, @brecht, @fclem, @GottfriedHofmann

Germano Cavalcante commented

2021-09-30 00:09:10 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Germano Cavalcante commented

2021-09-30 00:09:10 +02:00

bgl is a module that is at the end of its life.
Depending on the problem, we no longer maintain it.
The replacement is the gpu module.

You are working with a python wrapper from a low level C API (OpenGL).
bgl has few safe guards and the problem is probably not in Blender.

I suspect the problem is with the calculated buffer size.

ndarray = np.empty((image.size[1], image.size[0], 3), dtype=np.uint8)

Although it's RGB, the driver might calculate pads that are added to each pixel and thus force the user to calculate a buffer as if it had 4 channels.
It would be necessary to investigate in more detail. But I'm pretty sure what's happening is a misuse of OpenGL.

If you can replicate the same problem using the gpu module, we'll take a closer look.

`bgl` is a module that is at the end of its life. Depending on the problem, we no longer maintain it. The replacement is the `gpu` module. You are working with a python wrapper from a low level C API (OpenGL). `bgl` has few safe guards and the problem is probably not in Blender. I suspect the problem is with the calculated buffer size. ``` ndarray = np.empty((image.size[1], image.size[0], 3), dtype=np.uint8) ``` Although it's `RGB`, the driver might calculate pads that are added to each pixel and thus force the user to calculate a buffer as if it had 4 channels. It would be necessary to investigate in more detail. But I'm pretty sure what's happening is a misuse of OpenGL. If you can replicate the same problem using the `gpu` module, we'll take a closer look.

Christian Stolze commented

2021-09-30 02:23:33 +02:00

Thanks for your response. I don't understand why you consider this a misuse of OpenGL, but if it is, then the same thing happens with the new gpu module as I mentioned above. Please run the following modified version in Blender 3.0 to see the crash happen with the gpu module:

import bpy, os
import gpu, gpu_extras
import numpy as np
import timeit

# returns a flipped view into the given numpy array
def from_image_to_numpy(image, ndarray):
    
    # load image into offscreen
    offscreen = gpu.types.GPUOffScreen(image.size[0], image.size[1])

    with offscreen.bind():

        # get the active framebuffer
        framebuffer = gpu.state.active_framebuffer_get()

        # load image into texture and draw it into the offscreen
        texture = gpu.texture.from_image(image)
        gpu_extras.presets.draw_texture_2d(texture, (0,0), image.size[0], image.size[1])

        - then we pass the numpy array to the gpu.types.Buffer as template,
        - which causes Blender to write the buffer data into the numpy array directly
        buffer = gpu.types.Buffer('UBYTE', ndarray.shape, ndarray)

        # write pixel data from texture into the buffer (numpy array)
        framebuffer.read_color(0, 0, ndarray.shape[1], ndarray.shape[0], ndarray.shape[2], 0, 'UBYTE', data=buffer)

- SOME TESTING CODE
- +++++++++++++++++++++++++++++++++
if __name__ == '__main__':


    - PREPARE THE IMAGE AND NUMPY ARRAY
    - +++++++++++++++++++++++++++++++++
    IMAGE_NAME = "Untitled"
    IMAGE_COLORMODE = "RGB" # <----------- use "RGBA" here to see that it does not crash!
    
    # if no image with that name exists, create it
    if not IMAGE_NAME in bpy.data.images:
        bpy.ops.image.new(name='Untitled', width=819, height=455, generated_type='COLOR_GRID')
    
    # get an image from the Blender data blocks
    image = bpy.data.images[IMAGE_NAME]

    # create the numpy array
    ndarray = np.empty((image.size[1], image.size[0], len(IMAGE_COLORMODE)), dtype=np.uint8)

    - SOME BENCHMARKING OF THE FUNCTION
    - +++++++++++++++++++++++++++++++++
    # define number of repeated executions to take the timing from
    EXEC_NUMBER = 100
    
    # test code to get the average execution time for from_image_to_numpy()
    print("Execution of from_image_to_numpy() takes %.3f ms (avergage of %i executions)" % (timeit.timeit("from_image_to_numpy(image, ndarray)", number=EXEC_NUMBER, globals=locals()) / EXEC_NUMBER * 1000, EXEC_NUMBER))

If you use IMAGE_COLORMODE = "RGB" it crashes, if you use IMAGE_COLORMODE = "RGBA" it does not. Please note that based on this string definition, this code snipped passes a 3 or a 4 to the channel parameters in both the numpy array definition and the gpu.types.GPUFrameBuffer.read_color() method.

Thanks for your response. I don't understand why you consider this a misuse of OpenGL, but if it is, then the same thing happens with the new `gpu` module as I mentioned above. Please run the following modified version in Blender 3.0 to see the crash happen with the `gpu` module: ``` import bpy, os import gpu, gpu_extras import numpy as np import timeit # returns a flipped view into the given numpy array def from_image_to_numpy(image, ndarray): # load image into offscreen offscreen = gpu.types.GPUOffScreen(image.size[0], image.size[1]) with offscreen.bind(): # get the active framebuffer framebuffer = gpu.state.active_framebuffer_get() # load image into texture and draw it into the offscreen texture = gpu.texture.from_image(image) gpu_extras.presets.draw_texture_2d(texture, (0,0), image.size[0], image.size[1]) - then we pass the numpy array to the gpu.types.Buffer as template, - which causes Blender to write the buffer data into the numpy array directly buffer = gpu.types.Buffer('UBYTE', ndarray.shape, ndarray) # write pixel data from texture into the buffer (numpy array) framebuffer.read_color(0, 0, ndarray.shape[1], ndarray.shape[0], ndarray.shape[2], 0, 'UBYTE', data=buffer) - SOME TESTING CODE - +++++++++++++++++++++++++++++++++ if __name__ == '__main__': - PREPARE THE IMAGE AND NUMPY ARRAY - +++++++++++++++++++++++++++++++++ IMAGE_NAME = "Untitled" IMAGE_COLORMODE = "RGB" # <----------- use "RGBA" here to see that it does not crash! # if no image with that name exists, create it if not IMAGE_NAME in bpy.data.images: bpy.ops.image.new(name='Untitled', width=819, height=455, generated_type='COLOR_GRID') # get an image from the Blender data blocks image = bpy.data.images[IMAGE_NAME] # create the numpy array ndarray = np.empty((image.size[1], image.size[0], len(IMAGE_COLORMODE)), dtype=np.uint8) - SOME BENCHMARKING OF THE FUNCTION - +++++++++++++++++++++++++++++++++ # define number of repeated executions to take the timing from EXEC_NUMBER = 100 # test code to get the average execution time for from_image_to_numpy() print("Execution of from_image_to_numpy() takes %.3f ms (avergage of %i executions)" % (timeit.timeit("from_image_to_numpy(image, ndarray)", number=EXEC_NUMBER, globals=locals()) / EXEC_NUMBER * 1000, EXEC_NUMBER)) ``` If you use `IMAGE_COLORMODE = "RGB"` it crashes, if you use `IMAGE_COLORMODE = "RGBA"` it does not. Please note that based on this string definition, this code snipped passes a `3` or a `4` to the channel parameters in both the numpy array definition and the `gpu.types.GPUFrameBuffer.read_color()` method.

Germano Cavalcante commented

2021-09-30 14:31:37 +02:00

Thanks for the code.
I tested it and had no problems.
This indicates that the problem may be with your installed graphics driver.
I also edited the code to see if there's anything relating to the pad that I mentioned before:

import bpy
import gpu, gpu_extras
import numpy as np

from gpu_extras.presets import draw_texture_2d
from mathutils import Matrix

# returns a flipped view into the given numpy array
def from_image_to_numpy(image, ndarray):
    # load image into offscreen
    offscreen = gpu.types.GPUOffScreen(image.size[0], image.size[1])

    with offscreen.bind():
        # get the active framebuffer
        framebuffer = gpu.state.active_framebuffer_get()

        # load image into texture and draw it into the offscreen
        texture = gpu.texture.from_image(image)
        gpu.state.color_mask_set(True, True, True, True)
        gpu.state.depth_mask_set(False)
        gpu.state.depth_test_set('ALWAYS')
        gpu.state.blend_set('NONE')
        gpu.matrix.load_identity()
        gpu.matrix.load_projection_matrix(Matrix.Identity(4))
        #assert bgl.glIsEnabled(bgl.GL_SCISSOR_TEST) == False
        draw_texture_2d(texture, (-(image.size[0]/2), -(image.size[1]/2)), image.size[0], image.size[1])

        - then we pass the numpy array to the gpu.types.Buffer as template,
        - which causes Blender to write the buffer data into the numpy array directly
        buffer = gpu.types.Buffer('UBYTE', ndarray.shape, ndarray)

        # write pixel data from texture into the buffer (numpy array)
        framebuffer.read_color(0, 0, image.size[1], image.size[0], ndarray.shape[2], 0, 'UBYTE', data=buffer)

# SOME TESTING CODE
if __name__ == '__main__':
    # PREPARE THE IMAGE AND NUMPY ARRAY
    IMAGE_NAME = "Blank"
    IMAGE_COLORMODE = "RGB"
    CHANNELS_LEN = len(IMAGE_COLORMODE)
    
    # if no image with that name exists, create it
    if not IMAGE_NAME in bpy.data.images:
        bpy.ops.image.new(name='Blank', width=12, height=12, generated_type='BLANK')

    # get an image from the Blender data blocks
    image = bpy.data.images[IMAGE_NAME]
    for i in range(len(image.pixels)):
        image.pixels[i] = (i % 4) / 3.0

    # create the numpy array
    ndarray = np.ones((image.size[1] + 1, image.size[0], CHANNELS_LEN), dtype=np.uint8)
    
    # test code to get the average execution time for from_image_to_numpy()
    from_image_to_numpy(image, ndarray)

    print("-----------------")
    print(ndarray)

But everything returned according to the size calculated by channels. So that apparently wasn't the problem.
Can you test this script as well and report what appears on the console?
Also, although I'm not sure if this option works on Mac, could you try running blender with the --debug-gpu option? After replicating the crash, we will probably have more information about the problem.

Thanks for the code. I tested it and had no problems. This indicates that the problem may be with your installed graphics driver. I also edited the code to see if there's anything relating to the pad that I mentioned before: ```lines=20 import bpy import gpu, gpu_extras import numpy as np from gpu_extras.presets import draw_texture_2d from mathutils import Matrix # returns a flipped view into the given numpy array def from_image_to_numpy(image, ndarray): # load image into offscreen offscreen = gpu.types.GPUOffScreen(image.size[0], image.size[1]) with offscreen.bind(): # get the active framebuffer framebuffer = gpu.state.active_framebuffer_get() # load image into texture and draw it into the offscreen texture = gpu.texture.from_image(image) gpu.state.color_mask_set(True, True, True, True) gpu.state.depth_mask_set(False) gpu.state.depth_test_set('ALWAYS') gpu.state.blend_set('NONE') gpu.matrix.load_identity() gpu.matrix.load_projection_matrix(Matrix.Identity(4)) #assert bgl.glIsEnabled(bgl.GL_SCISSOR_TEST) == False draw_texture_2d(texture, (-(image.size[0]/2), -(image.size[1]/2)), image.size[0], image.size[1]) - then we pass the numpy array to the gpu.types.Buffer as template, - which causes Blender to write the buffer data into the numpy array directly buffer = gpu.types.Buffer('UBYTE', ndarray.shape, ndarray) # write pixel data from texture into the buffer (numpy array) framebuffer.read_color(0, 0, image.size[1], image.size[0], ndarray.shape[2], 0, 'UBYTE', data=buffer) # SOME TESTING CODE if __name__ == '__main__': # PREPARE THE IMAGE AND NUMPY ARRAY IMAGE_NAME = "Blank" IMAGE_COLORMODE = "RGB" CHANNELS_LEN = len(IMAGE_COLORMODE) # if no image with that name exists, create it if not IMAGE_NAME in bpy.data.images: bpy.ops.image.new(name='Blank', width=12, height=12, generated_type='BLANK') # get an image from the Blender data blocks image = bpy.data.images[IMAGE_NAME] for i in range(len(image.pixels)): image.pixels[i] = (i % 4) / 3.0 # create the numpy array ndarray = np.ones((image.size[1] + 1, image.size[0], CHANNELS_LEN), dtype=np.uint8) # test code to get the average execution time for from_image_to_numpy() from_image_to_numpy(image, ndarray) print("-----------------") print(ndarray) ``` But everything returned according to the size calculated by channels. So that apparently wasn't the problem. Can you test this script as well and report what appears on the console? Also, although I'm not sure if this option works on Mac, could you try running blender with the `--debug-gpu` option? After replicating the crash, we will probably have more information about the problem.

Brecht Van Lommel commented

2021-09-30 14:50:29 +02:00

For best performance just use RGBA, it's natively stored that way and converting to and from RGB has a cost.

The reason this fails is because GL_UNPACK_ALIGNMENT is set to 4 by default in OpenGL, which means rows must be aligned to 4 bytes.

For best performance just use RGBA, it's natively stored that way and converting to and from RGB has a cost. The reason this fails is because `GL_UNPACK_ALIGNMENT` is set to 4 by default in OpenGL, which means rows must be aligned to 4 bytes.

Christian Stolze commented

2021-09-30 18:57:54 +02:00

Added subscriber: @brecht

Christian Stolze commented

2021-09-30 18:57:54 +02:00

Thanks, @mano-wii for spending time on that. The code you delivered does not crash on my machine, but it also uses a 12x12 image instead of the 819x455 I chose before. Indeed, if I chose row sizes that are divisible by 4 my code does not crash either. So, what Brecht says seems to be the right thing.

@brecht I wanted to use RGB data instead of RGBA data because I need to reduce the amount of data in my script. The images I handle with the script are send via an interprocess communication to another app and the latency is too large for the image sizes I target (2k to 4k). skipping the (not required) alpha channel reduces the data and the latency a lot.

Is there any way I can manipulate the GL_UNPACK_ALIGNMENT with the new gpu module (I would rather choose not to manually add zero padding to the pixel data to fill the rows)?

Edit: @brecht Just tested the speed of reading RGB and RGBA data for a 4096x4096 image - reading RGB to the numpy array via the above method is ~30% faster than reading RGBA. That is in contradiction to your statement about the performance. I guess, the computation cost required to copy a large amount of data is relevant here.

Edit 2: Yes, it is indeed dependent on the image / buffer size. For smaller images, reading RGBA is faster than reading in RGB.

Thanks, @mano-wii for spending time on that. The code you delivered does not crash on my machine, but it also uses a 12x12 image instead of the 819x455 I chose before. Indeed, if I chose row sizes that are divisible by 4 my code does not crash either. So, what Brecht says seems to be the right thing. @brecht I wanted to use RGB data instead of RGBA data because I need to reduce the amount of data in my script. The images I handle with the script are send via an interprocess communication to another app and the latency is too large for the image sizes I target (2k to 4k). skipping the (not required) alpha channel reduces the data and the latency a lot. Is there any way I can manipulate the `GL_UNPACK_ALIGNMENT` with the new `gpu` module (I would rather choose not to manually add zero padding to the pixel data to fill the rows)? **Edit:** @brecht Just tested the speed of reading RGB and RGBA data for a 4096x4096 image - reading RGB to the numpy array via the above method is ~30% faster than reading RGBA. That is in contradiction to your statement about the performance. I guess, the computation cost required to copy a large amount of data is relevant here. **Edit 2:** Yes, it is indeed dependent on the image / buffer size. For smaller images, reading RGBA is faster than reading in RGB.

Germano Cavalcante commented

2021-09-30 19:17:36 +02:00

From what I can see in the code, GL_UNPACK_ALIGNMENT is set to 1 by default in Blender.
https://developer.blender.org/diffusion/B/browse/master/source/blender/gpu/opengl/gl_state.cc$54

Does this not work for some OS?
It would be nice if this value were checked and tested on different hardware.

From what I can see in the code, `GL_UNPACK_ALIGNMENT` is set to `1` by default in Blender. https://developer.blender.org/diffusion/B/browse/master/source/blender/gpu/opengl/gl_state.cc$54 Does this not work for some OS? It would be nice if this value were checked and tested on different hardware.

Brecht Van Lommel commented

2021-09-30 20:11:43 +02:00

@mano-wii. Actually in this case I think it's GL_PACK_ALIGNMENT since it's reading the texture back. I guess we can set that to 1 without causing problems.

@mano-wii. Actually in this case I think it's `GL_PACK_ALIGNMENT` since it's reading the texture back. I guess we can set that to 1 without causing problems.

blender-admin commented

2021-09-30 22:22:12 +02:00

This issue was referenced by bdc66c9569

This issue was referenced by bdc66c9569eb244296bc1fad362f372ff8a939e2

Christian Stolze commented

2021-09-30 22:29:13 +02:00

Yes, @brecht is right. Just verified that by setting the GL_PACK_ALIGNMENT to 1 with my old bgl code manually and the crash is gone.

Edit: Thanks for the commit, @mano-wii.

Yes, @brecht is right. Just verified that by setting the `GL_PACK_ALIGNMENT ` to 1 with my old bgl code manually and the crash is gone. **Edit:** Thanks for the commit, @mano-wii.

Germano Cavalcante commented

2021-09-30 23:29:06 +02:00

In #91828#1229168, @regcs wrote:
Edit: Thanks for the commit, @mano-wii.

Still under review, but I don't think it will take long to land on master ;)

> In #91828#1229168, @regcs wrote: > **Edit:** Thanks for the commit, @mano-wii. Still under review, but I don't think it will take long to land on master ;)

Christian Stolze commented

2021-10-01 08:26:02 +02:00

Yeah, not a lot to review this time. ^^

By the way, will this also make it's way into 2.93 LTS as a bug fix?

Yeah, not a lot to review this time. ^^ By the way, will this also make it's way into 2.93 LTS as a bug fix?

Germano Cavalcante commented

2021-10-01 14:12:19 +02:00

Changed status from 'Needs User Info' to: 'Resolved'

Germano Cavalcante closed this issue

2021-10-01 14:12:19 +02:00

Germano Cavalcante self-assigned this 2021-10-01 14:12:19 +02:00

Germano Cavalcante commented

2021-10-01 15:32:52 +02:00

In #91828#1229269, @regcs wrote:
By the way, will this also make it's way into 2.93 LTS as a bug fix?

Well, I don't see a problem in backporting, but for LTS it was decided to backport only critical issues.
Does this issue qualify as being critical?
The 3.0 release is getting close (December).
And you can work around the problem by using the bgl module in 2.93.

> In #91828#1229269, @regcs wrote: > By the way, will this also make it's way into 2.93 LTS as a bug fix? Well, I don't see a problem in backporting, but for LTS it was decided to backport only critical issues. Does this issue qualify as being critical? The 3.0 release is getting close (December). And you can work around the problem by using the bgl module in 2.93.

Christian Stolze commented

2021-10-01 18:42:21 +02:00

Yeah, sure I can work around it in LTS with the bgl. I was just curious if that will be backported or not, since I don’t yet fully understood what the usual workflow with bug fixes is. Like, who decides if a bug fix like this is considered critical or not. Or if anything that leads to crashes (like this reported thing here) is automatically backported.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender crashes when reading to bgl.Buffer / gpu.types.Buffer #91828