| Age | Commit message (Collapse) | Author |
|---|
|
Adds a check when starting blender if your platform is supported. We use a blacklist
as drivers are updated more regular then blender (stable releases).
The mechanism detects if the support level changed or has been validated by the user previously.
Changes can happen due to users updating their drivers, but also when we change the support
level in our code base.
When the user has seen the limited support level message it is saved in the user config.
It would be better to have a system specific config section, but currently not clear
what could benefit from that.
When the platform is unsupported or has limited support a dialog box will appear including a link
to our user manual describing what to do.
**Windows**
Windows uses the MessageBox that is provided by the windows kernel.
**X11**
We use a very lowlevel messagebox for X11. It is very limited in use and can be fine tuned when needed.
**SDL/APPLE**
There is no implementation for SDL or APPLE at this moment as the platform support feature targets mostly Windows users.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5955
|
|
`context_local_shaders_workaround` is only supported on OpenGL 4.1 or higher.
|
|
This reverts commit 44d042094e21b519b38a3d78761b64bb5ceeb350 and adds a
simpler workaround for just the node links display issue. There are other
issues though so this is not a full workaround.
|
|
Related to T70011 and T70008
|
|
This has been tested with 18.2.2, 19.0.8 and 19.3.0~develop.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D5886
|
|
Apparently this workaround solves the problem.
|
|
Workarounds were not being enabled for drivers like `10.18.10.5069`.
|
|
Fix issue in latest patch and assure derivatives calculation is correct on
all GPU.
|
|
Reviewed By: #gpu_viewport, fclem
Differential Revision: https://developer.blender.org/D5392
|
|
|
|
The problem is that the `glDrawArraysInstancedBaseInstance` is ignoring the last parameter.
The solution is to indicate that `GLEW_ARB_base_instance` is not supported in these cases.
Reviewers: fclem, brecht, jbakker
Reviewed By: fclem, brecht
Differential Revision: https://developer.blender.org/D5383
|
|
Add more versions to the workaround list.
|
|
There was an workaround implemented for specific the Intel HD Graphics
4000 GPU on Windows platform. Other GPU from the same series also need
this workaround.
We will enable the workaround for specific drivers.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5239
|
|
In the Intel HD 4000 driver a shader has to be deleted in the same context in which it is created.
However, because you can't use a rendering context on different threads, to maintain the multithreaded compilation, the solution was to use the `GL_ARB_get_program_binary` and copy the binary generated for the shader and generate a shader on the main context using that binary.
This solution is limited only to Intel HD 4000 and windows.
Reviewers: fclem
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D5019
|
|
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
The shaders are: `GPU_SHADER_3D_FLAT_SELECT_ID` and `GPU_SHADER_3D_UNIFORM_SELECT_ID`.
This commit allows the drawing of the mesh select ids to be done on a 32UI format texture.
This simplifies the shader that previously acted on the backbuffer and had to do an uint to rgba conversion.
Differential Revision: https://developer.blender.org/D4350
|
|
Some old AMD drivers crash when a vbo with stride 1 is used a few times.
I have not found a real solution to this problem. So the solution was to use a vbo with stride 4 (which in theory is less efficient and takes up more memory space).
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
I start to think that an automatic detection would be a better solution.
|
|
|
|
Dozens of renderes are included.
|
|
series
|
|
|
|
|
|
|
|
This is nice to test workarounds on other configs that may benefits from
the existing workarounds.
|
|
This seems to be a driver bug. Only windows + Radeon HD 7500M seems
to be affected. Fix can be extended to more config if necessary.
|
|
Seems like a driver bug but doing glFlush() before these calls fixes it.
|
|
Fixes T55987
|
|
On some platform does not support line width > 1.0 and can even throw and
error. Better check an at least display something rather than no lines at
all.
|
|
|
|
|
|
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).
|
|
This happens on NVidia GPUs, using more textures than the maximum allowed
by the gl will NOT trigger a linking issue (maybe because of bindless
texture implementation?).
So in this case we manually count the number of samplers per shader stage
and compare it against the GL limit. We discard the shader if the sampler
count is too high. This shows the user something is wrong with the shader.
|
|
|
|
|
|
Note that this was only reported to happen on AMD GPU + windows.
|
|
|
|
|
|
This was causing issue with shader compilation.
|
