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.
This bug (explained here https://github.com/dfelinto/opengl-sandbox/blob/downsample/README.md) is breaking eevee beyond the point it's workable.
This patch workaround the issue by making sure every fbo have mipmaps that are strictly greater than 16px. This break the bloom visuals a bit but only for this setup.
We only keep this as a way to get GPU_stubs to run, in case we want to do a
throughout cleanup in the codebase and want code using legacy calls to
fail to build.
There is no more point of keep those around. ES20 may need special case
when/if we dabble with it again. Meanwhile no point on polluting the
code with this.
(ghost still has reference for the PROFILE, but that's reasonable)
In the move to OpenGL 3.3 core profile, we drop support for compatibility profile and older versions.
OpenSubdiv was the only user; I'll update OSD next.
These are always supported now
- instancing as of GL 3.1
- geometry shaders as of GL 3.2
The change to rna_scene.c could use some cleanup, since we don't really need a runtime query function.
See gpu_shader.c for the main changes.
EXT_geometry_shader4 brought this feature to GL versions < 3.2, but now it's just cluttering up our code.
Soon all platforms will be on version 3.3 so we won't even have to check support at runtime!
Initial work by Clément Foucault with contributions from Dalai Felinto
(mainly per-collection engine settings logic, and depsgraph iterator placeholder).
This makes Blender require OpenGL 3.3. Which means Intel graphic card
and OSX will break. Disable CLAY_ENGINE in CMake in those cases.
This is a prototype render engine intended to help the design of real
render engines. This is mainly an engine with enphasis in matcap and
ambient occlusion.
Implemented Features
--------------------
* Clay Render Engine, following the new API, to be used as reference for
future engines
* A more complete Matcap customization with more options
* Per-Collection render engine settings
* New Ground Truth AO - not enabled
Missing Features
----------------
* Finish object edit mode
- Fix shaders to use new matrix
- Fix artifacts when edge does off screen
- Fix depth issue
- Selection sillhouette
- Mesh wires
- Use mesh normals (for higher quality matcap)
- Non-Mesh objects drawing
- Widget drawing
- Performance issues
* Finish mesh edit mode
- Derived-Mesh-less edit mode API (mesh_rende.c)
* General edit mode
- Per-collection edit mode settings
* General engines
- Per-collection engine settings
(they are their, but they still need to be flushed by depsgraph, and
used by the drawing code)
This will make triple buffer used by default for such configuration.
Ideally we would switch to triple buffer on all platforms, but let's
do it in 2.8 branch and don't open can of worms in master now.
This should solve issues like T49945.
GL 3.3 is the new minimum. Compatibility profile for now, core profile eventually. During development, GL 3.0 (on Mesa) and 2.1 (on Mac) will still work.
Part of T49012
At context startup, make sure our assumptions about the OpenGL version are true. Should match since we set up the contexts... but this is what asserts are for, to check "should"s!
Part of T49012
glMapBufferRange is a wonderful function that doesn’t exist on GL < 3.0.
Use the APPLE_flush_buffer_range extension on Mac. It offers several of
glMapBufferRange’s benefits.
Use older “black arts” method to orphan VBOs when we are done with
them. In modern OpenGL this behavior is more obvious.
Add APPLE_flush_buffer_range to Mac requirements. Every GPU is
supported. T49012
ARB_framebuffer_object replaces several related EXT extensions. The ARB
version pulls GL 3 FBO features into GL 2.1, useful for Mac platform.
Its functions and enums have no ARB suffix so transition to modern GL
will be seamless!
Extension is checked at startup, so is guaranteed to be true at runtime.
Part of T49012
Mac’s OpenGL version is furthest away from our target of GL 3.2. This
commit brings Mac closer to other platforms, so that our shaders and
other code don’t diverge too much during development.
According to Apple’s OpenGL matrix these useful extensions are
available on all GPUs that will be able to run Blender 2.8.
Only checked in debug builds; we might need something more forceful.
Part of T49012
This patch supports "Image or Movie" and "Environment map" types of world texture for the viewport.
It supports:
- "View", "AngMap" and "Equirectangular" types of mapping.
- Different types of texture blending (according to BI world render).
- Same color blending as when it lacked textures (but render via glsl).
{F207734}
{F207735}
Example: {F275180}
Original author: @valentin_b4w
Regards,
Alexander (Blend4Web Team).
Reviewers: sergey, valentin_b4w, brecht, merwin
Reviewed By: merwin
Subscribers: campbellbarton, merwin, blueprintrandom, youle, a.romanov, yurikovelenov, AlexKowel, Evgeny_Rodygin
Projects: #rendering, #opengl_gfx, #bf_blender:_next
Differential Revision: https://developer.blender.org/D1414
nVidia Linux driver reports GL_CONTEXT_PROFILE_MASK = 0, which is a bug.
In that case check for the ARB_compatibility extension.
Non-buggy drivers will continue to use
GL_CONTEXT_COMPATIBILITY_PROFILE_BIT.
Thx to Dr Hackerman for reporting.
