In the case of the report a GL_PROXY_TEXTURE_2D_ARRAY of 2509x2509x1 failed to be allocated.
This is a work around as the GL_PROXY_TEXTURE_* is not reliable.
Reviewed By: brecht, fclem
Maniphest Tasks: T63223
Differential Revision: https://developer.blender.org/D4651
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Was generating INVALID_FRAMEBUFFER here instead of failled texture alloc.
Add safety asserts in gpu_texture.c and clamp minimum size to 1 inside
GPU_offscreen_create.
This replaces the test of consistency and capacity made with `GL_PROXY_TEXTURE_..` on AMD GPUs with one that checks only if the texture fits the limits of size and layer.
Differential Revision: https://developer.blender.org/D4081
We exploit the fact that we are using the metallic workflow for material
and pass the metallic parameter instead of the specular color.
Pack the front facing bit in the color buffer only for matcap display.
Change buffer formats to use less bytes as possible.
Also don't request buffers that we won't use.
Saved 40MB on 2K screen on StudioLight + Shadows + Specular Lighting.
Includes several cleanups.
Adding a workaround in this case: we blit the depth buffer instead of the
stencil buffer and use the copy as the texture. This is slower but at
least it should work.
When calling glBlitFramebuffer on most (if not all) mac that have a GPU
from the Radeon Pro series, the data is not properly copied and only a
subset of the pixels are correctly copied.
This only happens when blitting the depth buffer if the depth buffer is
GL_DEPTH24_STENCIL8.
Changing the depth buffer format to GPU_DEPTH32F_STENCIL8 fixes the issue
but only works if blitting the depth componnent. The stencil componnent
still provoke issues when being copied.
This is caused by a driver bug that prevent us from rendering to (or even
binding) a texture mip level that is below GL_TEXTURE_MAX_LEVEL of the
target texture. This is fine in most drivers (and legal AFAIK) but not on
thoses Intels HDXXX + Windows.
As a fix we just put GL_TEXTURE_MAX_LEVEL lower (which is illegal because
it is undefined behaviour), but in practice it works ok and does not
trigger any warnings or errors.
This commit fixes most of the problems encountered on these GPUs (T56668).
Fix T56789: There was issue with certain driver with glGenerateMipmap and
GPU_DEPTH_COMPONENT24.
In this case we just create a complete texture with mipmaps manually
without downsampling / initializing the data.
This lower the use of texture samplers slots and let users use more real
textures in their shaders.
This patch also make the ramp texture 16 bit floating point. Meaning you
can now use value greater than one in your color ramps.
With the limit of 128 colorband per shader (a color band being either a
color ramp, a wavelength node or a curve node (and maybe wavelength node in
the future)).
Only drawback with the current implementation is that it does not remove
colorband from pruned GPUNodes but it shouldn't really matter in practice.
This should fix T56010
GPUFrameBuffers were being free when no context was attached or in the
wrong gl context. This make sure this does not happen again.
You can now safely free any gl resource from any thread (well as long as
it's not used anymore!).
- Texture creation now requires explicit data type.
- GPU_texture_add_mipmap enable explicit mipmap upload.
- GPU_texture_get_mipmap_size can be used to get the size of a mipmap level
of an existing GPUTexture
- GPU_texture_read let you read back data from a gpu texture.
This has wrappers for the most common gl* functions in the codebase, and is in preparation for D3502
Reviewers: brecht, fclem
Differential Revision: https://developer.blender.org/D3501
In an effort to centralize all opengl calls in the codebase, this patch replaces
the raw opengl calls in bf_blenfont with GPUTexture so it's no longer depended
on opengl headers.
reviewer: Brecht
Differential Revision: https://developer.blender.org/D3483
This is a dirty fix. A bit more cleaner approach would be to check if a
context is bound and delay the deletion only in this case.
Also we may want to do this orphan deletion at some other places than
wm_window_swap_buffers.
