Skip to content

BF: More adjustements to displaying 4D images on macOS

Paul McCarthy requested to merge paulmc/fsleyes:bf/macos-mipmap into main

There appears to be a bug in the OpenGL driver on Intel-based macbooks where an integrated Intel GPU is in use. The bug affects use of the glTexImage3D function, when replacing the data for an existing 3D texture.

For 3D textures of a certain size, the glTexImage3D function does not seem to successfully populate texture data for existing textures. After a texture has been created, the first call to glTexImage3D succeeds, but then subsequent calls (e.g. to refresh the texture for a 4D image when the volume is changed) return without any error, leaving us with a corrupted texture and display.

The issue seems to related to both the dimensions, and the overall size of the data being transferred. For example, 4D uint8 image (created as a 3D GL_RED texture with internal format GL_R8) with 3D dimensions (435, 300, 300) and (870, 150, 300) display fine, but images with dimensions (1740, 150, 150) and (436, 300, 300) are corrupted. This is on a GPU which reports a GL_MAX_3D_TEXTURE_SIZE of 2048.

The only workaround I have come up with is to delete and recreate the texture handle every time the texture is refreshed. This doesn't seem to have a substantial impact on performance, as the overhead is likely to be the data transfer, which has to happen anyway.

The issue has been observed on macbooks with these GPUs:

  • Intel Iris Pro OpenGL Engine
  • Intel Iris Plus Graphics 625/645/655

Merge request reports