Commit Graph

6 Commits

Author SHA1 Message Date
Ian Romanick
ef1ca06ce8 glsl: Combine nop-swizzle optimization with swizzle-swizzle optimization
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: <thomashelland90@gmail.com>
2017-11-08 18:37:29 -08:00
Timothy Arceri
194537ebe4 mesa/glsl/i965: remove Driver.NewShader()
After removing brw_shader in the previous commit this is no longer
needed.

V2: remove use in src/compiler/glsl/test_optpass.cpp

Reviewed-by: Eric Anholt <eric@anholt.net>
2016-12-30 10:57:17 +11:00
Marek Olšák
83d9b8a6f6 glsl/lower_if: don't lower branches touching tess control outputs
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
2016-11-15 20:23:35 +01:00
Ilia Mirkin
e483cb9a3a glsl: reuse main extension table to appropriately restrict extensions
Previously we were only restricting based on ES/non-ES-ness and whether
the overall enable bit had been flipped on. However we have been adding
more fine-grained restrictions, such as based on compat profiles, as
well as specific ES versions. Most of the time this doesn't matter, but
it can create awkward situations and duplication of logic.

Here we separate the main extension table into a separate object file,
linked to the glsl compiler, which makes use of it with a custom
function which takes the ES-ness of the shader into account (thus
allowing desktop shaders to properly use ES extensions that would
otherwise have been disallowed.) We can also now use this logic to
generate #define's for all supported extensions automatically, removing
the duplicate (and often inaccurate) list in glcpp.

The effect of this change should be nil in most cases. However in some
situations, extensions like GL_ARB_gpu_shader5 which were formerly
available in compat contexts on the GLSL side of things will now become
inaccessible.

This regresses two ES CTS tests:

  ES3-CTS.shaders.shader_integer_mix.define
  ES31-CTS.shader_integer_mix.define

however that is due to them using #version 100 instead of 300 es. As the
extension is only defined for ES3, I believe this is the correct
behavior.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v2)
v2 -> v3: integrate glcpp defines into the same mechanism
2016-07-23 13:48:04 -04:00
Timothy Arceri
1fb8c6df88 glsl/mesa: split gl_shader in two
There are two distinctly different uses of this struct. The first
is to store GL shader objects. The second is to store information
about a shader stage thats been linked.

The two uses actually share few fields and there is clearly confusion
about their use. For example the linked shaders map one to one with
a program so can simply be destroyed along with the program. However
previously we were calling reference counting on the linked shaders.

We were also creating linked shaders with a name even though it
is always 0 and called the driver version of the _mesa_new_shader()
function unnecessarily for GL shader objects.

Acked-by: Iago Toral Quiroga <itoral@igalia.com>
2016-06-30 16:51:25 +10:00
Emil Velikov
eb63640c1d glsl: move to compiler/
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Acked-by: Jose Fonseca <jfonseca@vmware.com>
2016-01-26 16:08:33 +00:00