This patch introduces a partial update of GPUTexture. When rendering
a large image the GPUTexture could have been scaled. The old implementation
would rescale the image on CPU and create a new GPUTexture. This
resulted in flooding the PCI bus.
The new solution would only scale and upload the parts of the GPUTexture
that has been changed. It does this by keeping track of areas of 256x256
pixels. When something changes the tiles that cover that changes will be
rescaled and uploaded the next time the GPUTexture is requested.
Test situation: Default Cube, 4 samples, 19200x10800 tile size 512.
Blender 2.83.9: 4m27s.
Blender 2.91: 20+m (regression)
This patch: 1m01s.
There is still room for more optimizations:
* Reduce the time that an image is locked.
** Use task scheduling to update the tiles of an image.
** Generic optimization of the ImBuf scale method.
Maniphest Tasks: T82591
Differential Revision: https://developer.blender.org/D9591
Issue was that not all code paths were taken to determine if
the GPU Texture was premultiplied or not. In this case the result
was set to unpremultiplied what is incorrect.
This fixes broken test case image alpha blend from image_colorspace.
Regression introduced by {b17cca6966}. When centralizing the gpu texture
premultiplication setting it was assumed that generated images
(`IMA_TYPE_UV_TEST`) were stored as premultiplied. That assumption was
totally wrong as the alpha association is determined by the existing of
the float/byte buffer.
NOTE: This change will render generated images with pure emissive
colors (show colors when alpha=0.0) what might add more reports. Any
reports could be merged in the next report {T82790}.
Reviewed By: Clément Foucault, Philipp Oeser
Differential Revision: https://developer.blender.org/D9585
With the new image editor drawing there were was some mutual exclusive
functionality. When rendering the alpha was shown correctly or the pure
emissive colors were shown correctly, but never both. The cause of this
is that the image_gpu did not used the correct alpha mode when generating
gpu textures for non-images (render results, compositors viewer)
The implementation always checked the alpha_mode. Alpha mode is an
attribute for images, but aren't set for non images. This patch adds
a more detailed check to ensure that the gpu texture is premultiplied.
The issue has been tested using several bug report files and production
files.
Reviewed By: Brecht van Lommel
Differential Revision: https://developer.blender.org/D8978
This project moves the current UV/Image editor drawing to the draw manager.
Why would we do this:
**Performance**:
Current implementation would draw each texel per time. Multiple texels could be
drawn per pixel what would overwrite the previous result. You can notice this
when working with large textures. Repeat image drawing made this visible by
drawing for a small period of time and stop drawing the rest. Now the rendering
is fast and all repeated images are drawn.
**Alpha drawing**:
Current implementation would draw directly in display space. Giving incorrect
results when displaying alpha transparent images.
This addresses {T52680}, {T74709}, {T79518}
The image editor now can show emission only colors. See {D8234} for
examples.
**Current Limitations**
Using images that are larger than supported by your GPU are resized (eg larger
than 16000x16000 are resized to 8k). This leaves some blurring artifacts. It is
a low priority to add support back of displaying individual pixels of huge
images. There is a design task {T80113} with more detail.
**Implementation overview**
Introduced an Image Engine in the draw module. this engine is responsible for
drawing the texture in the main area of the UV/Image editor. The overlay engine
has a edit_uv overlay which is responsible to draw the UV's, shadows and
overlays specifically for the UV Image editor. The background + checker pattern
is drawn by the overlay_background.
The patch will allow us to share overlays between the 3d viewport and UV/Image
editor more easily. In most cases we just need to switch the `pos` with the `u`
attribute in the vertex shader.
The project can be activated in the user preferences as experimental features.
In a later commit this will be reversed.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8234
This is to modernize the API:
- Add meaningful name to all textures (except DRW textures).
- Remove unused err_out argument: only used for offscreen python.
- Add mipmap count to creation functions for future changes.
- Clarify the data usage in creation functions.
This is a cleanup commit, there is no functional change.
# Conflicts:
# source/blender/gpu/GPU_texture.h
This is going to be unecessary after the GPU opengl texture backend refactor.
For now add a save/restore mechanism to leave the state untouched.
Also remove some calls where the caller would bind to particular binding
point and set the shader uniform.
As far as I can see, this problem was introduced with the gpu_free_unused_buffers() changes in rB97b597c.
The code checks the returned pointer to stop looping, but the last iteration will return the last GPUTexture and set the queue to NULL, meaning that the next pop() will crash.
Differential Revision: https://developer.blender.org/D8468
This is in order to disolve GPU_draw.h into more meaningful code blocks.
All the Image related function are in `image_gpu.c`.
All the MovieClip related function are in `movieclip.c`.
The IMB module now has a connection with GPU. This is not strickly
necessary and the code could be move to `image_gpu.c` if needed.
The Image garbage collection is also ported to `image_gpu.c`.
