[Mesa-dev] [Bug 93112] GLX: could not load software renderer
https://bugs.freedesktop.org/show_bug.cgi?id=93112 --- Comment #3 from poma --- (In reply to Emil Velikov from comment #2) > Albert, using please can be a world of difference :-P > > Poma, upstream commit 59cfb21d4670559d49a721df766073d9d288b51a should > already fix this. Please reopen if that's not the case. $ grep -i glx /var/log/Xorg.0.log [43.027] (II) LoadModule: "glx" [43.029] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [43.220] (II) Module glx: vendor="X.Org Foundation" [43.220] (==) AIGLX enabled [43.289] (II) AIGLX: Screen 0 is not DRI2 capable [43.289] (EE) AIGLX: reverting to software rendering [44.566] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [44.567] (II) AIGLX: Loaded and initialized swrast [44.567] (II) GLX: Initialized DRISWRAST GL provider for screen 0 $ glxinfo | grep -w renderer OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.7, 128 bits) $ rpm -q mesa-dri-drivers mesa-dri-drivers-11.2.0-0.devel.2.59cfb21.fc24.x86_64 Thanks man. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/main: TexImage2DMultisample needs to pass OpenGL3.3 conformance test.
> -Original Message-
> From: Timothy Arceri [mailto:t_arc...@yahoo.com.au]
> Sent: Thursday, November 26, 2015 11:32 PM
> To: Predut, Marius; Palli, Tapani; mesa-dev@lists.freedesktop.org
> Subject: Re: [Mesa-dev] [PATCH] mesa/main: TexImage2DMultisample needs to pass
> OpenGL3.3 conformance test.
>
> On Thu, 2015-11-26 at 11:00 +, Predut, Marius wrote:
> > > -Original Message-
> > > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
> > > Behalf Of Timothy Arceri
> > > Sent: Wednesday, November 25, 2015 6:02 PM
> > > To: Palli, Tapani; Predut, Marius; mesa-dev@lists.freedesktop.org
> > > Subject: Re: [Mesa-dev] [PATCH] mesa/main: TexImage2DMultisample
> > > needs to pass
> > > OpenGL3.3 conformance test.
> > >
> > > On Wed, 2015-11-25 at 17:13 +0200, Tapani Pälli wrote:
> > > > On 11/25/2015 04:00 PM, Predut, Marius wrote:
> > > > > > -Original Message-
> > > > > > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org
> > > > > > ] On
> > > > > > Behalf Of Timothy Arceri
> > > > > > Sent: Wednesday, November 25, 2015 1:12 PM
> > > > > > To: Palli, Tapani; Predut, Marius;
> > > > > > mesa-dev@lists.freedesktop.org
> > > > > > Subject: Re: [Mesa-dev] [PATCH] mesa/main:
> > > > > > TexImage2DMultisample
> > > > > > needs to pass
> > > > > > OpenGL3.3 conformance test.
> > > > > >
> > > > > > On Wed, 2015-11-25 at 12:47 +0200, Tapani Pälli wrote:
> > > > > > > Hi;
> > > > > > >
> > > > > > > On 11/25/2015 01:15 PM, Marius Predut wrote:
> > > > > > > > Open GL 3.3 reference document says:
> > > > > > > > samples must be in the range zero to GL_MAX_TEXTURE_SIZE
> > > > > > > > - 1.
> > > > > > > > Open GL.4 clearly states:
> > > > > > > > An INVALID_VALUE error is generated if samples is zero.
> > > > > > See my comment in bugzilla [1] I believe this is just a bug in
> > > > > > the reference pages, we implement things in Mesa going by what
> > > > > > the spec says and the spec says nothing about samples being 0
> > > > > > in the
> > > > > > 3.2 spec in fact it doen't even say anything in the 4.0 spec
> > > > > > which you have changed the check to.
> > > > > >
> > > > > > Also the 4.5 reference pages also conflict with the spec so
> > > > > > this is even more reason I think this change is wrong.
> > > > > >
> > > > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=91670
> > > > > >
> > > > > I don't think it is a bug in specs because in this case also the
> > > > > CTS and the piglit test is wrong:
> > > > >
> > > > > With this patch 2 things are fixed:
> > > > > 1.Khronos CTS conformance tests for OpenGL 3.3 2. The piglit
> > > > > test
> > > > > https://bugs.freedesktop.org/show_bug.cgi?id=93100 (Or
> > > > > https://bugs.freedesktop.org/show_bug.cgi?id=91670)
> > > > >
> > > > > The patch is based on this spec:
> > > > > https://www.opengl.org/sdk/docs/man3/xhtml/glTexImage3DMultisam
> > > > > ple.
> > > > > xml
> > > > >
> > > > > We can't believe or "suppose" something here, the specs need to
> > > > > be as an axioma.
> > > > > Can someone confirm that this reference includes the wrong
> > > > > specs?
> > > >
> > > > That's not a specification but a manual page. Timothy is pointing
> > > > to OpenGL specifications (available at www.opengl.org/registry).
> > > > It is true that for example 3.3 Core does not mention this error
> > > > case which means using 0 was allowed there. IMO either we should
> > > > allow to use 0 (and bump it to 1?) when running on 3.x context
> > > > since it's not forbidden or maybe just locally patch this whenever
> > > > running 3.x conformance.
> > >
> > > Hi Marius,
> > >
> > > Please provide the test CTS test that you are trying to fix so that
> > > we can take a look at what the CTS is trying to test.
> > >
> > > While the OpenGL 3.2 -> 4.2 specs seem to allow zero due simple to
> > > not mentioning it seems odd to me that the CTS would specificly test
> > > for this. As far as I understand it a value of 0 would result in
> > > undefined behaviour, so it doesn't seem right to allow this for
> > > these versions of OpenGL. IMO we should be going with the later
> > > specs that fix this oversight for all versions of GL.
> > >
> > > One thing I can see the CTS doing in various tests is querying the
> > > GL implementation for values, its possible we are passing a value of
> > > 0 back to the tests somewhere and its trying to used this with the
> > > multisample functions. The only way to know whats going on is if you
> > > tell us which test you are trying to fix.
> > >
> > > Tim
> >
> >
> > Hi Tim
> >
> > On my case, in file otc_gen_graphics-khronos
> > -glconform/framework/opengl/gluStateReset.cpp
> > I have something like :
> >
> > if (type >= CONTEXTTYPE_GL32_CORE)
> > {
> > // Reset 2D multisample texture.
> > gl.bindTexture
> > (GL_TEXTURE_2D_MULTISAMPLE, 0);
> > gl.texImage2DMultisample
> > (GL_TEXTURE_2D_MULTISAMPLE, 0, GL_RGBA8, 0, 0, GL
[Mesa-dev] [Bug 93100] [IVB]piglit/spec/opengl_3.3/gl-3.2-layered-rendering-framebuffertexture fails
https://bugs.freedesktop.org/show_bug.cgi?id=93100 --- Comment #3 from marius predut --- (In reply to Timothy Arceri from comment #2) > I think this is just a bug in the reference pages see my comments in bug > 91670 Please clarify this with Kronos and convince them to update the reference pages: https://www.opengl.org/sdk/docs/man3/xhtml/glTexImage3DMultisample.xml Till this reference page is available on WWW, I can't consider this defect need to be close, because may developers will consider it as it is. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] vl/buffers: fixes vl_video_buffer_formats for RGBX
Signed-off-by: Julien Isorce --- src/gallium/auxiliary/vl/vl_video_buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c b/src/gallium/auxiliary/vl/vl_video_buffer.c index 62f4aa9..b3f6ff5 100644 --- a/src/gallium/auxiliary/vl/vl_video_buffer.c +++ b/src/gallium/auxiliary/vl/vl_video_buffer.c @@ -115,7 +115,7 @@ vl_video_buffer_formats(struct pipe_screen *screen, enum pipe_format format) return const_resource_formats_VUYA; case PIPE_FORMAT_R8G8B8X8_UNORM: - return const_resource_formats_VUYX; + return const_resource_formats_YUVX; case PIPE_FORMAT_B8G8R8X8_UNORM: return const_resource_formats_VUYX; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/va: ensure linear memory for dmabuf
In order to do zero-copy between two different devices
the memory should not be tiled.
This is currently no way to set pipe_resource template's flag
from pipe_video_buffer template. So disabled_tiling is added.
Choosed "disable" prefix so that CALLOC keeps tiling enabled
by default.
Tested with GStreamer on a laptop that has 2 GPUs:
1- gstvaapidecode:
HW decoding and dmabuf export with nouveau driver on Nvidia GPU.
2- glimagesink:
EGLImage imports dmabuf on Intel GPU.
Note that tiling is working if 1 and 2 are done on the same GPU.
So it is up to the application to set or not the flag:
VA_SURFACE_EXTBUF_DESC_ENABLE_TILING
Signed-off-by: Julien Isorce
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 3 +++
src/gallium/include/pipe/p_video_codec.h | 1 +
src/gallium/state_trackers/va/surface.c| 5 +
3 files changed, 9 insertions(+)
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index 6cd2557..62f4aa9 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -253,6 +253,9 @@ vl_video_buffer_template(struct pipe_resource *templ,
templ->bind = PIPE_BIND_SAMPLER_VIEW | PIPE_BIND_RENDER_TARGET;
templ->usage = usage;
+ if (tmpl->disable_tiling)
+ templ->bind |= PIPE_BIND_LINEAR;
+
if (plane > 0) {
if (tmpl->chroma_format == PIPE_VIDEO_CHROMA_FORMAT_420) {
templ->width0 /= 2;
diff --git a/src/gallium/include/pipe/p_video_codec.h
b/src/gallium/include/pipe/p_video_codec.h
index 196d00b..dbfffd9 100644
--- a/src/gallium/include/pipe/p_video_codec.h
+++ b/src/gallium/include/pipe/p_video_codec.h
@@ -125,6 +125,7 @@ struct pipe_video_buffer
enum pipe_video_chroma_format chroma_format;
unsigned width;
unsigned height;
+ bool disable_tiling;
bool interlaced;
/**
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/state_trackers/va/surface.c
index c052c8f..f7043ad 100644
--- a/src/gallium/state_trackers/va/surface.c
+++ b/src/gallium/state_trackers/va/surface.c
@@ -616,6 +616,11 @@ vlVaCreateSurfaces2(VADriverContextP ctx, unsigned int
format,
switch (memory_type) {
case VA_SURFACE_ATTRIB_MEM_TYPE_VA:
+ /* The application will clear the TILING flag when the surface is
+ * intended to be exported as dmabuf. */
+ templat.disable_tiling = memory_attibute &&
+!(memory_attibute->flags & VA_SURFACE_EXTBUF_DESC_ENABLE_TILING);
+
surf->buffer = drv->pipe->create_video_buffer(drv->pipe, &templat);
if (!surf->buffer) {
FREE(surf);
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v3 1/1] i965: Do not overwrite optimizer dumps
When using INTEL_DEBUG=optimizer, each optimizing step is dump to disk,
in a separate file.
But as fs_visitor::optimize() and vec4_visitor::run() are called more
than once, it ends up overwriting the files already on disk, loosing
then previous optimizer steps.
To avoid this, add a new static variable that tracks the global
iteration across the entire life of the program running.
v2: use atomic_inc() for the static variable (Jason).
v3: define local variable as const (Jason).
Signed-off-by: Juan A. Suarez Romero
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
src/mesa/drivers/dri/i965/brw_vec4.cpp | 13 -
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 7904f4d..eee9e1d 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -39,6 +39,7 @@
#include "brw_program.h"
#include "brw_dead_control_flow.h"
#include "glsl/nir/glsl_types.h"
+#include "util/u_atomic.h"
using namespace brw;
@@ -4948,6 +4949,9 @@ fs_visitor::calculate_register_pressure()
void
fs_visitor::optimize()
{
+ static int global_iteration_atomic = 0;
+ const int global_iteration = p_atomic_inc_return(&global_iteration_atomic);
+
/* Start by validating the shader we currently have. */
validate();
@@ -4978,8 +4982,9 @@ fs_visitor::optimize()
\
if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && this_progress) { \
char filename[64]; \
- snprintf(filename, 64, "%s%d-%s-%02d-%02d-" #pass, \
- stage_abbrev, dispatch_width, nir->info.name, iteration,
pass_num); \
+ snprintf(filename, 64, "%s%d-%s-%02d-%02d-%02d-" #pass,\
+ stage_abbrev, dispatch_width, nir->info.name, \
+ global_iteration, iteration, pass_num); \
\
backend_shader::dump_instructions(filename); \
} \
@@ -4992,8 +4997,8 @@ fs_visitor::optimize()
if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
char filename[64];
- snprintf(filename, 64, "%s%d-%s-00-start",
- stage_abbrev, dispatch_width, nir->info.name);
+ snprintf(filename, 64, "%s%d-%s-%02d-00-00-start",
+ stage_abbrev, dispatch_width, nir->info.name, global_iteration);
backend_shader::dump_instructions(filename);
}
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index 9a79d67..7909f1d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -29,6 +29,7 @@
#include "brw_vec4_live_variables.h"
#include "brw_dead_control_flow.h"
#include "program/prog_parameter.h"
+#include "util/u_atomic.h"
#define MAX_INSTRUCTION (1 << 30)
@@ -1779,6 +1780,9 @@ vec4_visitor::convert_to_hw_regs()
bool
vec4_visitor::run()
{
+ static int global_iteration_atomic = 0;
+ const int global_iteration = p_atomic_inc_return(&global_iteration_atomic);
+
if (shader_time_index >= 0)
emit_shader_time_begin();
@@ -1812,8 +1816,8 @@ vec4_visitor::run()
\
if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && this_progress) { \
char filename[64];\
- snprintf(filename, 64, "%s-%s-%02d-%02d-" #pass, \
- stage_abbrev, nir->info.name, iteration, pass_num); \
+ snprintf(filename, 64, "%s-%s-%02d-%02d-%02d-" #pass, \
+ stage_abbrev, nir->info.name, global_iteration, iteration,
pass_num); \
\
backend_shader::dump_instructions(filename); \
}\
@@ -1822,11 +1826,10 @@ vec4_visitor::run()
this_progress; \
})
-
if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
char filename[64];
- snprintf(filename, 64, "%s-%s-00-start",
- stage_abbrev, nir->info.name);
+ snprintf(filename, 64, "%s-%s-%02d-00-00-start",
+ stage_abbrev, nir->info.name, global_iteration);
backend_shader::dump_instructions(filename);
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glsl/dead_builin_varyings: Fix gl_FragData array lowering
The current implementation looks for array dereferences on gl_FragData and
immediately then proceeds to lower them, however this is not enough because
we can have array access on vector variables too, like in this code:
out vec4 color;
void main()
{
int i;
for (i = 0; i < 4; i++)
color[i] = 1.0;
}
Fix it by making sure that the actual variable being dereferenced is an array.
Fixes a crash in:
spec/arb_gpu_shader_fp64/execution/built-in-functions/fs-ldexp-dvec4.shader_test
---
src/glsl/opt_dead_builtin_varyings.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/opt_dead_builtin_varyings.cpp
b/src/glsl/opt_dead_builtin_varyings.cpp
index 68b70ee..5387113 100644
--- a/src/glsl/opt_dead_builtin_varyings.cpp
+++ b/src/glsl/opt_dead_builtin_varyings.cpp
@@ -85,7 +85,7 @@ public:
{
ir_variable *var = ir->variable_referenced();
- if (!var || var->data.mode != this->mode)
+ if (!var || var->data.mode != this->mode || !var->type->is_array())
return visit_continue;
if (this->find_frag_outputs && var->data.location == FRAG_RESULT_DATA0) {
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 23/24] i965/vec4: Replace src_reg(imm) constructors with brw_imm_*().
On 26 November 2015 at 22:09, Matt Turner wrote: > On Thu, Nov 26, 2015 at 9:22 AM, Emil Velikov > wrote: >> On 25 November 2015 at 22:48, Matt Turner wrote: >> >>> I can't see it, but that might be because I can't stop thinking like I >>> was when I wrote the code. >>> >> Understandable, we've all been there. >> >>> Yeah, we skip any instruction that has a full writemask -- because if >>> it has a full writemask, we can just load the immediate as-is and we >>> don't need to turn it into 4x restricted floats. But that doesn't seem >>> to be related to the warning. >>> >>> The code seems fine to me. Here's what I see: >>> >>> We start with remaining_channels = WRITEMASK_XYZW. >> Actually we start with WRITEMASK_NONE (0). Based on your knowledge you >> can establish that on the first iteration(?) remaining_channels will >> be set to WRITEMASK_XYZW, although the compiler cannot determine that. >> >>> We initialize an >>> element of imm[] for each enabled bit of inst->dst.writemask, and then >>> we disable those bits from remaining_channels. >> If all channels are set we bail out just before that. Thus as we hit >> the imm[x] assignments of at least one channel is not set. Be that >> left uninitialized or storing data from a previous instruction. I take >> that this is by design ? >> >>> When remaining_channels >>> is zero (should be if and only if all elements of imm[] are >>> initialized), we read imm[]. >>> >> Barring your existing knowledge, remaining_channels can be zero on the >> first, second, N'th iteration, albeit extremely unlikely. Thus >> regardless of what data we have in imm[], we'll proceed to use it. >> >>> Do you see anything wrong or anything I've missed? >>> >>> FWIW, Clang does not warn about this and doesn't warn if I remove the >>> useless initializations of remaining_channels = 0 and inst_count = 0. >>> I think this is gcc and Coverity just being stupid. >> I think the whole things is that you know who it will run, whereas the >> code makes is a bit ambiguous. >> >> To fix (?) and make things a lot more obvious I'd suggest initializing >> (upon declaration) remaining_channels with WRITEMASK_XYZW. If >> gcc/coverity/other complains with that in place then it's definitely a >> defect on their end. > > The initialization of remaining_writemask is *dead* -- the first block > inside the for loop initializes it upon seeing the first instruction. True, although I was suggesting that this is not apparent to the compiler. > Initializing it to WRITEMASK_XYZW doesn't fix the warning in any case. > Any objections if we either change the it to WRITEMASK_XYZW or just nuke the initialization all together ? Guessing that you're leaning towards the latter. >> Out of curiosity: what is the input from gcc devs, do you have the bug >> number handy ? > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68548 > > They think it's a deficiency in gcc. Nice I'll keep an eye how this progress Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: remove len argument from _mesa_shader_debug()
There was only a single user which was using strlen(buf).
As this function is not user facing (i.e. we don't need to feed back
original length via a callback), we can simplify things.
Cc: Timothy Arceri
Suggested-by: Timothy Arceri
Signed-off-by: Emil Velikov
---
src/glsl/glsl_parser_extras.cpp | 2 +-
src/glsl/standalone_scaffolding.cpp | 2 +-
src/glsl/standalone_scaffolding.h | 2 +-
src/mesa/main/errors.c | 11 +--
src/mesa/main/errors.h | 2 +-
5 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 7138925..29cf0c6 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -477,7 +477,7 @@ _mesa_glsl_msg(const YYLTYPE *locp, _mesa_glsl_parse_state
*state,
struct gl_context *ctx = state->ctx;
/* Report the error via GL_ARB_debug_output. */
- _mesa_shader_debug(ctx, type, &msg_id, msg, strlen(msg));
+ _mesa_shader_debug(ctx, type, &msg_id, msg);
ralloc_strcat(&state->info_log, "\n");
}
diff --git a/src/glsl/standalone_scaffolding.cpp
b/src/glsl/standalone_scaffolding.cpp
index f3e34c6..1f69d0d 100644
--- a/src/glsl/standalone_scaffolding.cpp
+++ b/src/glsl/standalone_scaffolding.cpp
@@ -63,7 +63,7 @@ _mesa_reference_shader(struct gl_context *ctx, struct
gl_shader **ptr,
void
_mesa_shader_debug(struct gl_context *, GLenum, GLuint *,
- const char *, int)
+ const char *)
{
}
diff --git a/src/glsl/standalone_scaffolding.h
b/src/glsl/standalone_scaffolding.h
index a9ca5e4..f853a18 100644
--- a/src/glsl/standalone_scaffolding.h
+++ b/src/glsl/standalone_scaffolding.h
@@ -52,7 +52,7 @@ _mesa_clear_shader_program_data(struct gl_shader_program *);
extern "C" void
_mesa_shader_debug(struct gl_context *ctx, GLenum type, GLuint *id,
- const char *msg, int len);
+ const char *msg);
static inline gl_shader_stage
_mesa_shader_enum_to_shader_stage(GLenum v)
diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
index 366b119..85e5bbd 100644
--- a/src/mesa/main/errors.c
+++ b/src/mesa/main/errors.c
@@ -1599,20 +1599,19 @@ _mesa_log(const char *fmtString, ...)
* \param ctx GL context.
* \param type The namespace to which this message belongs.
* \param id The message ID within the given namespace.
- * \param msg The message to output. Need not be null-terminated.
- * \param len The length of 'msg'. If negative, 'msg' must be null-terminated.
+ * \param msg The message to output. Must be null-terminated.
*/
void
-_mesa_shader_debug( struct gl_context *ctx, GLenum type, GLuint *id,
-const char *msg, int len )
+_mesa_shader_debug(struct gl_context *ctx, GLenum type, GLuint *id,
+ const char *msg)
{
enum mesa_debug_source source = MESA_DEBUG_SOURCE_SHADER_COMPILER;
enum mesa_debug_severity severity = MESA_DEBUG_SEVERITY_HIGH;
+ int len;
debug_get_id(id);
- if (len < 0)
- len = strlen(msg);
+ len = strlen(msg);
/* Truncate the message if necessary. */
if (len >= MAX_DEBUG_MESSAGE_LENGTH)
diff --git a/src/mesa/main/errors.h b/src/mesa/main/errors.h
index 81e47a8..f291976 100644
--- a/src/mesa/main/errors.h
+++ b/src/mesa/main/errors.h
@@ -115,7 +115,7 @@ _mesa_get_debug_state_ptr(struct gl_context *ctx, GLenum
pname);
extern void
_mesa_shader_debug(struct gl_context *ctx, GLenum type, GLuint *id,
- const char *msg, int len);
+ const char *msg);
void GLAPIENTRY
_mesa_DebugMessageInsert(GLenum source, GLenum type, GLuint id,
--
2.6.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93114] No water rendered in CoR
https://bugs.freedesktop.org/show_bug.cgi?id=93114 --- Comment #8 from smidjar2@email.cz --- Wine without nice renders the water correctly too. I am going to try apitrace. If I understand it right, you want me to use apitrace and run the game with mesa, then switch to fglrx and run the trace recording there? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/program: remove empty function declaration
On 25 November 2015 at 20:18, Matt Turner wrote: > On Wed, Nov 25, 2015 at 12:17 PM, Emil Velikov > wrote: >> From: Emil Velikov >> >> Unused since >> >> 5e9aa9926b9 (2011) - _mesa_ir_compile_shader >> 69e07bdeb42 (2009) - _mesa_get_program_register > > I was confused because this second commit didn't have anything to do > with _mesa_ir_compile_shader, and then I realized that we're removing > two different prototypes. Make 'declaration' plural in the commit > title, and change s/empty/dead/ -- they're not empty, they're dead. > Must have been over the moon when I wrote that. Thanks I'll fix them up. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 0/6] Enable GL_OES_geometry_shader for OpenGL ES 3.1
After I was able to remove the ARB_geometry_shader4 extension I have now rebased my OES_geometry_shader patches. In order to avoid confusion I send V2 for all patches, i.e. all of my old OES_geometry_shader patches are now obsolete. The patches are available here: https://github.com/MartaLo/mesa/tree/gl_oes_geometry_shader_v2 Changes for V2: gles2: Update gl2ext.h to revision: 32902: Updated to the latest gl2ext.h glapi: add GL_OES_geometry_shader extension: After comments from Ilia I squashed my previous, http://patchwork.freedesktop.org/patch/60228/ and http://patchwork.freedesktop.org/patch/60225/ patches. glsl: add support for GL_OES_geometry_shader: After comments from Ilia, added support for glsl version 3.2 mesa: enable enums for OES_geometry_shader: This needed some work after the ARB_geometry_shader4 was removed. After a comment from Ilia, I moved all OES_geometry_shader enums to GL_CORE and GLES31. I created new EXTRA_EXT for enums that OES_geometry_shader has in common with ARB_shader_storage_buffer_object, ARB_gpu_shader5 and ARB_viewport_array. In my previous patch for the ARB_viewport_array enum LAYER_PROVOKING_VERTEX, I added an extra that checked ARB_viewport_array or OES_geometry_shader. But since ARB_viewport array requires EXT_geometry_shader4, I believe it is better to check if some version of geometry shader is available. The dependency for ARB_viewport_array on geometry shader should be fixed in a another patch. Also, we may need to discuss if the full ARB_viewport_array should be exposed under GLES 3.1. I also renamed the GS4 EXTRA_EXT stuff to only GS. I should have done that when I removed the ARB_geometry_shader4 the rest of the changes are simple rebases. Marta Lofstedt (6): gles2: Update gl2ext.h to revision: 32120 glapi: add GL_OES_geometry_shader extension glsl: add support for GL_OES_geometry_shader mesa: enable enums for OES_geometry_shader mesa: Update _mesa_has_geometry_shaders doc: Set GL_OES_geometry_shader as started docs/GL3.txt| 2 +- include/GLES2/gl2ext.h | 940 +++- src/glsl/builtin_variables.cpp | 17 +- src/glsl/glsl_parser.yy | 4 +- src/glsl/glsl_parser_extras.cpp | 1 + src/glsl/glsl_parser_extras.h | 2 + src/mapi/glapi/gen/apiexec.py | 2 +- src/mapi/glapi/gen/es_EXT.xml | 43 ++ src/mesa/main/context.h | 3 +- src/mesa/main/extensions_table.h| 1 + src/mesa/main/get.c | 58 +- src/mesa/main/get_hash_params.py| 50 +- src/mesa/main/mtypes.h | 1 + src/mesa/main/tests/dispatch_sanity.cpp | 3 + 14 files changed, 1076 insertions(+), 51 deletions(-) -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 5/6] mesa: Update _mesa_has_geometry_shaders
From: Marta Lofstedt
Updates the _mesa_has_geometry_shaders function to also look
for OpenGL ES 3.1 contexts that has OES_geometry_shader enabled.
---
src/mesa/main/context.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
index 8b64f45..23b2718 100644
--- a/src/mesa/main/context.h
+++ b/src/mesa/main/context.h
@@ -330,7 +330,8 @@ _mesa_is_gles31(const struct gl_context *ctx)
static inline bool
_mesa_has_geometry_shaders(const struct gl_context *ctx)
{
- return _mesa_is_desktop_gl(ctx) && ctx->Version >= 32;
+ return (_mesa_is_gles31(ctx) && ctx->Extensions.OES_geometry_shader) ||
+ (_mesa_is_desktop_gl(ctx) && ctx->Version >= 32);
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/6] gles2: Update gl2ext.h to revision: 32120
From: Marta Lofstedt
This is needed to be able to implement the accepted OES
extensions.
Signed-off-by: Marta Lofstedt
---
include/GLES2/gl2ext.h | 940 -
1 file changed, 934 insertions(+), 6 deletions(-)
diff --git a/include/GLES2/gl2ext.h b/include/GLES2/gl2ext.h
index 2b67c6e..2d05596 100644
--- a/include/GLES2/gl2ext.h
+++ b/include/GLES2/gl2ext.h
@@ -6,7 +6,7 @@ extern "C" {
#endif
/*
-** Copyright (c) 2013-2014 The Khronos Group Inc.
+** Copyright (c) 2013-2015 The Khronos Group Inc.
**
** Permission is hereby granted, free of charge, to any person obtaining a
** copy of this software and/or associated documentation files (the
@@ -33,14 +33,14 @@ extern "C" {
** used to make the header, and the header can be found at
** http://www.opengl.org/registry/
**
-** Khronos $Revision: 28335 $ on $Date: 2014-09-26 18:55:45 -0700 (Fri, 26 Sep
2014) $
+** Khronos $Revision: 32120 $ on $Date: 2015-10-15 04:27:13 -0700 (Thu, 15 Oct
2015) $
*/
#ifndef GL_APIENTRYP
#define GL_APIENTRYP GL_APIENTRY*
#endif
-/* Generated on date 20140926 */
+/* Generated on date 20151015 */
/* Generated C header for:
* API: gles2
@@ -117,6 +117,7 @@ typedef void (GL_APIENTRY *GLDEBUGPROCKHR)(GLenum
source,GLenum type,GLuint id,
#define GL_PROGRAM_KHR0x82E2
#define GL_VERTEX_ARRAY_KHR 0x8074
#define GL_QUERY_KHR 0x82E3
+#define GL_PROGRAM_PIPELINE_KHR 0x82E4
#define GL_SAMPLER_KHR0x82E6
#define GL_MAX_LABEL_LENGTH_KHR 0x82E8
#define GL_MAX_DEBUG_MESSAGE_LENGTH_KHR 0x9143
@@ -155,6 +156,11 @@ GL_APICALL void GL_APIENTRY glGetPointervKHR (GLenum
pname, void **params);
#endif
#endif /* GL_KHR_debug */
+#ifndef GL_KHR_no_error
+#define GL_KHR_no_error 1
+#define GL_CONTEXT_FLAG_NO_ERROR_BIT_KHR 0x0008
+#endif /* GL_KHR_no_error */
+
#ifndef GL_KHR_robust_buffer_access_behavior
#define GL_KHR_robust_buffer_access_behavior 1
#endif /* GL_KHR_robust_buffer_access_behavior */
@@ -219,6 +225,10 @@ GL_APICALL void GL_APIENTRY glGetnUniformuivKHR (GLuint
program, GLint location,
#define GL_KHR_texture_compression_astc_ldr 1
#endif /* GL_KHR_texture_compression_astc_ldr */
+#ifndef GL_KHR_texture_compression_astc_sliced_3d
+#define GL_KHR_texture_compression_astc_sliced_3d 1
+#endif /* GL_KHR_texture_compression_astc_sliced_3d */
+
#ifndef GL_OES_EGL_image
#define GL_OES_EGL_image 1
typedef void *GLeglImageOES;
@@ -238,6 +248,10 @@ GL_APICALL void GL_APIENTRY
glEGLImageTargetRenderbufferStorageOES (GLenum targe
#define GL_SAMPLER_EXTERNAL_OES 0x8D66
#endif /* GL_OES_EGL_image_external */
+#ifndef GL_OES_EGL_image_external_essl3
+#define GL_OES_EGL_image_external_essl3 1
+#endif /* GL_OES_EGL_image_external_essl3 */
+
#ifndef GL_OES_compressed_ETC1_RGB8_sub_texture
#define GL_OES_compressed_ETC1_RGB8_sub_texture 1
#endif /* GL_OES_compressed_ETC1_RGB8_sub_texture */
@@ -261,6 +275,14 @@ GL_APICALL void GL_APIENTRY
glEGLImageTargetRenderbufferStorageOES (GLenum targe
#define GL_PALETTE8_RGB5_A1_OES 0x8B99
#endif /* GL_OES_compressed_paletted_texture */
+#ifndef GL_OES_copy_image
+#define GL_OES_copy_image 1
+typedef void (GL_APIENTRYP PFNGLCOPYIMAGESUBDATAOESPROC) (GLuint srcName,
GLenum srcTarget, GLint srcLevel, GLint srcX, GLint srcY, GLint srcZ, GLuint
dstName, GLenum dstTarget, GLint dstLevel, GLint dstX, GLint dstY, GLint dstZ,
GLsizei srcWidth, GLsizei srcHeight, GLsizei srcDepth);
+#ifdef GL_GLEXT_PROTOTYPES
+GL_APICALL void GL_APIENTRY glCopyImageSubDataOES (GLuint srcName, GLenum
srcTarget, GLint srcLevel, GLint srcX, GLint srcY, GLint srcZ, GLuint dstName,
GLenum dstTarget, GLint dstLevel, GLint dstX, GLint dstY, GLint dstZ, GLsizei
srcWidth, GLsizei srcHeight, GLsizei srcDepth);
+#endif
+#endif /* GL_OES_copy_image */
+
#ifndef GL_OES_depth24
#define GL_OES_depth24 1
#define GL_DEPTH_COMPONENT24_OES 0x81A6
@@ -275,6 +297,44 @@ GL_APICALL void GL_APIENTRY
glEGLImageTargetRenderbufferStorageOES (GLenum targe
#define GL_OES_depth_texture 1
#endif /* GL_OES_depth_texture */
+#ifndef GL_OES_draw_buffers_indexed
+#define GL_OES_draw_buffers_indexed 1
+#define GL_MIN0x8007
+#define GL_MAX0x8008
+typedef void (GL_APIENTRYP PFNGLENABLEIOESPROC) (GLenum target, GLuint index);
+typedef void (GL_APIENTRYP PFNGLDISABLEIOESPROC) (GLenum target, GLuint index);
+typedef void (GL_APIENTRYP PFNGLBLENDEQUATIONIOESPROC) (GLuint buf, GLenum
mode);
+typedef void (GL_APIENTRYP PFNGLBLENDEQUATIONSEPARATEIOESPROC) (GLuint buf,
GLenum modeRGB, GLenum modeAlpha);
+typedef void (GL_APIENTRYP PFNGLBLENDFUNCIOESPROC) (GLuint buf, GLenum src,
GLenum dst);
+typedef void (GL_APIENTRYP PFNGLBLENDFUNCSEPARATEIOESPROC) (GLuint buf, GLenum
srcRGB, GLenum dstRGB, GLenum srcAlpha, GLenum dstAlpha);
+typedef void (GL_APIENTRYP PFNGLCOLORMASKIOESPROC) (GLuint
[Mesa-dev] [PATCH v2 6/6] doc: Set GL_OES_geometry_shader as started
From: Marta Lofstedt Signed-off-by: Marta Lofstedt Reviewed-by: Eduardo Lima Mitev --- docs/GL3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index acf1166..45da51a 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -244,7 +244,7 @@ GLES3.2, GLSL ES 3.2 GL_OES_copy_imagenot started (based on GL_ARB_copy_image, which is done for some drivers) GL_OES_draw_buffers_indexed not started GL_OES_draw_elements_base_vertex DONE (all drivers) - GL_OES_geometry_shader not started (based on GL_ARB_geometry_shader4, which is done for all drivers) + GL_OES_geometry_shader started (Marta) GL_OES_gpu_shader5 not started (based on parts of GL_ARB_gpu_shader5, which is done for some drivers) GL_OES_primitive_bounding boxnot started GL_OES_sample_shadingnot started (based on parts of GL_ARB_sample_shading, which is done for some drivers) -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 2/6] glapi: add GL_OES_geometry_shader extension
From: Marta Lofstedt
Add xml definitions for the GL_OES_geometry_shader extension
and expose the extension for OpenGL ES 3.1.
Signed-off-by: Marta Lofstedt
---
src/mapi/glapi/gen/apiexec.py | 2 +-
src/mapi/glapi/gen/es_EXT.xml | 43 +
src/mesa/main/extensions_table.h| 1 +
src/mesa/main/mtypes.h | 1 +
src/mesa/main/tests/dispatch_sanity.cpp | 3 +++
5 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/gen/apiexec.py
index 58ec08b..fa046fa 100644
--- a/src/mapi/glapi/gen/apiexec.py
+++ b/src/mapi/glapi/gen/apiexec.py
@@ -72,7 +72,7 @@ functions = {
# OpenGL 3.2 / GL_ARB_geometry_shader4. Mesa does not support
# GL_ARB_geometry_shader4, so OpenGL 3.2 is required.
-"FramebufferTexture": exec_info(core=32),
+"FramebufferTexture": exec_info(core=32, es2=31),
# OpenGL 4.0 / GL_ARB_shader_subroutines. Mesa only exposes this
# extension with core profile.
diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
index 577d825..f6c49c2 100644
--- a/src/mapi/glapi/gen/es_EXT.xml
+++ b/src/mapi/glapi/gen/es_EXT.xml
@@ -940,4 +940,47 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/src/mesa/main/extensions_table.h b/src/mesa/main/extensions_table.h
index 051d69a..d3cbb25 100644
--- a/src/mesa/main/extensions_table.h
+++ b/src/mesa/main/extensions_table.h
@@ -307,6 +307,7 @@ EXT(OES_element_index_uint , dummy_true
EXT(OES_fbo_render_mipmap , dummy_true
, x , x , ES1, ES2, 2005)
EXT(OES_fixed_point , dummy_true
, x , x , ES1, x , 2002)
EXT(OES_framebuffer_object , dummy_true
, x , x , ES1, x , 2005)
+EXT(OES_geometry_shader , dummy_true
, x , x , x , 31, 2015)
EXT(OES_get_program_binary , dummy_true
, x , x , x , ES2, 2008)
EXT(OES_mapbuffer , dummy_true
, x , x , ES1, ES2, 2005)
EXT(OES_packed_depth_stencil, dummy_true
, x , x , ES1, ES2, 2007)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index c1b18a4..bff355e 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -3818,6 +3818,7 @@ struct gl_extensions
GLboolean OES_texture_half_float;
GLboolean OES_texture_half_float_linear;
GLboolean OES_compressed_ETC1_RGB8_texture;
+ GLboolean OES_geometry_shader;
GLboolean extension_sentinel;
/** The extension string */
const GLubyte *String;
diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
b/src/mesa/main/tests/dispatch_sanity.cpp
index 97f81f9..b5b8c8b 100644
--- a/src/mesa/main/tests/dispatch_sanity.cpp
+++ b/src/mesa/main/tests/dispatch_sanity.cpp
@@ -2517,5 +2517,8 @@ const struct function gles31_functions_possible[] = {
/* GL_EXT_blend_func_extended */
{ "glGetProgramResourceLocationIndexEXT", 31, -1 },
+ /*GL_OES_geometry_shader*/
+ { "glFramebufferTextureOES", 31, -1},
+
{ NULL, 0, -1 },
};
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 4/6] mesa: enable enums for OES_geometry_shader
From: Marta Lofstedt
Enable GL_OES_geometry_shader enums for OpenGL ES 3.1.
Signed-off-by: Marta Lofstedt
---
src/mesa/main/get.c | 58 +---
src/mesa/main/get_hash_params.py | 50 +-
2 files changed, 80 insertions(+), 28 deletions(-)
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index c6a2e5b..3770fba 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -147,11 +147,14 @@ enum value_extra {
EXTRA_VALID_CLIP_DISTANCE,
EXTRA_FLUSH_CURRENT,
EXTRA_GLSL_130,
- EXTRA_EXT_UBO_GS4,
- EXTRA_EXT_ATOMICS_GS4,
- EXTRA_EXT_SHADER_IMAGE_GS4,
+ EXTRA_EXT_UBO_GS,
+ EXTRA_EXT_ATOMICS_GS,
+ EXTRA_EXT_SHADER_IMAGE_GS,
EXTRA_EXT_ATOMICS_TESS,
EXTRA_EXT_SHADER_IMAGE_TESS,
+ EXTRA_EXT_SSBO_GS,
+ EXTRA_EXT_GPU5_GS,
+ EXTRA_EXT_VIEWPORT_GS,
};
#define NO_EXTRA NULL
@@ -308,7 +311,7 @@ static const int extra_ARB_transform_feedback2_api_es3[] = {
};
static const int extra_ARB_uniform_buffer_object_and_geometry_shader[] = {
- EXTRA_EXT_UBO_GS4,
+ EXTRA_EXT_UBO_GS,
EXTRA_END
};
@@ -343,12 +346,12 @@ static const int extra_EXT_texture_array_es3[] = {
};
static const int extra_ARB_shader_atomic_counters_and_geometry_shader[] = {
- EXTRA_EXT_ATOMICS_GS4,
+ EXTRA_EXT_ATOMICS_GS,
EXTRA_END
};
static const int extra_ARB_shader_image_load_store_and_geometry_shader[] = {
- EXTRA_EXT_SHADER_IMAGE_GS4,
+ EXTRA_EXT_SHADER_IMAGE_GS,
EXTRA_END
};
@@ -375,6 +378,21 @@ static const int
extra_ARB_shader_storage_buffer_object_es31[] = {
EXTRA_END
};
+static const int extra_ARB_gpu_shader5_and_geometry_shader[] = {
+ EXTRA_EXT_GPU5_GS,
+ EXTRA_END
+};
+
+static const int extra_ARB_shader_storage_buffer_object_and_geometry_shader[]
= {
+ EXTRA_EXT_SSBO_GS,
+ EXTRA_END
+};
+
+static const int extra_ARB_viewport_array_and_geometry_shader[] = {
+ EXTRA_EXT_VIEWPORT_GS,
+ EXTRA_END
+};
+
EXTRA_EXT(ARB_texture_cube_map);
EXTRA_EXT(EXT_texture_array);
EXTRA_EXT(NV_fog_distance);
@@ -423,6 +441,7 @@ EXTRA_EXT(ARB_framebuffer_no_attachments);
EXTRA_EXT(ARB_tessellation_shader);
EXTRA_EXT(ARB_shader_subroutine);
EXTRA_EXT(ARB_shader_storage_buffer_object);
+EXTRA_EXT(OES_geometry_shader);
static const int
extra_ARB_color_buffer_float_or_glcore[] = {
@@ -454,6 +473,12 @@ static const int extra_gl32_es3[] = {
EXTRA_END,
};
+static const int extra_version_32_OES_geometry_shader[] = {
+EXTRA_VERSION_32,
+EXT(OES_geometry_shader),
+EXTRA_END
+};
+
static const int extra_gl40_ARB_sample_shading[] = {
EXTRA_VERSION_40,
EXT(ARB_sample_shading),
@@ -1149,17 +1174,17 @@ check_extra(struct gl_context *ctx, const char *func,
const struct value_desc *d
if (ctx->Const.GLSLVersion >= 130)
api_found = GL_TRUE;
break;
- case EXTRA_EXT_UBO_GS4:
+ case EXTRA_EXT_UBO_GS:
api_check = GL_TRUE;
api_found = (ctx->Extensions.ARB_uniform_buffer_object &&
_mesa_has_geometry_shaders(ctx));
break;
- case EXTRA_EXT_ATOMICS_GS4:
+ case EXTRA_EXT_ATOMICS_GS:
api_check = GL_TRUE;
api_found = (ctx->Extensions.ARB_shader_atomic_counters &&
_mesa_has_geometry_shaders(ctx));
break;
- case EXTRA_EXT_SHADER_IMAGE_GS4:
+ case EXTRA_EXT_SHADER_IMAGE_GS:
api_check = GL_TRUE;
api_found = (ctx->Extensions.ARB_shader_image_load_store &&
_mesa_has_geometry_shaders(ctx));
@@ -1174,6 +1199,21 @@ check_extra(struct gl_context *ctx, const char *func,
const struct value_desc *d
api_found = ctx->Extensions.ARB_shader_image_load_store &&
_mesa_has_tessellation(ctx);
break;
+ case EXTRA_EXT_GPU5_GS:
+ api_check = GL_TRUE;
+ api_found = (ctx->Extensions.ARB_framebuffer_no_attachments &&
+ _mesa_has_geometry_shaders(ctx));
+ break;
+ case EXTRA_EXT_SSBO_GS:
+ api_check = GL_TRUE;
+ api_found = (ctx->Extensions.ARB_shader_storage_buffer_object &&
+ _mesa_has_geometry_shaders(ctx));
+ break;
+ case EXTRA_EXT_VIEWPORT_GS:
+ api_check = GL_TRUE;
+ api_found = (ctx->Extensions.ARB_viewport_array &&
+ _mesa_has_geometry_shaders(ctx));
+ break;
case EXTRA_END:
break;
default: /* *e is a offset into the extension struct */
diff --git a/src/mesa/main/get_hash_params.py b/src/mesa/main/get_hash_params.py
index 0c58b30..2b90fa1 100644
--- a/src/mesa/main/get_hash_params.py
+++ b/src/mesa/main/get_hash_params.py
@@ -499,6 +499,37 @@ descriptor=[
{ "apis": ["GL_CORE", "GLES31"], "params": [
# GL_ARB_draw_indirect / GLES 3.1
[ "DRAW_INDIRECT_BUFFER_BINDING", "LOC_CUSTOM, TYPE_INT, 0,
extra_ARB_draw_indirect" ],
+
+# GL 3.2 / GL OES_geometry_shader
+ [ "MAX_G
[Mesa-dev] [PATCH v2 3/6] glsl: add support for GL_OES_geometry_shader
From: Marta Lofstedt
This adds glsl support of GL_OES_geometry_shader for
OpenGL ES 3.1.
Signed-off-by: Marta Lofstedt
---
src/glsl/builtin_variables.cpp | 17 +
src/glsl/glsl_parser.yy | 4 ++--
src/glsl/glsl_parser_extras.cpp | 1 +
src/glsl/glsl_parser_extras.h | 2 ++
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
index e8eab80..6a53789 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -667,7 +667,7 @@ builtin_variable_generator::generate_constants()
add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying * 4);
}
- if (state->is_version(150, 0)) {
+ if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
add_const("gl_MaxVertexOutputComponents",
state->Const.MaxVertexOutputComponents);
add_const("gl_MaxGeometryInputComponents",
@@ -729,11 +729,7 @@ builtin_variable_generator::generate_constants()
state->Const.MaxCombinedAtomicCounters);
add_const("gl_MaxAtomicCounterBindings",
state->Const.MaxAtomicBufferBindings);
-
- /* When Mesa adds support for GL_OES_geometry_shader and
- * GL_OES_tessellation_shader, this will need to change.
- */
- if (!state->es_shader) {
+ if (!state->es_shader || state->OES_geometry_shader_enable) {
add_const("gl_MaxGeometryAtomicCounters",
state->Const.MaxGeometryAtomicCounters);
add_const("gl_MaxTessControlAtomicCounters",
@@ -753,10 +749,7 @@ builtin_variable_generator::generate_constants()
add_const("gl_MaxAtomicCounterBufferSize",
state->Const.MaxAtomicCounterBufferSize);
- /* When Mesa adds support for GL_OES_geometry_shader and
- * GL_OES_tessellation_shader, this will need to change.
- */
- if (!state->es_shader) {
+ if (!state->es_shader || state->OES_geometry_shader_enable) {
add_const("gl_MaxGeometryAtomicCounterBuffers",
state->Const.MaxGeometryAtomicCounterBuffers);
add_const("gl_MaxTessControlAtomicCounterBuffers",
@@ -814,7 +807,7 @@ builtin_variable_generator::generate_constants()
add_const("gl_MaxCombinedImageUniforms",
state->Const.MaxCombinedImageUniforms);
- if (!state->es_shader) {
+ if (!state->es_shader || state->OES_geometry_shader_enable) {
add_const("gl_MaxCombinedImageUnitsAndFragmentOutputs",
state->Const.MaxCombinedShaderOutputResources);
add_const("gl_MaxImageSamples",
@@ -1057,7 +1050,7 @@ builtin_variable_generator::generate_fs_special_vars()
if (state->is_version(120, 100))
add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
- if (state->is_version(150, 0)) {
+ if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t, "gl_PrimitiveID");
var->data.interpolation = INTERP_QUALIFIER_FLAT;
}
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 5a8f980..fae6d0b 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -1262,7 +1262,7 @@ layout_qualifier_id:
}
}
- if ($$.flags.i && !state->is_version(150, 0)) {
+ if ($$.flags.i && !state->is_version(150, 320) &&
!state->OES_geometry_shader_enable) {
_mesa_glsl_error(& @1, state, "#version 150 layout "
"qualifier `%s' used", $1);
}
@@ -1499,7 +1499,7 @@ layout_qualifier_id:
if (match_layout_qualifier("max_vertices", $1, state) == 0) {
$$.flags.q.max_vertices = 1;
$$.max_vertices = new(ctx) ast_layout_expression(@1, $3);
- if (!state->is_version(150, 0)) {
+ if (!state->is_version(150, 310)) {
_mesa_glsl_error(& @3, state,
"#version 150 max_vertices qualifier "
"specified", $3);
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 7138925..193cc2a 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -635,6 +635,7 @@ static const _mesa_glsl_extension
_mesa_glsl_supported_extensions[] = {
/* OES extensions go here, sorted alphabetically.
*/
EXT(OES_EGL_image_external, false, true,
OES_EGL_image_external),
+ EXT(OES_geometry_shader,false, true, OES_geometry_shader),
EXT(OES_standard_derivatives, false, true,
OES_standard_derivatives),
EXT(OES_texture_3D, false, true, dummy_true),
EXT(OES_texture_storage_multisample_2d_array, false, true,
ARB_texture_multisample),
diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
index 17ff0b5..deca934 100644
--- a/src/glsl/glsl_parser_extras.h
+++ b/src/glsl/glsl_pa
Re: [Mesa-dev] [PATCH 8/9] nir: move to compiler
On 25 November 2015 at 22:01, Matt Turner wrote: > On Wed, Nov 25, 2015 at 1:32 PM, Emil Velikov > wrote: >> --- a/src/Makefile.am >> +++ b/src/Makefile.am >> @@ -23,6 +23,7 @@ SUBDIRS = . gtest util mapi/glapi/gen mapi >> >> # XXX: conditionally include >> SUBDIRS += compiler >> +SUBDIRS += compiler/nir > > We have a non-recursive build in src/glsl today. I don't want to go backwards. Not sure I fully get that can you elaborate ? Are you concerned that things won't build in parallel, increasing the compilation times ? On my dual core system running with -j2 results in approx 15 seconds increase. I'm willing to take that trade off for the improved readability. What is the difference on your system ? Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 5/6] mesa: Update _mesa_has_geometry_shaders
On 27 November 2015 at 14:31, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> Updates the _mesa_has_geometry_shaders function to also look
> for OpenGL ES 3.1 contexts that has OES_geometry_shader enabled.
> ---
> src/mesa/main/context.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/main/context.h b/src/mesa/main/context.h
> index 8b64f45..23b2718 100644
> --- a/src/mesa/main/context.h
> +++ b/src/mesa/main/context.h
> @@ -330,7 +330,8 @@ _mesa_is_gles31(const struct gl_context *ctx)
> static inline bool
> _mesa_has_geometry_shaders(const struct gl_context *ctx)
> {
> - return _mesa_is_desktop_gl(ctx) && ctx->Version >= 32;
> + return (_mesa_is_gles31(ctx) && ctx->Extensions.OES_geometry_shader) ||
Please use the new _mesa_has_##name_str helpers from Nanley. They
already have the appropriate API and version check -
_mesa_has_OES_geometry_shader is what we want here.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93114] No water rendered in CoR
https://bugs.freedesktop.org/show_bug.cgi?id=93114 --- Comment #9 from Jason Ekstrand --- (In reply to smidjar2.reg from comment #8) > Wine without nice renders the water correctly too. I am going to try > apitrace. If I understand it right, you want me to use apitrace and run the > game with mesa, then switch to fglrx and run the trace recording there? Yes, that way we know the trace is rendering the water correctly and that the bug is the driver. If the trace renders no water on fglrx then it's possible that some extension being exposed on fglrx is causing the engine to take a different rendering path that doesn't render the water correctly. Since the trace is just a dumb stream of GL calls, it should render exactly on both drivers (assuming fglrx supports all the extensions the trace uses, which it probably does). If the trace renders differently on the two drivers, then it's most likely a driver bug. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/6] gles2: Update gl2ext.h to revision: 32120
On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> This is needed to be able to implement the accepted OES
> extensions.
>
> Signed-off-by: Marta Lofstedt
> ---
> include/GLES2/gl2ext.h | 940
> -
> 1 file changed, 934 insertions(+), 6 deletions(-)
>
> diff --git a/include/GLES2/gl2ext.h b/include/GLES2/gl2ext.h
> index 2b67c6e..2d05596 100644
> --- a/include/GLES2/gl2ext.h
> +++ b/include/GLES2/gl2ext.h
> @@ -6,7 +6,7 @@ extern "C" {
> #endif
>
> /*
> -** Copyright (c) 2013-2014 The Khronos Group Inc.
> +** Copyright (c) 2013-2015 The Khronos Group Inc.
> **
> ** Permission is hereby granted, free of charge, to any person obtaining a
> ** copy of this software and/or associated documentation files (the
> @@ -33,14 +33,14 @@ extern "C" {
> ** used to make the header, and the header can be found at
> ** http://www.opengl.org/registry/
> **
> -** Khronos $Revision: 28335 $ on $Date: 2014-09-26 18:55:45 -0700 (Fri, 26
> Sep 2014) $
> +** Khronos $Revision: 32120 $ on $Date: 2015-10-15 04:27:13 -0700 (Thu, 15
> Oct 2015) $
> */
What is this header used for? Do we ship it, or is it purely internal
to mesa? If we ship it, might need to cc this to stable... e.g. buffer
storage and a couple other things are in here that we expose in 11.1.
Either way,
Reviewed-by: Ilia Mirkin
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] Move nir/glsl to src/compiler
On Nov 25, 2015 1:27 PM, "Emil Velikov" wrote: > > Hello all, > > Some of us have been thinking about moving nir out of glsl, and fleshing > out some common helper (static library) that is use by both. So here it > is - src/compiler. > > The modules (libcompiler, libnir and libglsl) are unfortunately not > really independent. > - libcompiler - compile time (mesa ir, glsl ir, util), link - util > - libglsl - compile (compiler, mesa ir, util), link - compiler, util > - libnir - compile (compiler, mesa ir, glsl ir, util), link - compiler, > util Thanks for working on this! Before I make comments, its worth noting that the biggest churn is just moving files. If we don't have the linking details figured out, that shouldn't block landing the file churn. I was kind of hoping that we could have a libnir that doesn't require glsl. It would be good for freedreno and vc4 among other things. Maybe split things up differently? - libcompilerutil: just glsl_types and shader_enums - libglsl - libnir - libcompiler Neither libglsl nor libnir should depend on the other. If you want everything, you use libcompiler which would depend on both libglsl and libnir and also bring in glsl_to_nir. Would that be practical? (I don't know autotools or libtool all that well.) > With the above in mind the headers are extremely fragile. Despite that > things work fine based on my testing. > > Note: the series depends (some some trivial dependencies) on the > no-extern-c patches send yesterday. > > This lot (incl. the requirement) can be found in branch nir-glsl-move at > https://github.com/evelikov/Mesa/ > > Comments, suggestions and ack/nak of the idea and approach are > appreciated. > > Cheers, > Emil > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/9] nir: remove unneeded include
Yes, please! Reviewed-by: Jason Ekstrand On Nov 25, 2015 1:27 PM, "Emil Velikov" wrote: > From: Emil Velikov > > Signed-off-by: Emil Velikov > --- > src/glsl/nir/nir_lower_samplers.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/src/glsl/nir/nir_lower_samplers.c > b/src/glsl/nir/nir_lower_samplers.c > index 5df79a6..2aab305 100644 > --- a/src/glsl/nir/nir_lower_samplers.c > +++ b/src/glsl/nir/nir_lower_samplers.c > @@ -25,7 +25,6 @@ > > #include "nir.h" > #include "nir_builder.h" > -#include "../program.h" > #include "program/hash_table.h" > #include "ir_uniform.h" > > -- > 2.6.2 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/6] glapi: add GL_OES_geometry_shader extension
On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> Add xml definitions for the GL_OES_geometry_shader extension
> and expose the extension for OpenGL ES 3.1.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mapi/glapi/gen/apiexec.py | 2 +-
> src/mapi/glapi/gen/es_EXT.xml | 43
> +
> src/mesa/main/extensions_table.h| 1 +
> src/mesa/main/mtypes.h | 1 +
> src/mesa/main/tests/dispatch_sanity.cpp | 3 +++
> 5 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/gen/apiexec.py
> index 58ec08b..fa046fa 100644
> --- a/src/mapi/glapi/gen/apiexec.py
> +++ b/src/mapi/glapi/gen/apiexec.py
> @@ -72,7 +72,7 @@ functions = {
>
> # OpenGL 3.2 / GL_ARB_geometry_shader4. Mesa does not support
> # GL_ARB_geometry_shader4, so OpenGL 3.2 is required.
> -"FramebufferTexture": exec_info(core=32),
> +"FramebufferTexture": exec_info(core=32, es2=31),
>
> # OpenGL 4.0 / GL_ARB_shader_subroutines. Mesa only exposes this
> # extension with core profile.
> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> index 577d825..f6c49c2 100644
> --- a/src/mapi/glapi/gen/es_EXT.xml
> +++ b/src/mapi/glapi/gen/es_EXT.xml
> @@ -940,4 +940,47 @@
>
>
>
> +
> +
> +
> + value="0x8DD9"/>
> + value="0x0004"/>
> + value="0x8916"/>
> + value="0x8917"/>
> + value="0x8918"/>
> + value="0x887F"/>
> + value="0x825E"/>
> + value="0x8A2C"/>
> + value="0x8A32"/>
> + value="0x9123"/>
> + value="0x9124"/>
> + value="0x8DE0"/>
> + value="0x8DE1"/>
> + value="0x8E5A"/>
> + value="0x8C29"/>
> + value="0x92CF"/>
> + value="0x92D5"/>
> + value="0x90CD"/>
> + value="0x90D7"/>
> + value="0x8E4D"/>
> + value="0x8E4E"/>
> + value="0x8260"/>
> + value="0x8C87"/>
> + value="0xA"/>
> + value="0xB"/>
> + value="0xC"/>
> + value="0xD"/>
> + value="0x9312"/>
> + value="0x9317"/>
> + value="0x8DA8"/>
> + value="0x8DA7"/>
> + value="0x9309"/>
> +
> + es2="3.1">
> +
> +
> +
> +
> +
> +
>
> diff --git a/src/mesa/main/extensions_table.h
> b/src/mesa/main/extensions_table.h
> index 051d69a..d3cbb25 100644
> --- a/src/mesa/main/extensions_table.h
> +++ b/src/mesa/main/extensions_table.h
> @@ -307,6 +307,7 @@ EXT(OES_element_index_uint , dummy_true
> EXT(OES_fbo_render_mipmap , dummy_true
> , x , x , ES1, ES2, 2005)
> EXT(OES_fixed_point , dummy_true
> , x , x , ES1, x , 2002)
> EXT(OES_framebuffer_object , dummy_true
> , x , x , ES1, x , 2005)
> +EXT(OES_geometry_shader , dummy_true
> , x , x , x , 31, 2015)
This should surely depend on OES_geometry_shader, not dummy_true...
Not a huge fan of adding the extra entry to gl_extensions, but I don't
see a great way around it. It'll all be hidden behind
_mesa_has_geometry_shaders anyways, so it shouldn't be too bad.
> EXT(OES_get_program_binary , dummy_true
> , x , x , x , ES2, 2008)
> EXT(OES_mapbuffer , dummy_true
> , x , x , ES1, ES2, 2005)
> EXT(OES_packed_depth_stencil, dummy_true
> , x , x , ES1, ES2, 2007)
> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
> index c1b18a4..bff355e 100644
> --- a/src/mesa/main/mtypes.h
> +++ b/src/mesa/main/mtypes.h
> @@ -3818,6 +3818,7 @@ struct gl_extensions
> GLboolean OES_texture_half_float;
> GLboolean OES_texture_half_float_linear;
> GLboolean OES_compressed_ETC1_RGB8_texture;
> + GLboolean OES_geometry_shader;
> GLboolean extension_sentinel;
> /** The extension string */
> const GLubyte *String;
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index 97f81f9..b5b8c8b 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -2517,5 +2517,8 @@ const struct function gles31_functions_possible[] = {
> /* GL_EXT_blend_func_extended */
> { "glGetProgramResourceLocationIndexEXT", 31, -1 },
>
> + /*GL_OES_geometry_shader*/
Spaces please.
With the above 2 fixed, this is
Reviewed-by: Ilia Mirkin
> + { "glFramebufferTextureOES", 31, -1},
> +
> { NULL, 0, -1 },
> };
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesk
[Mesa-dev] [Bug 93114] No water rendered in CoR
https://bugs.freedesktop.org/show_bug.cgi?id=93114 --- Comment #10 from smidjar2@email.cz --- I have created the trace and I tried running it with fglrx. Result is that there is no water rendered with fglrx too. apitrace found a bug in game's FXAA shader (preprocesor directive). I have 'fixed' it, but it had no effect on this issue. I also made a trace with the fglrx driver. That can't be replayed with the opensource driver because of missing features (glNamedBufferDataEXT, GL_UNIFORM_BUFFER_EXT and more). I can provide either of the traces. They are quite large, 130ish MB for opensource and 200 for fglrx trace, compressed by xz. Where would be the best place to upload them? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] docs: Update GL3.txt to add ARB_internalformat_query2
On 11/26/2015 10:01 PM, Ilia Mirkin wrote: > On Thu, Nov 26, 2015 at 3:57 PM, Eduardo Lima Mitev wrote: >> Added to OpenGL 4.3 section, tagged as 'in progress (elima)'. See >> https://bugs.freedesktop.org/show_bug.cgi?id=92687. >> >> Thanks to Thomas H.P. Andersen for remainding me about this. >> >> v1: - Update the already existing entry in section 4.3 >> instead (Ilia Mirkin). >> - Added my BZ nickname as contact person (Felix Schwarz). >> --- >> docs/GL3.txt | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/docs/GL3.txt b/docs/GL3.txt >> index ad6b95e..acf1166 100644 >> --- a/docs/GL3.txt >> +++ b/docs/GL3.txt >> @@ -158,7 +158,7 @@ GL 4.3, GLSL 4.30: >>GL_ARB_explicit_uniform_location DONE (all drivers >> that support GLSL) >>GL_ARB_fragment_layer_viewport DONE (i965, nv50, >> nvc0, r600, radeonsi, llvmpipe) >>GL_ARB_framebuffer_no_attachmentsDONE (i965) >> - GL_ARB_internalformat_query2 not started >> + GL_ARB_internalformat_query2 in progress (elima) > > Good luck! I see lots of typing in your future :) > Thank you. Fortunately we are a team working on this so the typing is shared :P. > Reviewed-by: Ilia Mirkin > Thanks! >>GL_ARB_invalidate_subdataDONE (all drivers) >>GL_ARB_multi_draw_indirect DONE (i965, nvc0, >> r600, radeonsi, llvmpipe, softpipe) >>GL_ARB_program_interface_query DONE (all drivers) >> -- >> 2.5.3 >> > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] compiler: move the glsl_types C wrapper
On Nov 25, 2015 1:27 PM, "Emil Velikov" wrote:
>
> From: Emil Velikov
>
> ... alongside its C++ brethren. On the flip side the files are called
> nir_types.{cpp,h} just because...
It does do one NIR-specific thing: if you call glsl_get_length on a matrix,
it gives you the number of columns. This probably isn't a huge deal though.
> At some point in the future we can fold the wrappers where they should
> be and rename things appropriately. Yet current direction is to try
> and split it out of nir.
>
> Signed-off-by: Emil Velikov
> ---
> src/compiler/Makefile.sources| 2 ++
> src/{glsl/nir => compiler}/nir_types.cpp | 2 +-
> src/{glsl/nir => compiler}/nir_types.h | 3 ++-
> src/glsl/Makefile.sources| 4 +---
> src/glsl/nir/nir.h | 2 +-
> src/glsl/nir/nir_lower_var_copies.c | 2 +-
> 6 files changed, 8 insertions(+), 7 deletions(-)
> rename src/{glsl/nir => compiler}/nir_types.cpp (99%)
> rename src/{glsl/nir => compiler}/nir_types.h (98%)
>
> diff --git a/src/compiler/Makefile.sources b/src/compiler/Makefile.sources
> index 38e75cf..e1228ca 100644
> --- a/src/compiler/Makefile.sources
> +++ b/src/compiler/Makefile.sources
> @@ -2,5 +2,7 @@ LIBCOMPILER_FILES = \
> builtin_type_macros.h \
> glsl_types.cpp \
> glsl_types.h \
> + nir_types.cpp \
> + nir_types.h \
> shader_enums.c \
> shader_enums.h
> diff --git a/src/glsl/nir/nir_types.cpp b/src/compiler/nir_types.cpp
> similarity index 99%
> rename from src/glsl/nir/nir_types.cpp
> rename to src/compiler/nir_types.cpp
> index 135591a..4f89d20 100644
> --- a/src/glsl/nir/nir_types.cpp
> +++ b/src/compiler/nir_types.cpp
> @@ -25,8 +25,8 @@
> *
> */
>
> +#include "glsl/ir.h"
> #include "nir_types.h"
> -#include "ir.h"
>
> void
> glsl_print_type(const glsl_type *type, FILE *fp)
> diff --git a/src/glsl/nir/nir_types.h b/src/compiler/nir_types.h
> similarity index 98%
> rename from src/glsl/nir/nir_types.h
> rename to src/compiler/nir_types.h
> index 572cff2..b2245c2 100644
> --- a/src/glsl/nir/nir_types.h
> +++ b/src/compiler/nir_types.h
> @@ -28,10 +28,11 @@
> #pragma once
>
> #include
> +#include
>
> /* C wrapper around compiler/glsl_types.h */
>
> -#include "compiler/glsl_types.h"
> +#include "glsl_types.h"
>
> #ifdef __cplusplus
> extern "C" {
> diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
> index 80cbd76..5bf6486 100644
> --- a/src/glsl/Makefile.sources
> +++ b/src/glsl/Makefile.sources
> @@ -76,12 +76,10 @@ NIR_FILES = \
> nir/nir_split_var_copies.c \
> nir/nir_sweep.c \
> nir/nir_to_ssa.c \
> - nir/nir_types.h \
> nir/nir_validate.c \
> nir/nir_vla.h \
> nir/nir_worklist.c \
> - nir/nir_worklist.h \
> - nir/nir_types.cpp
> + nir/nir_worklist.h
>
> # libglsl
>
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index e69b3c8..7e99a7b 100644
> --- a/src/glsl/nir/nir.h
> +++ b/src/glsl/nir/nir.h
> @@ -34,7 +34,7 @@
> #include "util/ralloc.h"
> #include "util/set.h"
> #include "util/bitset.h"
> -#include "nir_types.h"
> +#include "compiler/nir_types.h"
> #include "compiler/shader_enums.h"
> #include
>
> diff --git a/src/glsl/nir/nir_lower_var_copies.c
b/src/glsl/nir/nir_lower_var_copies.c
> index 98c107a..f5a5815 100644
> --- a/src/glsl/nir/nir_lower_var_copies.c
> +++ b/src/glsl/nir/nir_lower_var_copies.c
> @@ -25,8 +25,8 @@
> *
> */
>
> +#include "compiler/nir_types.h"
> #include "nir.h"
> -#include "nir_types.h"
>
> /*
> * Lowers all copy intrinsics to sequences of load/store intrinsics.
> --
> 2.6.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/6] glsl: add support for GL_OES_geometry_shader
On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> This adds glsl support of GL_OES_geometry_shader for
> OpenGL ES 3.1.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/glsl/builtin_variables.cpp | 17 +
> src/glsl/glsl_parser.yy | 4 ++--
> src/glsl/glsl_parser_extras.cpp | 1 +
> src/glsl/glsl_parser_extras.h | 2 ++
> 4 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
> index e8eab80..6a53789 100644
> --- a/src/glsl/builtin_variables.cpp
> +++ b/src/glsl/builtin_variables.cpp
> @@ -667,7 +667,7 @@ builtin_variable_generator::generate_constants()
>add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying * 4);
> }
>
> - if (state->is_version(150, 0)) {
> + if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
>add_const("gl_MaxVertexOutputComponents",
> state->Const.MaxVertexOutputComponents);
>add_const("gl_MaxGeometryInputComponents",
> @@ -729,11 +729,7 @@ builtin_variable_generator::generate_constants()
> state->Const.MaxCombinedAtomicCounters);
>add_const("gl_MaxAtomicCounterBindings",
> state->Const.MaxAtomicBufferBindings);
> -
> - /* When Mesa adds support for GL_OES_geometry_shader and
> - * GL_OES_tessellation_shader, this will need to change.
> - */
> - if (!state->es_shader) {
> + if (!state->es_shader || state->OES_geometry_shader_enable) {
> add_const("gl_MaxGeometryAtomicCounters",
> state->Const.MaxGeometryAtomicCounters);
> add_const("gl_MaxTessControlAtomicCounters",
Do you really want to be adding this in for OES_geometry_shader?
> @@ -753,10 +749,7 @@ builtin_variable_generator::generate_constants()
>add_const("gl_MaxAtomicCounterBufferSize",
> state->Const.MaxAtomicCounterBufferSize);
>
> - /* When Mesa adds support for GL_OES_geometry_shader and
> - * GL_OES_tessellation_shader, this will need to change.
> - */
> - if (!state->es_shader) {
> + if (!state->es_shader || state->OES_geometry_shader_enable) {
> add_const("gl_MaxGeometryAtomicCounterBuffers",
> state->Const.MaxGeometryAtomicCounterBuffers);
> add_const("gl_MaxTessControlAtomicCounterBuffers",
> @@ -814,7 +807,7 @@ builtin_variable_generator::generate_constants()
>add_const("gl_MaxCombinedImageUniforms",
> state->Const.MaxCombinedImageUniforms);
>
> - if (!state->es_shader) {
> + if (!state->es_shader || state->OES_geometry_shader_enable) {
> add_const("gl_MaxCombinedImageUnitsAndFragmentOutputs",
> state->Const.MaxCombinedShaderOutputResources);
> add_const("gl_MaxImageSamples",
> @@ -1057,7 +1050,7 @@ builtin_variable_generator::generate_fs_special_vars()
> if (state->is_version(120, 100))
>add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
>
> - if (state->is_version(150, 0)) {
> + if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
>var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t, "gl_PrimitiveID");
>var->data.interpolation = INTERP_QUALIFIER_FLAT;
> }
> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
> index 5a8f980..fae6d0b 100644
> --- a/src/glsl/glsl_parser.yy
> +++ b/src/glsl/glsl_parser.yy
> @@ -1262,7 +1262,7 @@ layout_qualifier_id:
> }
> }
>
> - if ($$.flags.i && !state->is_version(150, 0)) {
> + if ($$.flags.i && !state->is_version(150, 320) &&
> !state->OES_geometry_shader_enable) {
> _mesa_glsl_error(& @1, state, "#version 150 layout "
> "qualifier `%s' used", $1);
> }
> @@ -1499,7 +1499,7 @@ layout_qualifier_id:
>if (match_layout_qualifier("max_vertices", $1, state) == 0) {
> $$.flags.q.max_vertices = 1;
> $$.max_vertices = new(ctx) ast_layout_expression(@1, $3);
> - if (!state->is_version(150, 0)) {
> + if (!state->is_version(150, 310)) {
Why is this one different? Shouldn't this also be the same as the above check?
> _mesa_glsl_error(& @3, state,
> "#version 150 max_vertices qualifier "
> "specified", $3);
> diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
> index 7138925..193cc2a 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -635,6 +635,7 @@ static const _mesa_glsl_extension
> _mesa_glsl_supported_extensions[] = {
> /* OES extensions go here, sorted alphabetically.
> */
> EXT(OES_EGL_image_external, false, true,
> OES_EGL_image_external),
> + EXT(OES_geometry_shader,false, true,
> OES_geometry_shader),
> EXT(
Re: [Mesa-dev] [PATCH v2 4/6] mesa: enable enums for OES_geometry_shader
On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> Enable GL_OES_geometry_shader enums for OpenGL ES 3.1.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mesa/main/get.c | 58
> +---
> src/mesa/main/get_hash_params.py | 50 +-
> 2 files changed, 80 insertions(+), 28 deletions(-)
>
> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
> index c6a2e5b..3770fba 100644
> --- a/src/mesa/main/get.c
> +++ b/src/mesa/main/get.c
> @@ -147,11 +147,14 @@ enum value_extra {
> EXTRA_VALID_CLIP_DISTANCE,
> EXTRA_FLUSH_CURRENT,
> EXTRA_GLSL_130,
> - EXTRA_EXT_UBO_GS4,
> - EXTRA_EXT_ATOMICS_GS4,
> - EXTRA_EXT_SHADER_IMAGE_GS4,
> + EXTRA_EXT_UBO_GS,
> + EXTRA_EXT_ATOMICS_GS,
> + EXTRA_EXT_SHADER_IMAGE_GS,
> EXTRA_EXT_ATOMICS_TESS,
> EXTRA_EXT_SHADER_IMAGE_TESS,
> + EXTRA_EXT_SSBO_GS,
> + EXTRA_EXT_GPU5_GS,
> + EXTRA_EXT_VIEWPORT_GS,
> };
>
> #define NO_EXTRA NULL
> @@ -308,7 +311,7 @@ static const int extra_ARB_transform_feedback2_api_es3[]
> = {
> };
>
> static const int extra_ARB_uniform_buffer_object_and_geometry_shader[] = {
> - EXTRA_EXT_UBO_GS4,
> + EXTRA_EXT_UBO_GS,
> EXTRA_END
> };
>
> @@ -343,12 +346,12 @@ static const int extra_EXT_texture_array_es3[] = {
> };
>
> static const int extra_ARB_shader_atomic_counters_and_geometry_shader[] = {
> - EXTRA_EXT_ATOMICS_GS4,
> + EXTRA_EXT_ATOMICS_GS,
> EXTRA_END
> };
>
> static const int extra_ARB_shader_image_load_store_and_geometry_shader[] = {
> - EXTRA_EXT_SHADER_IMAGE_GS4,
> + EXTRA_EXT_SHADER_IMAGE_GS,
> EXTRA_END
> };
>
> @@ -375,6 +378,21 @@ static const int
> extra_ARB_shader_storage_buffer_object_es31[] = {
> EXTRA_END
> };
>
> +static const int extra_ARB_gpu_shader5_and_geometry_shader[] = {
> + EXTRA_EXT_GPU5_GS,
> + EXTRA_END
> +};
> +
> +static const int
> extra_ARB_shader_storage_buffer_object_and_geometry_shader[] = {
> + EXTRA_EXT_SSBO_GS,
> + EXTRA_END
> +};
> +
> +static const int extra_ARB_viewport_array_and_geometry_shader[] = {
> + EXTRA_EXT_VIEWPORT_GS,
> + EXTRA_END
> +};
> +
> EXTRA_EXT(ARB_texture_cube_map);
> EXTRA_EXT(EXT_texture_array);
> EXTRA_EXT(NV_fog_distance);
> @@ -423,6 +441,7 @@ EXTRA_EXT(ARB_framebuffer_no_attachments);
> EXTRA_EXT(ARB_tessellation_shader);
> EXTRA_EXT(ARB_shader_subroutine);
> EXTRA_EXT(ARB_shader_storage_buffer_object);
> +EXTRA_EXT(OES_geometry_shader);
>
> static const int
> extra_ARB_color_buffer_float_or_glcore[] = {
> @@ -454,6 +473,12 @@ static const int extra_gl32_es3[] = {
> EXTRA_END,
> };
>
> +static const int extra_version_32_OES_geometry_shader[] = {
> +EXTRA_VERSION_32,
> +EXT(OES_geometry_shader),
> +EXTRA_END
> +};
> +
> static const int extra_gl40_ARB_sample_shading[] = {
> EXTRA_VERSION_40,
> EXT(ARB_sample_shading),
> @@ -1149,17 +1174,17 @@ check_extra(struct gl_context *ctx, const char *func,
> const struct value_desc *d
> if (ctx->Const.GLSLVersion >= 130)
> api_found = GL_TRUE;
> break;
> - case EXTRA_EXT_UBO_GS4:
> + case EXTRA_EXT_UBO_GS:
> api_check = GL_TRUE;
> api_found = (ctx->Extensions.ARB_uniform_buffer_object &&
>_mesa_has_geometry_shaders(ctx));
> break;
> - case EXTRA_EXT_ATOMICS_GS4:
> + case EXTRA_EXT_ATOMICS_GS:
> api_check = GL_TRUE;
> api_found = (ctx->Extensions.ARB_shader_atomic_counters &&
>_mesa_has_geometry_shaders(ctx));
> break;
> - case EXTRA_EXT_SHADER_IMAGE_GS4:
> + case EXTRA_EXT_SHADER_IMAGE_GS:
> api_check = GL_TRUE;
> api_found = (ctx->Extensions.ARB_shader_image_load_store &&
>_mesa_has_geometry_shaders(ctx));
> @@ -1174,6 +1199,21 @@ check_extra(struct gl_context *ctx, const char *func,
> const struct value_desc *d
> api_found = ctx->Extensions.ARB_shader_image_load_store &&
> _mesa_has_tessellation(ctx);
> break;
> + case EXTRA_EXT_GPU5_GS:
> + api_check = GL_TRUE;
> + api_found = (ctx->Extensions.ARB_framebuffer_no_attachments &&
> + _mesa_has_geometry_shaders(ctx));
What does this have to do with ARB_gpu_shader5?
> + break;
> + case EXTRA_EXT_SSBO_GS:
> + api_check = GL_TRUE;
> + api_found = (ctx->Extensions.ARB_shader_storage_buffer_object &&
> + _mesa_has_geometry_shaders(ctx));
> + break;
> + case EXTRA_EXT_VIEWPORT_GS:
> + api_check = GL_TRUE;
> + api_found = (ctx->Extensions.ARB_viewport_array &&
> + _mesa_has_geometry_shaders(ctx));
Not sure this makes sense without geometry shaders tbh...
> + break;
>case EXTRA_END:
> break;
>default: /* *e is a offset into the extension struct */
>
Re: [Mesa-dev] [PATCH 0/9] Move nir/glsl to src/compiler
On 27 November 2015 at 17:54, Jason Ekstrand wrote: > > On Nov 25, 2015 1:27 PM, "Emil Velikov" wrote: >> >> Hello all, >> >> Some of us have been thinking about moving nir out of glsl, and fleshing >> out some common helper (static library) that is use by both. So here it >> is - src/compiler. >> >> The modules (libcompiler, libnir and libglsl) are unfortunately not >> really independent. >> - libcompiler - compile time (mesa ir, glsl ir, util), link - util >> - libglsl - compile (compiler, mesa ir, util), link - compiler, util >> - libnir - compile (compiler, mesa ir, glsl ir, util), link - compiler, >> util > > Thanks for working on this! Before I make comments, its worth noting that > the biggest churn is just moving files. If we don't have the linking > details figured out, that shouldn't block landing the file churn. > > I was kind of hoping that we could have a libnir that doesn't require glsl. > It would be good for freedreno and vc4 among other things. Maybe split > things up differently? > One of us is getting confused here. NIR does _not_ depend during link time on glsl and vice-versa (as per above list). To remove the compile-time dependency, I've spent a fair bit of time trying to flesh things out. Yet that's not possible without rewriting substantial hunks of glsl, nir and mesa. > - libcompilerutil: just glsl_types and shader_enums > - libglsl > - libnir > - libcompiler > > Neither libglsl nor libnir should depend on the other. If you want > everything, you use libcompiler which would depend on both libglsl and > libnir and also bring in glsl_to_nir. > > Would that be practical? (I don't know autotools or libtool all that well.) > With the above said I'm not sure how I can comment on this. Sorry :-( Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] compiler: move the glsl_types C wrapper
On 27 November 2015 at 18:00, Jason Ekstrand wrote:
>
> On Nov 25, 2015 1:27 PM, "Emil Velikov" wrote:
>>
>> From: Emil Velikov
>>
>> ... alongside its C++ brethren. On the flip side the files are called
>> nir_types.{cpp,h} just because...
>
> It does do one NIR-specific thing: if you call glsl_get_length on a matrix,
> it gives you the number of columns. This probably isn't a huge deal though.
>
By "NIR-specific" I believe you mean "used solely by NIR" or am I
missing something ?
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/6] glapi: add GL_OES_geometry_shader extension
Hello Marta,
On 27 November 2015 at 14:31, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> Add xml definitions for the GL_OES_geometry_shader extension
> and expose the extension for OpenGL ES 3.1.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/mapi/glapi/gen/apiexec.py | 2 +-
> src/mapi/glapi/gen/es_EXT.xml | 43
> +
> src/mesa/main/extensions_table.h| 1 +
> src/mesa/main/mtypes.h | 1 +
> src/mesa/main/tests/dispatch_sanity.cpp | 3 +++
> 5 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/src/mapi/glapi/gen/apiexec.py b/src/mapi/glapi/gen/apiexec.py
> index 58ec08b..fa046fa 100644
> --- a/src/mapi/glapi/gen/apiexec.py
> +++ b/src/mapi/glapi/gen/apiexec.py
> @@ -72,7 +72,7 @@ functions = {
>
> # OpenGL 3.2 / GL_ARB_geometry_shader4. Mesa does not support
> # GL_ARB_geometry_shader4, so OpenGL 3.2 is required.
> -"FramebufferTexture": exec_info(core=32),
> +"FramebufferTexture": exec_info(core=32, es2=31),
>
Please update the comment as well.
> # OpenGL 4.0 / GL_ARB_shader_subroutines. Mesa only exposes this
> # extension with core profile.
> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> index 577d825..f6c49c2 100644
> --- a/src/mapi/glapi/gen/es_EXT.xml
> +++ b/src/mapi/glapi/gen/es_EXT.xml
> @@ -940,4 +940,47 @@
>
>
>
> +
> +
> +
> + value="0x8DD9"/>
> + value="0x0004"/>
> + value="0x8916"/>
> + value="0x8917"/>
> + value="0x8918"/>
> + value="0x887F"/>
> + value="0x825E"/>
> + value="0x8A2C"/>
> + value="0x8A32"/>
> + value="0x9123"/>
> + value="0x9124"/>
> + value="0x8DE0"/>
> + value="0x8DE1"/>
> + value="0x8E5A"/>
> + value="0x8C29"/>
> + value="0x92CF"/>
> + value="0x92D5"/>
> + value="0x90CD"/>
> + value="0x90D7"/>
> + value="0x8E4D"/>
> + value="0x8E4E"/>
> + value="0x8260"/>
> + value="0x8C87"/>
> + value="0xA"/>
> + value="0xB"/>
> + value="0xC"/>
> + value="0xD"/>
> + value="0x9312"/>
> + value="0x9317"/>
> + value="0x8DA8"/>
> + value="0x8DA7"/>
> + value="0x9309"/>
> +
Wondering if Eric's recent patches don't make these obsolete. Haven't
look closely at them yet, have you ?
Cheers,
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/6] glsl: add support for GL_OES_geometry_shader
On 27 November 2015 at 18:02, Ilia Mirkin wrote:
> On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
> wrote:
>> From: Marta Lofstedt
>>
>> This adds glsl support of GL_OES_geometry_shader for
>> OpenGL ES 3.1.
>>
>> Signed-off-by: Marta Lofstedt
>> ---
>> src/glsl/builtin_variables.cpp | 17 +
>> src/glsl/glsl_parser.yy | 4 ++--
>> src/glsl/glsl_parser_extras.cpp | 1 +
>> src/glsl/glsl_parser_extras.h | 2 ++
>> 4 files changed, 10 insertions(+), 14 deletions(-)
>>
>> diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
>> index e8eab80..6a53789 100644
>> --- a/src/glsl/builtin_variables.cpp
>> +++ b/src/glsl/builtin_variables.cpp
>> @@ -667,7 +667,7 @@ builtin_variable_generator::generate_constants()
>>add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying *
>> 4);
>> }
>>
>> - if (state->is_version(150, 0)) {
>> + if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
>>add_const("gl_MaxVertexOutputComponents",
>> state->Const.MaxVertexOutputComponents);
>>add_const("gl_MaxGeometryInputComponents",
>> @@ -729,11 +729,7 @@ builtin_variable_generator::generate_constants()
>> state->Const.MaxCombinedAtomicCounters);
>>add_const("gl_MaxAtomicCounterBindings",
>> state->Const.MaxAtomicBufferBindings);
>> -
>> - /* When Mesa adds support for GL_OES_geometry_shader and
>> - * GL_OES_tessellation_shader, this will need to change.
>> - */
>> - if (!state->es_shader) {
>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>> add_const("gl_MaxGeometryAtomicCounters",
>> state->Const.MaxGeometryAtomicCounters);
>> add_const("gl_MaxTessControlAtomicCounters",
>
> Do you really want to be adding this in for OES_geometry_shader?
>
>> @@ -753,10 +749,7 @@ builtin_variable_generator::generate_constants()
>>add_const("gl_MaxAtomicCounterBufferSize",
>> state->Const.MaxAtomicCounterBufferSize);
>>
>> - /* When Mesa adds support for GL_OES_geometry_shader and
>> - * GL_OES_tessellation_shader, this will need to change.
>> - */
>> - if (!state->es_shader) {
>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>> add_const("gl_MaxGeometryAtomicCounterBuffers",
>> state->Const.MaxGeometryAtomicCounterBuffers);
>> add_const("gl_MaxTessControlAtomicCounterBuffers",
>> @@ -814,7 +807,7 @@ builtin_variable_generator::generate_constants()
>>add_const("gl_MaxCombinedImageUniforms",
>> state->Const.MaxCombinedImageUniforms);
>>
>> - if (!state->es_shader) {
>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>> add_const("gl_MaxCombinedImageUnitsAndFragmentOutputs",
>> state->Const.MaxCombinedShaderOutputResources);
>> add_const("gl_MaxImageSamples",
>> @@ -1057,7 +1050,7 @@ builtin_variable_generator::generate_fs_special_vars()
>> if (state->is_version(120, 100))
>>add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
>>
>> - if (state->is_version(150, 0)) {
>> + if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
>>var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t, "gl_PrimitiveID");
>>var->data.interpolation = INTERP_QUALIFIER_FLAT;
>> }
>> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
>> index 5a8f980..fae6d0b 100644
>> --- a/src/glsl/glsl_parser.yy
>> +++ b/src/glsl/glsl_parser.yy
>> @@ -1262,7 +1262,7 @@ layout_qualifier_id:
>> }
>> }
>>
>> - if ($$.flags.i && !state->is_version(150, 0)) {
>> + if ($$.flags.i && !state->is_version(150, 320) &&
>> !state->OES_geometry_shader_enable) {
>> _mesa_glsl_error(& @1, state, "#version 150 layout "
>> "qualifier `%s' used", $1);
>> }
>> @@ -1499,7 +1499,7 @@ layout_qualifier_id:
>>if (match_layout_qualifier("max_vertices", $1, state) == 0) {
>> $$.flags.q.max_vertices = 1;
>> $$.max_vertices = new(ctx) ast_layout_expression(@1, $3);
>> - if (!state->is_version(150, 0)) {
>> + if (!state->is_version(150, 310)) {
>
> Why is this one different? Shouldn't this also be the same as the above check?
>
Depends on how much the OES_geometry_shader text differs from the one
in GLES 3.2. If they are the same - one can fix the
_mesa_glsl_supported_extensions[] handling to use the existing
_mesa_has_#extension_name() helpers from Nanley and drop the GLES
version checks above.
This sounds like the better long term solution, imho, although others
might disagree.
If they differ ... we might want to pull the same thing as the ARB
version - never expose the standalone extension but have the
functionality for respective core version.
Cheers,
Emil
Re: [Mesa-dev] [PATCH 7/9] compiler: move the glsl_types C wrapper
On Nov 27, 2015 10:21 AM, "Emil Velikov" wrote:
>
> On 27 November 2015 at 18:00, Jason Ekstrand wrote:
> >
> > On Nov 25, 2015 1:27 PM, "Emil Velikov"
wrote:
> >>
> >> From: Emil Velikov
> >>
> >> ... alongside its C++ brethren. On the flip side the files are called
> >> nir_types.{cpp,h} just because...
> >
> > It does do one NIR-specific thing: if you call glsl_get_length on a
matrix,
> > it gives you the number of columns. This probably isn't a huge deal
though.
> >
> By "NIR-specific" I believe you mean "used solely by NIR" or am I
> missing something ?
I mean that GLSL IR and NIR treat matrices differently. NIR has no concept
of a matrix but rather treats them as an array of vectors. GLSL IR treats
matrices and vectors more-or-less the same; matrices just have more than
one column. However, almost all C code that works with glsl_type is working
with NIR so this shouldn't be a problem.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/6] gles2: Update gl2ext.h to revision: 32120
On 27 November 2015 at 17:50, Ilia Mirkin wrote:
> On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
> wrote:
>> From: Marta Lofstedt
>>
>> This is needed to be able to implement the accepted OES
>> extensions.
>>
>> Signed-off-by: Marta Lofstedt
>> ---
>> include/GLES2/gl2ext.h | 940
>> -
>> 1 file changed, 934 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/GLES2/gl2ext.h b/include/GLES2/gl2ext.h
>> index 2b67c6e..2d05596 100644
>> --- a/include/GLES2/gl2ext.h
>> +++ b/include/GLES2/gl2ext.h
>> @@ -6,7 +6,7 @@ extern "C" {
>> #endif
>>
>> /*
>> -** Copyright (c) 2013-2014 The Khronos Group Inc.
>> +** Copyright (c) 2013-2015 The Khronos Group Inc.
>> **
>> ** Permission is hereby granted, free of charge, to any person obtaining a
>> ** copy of this software and/or associated documentation files (the
>> @@ -33,14 +33,14 @@ extern "C" {
>> ** used to make the header, and the header can be found at
>> ** http://www.opengl.org/registry/
>> **
>> -** Khronos $Revision: 28335 $ on $Date: 2014-09-26 18:55:45 -0700 (Fri, 26
>> Sep 2014) $
>> +** Khronos $Revision: 32120 $ on $Date: 2015-10-15 04:27:13 -0700 (Thu, 15
>> Oct 2015) $
>> */
>
> What is this header used for? Do we ship it, or is it purely internal
> to mesa? If we ship it, might need to cc this to stable... e.g. buffer
> storage and a couple other things are in here that we expose in 11.1.
We ship it. Although everyone (distributions?) can freely grab them
from the Khronos public section.
-Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/6] glsl: add support for GL_OES_geometry_shader
On Fri, Nov 27, 2015 at 1:31 PM, Emil Velikov wrote:
> On 27 November 2015 at 18:02, Ilia Mirkin wrote:
>> On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
>> wrote:
>>> From: Marta Lofstedt
>>>
>>> This adds glsl support of GL_OES_geometry_shader for
>>> OpenGL ES 3.1.
>>>
>>> Signed-off-by: Marta Lofstedt
>>> ---
>>> src/glsl/builtin_variables.cpp | 17 +
>>> src/glsl/glsl_parser.yy | 4 ++--
>>> src/glsl/glsl_parser_extras.cpp | 1 +
>>> src/glsl/glsl_parser_extras.h | 2 ++
>>> 4 files changed, 10 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
>>> index e8eab80..6a53789 100644
>>> --- a/src/glsl/builtin_variables.cpp
>>> +++ b/src/glsl/builtin_variables.cpp
>>> @@ -667,7 +667,7 @@ builtin_variable_generator::generate_constants()
>>>add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying *
>>> 4);
>>> }
>>>
>>> - if (state->is_version(150, 0)) {
>>> + if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
>>>add_const("gl_MaxVertexOutputComponents",
>>> state->Const.MaxVertexOutputComponents);
>>>add_const("gl_MaxGeometryInputComponents",
>>> @@ -729,11 +729,7 @@ builtin_variable_generator::generate_constants()
>>> state->Const.MaxCombinedAtomicCounters);
>>>add_const("gl_MaxAtomicCounterBindings",
>>> state->Const.MaxAtomicBufferBindings);
>>> -
>>> - /* When Mesa adds support for GL_OES_geometry_shader and
>>> - * GL_OES_tessellation_shader, this will need to change.
>>> - */
>>> - if (!state->es_shader) {
>>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>>> add_const("gl_MaxGeometryAtomicCounters",
>>> state->Const.MaxGeometryAtomicCounters);
>>> add_const("gl_MaxTessControlAtomicCounters",
>>
>> Do you really want to be adding this in for OES_geometry_shader?
>>
>>> @@ -753,10 +749,7 @@ builtin_variable_generator::generate_constants()
>>>add_const("gl_MaxAtomicCounterBufferSize",
>>> state->Const.MaxAtomicCounterBufferSize);
>>>
>>> - /* When Mesa adds support for GL_OES_geometry_shader and
>>> - * GL_OES_tessellation_shader, this will need to change.
>>> - */
>>> - if (!state->es_shader) {
>>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>>> add_const("gl_MaxGeometryAtomicCounterBuffers",
>>> state->Const.MaxGeometryAtomicCounterBuffers);
>>> add_const("gl_MaxTessControlAtomicCounterBuffers",
>>> @@ -814,7 +807,7 @@ builtin_variable_generator::generate_constants()
>>>add_const("gl_MaxCombinedImageUniforms",
>>> state->Const.MaxCombinedImageUniforms);
>>>
>>> - if (!state->es_shader) {
>>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>>> add_const("gl_MaxCombinedImageUnitsAndFragmentOutputs",
>>> state->Const.MaxCombinedShaderOutputResources);
>>> add_const("gl_MaxImageSamples",
>>> @@ -1057,7 +1050,7 @@ builtin_variable_generator::generate_fs_special_vars()
>>> if (state->is_version(120, 100))
>>>add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
>>>
>>> - if (state->is_version(150, 0)) {
>>> + if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
>>>var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t, "gl_PrimitiveID");
>>>var->data.interpolation = INTERP_QUALIFIER_FLAT;
>>> }
>>> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
>>> index 5a8f980..fae6d0b 100644
>>> --- a/src/glsl/glsl_parser.yy
>>> +++ b/src/glsl/glsl_parser.yy
>>> @@ -1262,7 +1262,7 @@ layout_qualifier_id:
>>> }
>>> }
>>>
>>> - if ($$.flags.i && !state->is_version(150, 0)) {
>>> + if ($$.flags.i && !state->is_version(150, 320) &&
>>> !state->OES_geometry_shader_enable) {
>>> _mesa_glsl_error(& @1, state, "#version 150 layout "
>>> "qualifier `%s' used", $1);
>>> }
>>> @@ -1499,7 +1499,7 @@ layout_qualifier_id:
>>>if (match_layout_qualifier("max_vertices", $1, state) == 0) {
>>> $$.flags.q.max_vertices = 1;
>>> $$.max_vertices = new(ctx) ast_layout_expression(@1, $3);
>>> - if (!state->is_version(150, 0)) {
>>> + if (!state->is_version(150, 310)) {
>>
>> Why is this one different? Shouldn't this also be the same as the above
>> check?
>>
> Depends on how much the OES_geometry_shader text differs from the one
> in GLES 3.2. If they are the same - one can fix the
> _mesa_glsl_supported_extensions[] handling to use the existing
> _mesa_has_#extension_name() helpers from Nanley and drop the GLES
> version checks above.
Nope, those helpers would be of no help here. An entirely separate set
of helpers could be made, of course,
Re: [Mesa-dev] [PATCH 0/9] Move nir/glsl to src/compiler
On Nov 27, 2015 10:16 AM, "Emil Velikov" wrote: > > On 27 November 2015 at 17:54, Jason Ekstrand wrote: > > > > On Nov 25, 2015 1:27 PM, "Emil Velikov" wrote: > >> > >> Hello all, > >> > >> Some of us have been thinking about moving nir out of glsl, and fleshing > >> out some common helper (static library) that is use by both. So here it > >> is - src/compiler. > >> > >> The modules (libcompiler, libnir and libglsl) are unfortunately not > >> really independent. > >> - libcompiler - compile time (mesa ir, glsl ir, util), link - util > >> - libglsl - compile (compiler, mesa ir, util), link - compiler, util > >> - libnir - compile (compiler, mesa ir, glsl ir, util), link - compiler, > >> util > > > > Thanks for working on this! Before I make comments, its worth noting that > > the biggest churn is just moving files. If we don't have the linking > > details figured out, that shouldn't block landing the file churn. > > > > I was kind of hoping that we could have a libnir that doesn't require glsl. > > It would be good for freedreno and vc4 among other things. Maybe split > > things up differently? > > > One of us is getting confused here. > > NIR does _not_ depend during link time on glsl and vice-versa (as per > above list). OK, that wasn't clear. Where does glsl_to_nir go then? Does it not actually need to link against libglsl? I could believe it but it does have to link against NIR. > To remove the compile-time dependency, I've spent a fair bit of time > trying to flesh things out. Yet that's not possible without rewriting > substantial hunks of glsl, nir and mesa. That's fine. I know that's a lot of work so don't worry about it for now. > > - libcompilerutil: just glsl_types and shader_enums > > - libglsl > > - libnir > > - libcompiler > > > > Neither libglsl nor libnir should depend on the other. If you want > > everything, you use libcompiler which would depend on both libglsl and > > libnir and also bring in glsl_to_nir. > > > > Would that be practical? (I don't know autotools or libtool all that well.) > > > With the above said I'm not sure how I can comment on this. Sorry :-( > > Thanks > Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/6] gles2: Update gl2ext.h to revision: 32120
On Fri, Nov 27, 2015 at 1:35 PM, Emil Velikov wrote:
> On 27 November 2015 at 17:50, Ilia Mirkin wrote:
>> On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
>> wrote:
>>> From: Marta Lofstedt
>>>
>>> This is needed to be able to implement the accepted OES
>>> extensions.
>>>
>>> Signed-off-by: Marta Lofstedt
>>> ---
>>> include/GLES2/gl2ext.h | 940
>>> -
>>> 1 file changed, 934 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/include/GLES2/gl2ext.h b/include/GLES2/gl2ext.h
>>> index 2b67c6e..2d05596 100644
>>> --- a/include/GLES2/gl2ext.h
>>> +++ b/include/GLES2/gl2ext.h
>>> @@ -6,7 +6,7 @@ extern "C" {
>>> #endif
>>>
>>> /*
>>> -** Copyright (c) 2013-2014 The Khronos Group Inc.
>>> +** Copyright (c) 2013-2015 The Khronos Group Inc.
>>> **
>>> ** Permission is hereby granted, free of charge, to any person obtaining a
>>> ** copy of this software and/or associated documentation files (the
>>> @@ -33,14 +33,14 @@ extern "C" {
>>> ** used to make the header, and the header can be found at
>>> ** http://www.opengl.org/registry/
>>> **
>>> -** Khronos $Revision: 28335 $ on $Date: 2014-09-26 18:55:45 -0700 (Fri, 26
>>> Sep 2014) $
>>> +** Khronos $Revision: 32120 $ on $Date: 2015-10-15 04:27:13 -0700 (Thu, 15
>>> Oct 2015) $
>>> */
>>
>> What is this header used for? Do we ship it, or is it purely internal
>> to mesa? If we ship it, might need to cc this to stable... e.g. buffer
>> storage and a couple other things are in here that we expose in 11.1.
>
> We ship it. Although everyone (distributions?) can freely grab them
> from the Khronos public section.
OK, then we need to get this into 11.1 since we added
GL_EXT_blend_func_extended there (and GL_EXT_buffer_storage, but that
one's a bit more theoretical since there's no ES 3.1 support yet).
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] compiler: move the glsl_types C wrapper
On 27 November 2015 at 18:33, Jason Ekstrand wrote:
>
> On Nov 27, 2015 10:21 AM, "Emil Velikov" wrote:
>>
>> On 27 November 2015 at 18:00, Jason Ekstrand wrote:
>> >
>> > On Nov 25, 2015 1:27 PM, "Emil Velikov"
>> > wrote:
>> >>
>> >> From: Emil Velikov
>> >>
>> >> ... alongside its C++ brethren. On the flip side the files are called
>> >> nir_types.{cpp,h} just because...
>> >
>> > It does do one NIR-specific thing: if you call glsl_get_length on a
>> > matrix,
>> > it gives you the number of columns. This probably isn't a huge deal
>> > though.
>> >
>> By "NIR-specific" I believe you mean "used solely by NIR" or am I
>> missing something ?
>
> I mean that GLSL IR and NIR treat matrices differently. NIR has no concept
> of a matrix but rather treats them as an array of vectors. GLSL IR treats
> matrices and vectors more-or-less the same; matrices just have more than one
> column. However, almost all C code that works with glsl_type is working with
> NIR so this shouldn't be a problem.
Ouch, this sounds like a nice subtlety which might need to keep an eye
for when doing the IR re-factoring/cleanups.
Thanks for that I wasn't aware of it.
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] Move nir/glsl to src/compiler
On 27 November 2015 at 18:37, Jason Ekstrand wrote: > > On Nov 27, 2015 10:16 AM, "Emil Velikov" wrote: >> >> On 27 November 2015 at 17:54, Jason Ekstrand wrote: >> > >> > On Nov 25, 2015 1:27 PM, "Emil Velikov" >> > wrote: >> >> >> >> Hello all, >> >> >> >> Some of us have been thinking about moving nir out of glsl, and >> >> fleshing >> >> out some common helper (static library) that is use by both. So here it >> >> is - src/compiler. >> >> >> >> The modules (libcompiler, libnir and libglsl) are unfortunately not >> >> really independent. >> >> - libcompiler - compile time (mesa ir, glsl ir, util), link - util >> >> - libglsl - compile (compiler, mesa ir, util), link - compiler, util >> >> - libnir - compile (compiler, mesa ir, glsl ir, util), link - >> >> compiler, >> >> util >> > >> > Thanks for working on this! Before I make comments, its worth noting >> > that >> > the biggest churn is just moving files. If we don't have the linking >> > details figured out, that shouldn't block landing the file churn. >> > >> > I was kind of hoping that we could have a libnir that doesn't require >> > glsl. >> > It would be good for freedreno and vc4 among other things. Maybe split >> > things up differently? >> > >> One of us is getting confused here. >> >> NIR does _not_ depend during link time on glsl and vice-versa (as per >> above list). > > OK, that wasn't clear. Where does glsl_to_nir go then? Does it not > actually need to link against libglsl? I could believe it but it does have > to link against NIR. > Suggestions on how to make it clearer are appreciated :-) glsl_to_nir is stored as currently - in NIR. Things just work out fine as [I'm leaning that] the linker just removes the file where it's not needed. And with it the glsl link time dependency. >> To remove the compile-time dependency, I've spent a fair bit of time >> trying to flesh things out. Yet that's not possible without rewriting >> substantial hunks of glsl, nir and mesa. > > That's fine. I know that's a lot of work so don't worry about it for now. > I had no idea and things started exploding rather badly quite quick when I gave it a try. -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] Move nir/glsl to src/compiler
On Nov 27, 2015 10:44 AM, "Emil Velikov" wrote: > > On 27 November 2015 at 18:37, Jason Ekstrand wrote: > > > > On Nov 27, 2015 10:16 AM, "Emil Velikov" wrote: > >> > >> On 27 November 2015 at 17:54, Jason Ekstrand wrote: > >> > > >> > On Nov 25, 2015 1:27 PM, "Emil Velikov" > >> > wrote: > >> >> > >> >> Hello all, > >> >> > >> >> Some of us have been thinking about moving nir out of glsl, and > >> >> fleshing > >> >> out some common helper (static library) that is use by both. So here it > >> >> is - src/compiler. > >> >> > >> >> The modules (libcompiler, libnir and libglsl) are unfortunately not > >> >> really independent. > >> >> - libcompiler - compile time (mesa ir, glsl ir, util), link - util > >> >> - libglsl - compile (compiler, mesa ir, util), link - compiler, util > >> >> - libnir - compile (compiler, mesa ir, glsl ir, util), link - > >> >> compiler, > >> >> util > >> > > >> > Thanks for working on this! Before I make comments, its worth noting > >> > that > >> > the biggest churn is just moving files. If we don't have the linking > >> > details figured out, that shouldn't block landing the file churn. > >> > > >> > I was kind of hoping that we could have a libnir that doesn't require > >> > glsl. > >> > It would be good for freedreno and vc4 among other things. Maybe split > >> > things up differently? > >> > > >> One of us is getting confused here. > >> > >> NIR does _not_ depend during link time on glsl and vice-versa (as per > >> above list). > > > > OK, that wasn't clear. Where does glsl_to_nir go then? Does it not > > actually need to link against libglsl? I could believe it but it does have > > to link against NIR. > > > Suggestions on how to make it clearer are appreciated :-) Meh, you clarified :-) > glsl_to_nir is stored as currently - in NIR. Things just work out fine > as [I'm leaning that] the linker just removes the file where it's not > needed. And with it the glsl link time dependency. As long as it works. > >> To remove the compile-time dependency, I've spent a fair bit of time > >> trying to flesh things out. Yet that's not possible without rewriting > >> substantial hunks of glsl, nir and mesa. > > > > That's fine. I know that's a lot of work so don't worry about it for now. > > > I had no idea and things started exploding rather badly quite quick > when I gave it a try. > > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/6] glsl: add support for GL_OES_geometry_shader
On 27 November 2015 at 18:36, Ilia Mirkin wrote:
> On Fri, Nov 27, 2015 at 1:31 PM, Emil Velikov
> wrote:
>> On 27 November 2015 at 18:02, Ilia Mirkin wrote:
>>> On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
>>> wrote:
From: Marta Lofstedt
This adds glsl support of GL_OES_geometry_shader for
OpenGL ES 3.1.
Signed-off-by: Marta Lofstedt
---
src/glsl/builtin_variables.cpp | 17 +
src/glsl/glsl_parser.yy | 4 ++--
src/glsl/glsl_parser_extras.cpp | 1 +
src/glsl/glsl_parser_extras.h | 2 ++
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp
b/src/glsl/builtin_variables.cpp
index e8eab80..6a53789 100644
--- a/src/glsl/builtin_variables.cpp
+++ b/src/glsl/builtin_variables.cpp
@@ -667,7 +667,7 @@ builtin_variable_generator::generate_constants()
add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying *
4);
}
- if (state->is_version(150, 0)) {
+ if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
add_const("gl_MaxVertexOutputComponents",
state->Const.MaxVertexOutputComponents);
add_const("gl_MaxGeometryInputComponents",
@@ -729,11 +729,7 @@ builtin_variable_generator::generate_constants()
state->Const.MaxCombinedAtomicCounters);
add_const("gl_MaxAtomicCounterBindings",
state->Const.MaxAtomicBufferBindings);
-
- /* When Mesa adds support for GL_OES_geometry_shader and
- * GL_OES_tessellation_shader, this will need to change.
- */
- if (!state->es_shader) {
+ if (!state->es_shader || state->OES_geometry_shader_enable) {
add_const("gl_MaxGeometryAtomicCounters",
state->Const.MaxGeometryAtomicCounters);
add_const("gl_MaxTessControlAtomicCounters",
>>>
>>> Do you really want to be adding this in for OES_geometry_shader?
>>>
@@ -753,10 +749,7 @@ builtin_variable_generator::generate_constants()
add_const("gl_MaxAtomicCounterBufferSize",
state->Const.MaxAtomicCounterBufferSize);
- /* When Mesa adds support for GL_OES_geometry_shader and
- * GL_OES_tessellation_shader, this will need to change.
- */
- if (!state->es_shader) {
+ if (!state->es_shader || state->OES_geometry_shader_enable) {
add_const("gl_MaxGeometryAtomicCounterBuffers",
state->Const.MaxGeometryAtomicCounterBuffers);
add_const("gl_MaxTessControlAtomicCounterBuffers",
@@ -814,7 +807,7 @@ builtin_variable_generator::generate_constants()
add_const("gl_MaxCombinedImageUniforms",
state->Const.MaxCombinedImageUniforms);
- if (!state->es_shader) {
+ if (!state->es_shader || state->OES_geometry_shader_enable) {
add_const("gl_MaxCombinedImageUnitsAndFragmentOutputs",
state->Const.MaxCombinedShaderOutputResources);
add_const("gl_MaxImageSamples",
@@ -1057,7 +1050,7 @@
builtin_variable_generator::generate_fs_special_vars()
if (state->is_version(120, 100))
add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
- if (state->is_version(150, 0)) {
+ if (state->is_version(150, 320) || state->OES_geometry_shader_enable) {
var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t, "gl_PrimitiveID");
var->data.interpolation = INTERP_QUALIFIER_FLAT;
}
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 5a8f980..fae6d0b 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -1262,7 +1262,7 @@ layout_qualifier_id:
}
}
- if ($$.flags.i && !state->is_version(150, 0)) {
+ if ($$.flags.i && !state->is_version(150, 320) &&
!state->OES_geometry_shader_enable) {
_mesa_glsl_error(& @1, state, "#version 150 layout "
"qualifier `%s' used", $1);
}
@@ -1499,7 +1499,7 @@ layout_qualifier_id:
if (match_layout_qualifier("max_vertices", $1, state) == 0) {
$$.flags.q.max_vertices = 1;
$$.max_vertices = new(ctx) ast_layout_expression(@1, $3);
- if (!state->is_version(150, 0)) {
+ if (!state->is_version(150, 310)) {
>>>
>>> Why is this one different? Shouldn't this also be the same as the above
>>> check?
>>>
>> Depends on how much the OES_geometry_shader text differs from the one
>> in GLES 3.2. If they are the same - one can fix the
>> _mesa_glsl_supported_extensions[] handling to use the existing
>> _mesa_has_#extension_name()
Re: [Mesa-dev] [PATCH v2 3/6] glsl: add support for GL_OES_geometry_shader
On Fri, Nov 27, 2015 at 1:55 PM, Emil Velikov wrote:
> On 27 November 2015 at 18:36, Ilia Mirkin wrote:
>> On Fri, Nov 27, 2015 at 1:31 PM, Emil Velikov
>> wrote:
>>> On 27 November 2015 at 18:02, Ilia Mirkin wrote:
On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
wrote:
> From: Marta Lofstedt
>
> This adds glsl support of GL_OES_geometry_shader for
> OpenGL ES 3.1.
>
> Signed-off-by: Marta Lofstedt
> ---
> src/glsl/builtin_variables.cpp | 17 +
> src/glsl/glsl_parser.yy | 4 ++--
> src/glsl/glsl_parser_extras.cpp | 1 +
> src/glsl/glsl_parser_extras.h | 2 ++
> 4 files changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/src/glsl/builtin_variables.cpp
> b/src/glsl/builtin_variables.cpp
> index e8eab80..6a53789 100644
> --- a/src/glsl/builtin_variables.cpp
> +++ b/src/glsl/builtin_variables.cpp
> @@ -667,7 +667,7 @@ builtin_variable_generator::generate_constants()
>add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying
> * 4);
> }
>
> - if (state->is_version(150, 0)) {
> + if (state->is_version(150, 320) || state->OES_geometry_shader_enable)
> {
>add_const("gl_MaxVertexOutputComponents",
> state->Const.MaxVertexOutputComponents);
>add_const("gl_MaxGeometryInputComponents",
> @@ -729,11 +729,7 @@ builtin_variable_generator::generate_constants()
> state->Const.MaxCombinedAtomicCounters);
>add_const("gl_MaxAtomicCounterBindings",
> state->Const.MaxAtomicBufferBindings);
> -
> - /* When Mesa adds support for GL_OES_geometry_shader and
> - * GL_OES_tessellation_shader, this will need to change.
> - */
> - if (!state->es_shader) {
> + if (!state->es_shader || state->OES_geometry_shader_enable) {
> add_const("gl_MaxGeometryAtomicCounters",
> state->Const.MaxGeometryAtomicCounters);
> add_const("gl_MaxTessControlAtomicCounters",
Do you really want to be adding this in for OES_geometry_shader?
> @@ -753,10 +749,7 @@ builtin_variable_generator::generate_constants()
>add_const("gl_MaxAtomicCounterBufferSize",
> state->Const.MaxAtomicCounterBufferSize);
>
> - /* When Mesa adds support for GL_OES_geometry_shader and
> - * GL_OES_tessellation_shader, this will need to change.
> - */
> - if (!state->es_shader) {
> + if (!state->es_shader || state->OES_geometry_shader_enable) {
> add_const("gl_MaxGeometryAtomicCounterBuffers",
> state->Const.MaxGeometryAtomicCounterBuffers);
> add_const("gl_MaxTessControlAtomicCounterBuffers",
> @@ -814,7 +807,7 @@ builtin_variable_generator::generate_constants()
>add_const("gl_MaxCombinedImageUniforms",
> state->Const.MaxCombinedImageUniforms);
>
> - if (!state->es_shader) {
> + if (!state->es_shader || state->OES_geometry_shader_enable) {
> add_const("gl_MaxCombinedImageUnitsAndFragmentOutputs",
> state->Const.MaxCombinedShaderOutputResources);
> add_const("gl_MaxImageSamples",
> @@ -1057,7 +1050,7 @@
> builtin_variable_generator::generate_fs_special_vars()
> if (state->is_version(120, 100))
>add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
>
> - if (state->is_version(150, 0)) {
> + if (state->is_version(150, 320) || state->OES_geometry_shader_enable)
> {
>var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t,
> "gl_PrimitiveID");
>var->data.interpolation = INTERP_QUALIFIER_FLAT;
> }
> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
> index 5a8f980..fae6d0b 100644
> --- a/src/glsl/glsl_parser.yy
> +++ b/src/glsl/glsl_parser.yy
> @@ -1262,7 +1262,7 @@ layout_qualifier_id:
> }
> }
>
> - if ($$.flags.i && !state->is_version(150, 0)) {
> + if ($$.flags.i && !state->is_version(150, 320) &&
> !state->OES_geometry_shader_enable) {
> _mesa_glsl_error(& @1, state, "#version 150 layout "
> "qualifier `%s' used", $1);
> }
> @@ -1499,7 +1499,7 @@ layout_qualifier_id:
>if (match_layout_qualifier("max_vertices", $1, state) == 0) {
> $$.flags.q.max_vertices = 1;
> $$.max_vertices = new(ctx) ast_layout_expression(@1, $3);
> - if (!state->is_version(150, 0)) {
> + if (!state->is_version(150, 310)) {
Why is this one different? Shouldn't this also be the same as the above
check?
>>> Depends on how much the OES_geometry_sha
Re: [Mesa-dev] [PATCH v2 3/6] glsl: add support for GL_OES_geometry_shader
On 27 November 2015 at 19:00, Ilia Mirkin wrote:
> On Fri, Nov 27, 2015 at 1:55 PM, Emil Velikov
> wrote:
>> On 27 November 2015 at 18:36, Ilia Mirkin wrote:
>>> On Fri, Nov 27, 2015 at 1:31 PM, Emil Velikov
>>> wrote:
On 27 November 2015 at 18:02, Ilia Mirkin wrote:
> On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
> wrote:
>> From: Marta Lofstedt
>>
>> This adds glsl support of GL_OES_geometry_shader for
>> OpenGL ES 3.1.
>>
>> Signed-off-by: Marta Lofstedt
>> ---
>> src/glsl/builtin_variables.cpp | 17 +
>> src/glsl/glsl_parser.yy | 4 ++--
>> src/glsl/glsl_parser_extras.cpp | 1 +
>> src/glsl/glsl_parser_extras.h | 2 ++
>> 4 files changed, 10 insertions(+), 14 deletions(-)
>>
>> diff --git a/src/glsl/builtin_variables.cpp
>> b/src/glsl/builtin_variables.cpp
>> index e8eab80..6a53789 100644
>> --- a/src/glsl/builtin_variables.cpp
>> +++ b/src/glsl/builtin_variables.cpp
>> @@ -667,7 +667,7 @@ builtin_variable_generator::generate_constants()
>>add_const("gl_MaxVaryingComponents", state->ctx->Const.MaxVarying
>> * 4);
>> }
>>
>> - if (state->is_version(150, 0)) {
>> + if (state->is_version(150, 320) ||
>> state->OES_geometry_shader_enable) {
>>add_const("gl_MaxVertexOutputComponents",
>> state->Const.MaxVertexOutputComponents);
>>add_const("gl_MaxGeometryInputComponents",
>> @@ -729,11 +729,7 @@ builtin_variable_generator::generate_constants()
>> state->Const.MaxCombinedAtomicCounters);
>>add_const("gl_MaxAtomicCounterBindings",
>> state->Const.MaxAtomicBufferBindings);
>> -
>> - /* When Mesa adds support for GL_OES_geometry_shader and
>> - * GL_OES_tessellation_shader, this will need to change.
>> - */
>> - if (!state->es_shader) {
>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>> add_const("gl_MaxGeometryAtomicCounters",
>> state->Const.MaxGeometryAtomicCounters);
>> add_const("gl_MaxTessControlAtomicCounters",
>
> Do you really want to be adding this in for OES_geometry_shader?
>
>> @@ -753,10 +749,7 @@ builtin_variable_generator::generate_constants()
>>add_const("gl_MaxAtomicCounterBufferSize",
>> state->Const.MaxAtomicCounterBufferSize);
>>
>> - /* When Mesa adds support for GL_OES_geometry_shader and
>> - * GL_OES_tessellation_shader, this will need to change.
>> - */
>> - if (!state->es_shader) {
>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>> add_const("gl_MaxGeometryAtomicCounterBuffers",
>> state->Const.MaxGeometryAtomicCounterBuffers);
>> add_const("gl_MaxTessControlAtomicCounterBuffers",
>> @@ -814,7 +807,7 @@ builtin_variable_generator::generate_constants()
>>add_const("gl_MaxCombinedImageUniforms",
>> state->Const.MaxCombinedImageUniforms);
>>
>> - if (!state->es_shader) {
>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>> add_const("gl_MaxCombinedImageUnitsAndFragmentOutputs",
>> state->Const.MaxCombinedShaderOutputResources);
>> add_const("gl_MaxImageSamples",
>> @@ -1057,7 +1050,7 @@
>> builtin_variable_generator::generate_fs_special_vars()
>> if (state->is_version(120, 100))
>>add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
>>
>> - if (state->is_version(150, 0)) {
>> + if (state->is_version(150, 320) ||
>> state->OES_geometry_shader_enable) {
>>var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t,
>> "gl_PrimitiveID");
>>var->data.interpolation = INTERP_QUALIFIER_FLAT;
>> }
>> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
>> index 5a8f980..fae6d0b 100644
>> --- a/src/glsl/glsl_parser.yy
>> +++ b/src/glsl/glsl_parser.yy
>> @@ -1262,7 +1262,7 @@ layout_qualifier_id:
>> }
>> }
>>
>> - if ($$.flags.i && !state->is_version(150, 0)) {
>> + if ($$.flags.i && !state->is_version(150, 320) &&
>> !state->OES_geometry_shader_enable) {
>> _mesa_glsl_error(& @1, state, "#version 150 layout "
>> "qualifier `%s' used", $1);
>> }
>> @@ -1499,7 +1499,7 @@ layout_qualifier_id:
>>if (match_layout_qualifier("max_vertices", $1, state) == 0) {
>> $$.flags.q.max_vertices = 1;
>> $$.max_vertices = new(ctx) ast_layout_expression(@1, $3);
>> - if (!state->is_version(150, 0)) {
>> + if (!state->is_versio
Re: [Mesa-dev] [PATCH v2 3/6] glsl: add support for GL_OES_geometry_shader
On Fri, Nov 27, 2015 at 2:12 PM, Emil Velikov wrote:
> On 27 November 2015 at 19:00, Ilia Mirkin wrote:
>> On Fri, Nov 27, 2015 at 1:55 PM, Emil Velikov
>> wrote:
>>> On 27 November 2015 at 18:36, Ilia Mirkin wrote:
On Fri, Nov 27, 2015 at 1:31 PM, Emil Velikov
wrote:
> On 27 November 2015 at 18:02, Ilia Mirkin wrote:
>> On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt
>> wrote:
>>> From: Marta Lofstedt
>>>
>>> This adds glsl support of GL_OES_geometry_shader for
>>> OpenGL ES 3.1.
>>>
>>> Signed-off-by: Marta Lofstedt
>>> ---
>>> src/glsl/builtin_variables.cpp | 17 +
>>> src/glsl/glsl_parser.yy | 4 ++--
>>> src/glsl/glsl_parser_extras.cpp | 1 +
>>> src/glsl/glsl_parser_extras.h | 2 ++
>>> 4 files changed, 10 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/src/glsl/builtin_variables.cpp
>>> b/src/glsl/builtin_variables.cpp
>>> index e8eab80..6a53789 100644
>>> --- a/src/glsl/builtin_variables.cpp
>>> +++ b/src/glsl/builtin_variables.cpp
>>> @@ -667,7 +667,7 @@ builtin_variable_generator::generate_constants()
>>>add_const("gl_MaxVaryingComponents",
>>> state->ctx->Const.MaxVarying * 4);
>>> }
>>>
>>> - if (state->is_version(150, 0)) {
>>> + if (state->is_version(150, 320) ||
>>> state->OES_geometry_shader_enable) {
>>>add_const("gl_MaxVertexOutputComponents",
>>> state->Const.MaxVertexOutputComponents);
>>>add_const("gl_MaxGeometryInputComponents",
>>> @@ -729,11 +729,7 @@ builtin_variable_generator::generate_constants()
>>> state->Const.MaxCombinedAtomicCounters);
>>>add_const("gl_MaxAtomicCounterBindings",
>>> state->Const.MaxAtomicBufferBindings);
>>> -
>>> - /* When Mesa adds support for GL_OES_geometry_shader and
>>> - * GL_OES_tessellation_shader, this will need to change.
>>> - */
>>> - if (!state->es_shader) {
>>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>>> add_const("gl_MaxGeometryAtomicCounters",
>>> state->Const.MaxGeometryAtomicCounters);
>>> add_const("gl_MaxTessControlAtomicCounters",
>>
>> Do you really want to be adding this in for OES_geometry_shader?
>>
>>> @@ -753,10 +749,7 @@ builtin_variable_generator::generate_constants()
>>>add_const("gl_MaxAtomicCounterBufferSize",
>>> state->Const.MaxAtomicCounterBufferSize);
>>>
>>> - /* When Mesa adds support for GL_OES_geometry_shader and
>>> - * GL_OES_tessellation_shader, this will need to change.
>>> - */
>>> - if (!state->es_shader) {
>>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>>> add_const("gl_MaxGeometryAtomicCounterBuffers",
>>> state->Const.MaxGeometryAtomicCounterBuffers);
>>> add_const("gl_MaxTessControlAtomicCounterBuffers",
>>> @@ -814,7 +807,7 @@ builtin_variable_generator::generate_constants()
>>>add_const("gl_MaxCombinedImageUniforms",
>>> state->Const.MaxCombinedImageUniforms);
>>>
>>> - if (!state->es_shader) {
>>> + if (!state->es_shader || state->OES_geometry_shader_enable) {
>>> add_const("gl_MaxCombinedImageUnitsAndFragmentOutputs",
>>> state->Const.MaxCombinedShaderOutputResources);
>>> add_const("gl_MaxImageSamples",
>>> @@ -1057,7 +1050,7 @@
>>> builtin_variable_generator::generate_fs_special_vars()
>>> if (state->is_version(120, 100))
>>>add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
>>>
>>> - if (state->is_version(150, 0)) {
>>> + if (state->is_version(150, 320) ||
>>> state->OES_geometry_shader_enable) {
>>>var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t,
>>> "gl_PrimitiveID");
>>>var->data.interpolation = INTERP_QUALIFIER_FLAT;
>>> }
>>> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
>>> index 5a8f980..fae6d0b 100644
>>> --- a/src/glsl/glsl_parser.yy
>>> +++ b/src/glsl/glsl_parser.yy
>>> @@ -1262,7 +1262,7 @@ layout_qualifier_id:
>>> }
>>> }
>>>
>>> - if ($$.flags.i && !state->is_version(150, 0)) {
>>> + if ($$.flags.i && !state->is_version(150, 320) &&
>>> !state->OES_geometry_shader_enable) {
>>> _mesa_glsl_error(& @1, state, "#version 150 layout "
>>> "qualifier `%s' used", $1);
>>> }
>>> @@ -1499,7 +1499,7 @@ layout_qualifier_id:
>>>if (match_layout_qualifier("max_vertices", $1, state) == 0) {
>>> $$.flags.q.max_vertices = 1;
>
Re: [Mesa-dev] [PATCH 8/9] nir: move to compiler
On Fri, Nov 27, 2015 at 6:50 AM, Emil Velikov wrote: > On 25 November 2015 at 22:01, Matt Turner wrote: >> On Wed, Nov 25, 2015 at 1:32 PM, Emil Velikov >> wrote: > >>> --- a/src/Makefile.am >>> +++ b/src/Makefile.am >>> @@ -23,6 +23,7 @@ SUBDIRS = . gtest util mapi/glapi/gen mapi >>> >>> # XXX: conditionally include >>> SUBDIRS += compiler >>> +SUBDIRS += compiler/nir >> >> We have a non-recursive build in src/glsl today. I don't want to go >> backwards. > Not sure I fully get that can you elaborate ? Are you concerned that > things won't build in parallel, increasing the compilation times ? > > On my dual core system running with -j2 results in approx 15 seconds > increase. I'm willing to take that trade off for the improved > readability. What is the difference on your system ? src/glsl has single Makefile that builds libglcpp, glcpp, libglsl, glsl_compiler, glsl_test, libnir, and various test programs, allowing all of these things to happen in parallel. The Makefile is perfectly maintainable as it is and there's no advantage of splitting it, especially when the work has been done to get things to this state (commits 86d30dea, efd201ca) and NIR was added without an additional Makefile. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 8/9] nir: move to compiler
On Nov 27, 2015 11:26 AM, "Matt Turner" wrote: > > On Fri, Nov 27, 2015 at 6:50 AM, Emil Velikov wrote: > > On 25 November 2015 at 22:01, Matt Turner wrote: > >> On Wed, Nov 25, 2015 at 1:32 PM, Emil Velikov wrote: > > > >>> --- a/src/Makefile.am > >>> +++ b/src/Makefile.am > >>> @@ -23,6 +23,7 @@ SUBDIRS = . gtest util mapi/glapi/gen mapi > >>> > >>> # XXX: conditionally include > >>> SUBDIRS += compiler > >>> +SUBDIRS += compiler/nir > >> > >> We have a non-recursive build in src/glsl today. I don't want to go backwards. > > Not sure I fully get that can you elaborate ? Are you concerned that > > things won't build in parallel, increasing the compilation times ? > > > > On my dual core system running with -j2 results in approx 15 seconds > > increase. I'm willing to take that trade off for the improved > > readability. What is the difference on your system ? > > src/glsl has single Makefile that builds libglcpp, glcpp, libglsl, > glsl_compiler, glsl_test, libnir, and various test programs, allowing > all of these things to happen in parallel. The Makefile is perfectly > maintainable as it is and there's no advantage of splitting it, > especially when the work has been done to get things to this state > (commits 86d30dea, efd201ca) and NIR was added without an additional > Makefile. I would tend to agree. Making things hierarchical is nice but, unfortunately, autotools makes this and parallelization mutually exclusive. ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: remove len argument from _mesa_shader_debug()
On Fri, 2015-11-27 at 13:16 +, Emil Velikov wrote: > There was only a single user which was using strlen(buf). > As this function is not user facing (i.e. we don't need to feed back > original length via a callback), we can simplify things. > Thanks for fixing this up. Reviewed-by: Timothy Arceri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/8] mesa: do not enable KHR_debug for ES 1.0
On Thu, 2015-11-26 at 14:08 +, Emil Velikov wrote: > On 26 November 2015 at 04:39, Timothy Arceri > wrote: > > On Thu, 2015-11-26 at 00:36 +, Emil Velikov wrote: > > > The extension requires (cough implements) GetPointervKHR (alias > > > of > > > GetPointerv) which in itself is available for ES 1.1 enabled > > > mesa. > > > > > > Anyone willing to fish around and implement it for ES 1.0 is more > > > than > > > welcome to revert this commit. Until then lets restrict things. > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93048 > > > Signed-off-by: Emil Velikov > > > --- > > > src/mapi/glapi/gen/KHR_debug.xml | 20 ++-- > > > src/mesa/main/extensions_table.h | 2 +- > > > 2 files changed, 11 insertions(+), 11 deletions(-) > > > > > > diff --git a/src/mapi/glapi/gen/KHR_debug.xml > > > b/src/mapi/glapi/gen/KHR_debug.xml > > > index 431a788..50daba3 100644 > > > --- a/src/mapi/glapi/gen/KHR_debug.xml > > > +++ b/src/mapi/glapi/gen/KHR_debug.xml > > > @@ -146,7 +146,7 @@ > > > > > > > > > > > > - > > alias="DebugMessageControl" es1="1.0" es2="2.0"> > > > + > > alias="DebugMessageControl" es1="1.1" es2="2.0"> > > > > > > > > > > > > @@ -155,7 +155,7 @@ > > > > > > > > > > > > - > > alias="DebugMessageInsert" > > > es1="1.0" es2="2.0"> > > > + > > alias="DebugMessageInsert" > > > es1="1.1" es2="2.0"> > > > > > > > > > > > > @@ -164,12 +164,12 @@ > > > > > > > > > > > > - > > alias="DebugMessageCallback" es1="1.0" es2="2.0"> > > > + > > alias="DebugMessageCallback" es1="1.1" es2="2.0"> > > > > > > > > > > > > > > > - > > alias="GetDebugMessageLog" > > > es1="1.0" es2="2.0"> > > > + > > alias="GetDebugMessageLog" > > > es1="1.1" es2="2.0"> > > > > > > > > > > > > @@ -186,23 +186,23 @@ > > > > > > > > > > > > - > > es1="1.0" es2="2.0"> > > > + > > es1="1.1" es2="2.0"> > > > > > > > > > > > > > > > > > > > > > - > > es1="1.0" > > > es2="2.0"/> > > > + > > es1="1.1" > > > es2="2.0"/> > > > > > > - > > es2="2.0"> > > > + > > es2="2.0"> > > > > > > > > > > > > > > > > > > > > > - > > es1="1.0" es2="2.0"> > > > + > > es1="1.1" es2="2.0"> > > > > > > > > > > > > @@ -210,13 +210,13 @@ > > > > > > > > > > > > - > > es1="1.0" es2="2.0"> > > > + > > es1="1.1" es2="2.0"> > > > > > > > > > > > > > > > > > > - > > alias="GetObjectPtrLabel" > > > es1="1.0" es2="2.0"> > > > + > > alias="GetObjectPtrLabel" > > > es1="1.1" es2="2.0"> > > > > > > > > > > > > diff --git a/src/mesa/main/extensions_table.h > > > b/src/mesa/main/extensions_table.h > > > index 051d69a..52a4ed6 100644 > > > --- a/src/mesa/main/extensions_table.h > > > +++ b/src/mesa/main/extensions_table.h > > > @@ -258,7 +258,7 @@ EXT(INGR_blend_func_separate, > > > EXT_blend_func_separate > > > EXT(INTEL_performance_query , > > > INTEL_performance_query, GLL, GLC, x , ES2, > > > 2013) > > > > > > EXT(KHR_context_flush_control , dummy_true > > > , GLL, GLC, x , ES2, 2014) > > > -EXT(KHR_debug , dummy_true > > > , GLL, GLC, ES1, ES2, 2012) > > > +EXT(KHR_debug , dummy_true > > > , GLL, GLC, 11, ES2, 2012) > > > > What is this table used for? > Two things 1) the classic "should we print the extension name in > glGetString(GL_EXTENSIONS)" and more accurate > _mesa_has_$extension_name. Latter is a new addition due to some bugs. > > > And why do we use 11 here? > > > > The top of the file defines GLL, GLC, ES1 and ES2 as 0 and x as ~0 > > why > > isn't this also 0? > > > > GLL, GLC... are "enable on any version of $API", while x is "always > disable for $API". Alternatively a number represents the minimum > required version for the said API. In that case it seems ok. Reviewed-by: Timothy Arceri > > -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 7/8] mesa: errors: validate the length of null terminated string
On Thu, 2015-11-26 at 00:36 +, Emil Velikov wrote:
> We're about to rework the meaning of gl_debug_message::length to
to only store ??
> store
> the user provided data. Thus we should add an explicit validation for
> null terminated strings.
>
> Signed-off-by: Emil Velikov
Reviewed-by: Timothy Arceri
> ---
> src/mesa/main/errors.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
> index 39e5642..79149a9 100644
> --- a/src/mesa/main/errors.c
> +++ b/src/mesa/main/errors.c
> @@ -960,8 +960,22 @@ error:
>
>
> static GLboolean
> -validate_length(struct gl_context *ctx, const char *callerstr,
> GLsizei length)
> +validate_length(struct gl_context *ctx, const char *callerstr,
> GLsizei length,
> +const GLchar *buf)
> {
> +
> + if (length < 0) {
> + GLsizei len = strlen(buf);
> +
> + if (len >= MAX_DEBUG_MESSAGE_LENGTH) {
> + _mesa_error(ctx, GL_INVALID_VALUE,
> +"%s(null terminated string length=%d, is not
> less than "
> +"GL_MAX_DEBUG_MESSAGE_LENGTH=%d)", callerstr,
> len,
> +MAX_DEBUG_MESSAGE_LENGTH);
> + return GL_FALSE;
> + }
> + }
> +
> if (length >= MAX_DEBUG_MESSAGE_LENGTH) {
>_mesa_error(ctx, GL_INVALID_VALUE,
> "%s(length=%d, which is not less than "
> @@ -992,7 +1006,7 @@ _mesa_DebugMessageInsert(GLenum source, GLenum
> type, GLuint id,
>
> if (length < 0)
>length = strlen(buf);
> - if (!validate_length(ctx, callerstr, length))
> + if (!validate_length(ctx, callerstr, length, buf))
>return; /* GL_INVALID_VALUE */
>
> log_msg(ctx, gl_enum_to_debug_source(source),
> @@ -1161,7 +1175,7 @@ _mesa_PushDebugGroup(GLenum source, GLuint id,
> GLsizei length,
>
> if (length < 0)
>length = strlen(message);
> - if (!validate_length(ctx, callerstr, length))
> + if (!validate_length(ctx, callerstr, length, message))
>return; /* GL_INVALID_VALUE */
>
> debug = _mesa_lock_debug_state(ctx);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 8/8] mesa: rework the meaning of gl_debug_message::length
On Thu, 2015-11-26 at 14:31 +, Emil Velikov wrote:
> On 26 November 2015 at 05:26, Timothy Arceri
> wrote:
> > On Thu, 2015-11-26 at 00:36 +, Emil Velikov wrote:
> > > Currently it stores strlen(buf) whenever the user originally
> > > provided
> > > a
> > > negative value for length.
> > >
> > > Although I've not seen any explicit text in the spec, CTS
> > > requires
> > > that
> > > the very same length (be that negative value or not) is returned
> > > back
> > > on
> > > Pop.
> > >
> > > So let's push down the length < 0 checks, tweak the meaning of
> > > gl_debug_message::length and fix GetDebugMessageLog to add and
> > > count
> > > the
> > > null terminators, as required by the spec.
> > >
> > > v2: return correct total length in GetDebugMessageLog
> > >
> > > XXX:
> > > - should we use -1, or strlen on ENOMEM in debug_message_store ?
> > > - split out the GetDebugMessageLog fixes into separate patch ?
> > > - split the "push the length < 0 check further down" into
> > > separate
> > > patch ?
> > >
> > > Signed-off-by: Emil Velikov
> > > ---
> > > src/mesa/main/errors.c | 43
> > >
> > > ---
> > > 1 file changed, 24 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/src/mesa/main/errors.c b/src/mesa/main/errors.c
> > > index 79149a9..78d21cc 100644
> > > --- a/src/mesa/main/errors.c
> > > +++ b/src/mesa/main/errors.c
> > > @@ -76,6 +76,8 @@ struct gl_debug_message
> > > enum mesa_debug_type type;
> > > GLuint id;
> > > enum mesa_debug_severity severity;
> > > + /* length as given by the user - if message was explicitly
> > > null
> > > terminated,
> > > +* length can be negative */
> > > GLsizei length;
> > > GLcharARB *message;
> > > };
> > > @@ -211,14 +213,19 @@ debug_message_store(struct gl_debug_message
> > > *msg,
> > > enum mesa_debug_severity severity,
> > > GLsizei len, const char *buf)
> > > {
> > > + GLsizei length = len;
> > > +
> > > assert(!msg->message && !msg->length);
> > >
> > > - msg->message = malloc(len+1);
> > > + if (length < 0)
> > > + length = strlen(buf);
> > > +
> > > + msg->message = malloc(length+1);
> > > if (msg->message) {
> > > - (void) strncpy(msg->message, buf, (size_t)len);
> > > - msg->message[len] = '\0';
> > > + (void) strncpy(msg->message, buf, (size_t)length);
> > > + msg->message[length] = '\0';
> > >
> > > - msg->length = len+1;
> > > + msg->length = len;
> > >msg->source = source;
> > >msg->type = type;
> > >msg->id = id;
> > > @@ -229,7 +236,7 @@ debug_message_store(struct gl_debug_message
> > > *msg,
> > >
> > >/* malloc failed! */
> > >msg->message = out_of_memory;
> > > - msg->length = strlen(out_of_memory)+1;
> > > + msg->length = -1;
> >
> > Why change this?
> >
> Because negative length now means "message is a null terminated
> string". This isn't a user provided string so it shouldn't matter.
> I'd
> rather keep things consistent though :-)
Ok makes sense I guess.
>
> > >msg->source = MESA_DEBUG_SOURCE_OTHER;
> > >msg->type = MESA_DEBUG_TYPE_ERROR;
> > >msg->id = oom_msg_id;
> > > @@ -607,7 +614,7 @@ debug_log_message(struct gl_debug_state
> > > *debug,
> > > GLint nextEmpty;
> > > struct gl_debug_message *emptySlot;
> > >
> > > - assert(len >= 0 && len < MAX_DEBUG_MESSAGE_LENGTH);
> > > + assert(len < MAX_DEBUG_MESSAGE_LENGTH);
> > >
> > > if (log->NumMessages == MAX_DEBUG_LOGGED_MESSAGES)
> > >return;
> > > @@ -1004,8 +1011,6 @@ _mesa_DebugMessageInsert(GLenum source,
> > > GLenum
> > > type, GLuint id,
> > > if (!validate_params(ctx, INSERT, callerstr, source, type,
> > > severity))
> > >return; /* GL_INVALID_ENUM */
> > >
> > > - if (length < 0)
> > > - length = strlen(buf);
> >
> > This should be in the previous patch.
> >
> > > if (!validate_length(ctx, callerstr, length, buf))
> > >return; /* GL_INVALID_VALUE */
> > >
> > > @@ -1047,23 +1052,28 @@ _mesa_GetDebugMessageLog(GLuint count,
> > > GLsizei logSize, GLenum *sources,
> > >
> > > for (ret = 0; ret < count; ret++) {
> > >const struct gl_debug_message *msg =
> > > debug_fetch_message(debug);
> > > + GLsizei len;
> > >
> > >if (!msg)
> > > break;
> > >
> > > - if (logSize < msg->length && messageLog != NULL)
> > > + len = msg->length;
> > > + if (len < 0)
> > > + len = strlen(msg->message);
> > > +
> > > + if (logSize < len+1 && messageLog != NULL)
> > > break;
> > >
> > >if (messageLog) {
> > > - assert(msg->message[msg->length-1] == '\0');
> > > - (void) strncpy(messageLog, msg->message, (size_t)msg
> > > ->length);
> > > + assert(msg->message[len] == '\0');
> > > + (void) strncpy(messageLog, msg->message,
> > > (size_t)len+1);
> > >
> > > -
[Mesa-dev] [Bug 93100] [IVB]piglit/spec/opengl_3.3/gl-3.2-layered-rendering-framebuffertexture fails
https://bugs.freedesktop.org/show_bug.cgi?id=93100 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #4 from Timothy Arceri --- This is not a Mesa bug so closing. For reference the Man page bug is being tracked here: https://www.khronos.org/bugzilla/show_bug.cgi?id=1419 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeon: only suspend queries on flush if they haven't been suspended yet
From: Nicolai Hähnle
Non-timer queries are suspended during blits. When the blits end, the queries
are resumed, but this resume operation itself might run out of CS space and
trigger a flush. When this happens, we must prevent a duplicate suspend during
preflush suspend, and we must also prevent a duplicate resume when the CS flush
returns back to the original resume operation.
This fixes a regression that was introduced by:
commit 8a125afa6e88a3eeddba8c7fdc1a75c9b99d5489
Author: Nicolai Hähnle
Date: Wed Nov 18 18:40:22 2015 +0100
radeon: ensure that timing/profiling queries are suspended on flush
The queries_suspended_for_flush flag is redundant because suspended queries
are not removed from their respective linked list.
Reviewed-by: Marek Olšák
Reported-by: Axel Davy
Cc: "11.1"
---
src/gallium/drivers/radeon/r600_pipe_common.c | 10 --
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index f03dcd9..aaea8fe 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -136,8 +136,12 @@ static void r600_memory_barrier(struct pipe_context *ctx,
unsigned flags)
void r600_preflush_suspend_features(struct r600_common_context *ctx)
{
/* suspend queries */
- if (!LIST_IS_EMPTY(&ctx->active_nontimer_queries))
+ if (ctx->num_cs_dw_nontimer_queries_suspend) {
+ /* Since non-timer queries are suspended during blits,
+* we have to guard against double-suspends. */
r600_suspend_nontimer_queries(ctx);
+ ctx->nontimer_queries_suspended_by_flush = true;
+ }
if (!LIST_IS_EMPTY(&ctx->active_timer_queries))
r600_suspend_timer_queries(ctx);
@@ -158,8 +162,10 @@ void r600_postflush_resume_features(struct
r600_common_context *ctx)
/* resume queries */
if (!LIST_IS_EMPTY(&ctx->active_timer_queries))
r600_resume_timer_queries(ctx);
- if (!LIST_IS_EMPTY(&ctx->active_nontimer_queries))
+ if (ctx->nontimer_queries_suspended_by_flush) {
+ ctx->nontimer_queries_suspended_by_flush = false;
r600_resume_nontimer_queries(ctx);
+ }
}
static void r600_flush_from_st(struct pipe_context *ctx,
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 253d657..a4f3fce 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -396,6 +396,7 @@ struct r600_common_context {
struct list_headactive_nontimer_queries;
struct list_headactive_timer_queries;
unsignednum_cs_dw_nontimer_queries_suspend;
+ boolnontimer_queries_suspended_by_flush;
unsignednum_cs_dw_timer_queries_suspend;
/* Additional hardware info. */
unsignedbackend_mask;
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon: only suspend queries on flush if they haven't been suspended yet
Tested-by: Axel Davy
On 28/11/2015 00:24, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Non-timer queries are suspended during blits. When the blits end, the queries
are resumed, but this resume operation itself might run out of CS space and
trigger a flush. When this happens, we must prevent a duplicate suspend during
preflush suspend, and we must also prevent a duplicate resume when the CS flush
returns back to the original resume operation.
This fixes a regression that was introduced by:
commit 8a125afa6e88a3eeddba8c7fdc1a75c9b99d5489
Author: Nicolai Hähnle
Date: Wed Nov 18 18:40:22 2015 +0100
radeon: ensure that timing/profiling queries are suspended on flush
The queries_suspended_for_flush flag is redundant because suspended queries
are not removed from their respective linked list.
Reviewed-by: Marek Olšák
Reported-by: Axel Davy
Cc: "11.1"
---
src/gallium/drivers/radeon/r600_pipe_common.c | 10 --
src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
b/src/gallium/drivers/radeon/r600_pipe_common.c
index f03dcd9..aaea8fe 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.c
+++ b/src/gallium/drivers/radeon/r600_pipe_common.c
@@ -136,8 +136,12 @@ static void r600_memory_barrier(struct pipe_context *ctx,
unsigned flags)
void r600_preflush_suspend_features(struct r600_common_context *ctx)
{
/* suspend queries */
- if (!LIST_IS_EMPTY(&ctx->active_nontimer_queries))
+ if (ctx->num_cs_dw_nontimer_queries_suspend) {
+ /* Since non-timer queries are suspended during blits,
+* we have to guard against double-suspends. */
r600_suspend_nontimer_queries(ctx);
+ ctx->nontimer_queries_suspended_by_flush = true;
+ }
if (!LIST_IS_EMPTY(&ctx->active_timer_queries))
r600_suspend_timer_queries(ctx);
@@ -158,8 +162,10 @@ void r600_postflush_resume_features(struct r600_common_context *ctx)
/* resume queries */
if (!LIST_IS_EMPTY(&ctx->active_timer_queries))
r600_resume_timer_queries(ctx);
- if (!LIST_IS_EMPTY(&ctx->active_nontimer_queries))
+ if (ctx->nontimer_queries_suspended_by_flush) {
+ ctx->nontimer_queries_suspended_by_flush = false;
r600_resume_nontimer_queries(ctx);
+ }
}
static void r600_flush_from_st(struct pipe_context *ctx,
diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
b/src/gallium/drivers/radeon/r600_pipe_common.h
index 253d657..a4f3fce 100644
--- a/src/gallium/drivers/radeon/r600_pipe_common.h
+++ b/src/gallium/drivers/radeon/r600_pipe_common.h
@@ -396,6 +396,7 @@ struct r600_common_context {
struct list_headactive_nontimer_queries;
struct list_headactive_timer_queries;
unsignednum_cs_dw_nontimer_queries_suspend;
+ boolnontimer_queries_suspended_by_flush;
unsignednum_cs_dw_timer_queries_suspend;
/* Additional hardware info. */
unsignedbackend_mask;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon: only suspend queries on flush if they haven't been suspended yet
Reviewed-by: Marek Olšák
Marek
On Sat, Nov 28, 2015 at 12:24 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Non-timer queries are suspended during blits. When the blits end, the queries
> are resumed, but this resume operation itself might run out of CS space and
> trigger a flush. When this happens, we must prevent a duplicate suspend during
> preflush suspend, and we must also prevent a duplicate resume when the CS
> flush
> returns back to the original resume operation.
>
> This fixes a regression that was introduced by:
>
> commit 8a125afa6e88a3eeddba8c7fdc1a75c9b99d5489
> Author: Nicolai Hähnle
> Date: Wed Nov 18 18:40:22 2015 +0100
>
> radeon: ensure that timing/profiling queries are suspended on flush
>
> The queries_suspended_for_flush flag is redundant because suspended
> queries
> are not removed from their respective linked list.
>
> Reviewed-by: Marek Olšák
>
> Reported-by: Axel Davy
> Cc: "11.1"
> ---
> src/gallium/drivers/radeon/r600_pipe_common.c | 10 --
> src/gallium/drivers/radeon/r600_pipe_common.h | 1 +
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.c
> b/src/gallium/drivers/radeon/r600_pipe_common.c
> index f03dcd9..aaea8fe 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.c
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.c
> @@ -136,8 +136,12 @@ static void r600_memory_barrier(struct pipe_context
> *ctx, unsigned flags)
> void r600_preflush_suspend_features(struct r600_common_context *ctx)
> {
> /* suspend queries */
> - if (!LIST_IS_EMPTY(&ctx->active_nontimer_queries))
> + if (ctx->num_cs_dw_nontimer_queries_suspend) {
> + /* Since non-timer queries are suspended during blits,
> +* we have to guard against double-suspends. */
> r600_suspend_nontimer_queries(ctx);
> + ctx->nontimer_queries_suspended_by_flush = true;
> + }
> if (!LIST_IS_EMPTY(&ctx->active_timer_queries))
> r600_suspend_timer_queries(ctx);
>
> @@ -158,8 +162,10 @@ void r600_postflush_resume_features(struct
> r600_common_context *ctx)
> /* resume queries */
> if (!LIST_IS_EMPTY(&ctx->active_timer_queries))
> r600_resume_timer_queries(ctx);
> - if (!LIST_IS_EMPTY(&ctx->active_nontimer_queries))
> + if (ctx->nontimer_queries_suspended_by_flush) {
> + ctx->nontimer_queries_suspended_by_flush = false;
> r600_resume_nontimer_queries(ctx);
> + }
> }
>
> static void r600_flush_from_st(struct pipe_context *ctx,
> diff --git a/src/gallium/drivers/radeon/r600_pipe_common.h
> b/src/gallium/drivers/radeon/r600_pipe_common.h
> index 253d657..a4f3fce 100644
> --- a/src/gallium/drivers/radeon/r600_pipe_common.h
> +++ b/src/gallium/drivers/radeon/r600_pipe_common.h
> @@ -396,6 +396,7 @@ struct r600_common_context {
> struct list_headactive_nontimer_queries;
> struct list_headactive_timer_queries;
> unsignednum_cs_dw_nontimer_queries_suspend;
> + boolnontimer_queries_suspended_by_flush;
> unsignednum_cs_dw_timer_queries_suspend;
> /* Additional hardware info. */
> unsignedbackend_mask;
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 4/6] mesa: enable enums for OES_geometry_shader
On Friday, November 27, 2015 01:08:08 PM Ilia Mirkin wrote: > On Fri, Nov 27, 2015 at 9:31 AM, Marta Lofstedt > wrote: [snip] > > @@ -1174,6 +1199,21 @@ check_extra(struct gl_context *ctx, const char > > *func, const struct value_desc *d > > api_found = ctx->Extensions.ARB_shader_image_load_store && > > _mesa_has_tessellation(ctx); > > break; > > + case EXTRA_EXT_GPU5_GS: > > + api_check = GL_TRUE; > > + api_found = (ctx->Extensions.ARB_framebuffer_no_attachments && > > + _mesa_has_geometry_shaders(ctx)); > > What does this have to do with ARB_gpu_shader5? FWIW, OES_geometry_shader includes instanced geometry shaders, which on desktop GL were introduced with ARB_gpu_shader5. I haven't read this to know whether that explains this code, but the two are related :) signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93114] No water rendered in CoR
https://bugs.freedesktop.org/show_bug.cgi?id=93114 --- Comment #11 from Kenneth Graunke --- Last I checked this was a very buggy GL application, so beware... -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02.5/11] i965/vec4: Stop pretending to support indirect output stores
On Thursday, November 26, 2015 12:10:15 AM Jason Ekstrand wrote:
> Since we're using nir_lower_outputs_to_temporaries to shadow all our
> outputs, it's impossible to actually get an indirect store. The code we
> had to "handle" this was pretty bogus as it created a register with a
> reladdr and then stuffed it in a fixed varying slot without so much as a
> MOV. Not only does this not do the MOV, it also puts the indirect on the
> wrong side of the transaction. Let's just delete the broken dead code.
> ---
>
> This was squashed into patch 3 but probably deserves its own patch.
>
> src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> index 96787db..8e06d6b 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> @@ -393,21 +393,15 @@ vec4_visitor::nir_emit_intrinsic(nir_intrinsic_instr
> *instr)
> }
>
> case nir_intrinsic_store_output_indirect:
> - has_indirect = true;
> - /* fallthrough */
> + unreachable("nir_lower_outputs_to_temporaries should prevent this");
> +
> case nir_intrinsic_store_output: {
>int varying = instr->const_index[0];
>
>src = get_nir_src(instr->src[0], BRW_REGISTER_TYPE_F,
> instr->num_components);
> - dest = dst_reg(src);
>
> - if (has_indirect) {
> - dest.reladdr = new(mem_ctx) src_reg(get_nir_src(instr->src[1],
> - BRW_REGISTER_TYPE_D,
> - 1));
> - }
> - output_reg[varying] = dest;
> + output_reg[varying] = dst_reg(src);
>break;
> }
>
>
This patch is:
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Don't mark dead instructions' sources live.
On Wednesday, November 25, 2015 06:14:28 PM Matt Turner wrote:
> Removes dead code from glsl-mat-from-int-ctor-03.shader_test.
>
> Reported-by: Juan A. Suarez Romero
> ---
> src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 4
> src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp | 4
> 2 files changed, 8 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
> index a50cf6f..6b4b602 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
> @@ -109,6 +109,10 @@ fs_visitor::dead_code_eliminate()
> BITSET_CLEAR(flag_live, inst->flag_subreg);
> }
>
> + /* Don't mark dead instructions' sources as live */
> + if (inst->opcode == BRW_OPCODE_NOP)
> +continue;
> +
> for (int i = 0; i < inst->sources; i++) {
> if (inst->src[i].file == VGRF) {
> int var = live_intervals->var_from_reg(inst->src[i]);
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
> b/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
> index 58aed81..369941b 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
> @@ -150,6 +150,10 @@ vec4_visitor::dead_code_eliminate()
> BITSET_CLEAR(flag_live, c);
> }
>
> + /* Don't mark dead instructions' sources as live */
> + if (inst->opcode == BRW_OPCODE_NOP)
> +continue;
> +
> for (int i = 0; i < 3; i++) {
> if (inst->src[i].file == VGRF) {
> for (unsigned j = 0; j < inst->regs_read(i); j++) {
>
This is
Reviewed-by: Kenneth Graunke
A while back I grumbled at you and Tapani about not updating
inst->sources and leaving junk source registers in place when mutating
an instruction to change its opcode.
If inst->sources were updated correctly when converting to NOP (i.e. set
to 0), you would not have this bug, as the loop over sources would not
happen. You wouldn't need to special case NOP here, either.
Which actually makes me wonder: if we convert from ADD to MOV (or
similar), do we leave a bogus src[1] in place and treat it as live?
Presumably most cases where that happens are because we did algebraic
optimizations involving IMMs, so the extra live thing would be an
immediate and not cause any trouble...
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] clover: Check the return value of pipe_loader_probe() when probing for devices
When probing for devices, clover will call pipe_loader_probe() twice.
The first time to retrieve the number of devices, and then second time
to retrieve the device structures.
We currently assume that the return value of both calls will be the
same, but this will not be the case if a device happens to disappear
between the two calls.
This patch removes this assumption and checks the return value of the
second pipe_loader_probe() call to ensure it does not try to initialize
devices that no longer exits.
CC:
---
src/gallium/state_trackers/clover/core/platform.cpp | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/clover/core/platform.cpp
b/src/gallium/state_trackers/clover/core/platform.cpp
index 328b71c..689d692 100644
--- a/src/gallium/state_trackers/clover/core/platform.cpp
+++ b/src/gallium/state_trackers/clover/core/platform.cpp
@@ -28,9 +28,10 @@ platform::platform() : adaptor_range(evals(), devs) {
int n = pipe_loader_probe(NULL, 0);
std::vector ldevs(n);
- pipe_loader_probe(&ldevs.front(), n);
+ n = pipe_loader_probe(&ldevs.front(), n);
- for (pipe_loader_device *ldev : ldevs) {
+ for (int i = 0; i < n; ++i) {
+ pipe_loader_device *ldev = ldevs[i];
try {
devs.push_back(create(*this, ldev));
} catch (error &) {
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Don't mark dead instructions' sources live.
On Fri, Nov 27, 2015 at 7:32 PM, Kenneth Graunke wrote:
> On Wednesday, November 25, 2015 06:14:28 PM Matt Turner wrote:
>> Removes dead code from glsl-mat-from-int-ctor-03.shader_test.
>>
>> Reported-by: Juan A. Suarez Romero
>> ---
>> src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp | 4
>> src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp | 4
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
>> index a50cf6f..6b4b602 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs_dead_code_eliminate.cpp
>> @@ -109,6 +109,10 @@ fs_visitor::dead_code_eliminate()
>> BITSET_CLEAR(flag_live, inst->flag_subreg);
>> }
>>
>> + /* Don't mark dead instructions' sources as live */
>> + if (inst->opcode == BRW_OPCODE_NOP)
>> +continue;
>> +
>> for (int i = 0; i < inst->sources; i++) {
>> if (inst->src[i].file == VGRF) {
>> int var = live_intervals->var_from_reg(inst->src[i]);
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
>> b/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
>> index 58aed81..369941b 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4_dead_code_eliminate.cpp
>> @@ -150,6 +150,10 @@ vec4_visitor::dead_code_eliminate()
>> BITSET_CLEAR(flag_live, c);
>> }
>>
>> + /* Don't mark dead instructions' sources as live */
>> + if (inst->opcode == BRW_OPCODE_NOP)
>> +continue;
>> +
>> for (int i = 0; i < 3; i++) {
>> if (inst->src[i].file == VGRF) {
>> for (unsigned j = 0; j < inst->regs_read(i); j++) {
>>
>
> This is
> Reviewed-by: Kenneth Graunke
Thanks!
> A while back I grumbled at you and Tapani about not updating
> inst->sources and leaving junk source registers in place when mutating
> an instruction to change its opcode.
I suspect you're thinking about commit bb33a31c and Tapani's fix
commit 627c6830. The bug Tapani's commit fixed had nothing to do with
inst->sources or left behind junk in the src[] array. I can't find
where you said anything on list, but I have a memory of talking about
it in person.
The story is, none of the opt_algebraic code (except Curro's more
recent SHADER_OPCODE_BROADCAST additions) modifies inst->sources --
most of the code predates LOAD_PAYLOAD (the reason inst->sources
exists). When I made commit bb33a31c, I just kept doing what the
existing code does: set unused sources to reg_undef.
> If inst->sources were updated correctly when converting to NOP (i.e. set
> to 0), you would not have this bug, as the loop over sources would not
> happen. You wouldn't need to special case NOP here, either.
That's not true.
You could set inst->sources to 0, but you'd also unset inst->predicate
so that reads_flag() doesn't return true. And, you'd have to figure
out something different to do in the vec4 backend, because it doesn't
have inst->sources. Also, there are three places in the DCE where we
decide an instruction is dead, so you'd have to do those steps in
three different places, while *still* setting opcode = NOP.
Or, you can just look for opcode == NOP, which I think is a much
better solution especially since it's what you have to do in order to
find and delete the instruction later anyway. opcode == NOP is *the*
uniquely identifying piece of information to determine if the
instruction is dead.
> Which actually makes me wonder: if we convert from ADD to MOV (or
> similar), do we leave a bogus src[1] in place and treat it as live?
> Presumably most cases where that happens are because we did algebraic
> optimizations involving IMMs, so the extra live thing would be an
> immediate and not cause any trouble...
No, we set dead sources to reg_undef in opt_algebraic.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 93114] No water rendered in CoR
https://bugs.freedesktop.org/show_bug.cgi?id=93114 Jason Ekstrand changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |NOTOURBUG --- Comment #12 from Jason Ekstrand --- (In reply to Kenneth Graunke from comment #11) > Last I checked this was a very buggy GL application, so beware... I think that just got justified... Given that fglrx also renders the trace wrong, it sounds like a bug in the game. I'm closing this as NOTOURBUG. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/1] i965: Do not overwrite optimizer dumps
On Nov 27, 2015 3:55 AM, "Juan A. Suarez Romero"
wrote:
>
> When using INTEL_DEBUG=optimizer, each optimizing step is dump to disk,
> in a separate file.
>
> But as fs_visitor::optimize() and vec4_visitor::run() are called more
> than once, it ends up overwriting the files already on disk, loosing
> then previous optimizer steps.
>
> To avoid this, add a new static variable that tracks the global
> iteration across the entire life of the program running.
>
> v2: use atomic_inc() for the static variable (Jason).
>
> v3: define local variable as const (Jason).
>
> Signed-off-by: Juan A. Suarez Romero
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +
> src/mesa/drivers/dri/i965/brw_vec4.cpp | 13 -
> 2 files changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index 7904f4d..eee9e1d 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -39,6 +39,7 @@
> #include "brw_program.h"
> #include "brw_dead_control_flow.h"
> #include "glsl/nir/glsl_types.h"
> +#include "util/u_atomic.h"
>
> using namespace brw;
>
> @@ -4948,6 +4949,9 @@ fs_visitor::calculate_register_pressure()
> void
> fs_visitor::optimize()
> {
> + static int global_iteration_atomic = 0;
> + const int global_iteration =
p_atomic_inc_return(&global_iteration_atomic);
> +
> /* Start by validating the shader we currently have. */
> validate();
>
> @@ -4978,8 +4982,9 @@ fs_visitor::optimize()
> \
>if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && this_progress) { \
> char filename[64]; \
> - snprintf(filename, 64, "%s%d-%s-%02d-%02d-" #pass,
\
> - stage_abbrev, dispatch_width, nir->info.name,
iteration, pass_num); \
> + snprintf(filename, 64, "%s%d-%s-%02d-%02d-%02d-" #pass,\
> + stage_abbrev, dispatch_width, nir->info.name, \
> + global_iteration, iteration, pass_num); \
> \
> backend_shader::dump_instructions(filename); \
>} \
> @@ -4992,8 +4997,8 @@ fs_visitor::optimize()
>
> if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
>char filename[64];
> - snprintf(filename, 64, "%s%d-%s-00-start",
> - stage_abbrev, dispatch_width, nir->info.name);
> + snprintf(filename, 64, "%s%d-%s-%02d-00-00-start",
> + stage_abbrev, dispatch_width, nir->info.name,
global_iteration);
>
>backend_shader::dump_instructions(filename);
> }
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> index 9a79d67..7909f1d 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
> @@ -29,6 +29,7 @@
> #include "brw_vec4_live_variables.h"
> #include "brw_dead_control_flow.h"
> #include "program/prog_parameter.h"
> +#include "util/u_atomic.h"
>
> #define MAX_INSTRUCTION (1 << 30)
>
> @@ -1779,6 +1780,9 @@ vec4_visitor::convert_to_hw_regs()
> bool
> vec4_visitor::run()
> {
> + static int global_iteration_atomic = 0;
> + const int global_iteration =
p_atomic_inc_return(&global_iteration_atomic);
> +
> if (shader_time_index >= 0)
>emit_shader_time_begin();
>
> @@ -1812,8 +1816,8 @@ vec4_visitor::run()
> \
>if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER) && this_progress) { \
> char filename[64];\
> - snprintf(filename, 64, "%s-%s-%02d-%02d-" #pass, \
> - stage_abbrev, nir->info.name, iteration, pass_num); \
> + snprintf(filename, 64, "%s-%s-%02d-%02d-%02d-" #pass, \
> + stage_abbrev, nir->info.name, global_iteration,
iteration, pass_num); \
> \
> backend_shader::dump_instructions(filename); \
>}\
> @@ -1822,11 +1826,10 @@ vec4_visitor::run()
>this_progress; \
> })
>
> -
Unneeded white space change.
Other than that, this looks much better.
Reviewed-by: Jason Ekstrand
I'd like to get Matt's OK before pushing anything though. He may yet have
a better idea about how to make things properly unique.
> if (unlikely(INTEL_DEBUG & DEBUG_OPTIMIZER)) {
>char filename[64];
> - snprintf(filename, 64, "%s-%s-00-start",
> - stage_abbrev, nir->info.name);
> + snprintf(filename, 64, "%s-%s-%02d-00
