Re: [Mesa-dev] COMPSIZE function in OpenGL XML registry

2015-06-10 Thread Ian Romanick
On 06/10/2015 11:25 AM, Shervin Sharifi wrote:
> Hi,
>  
>  This may not be the right forum to ask this, but I didn't know of a
> better forum, so I thought I can ask here.
> 
>  I'm new to OpenGL. I am looking at XML registry for OpenGL and there
> are some parameters with attributes containing a function COMPSIZE (I've
> pasted an example below).
>  I tried to find information on what the COMPSIZE function is, where/how
> it is used, etc, but couldn't find documentation or credible information
> on the Internet.
>  Any information or pointer to that would be really helpful. 

It's a signal to code generation scripts that the size of the data
referenced by the "pointer" parameter depends on the values of "type"
and "stride".  For example, GLX protocol code uses this to know how much
image data to send to the server for glTexImage2D.

>  Thanks, 
> Shervin
> 
> 
> 
> This example is from gl.xml in the OpenGL registry:
> 
> 
> void glBinormalPointerEXT
> GLenum
> type
> GLsizei stride
> const void
> *pointer
> 
> 
> 
> ___
> 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] COMPSIZE function in OpenGL XML registry

2015-06-10 Thread Ian Romanick
On 06/10/2015 03:05 PM, Shervin Sharifi wrote:
> Thanks Ian.
> If I want to implement the actual CompSize function, how should I figure
> out the details? 

The way I did it for the GLX protocol code in Mesa is to make a
glFoo_compsize function for each GL function that has a variable sized
array as input.  Often these functions can be shared (e.g., the function
for glTexParameteriv and glTexParameterfv are the same).

You have to read the docs to figure out that, for example, passing
GL_TEXTURE_BASE_LEVEL to glTexParameteriv means there's 1 value but
passing GL_TEXTURE_BORDER_COLOR means there are 4 values.  I implemented
that in Mesa (many years before the current Khronos XML existed) by
having additional decorations in my XML.  Each enum specifies which
functions can use it and how many values it carries.

The Khronos XML specifies which enums can be passed to which functions
(via ), but it doesn't look like it has any information about how
much data goes along with it. :(

> Thanks, 
>Shervin
> 
> On Wed, Jun 10, 2015 at 2:56 PM, Ian Romanick  <mailto:i...@freedesktop.org>> wrote:
> 
> On 06/10/2015 11:25 AM, Shervin Sharifi wrote:
> > Hi,
> >
> >  This may not be the right forum to ask this, but I didn't know of a
> > better forum, so I thought I can ask here.
> >
> >  I'm new to OpenGL. I am looking at XML registry for OpenGL and there
> > are some parameters with attributes containing a function COMPSIZE (I've
> > pasted an example below).
> >  I tried to find information on what the COMPSIZE function is, where/how
> > it is used, etc, but couldn't find documentation or credible information
> > on the Internet.
> >  Any information or pointer to that would be really helpful.
> 
> It's a signal to code generation scripts that the size of the data
> referenced by the "pointer" parameter depends on the values of "type"
> and "stride".  For example, GLX protocol code uses this to know how much
> image data to send to the server for glTexImage2D.
> 
> >  Thanks,
> > Shervin
> >
> >
> >
> > This example is from gl.xml in the OpenGL registry:
> >
> > 
> > void glBinormalPointerEXT
> > GLenum
> > type
> > GLsizei stride
> > const void
> > *pointer
> > 
> >
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org <mailto: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] [Mesa-stable] [PATCH] egl/x11: Set version of swrastLoader to 2

2015-06-16 Thread Ian Romanick
Gak... I thought we fixed all of those. :(

Reviewed-by: Ian Romanick 

On 06/15/2015 08:08 PM, Boyan Ding wrote:
> which it actually implements instead of the newest version defined in
> dri_interface.h
> 
> Cc: "10.5 10.6" 
> Signed-off-by: Boyan Ding 
> ---
>  src/egl/drivers/dri2/platform_x11.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/egl/drivers/dri2/platform_x11.c 
> b/src/egl/drivers/dri2/platform_x11.c
> index f1101d6..53717b3 100644
> --- a/src/egl/drivers/dri2/platform_x11.c
> +++ b/src/egl/drivers/dri2/platform_x11.c
> @@ -1112,7 +1112,7 @@ dri2_initialize_x11_swrast(_EGLDriver *drv, _EGLDisplay 
> *disp)
>goto cleanup_conn;
>  
> dri2_dpy->swrast_loader_extension.base.name = __DRI_SWRAST_LOADER;
> -   dri2_dpy->swrast_loader_extension.base.version = 
> __DRI_SWRAST_LOADER_VERSION;
> +   dri2_dpy->swrast_loader_extension.base.version = 2;
> dri2_dpy->swrast_loader_extension.getDrawableInfo = swrastGetDrawableInfo;
> dri2_dpy->swrast_loader_extension.putImage = swrastPutImage;
> dri2_dpy->swrast_loader_extension.getImage = swrastGetImage;
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/5] darwin: Suppress type conversion warnings for GLhandleARB

2015-06-18 Thread Ian Romanick
On 06/17/2015 10:53 PM, Julien Isorce wrote:
> From: Jon TURNEY 
> 
> On darwin, GLhandleARB is defined as a void *, not the unsigned int it is on
> linux.
> 
> For the moment, apply a cast to supress the warning
> 
> Possibly this is safe, as for the mesa software renderer the shader program
> handle is not a real pointer, but a integer handle
> 
> Probably this is not the right thing to do, and we should pay closer attention
> to how the GLhandlerARB type is used.

In Mesa, glBindAttribLocation (which takes GLuint) and
glBindAttribLocationARB (which takes GLhandleARB) are *the same
function*.  The same applies to pretty much all the other GLhandleARB
functions.  Disentangling them would require an ABI break on Linux.
That just isn't going to happen...

...unless we decide to have a flag day and do a major amount of clean up
on the libGL <-> driver interface.  Before that is even contemplated, we
need to finish the rewrite / refactor of the glapi generator scripts and
get moved over to the Khronos XML.  Dylan has been working on this, but
I don't know how much progress he has made lately.

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66346
> Signed-off-by: Jon TURNEY 
> ---
>  src/mesa/main/shader_query.cpp | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/main/shader_query.cpp b/src/mesa/main/shader_query.cpp
> index a6246a3..e3a1213 100644
> --- a/src/mesa/main/shader_query.cpp
> +++ b/src/mesa/main/shader_query.cpp
> @@ -69,7 +69,7 @@ _mesa_BindAttribLocation(GLhandleARB program, GLuint index,
> GET_CURRENT_CONTEXT(ctx);
>  
> struct gl_shader_program *const shProg =
> -  _mesa_lookup_shader_program_err(ctx, program, "glBindAttribLocation");
> +  _mesa_lookup_shader_program_err(ctx, (uintptr_t)program, 
> "glBindAttribLocation");
> if (!shProg)
>return;
>  
> @@ -137,7 +137,7 @@ _mesa_GetActiveAttrib(GLhandleARB program, GLuint 
> desired_index,
>return;
> }
>  
> -   shProg = _mesa_lookup_shader_program_err(ctx, program, 
> "glGetActiveAttrib");
> +   shProg = _mesa_lookup_shader_program_err(ctx, (uintptr_t)program, 
> "glGetActiveAttrib");
> if (!shProg)
>return;
>  
> @@ -251,7 +251,7 @@ _mesa_GetAttribLocation(GLhandleARB program, const 
> GLcharARB * name)
>  {
> GET_CURRENT_CONTEXT(ctx);
> struct gl_shader_program *const shProg =
> -  _mesa_lookup_shader_program_err(ctx, program, "glGetAttribLocation");
> +  _mesa_lookup_shader_program_err(ctx, (uintptr_t)program, 
> "glGetAttribLocation");
>  
> if (!shProg) {
>return -1;
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] glsl: Specify the shader stage in linker errors due to too many in/outputs.

2015-06-22 Thread Ian Romanick
This patch is

Reviewed-by: Ian Romanick 

On 06/19/2015 06:08 AM, Jose Fonseca wrote:
> ---
>  src/glsl/link_varyings.cpp | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
> index 7b2d4bd..278a778 100644
> --- a/src/glsl/link_varyings.cpp
> +++ b/src/glsl/link_varyings.cpp
> @@ -1540,13 +1540,15 @@ check_against_output_limit(struct gl_context *ctx,
> const unsigned output_components = output_vectors * 4;
> if (output_components > max_output_components) {
>if (ctx->API == API_OPENGLES2 || prog->IsES)
> - linker_error(prog, "shader uses too many output vectors "
> + linker_error(prog, "%s shader uses too many output vectors "
>"(%u > %u)\n",
> +  _mesa_shader_stage_to_string(producer->Stage),
>output_vectors,
>max_output_components / 4);
>else
> - linker_error(prog, "shader uses too many output components "
> + linker_error(prog, "%s shader uses too many output components "
>"(%u > %u)\n",
> +  _mesa_shader_stage_to_string(producer->Stage),
>output_components,
>max_output_components);
>  
> @@ -1579,13 +1581,15 @@ check_against_input_limit(struct gl_context *ctx,
> const unsigned input_components = input_vectors * 4;
> if (input_components > max_input_components) {
>if (ctx->API == API_OPENGLES2 || prog->IsES)
> - linker_error(prog, "shader uses too many input vectors "
> + linker_error(prog, "%s shader uses too many input vectors "
>"(%u > %u)\n",
> +  _mesa_shader_stage_to_string(consumer->Stage),
>input_vectors,
>max_input_components / 4);
>else
> - linker_error(prog, "shader uses too many input components "
> + linker_error(prog, "%s shader uses too many input components "
>"(%u > %u)\n",
> +  _mesa_shader_stage_to_string(consumer->Stage),
>input_components,
>max_input_components);
>  
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/2] glsl: handle conversions to double when comparing param matches

2015-06-22 Thread Ian Romanick
This seems believable... is there a piglit test?

On 06/17/2015 12:15 PM, Ilia Mirkin wrote:
> This allows mod(int, int) to become selected as float mod when doubles
> are supported.
> 
> Signed-off-by: Ilia Mirkin 
> Cc: "10.6" 
> ---
>  src/glsl/ir_function.cpp | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/src/glsl/ir_function.cpp b/src/glsl/ir_function.cpp
> index 2b2643c..1319443 100644
> --- a/src/glsl/ir_function.cpp
> +++ b/src/glsl/ir_function.cpp
> @@ -148,9 +148,11 @@ get_parameter_match_type(const ir_variable *param,
> if (from_type == to_type)
>return PARAMETER_EXACT_MATCH;
>  
> -   /* XXX: When ARB_gpu_shader_fp64 support is added, check for 
> float->double,
> -* and int/uint->double conversions
> -*/
> +   if (to_type->base_type == GLSL_TYPE_DOUBLE) {
> +  if (from_type->base_type == GLSL_TYPE_FLOAT)
> + return PARAMETER_FLOAT_TO_DOUBLE;
> +  return PARAMETER_INT_TO_DOUBLE;
> +   }
>  
> if (to_type->base_type == GLSL_TYPE_FLOAT)
>return PARAMETER_INT_TO_FLOAT;
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/2] glsl: Fix counting of varyings.

2015-06-22 Thread Ian Romanick
On 06/19/2015 06:08 AM, Jose Fonseca wrote:
> When input and output varyings started to be counted separately (commit
> 42305fb5) the is_varying_var function wasn't updated to return true for
> output varyings or input varyings for stages other than the fragment
> shader), effectively making the varying limit to never be checked.

Without SSO, counting the varying inputs used by, say, the fragment
shader, should be sufficient.  With SSO, it's more difficult.

> With this change, color, texture coord, and generic varyings are not
> counted, but others are ignored.  It is assumed the hardware will handle
> special varyings internally (ie, optimistic rather than pessimistic), to
> avoid causing regressions where things were working somehow.
> 
> This fixes `glsl-max-varyings --exceed-limits` with softpipe/llvmpipe,
> which was asserting because we were getting varyings beyond
> VARYING_SLOT_MAX in st_glsl_to_tgsi.cpp.
> 
> It also prevents the assertion failure with
> https://bugs.freedesktop.org/show_bug.cgi?id=90539 but the tests still
> fails due to the link error.
> 
> This change also adds a few assertions to catch this sort of errors
> earlier, and potentially prevent buffer overflows in the future (no
> buffer overflow was detected here though).
> 
> However, this change causes several tests to regress:
> 
>   spec/glsl-1.10/execution/varying-packing/simple ivec3 array
>   spec/glsl-1.10/execution/varying-packing/simple ivec3 separate
>   spec/glsl-1.10/execution/varying-packing/simple uvec3 array
>   spec/glsl-1.10/execution/varying-packing/simple uvec3 separate

Wait... so the ivec3 and uvec3 tests fail, but the vec3 test passes?

>   spec/arb_gpu_shader_fp64/varying-packing/simple dmat3 array
>   spec/glsl-1.50/execution/geometry/max-input-components
>   spec/glsl-1.50/execution/variable-indexing/gs-input-array-vec4-index-rd
>   
> spec/glsl-1.50/execution/variable-indexing/vs-output-array-vec4-index-wr-before-gs
> 
> But this all seem to be issues either in the way we count varyings
> (e.g., geometry inputs get counted multiple times) or in the tests
> themselves, or limitations in the varying packer, and deserve attention
> on their own right.

Do you have a feeling for which tests are which sorts of problems?

I'd like to run this through GLES3 conformance before it gets pushed.
I'm not too worried about the geometry shader issues, but the ivec /
uvec tests seem more problematic.

> ---
>  src/glsl/link_varyings.cpp | 70 
> --
>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  2 +
>  2 files changed, 58 insertions(+), 14 deletions(-)
> 
> diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
> index 278a778..7649720 100644
> --- a/src/glsl/link_varyings.cpp
> +++ b/src/glsl/link_varyings.cpp
> @@ -190,6 +190,8 @@ cross_validate_outputs_to_inputs(struct gl_shader_program 
> *prog,
>*/
>   const unsigned idx = var->data.location - VARYING_SLOT_VAR0;
>  
> + assert(idx < MAX_VARYING);
> +
>   if (explicit_locations[idx] != NULL) {
>  linker_error(prog,
>   "%s shader has multiple outputs explicitly "
> @@ -1031,25 +1033,63 @@ varying_matches::match_comparator(const void 
> *x_generic, const void *y_generic)
>  /**
>   * Is the given variable a varying variable to be counted against the
>   * limit in ctx->Const.MaxVarying?
> - * This includes variables such as texcoords, colors and generic
> - * varyings, but excludes variables such as gl_FrontFacing and gl_FragCoord.
> + *
> + * OpenGL specification states:

Please use the canonical format.

* Section A.B (Foo Bar) of the OpenGL X.Y Whichever Profile spec
* says:

That enables later readers to more easily find the text in the spec.
Also, the language changes from time to time.

> + *
> + *   Each output variable component used as either a vertex shader output or
> + *   fragment shader input counts against this limit, except for the 
> components
> + *   of gl_Position. A program containing only a vertex and fragment shader

This bit about gl_Position is tricky... I believe this language has
changed more than once in the spec.  It's also the reason the varying
limit has changed from 64 components to 60 components.  I don't think
that affects this patch... it's just a thing I thought was worth
pointing out.

> + *   that accesses more than this limit's worth of components of outputs may
> + *   fail to link, unless device-dependent optimizations are able to make the
> + *   program fit within available hardware resources.
> + *
>   */
>  static bool
>  var_counts_against_varying_limit(gl_shader_stage stage, const ir_variable 
> *var)
>  {
> -   /* Only fragment shaders will take a varying variable as an input */
> -   if (stage == MESA_SHADER_FRAGMENT &&
> -   var->data.mode == ir_var_shader_in) {
> -  switch (var->data.location) {
> -  case VARYING_SLOT_POS:
> -  case VARYING_SLOT_FACE:
> -  ca

Re: [Mesa-dev] abundance of branches in mesa.git

2015-06-22 Thread Ian Romanick
On 06/22/2015 10:40 AM, Marek Olšák wrote:
> I will happily remove the branch after the kernel driver lands.
> 
> I also wonder why all Mesa developers can force-push branches in Mesa
> but not libdrm.

That's probably just historical.  We probably ought to restrict that on
Mesa as well.

It sounds like you guys have some requirements for a shared repo.  It
seems like a repo on fd.o could work.  I think you'd just need a
"amddevs" group and make the repo group rwx.  I thought fd.o GIT did
https (maybe just SSH?).

> Marek
> 
> On Mon, Jun 22, 2015 at 5:39 PM, Ilia Mirkin  wrote:
>> On Mon, Jun 22, 2015 at 11:30 AM, Christian König
>>  wrote:
>>> On 22.06.2015 15:41, Ilia Mirkin wrote:

 On Mon, Jun 22, 2015 at 9:39 AM, Tom Stellard  wrote:
>
> On Mon, Jun 22, 2015 at 12:23:54PM +0200, Marek Olšák wrote:
>>
>> On Mon, Jun 22, 2015 at 5:36 AM, Ilia Mirkin 
>> wrote:
>>>
>>> On Sun, Jun 21, 2015 at 11:33 PM, Michel Dänzer 
>>> wrote:

 On 22.06.2015 00:31, Ilia Mirkin wrote:
>
> On Sun, Jun 21, 2015 at 12:22 PM, Emil Velikov
>  wrote:
>>
>> On 20/06/15 10:01, Eirik Byrkjeflot Anonsen wrote:
>>>
>>> Ilia Mirkin  writes:
>>>
 Hello,

 There are a *ton* of branches in the upstream mesa git. Here is a
 full list:

>>> [...]

 is there
 any reason to keep these around with the exception of:

 master
 $version (i.e. 9.0, 10.0, mesa_7_7_branch, etc)
>>>
>>> Instead of outright deleting old branches, it would be possible to
>>> set
>>> up an "archive" repository which mirrors all branches of the main
>>> repository. And then delete "obsolete" branches only from the main
>>> repository. Ideally, you would want a git hook to refuse to create
>>> a new
>>> branch (in the main repository) if a branch by that name already
>>> exists
>>> in the archive repository. Possibly with the exception that
>>> creating a
>>> same-named branch on the same commit would be allowed.
>>>
>>> (And the same for tags, of course)
>>>
>> Personally I am fine with either approach - stay/nuke/move. But I'm
>> thinking that having a mix of the two suggestions might be a nice
>> middle
>> ground.
>>
>> Write a script that nukes branches that are merged in master (check
>> the
>> top commit of the branch) and have an 'archive' repo that contains
>> everything else (minus the stable branches).

 Sounds good to me, FWIW.


> That still leaves a ton around, and curiously removes mesa_7_5 and
> mesa_7_6.

 I think the latter is expected, we were using a different branching
 model back in those days.


> origin/amdgpu

 Note that this is a currently active branch, to be merged to master
 soon.
>>>
>>> Perhaps there's something I don't understand, but why is a feature
>>> branch made available on the shared tree? In my view of things the
>>> only branches on the shared mesa.git tree should be the version
>>> branches.
>>
>> As you can see, a lot of feature branches are in the shared tree
>> already, so there is a precedent. Sharing a branch among people in
>> this way sometimes tends to be more convenient.
>>
>> The reason here is that it's the only mesa repository where most
>> people from our team have commit access.
>>
> Also, the shared git tree supports https access, which means it is
> accessible when behind a firewall.

 OK, well if that's the prevailing attitude, then I'm on a fool's
 errand, and I'll just drop this.
>>>
>>>
>>> I still think it would be a good idea to archive the branches after a while,
>>> cause the current status is rather confusing if you search for something
>>> specifc.
>>
>> Yeah, but if the policy is "create random branches whenever you feel
>> like on the upstream mesa tree", then this same current situation will
>> happen again, so it's not really worth fixing now (at least for me).
>> I'm not aware of any other major project with this sort of branching
>> policy, but I guess there's always a first!
>>
>> I don't really see why you wouldn't just use a shared tree in
>> someone's ~/foo, chgrp'd to mesa or some other convenient group, or
>> how https plays into things, but I'm sure there's some reason for it.
>> [Or why those amdgpu patches are on a branch in the first place rather
>> than in master.] If the final state isn't a tree with a policy of not
>> adding (non-release) branches, I don't think I'm particularly
>> interested in doing the legwork.
>>
>> Cheers,
>>
>>   -ilia
>> __

Re: [Mesa-dev] [PATCH 00/11] glapi fixes - build whole of mesa with

2015-06-22 Thread Ian Romanick
On 06/22/2015 07:01 AM, Jose Fonseca wrote:
> On 19/06/15 23:09, Emil Velikov wrote:
>> On 19 June 2015 at 21:26, Jose Fonseca  wrote:
>>> On 19/06/15 20:56, Emil Velikov wrote:

 Hi all,

 A lovely series inspired (more like 'was awaken to send these out') by
 Pal Rohár, who was having issues when building xlib-libgl (plus the now
 enabled gles*)

 So here, we teach the final two static glapi users about shared-glapi,
 plus some related fixes. After this is done we can finally start
 transitioning to shared-only glapi, with some more details as mentioned
 in one of the patches:

   XXX: With this one done, we can finally transition with enforcing
   shared-glapi, and

- link the dri modules against libglapi.so, add
 --no-undefined to
   the LDFLAGS
- drop the dlopen(libglapi.so/libGL.so, RTLD_GLOBAL) workarounds
   in the loaders - libGL, libEGL and libgbm.
- start killing off/cleaning up the dispatch ?

   The caveats:
   1) up to what stage do we care about static libraries
- libgl (either dri or xlib based)
- osmesa
- libEGL

   2) how about other platforms (scons) ?
- currently the scons uses static glapi,
- would we need the dlopen(...) on windows ?

 Hope everyone is excited about this one as I am :-)
>>>
>>>
>>> Maybe I missed the context of this changes, but why this matters or
>>> is an
>>> improvement?
>>>
>> If one goes the extra mile (which this series doesn't) - one configure
>> option less, substantial some code de-duplication and consistent use
>> of the code amongst all components provided. This way any
>> improvements/cleanups made to the shared glapi will be available to
>> osmesa/xlib-libgl.
> 
> I'm perfectly happy with removing the configure option.
> 
> And I understand the benefits of unified code paths, but I believe that
> for this particular case, the difference in requirements really demands
> the separate code paths.
> 
>>> In summary, having the ability of using a shared glapi sounds great, but
>>> forcing shared glapi everywhere, sounds a bad idea.
>>>
>> I'm suspecting that people might be keen on the following idea - use
>> static glapi for osmesa/xlib-libgl and shared one everywhere else?
> 
> Yes, that sounds reasonable for me.  (Needs libgl-gdi too.)
> 
>>
>> I fear that this will lead to further separation/bit-rot between the
>> different implementations, but it seems like the bester compromise.
> 
> I don't feel strongly between: a) using the same source code for both
> static/shared glapi (switched by a pre-processor define), or b) only
> share the interface but have shared/static glapi implementations.  I'm
> actually not that familiar with that code.
> 
> 
> Either way, we can have two glapi build targets (a shared-glapi and a
> static-glapipe) side-by-side, so that there are no more source-wide
> configure flags.
> 
> 
> I believe a lot of the complexity of that code comes from assembly.  I
> wonder if it's really justified nowadays (and even if it is, whether it
> would be better served with GNU C assembly.) Futhermore, I believe on
> Windows we use any assembly, so if we split shared/static glapi source
> code, we could probably abandon assembly from the static-glapi.

It comes from the intersection of the assembly and the myriad threading
options.  Having TLS and shared-glapi is the only "option" for DRI
builds would be terrific.  We have a couple work loads that, especially
on Atom CPUs, are sensitive to any added overhead.  My recollection was
that GCC does not generate the code you want for the dispatch functions.

I feel like we keeping coming around to the loader/driver interface
needing some significant work.  I certainly have a bunch of ideas for
how things could be improved.  I'll start working on a proposal.

> Jose
> ___
> 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


[Mesa-dev] [PATCH] radeon: Advertise correct GL_SAMPLES_PASSED value.

2015-06-22 Thread Ian Romanick
From: Ian Romanick 

Commit b765119c changed the default value of all the counter bits to
64.  However, older hardware only has 32 counter bits.

This has only been build-tested.  We don't have any tests that verify
the advertised value against implementation behavior, so I don't know
what additional testing could be done.

NOTE: It appears that many Gallium drivers (at least r300 and i915g)
have the same problem, but I don't see a way for the state-tracker to
determine the counter size.

Signed-off-by: Ian Romanick 
Cc: Marek Olšák 
Cc: Alex Deucher 
---
 .../drivers/dri/radeon/radeon_common_context.c | 23 ++
 1 file changed, 23 insertions(+)

diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.c 
b/src/mesa/drivers/dri/radeon/radeon_common_context.c
index 9699dcb..3d0ceda 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common_context.c
+++ b/src/mesa/drivers/dri/radeon/radeon_common_context.c
@@ -194,6 +194,29 @@ GLboolean radeonInitContext(radeonContextPtr radeon,
 
radeon_init_dma(radeon);
 
+/* _mesa_initialize_context calls _mesa_init_queryobj which
+ * initializes all of the counter sizes to 64.  The counters on r100
+ * and r200 are only 32-bits for occlusion queries.  Those are the
+ * only counters, so set the other sizes to zero.
+ */
+radeon->glCtx.Const.QueryCounterBits.SamplesPassed = 32;
+
+radeon->glCtx.Const.QueryCounterBits.TimeElapsed = 0;
+radeon->glCtx.Const.QueryCounterBits.Timestamp = 0;
+radeon->glCtx.Const.QueryCounterBits.PrimitivesGenerated = 0;
+radeon->glCtx.Const.QueryCounterBits.PrimitivesWritten = 0;
+radeon->glCtx.Const.QueryCounterBits.VerticesSubmitted = 0;
+radeon->glCtx.Const.QueryCounterBits.PrimitivesSubmitted = 0;
+radeon->glCtx.Const.QueryCounterBits.VsInvocations = 0;
+radeon->glCtx.Const.QueryCounterBits.TessPatches = 0;
+radeon->glCtx.Const.QueryCounterBits.TessInvocations = 0;
+radeon->glCtx.Const.QueryCounterBits.GsInvocations = 0;
+radeon->glCtx.Const.QueryCounterBits.GsPrimitives = 0;
+radeon->glCtx.Const.QueryCounterBits.FsInvocations = 0;
+radeon->glCtx.Const.QueryCounterBits.ComputeInvocations = 0;
+radeon->glCtx.Const.QueryCounterBits.ClInPrimitives = 0;
+radeon->glCtx.Const.QueryCounterBits.ClOutPrimitives = 0;
+
return GL_TRUE;
 }
 
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [RFC] Compatibility between old dri modules and new loaders, and vice verse

2015-06-22 Thread Ian Romanick
On 06/22/2015 11:54 AM, Dave Airlie wrote:
>>
>> As kindly hinted by Marek, currently we do have a wide selection of
>> supported dri <> loader combinations.
>>
>> Although we like to think that things never break, we have to admit
>> that not many of us test every possible combinations of dri modules
>> and loaders. With the chances getting smaller as the time gap (age)
>> between the two increases. As such I would like to ask if we're
>> interested in gradually depreciating as the gap grows beyond X years.
>>
>> The rough idea that I have in my mind is:
>> - Check for obsolete extensions (requirements for such) - both in the
>> dri modules and the loaders (including the xserver).
>> - Add some WARN messages ("You're using an old loader/DRI module.
>> Update to XXX or later") when such code path is hit.
>> - After X mesa releases, we remove the dri extension from the
>> module(s) and bump the requirement(s) in the loader(s).
>>
>> And now the more important question why ?
>>  - Very rarely tested and not actively supported - if it works it
>> works, we only cover one stable branch.
>>  - Having a quick look at the the "if extension && extension.version
>>> = y" maze does leave most of us speechless.
>>  - Will allow us to start removing a few of the nasty quirks/hacks
>> that we currently have laying around.
>>
>> Worth mentioning:
>>  - Depreciation period will be based on the longest time frame set by
>> LTS versions of distros. For example if Debian A ships X and mesa 3
>> years apart, while Ubuntu does is ~2.5 and RedHat ~2.8, we'll stick
>> with 3 years.
>>  - libGL dri1 support... it's been almost four years since the removal
>> of the dri1 modules. Since then the only activity that I've noticed by
>> Connor Behan on the r128 front. Although it seems that he has covered
>> the ddx and is just looking at the kernel side of things. Should we
>> consider mesa X (10.6 ?) as the last one that supports such old
>> modules in it's libGL and give it a much needed cleanup ?
>>
>>
>> How would people feel about this - do we have any strong ack/nack
>> about the idea ? Are there many people/companies that support distros
>> where the xserver <> mesa gap is over, say 2 years ?
> 
> We still ship 7.11 based dri1 drivers in RHEL6, and there is still a
> chance of us rebasing to newer Mesa in that depending on schedules.
> 
> ajax might have a different opinion, on how likely that is, but
> that would be at least another year from now where we'd want DRI1
> to work.

A time line would be good.  I think it will take a fair amount of time
to get a new loader<>driver interface in order.  If we can't change
anything for two years, then there's not a lot of point to thinking
about it now.  If it's a year or less away, that's a different story.

The other possibility would be for RHEL to ship more than one libGL...
one for DRI1 drivers and one for everything else.  I don't know how
horrible that would be.

> Dave.
> ___
> 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] Fix strict-aliasing violations in GLSL shader list implementation

2015-06-23 Thread Ian Romanick
On 06/23/2015 02:36 PM, Thomas Helland wrote:
> 2015-06-24 23:05 GMT+02:00 Davin McCall :
>> Hi - I'm new here.
>>
>> I've recently started poking the Mesa codebase for little reason other than
>> personal interest. In the "help wanted" section of the website it mentions
>> aliasing violations as a target for newcomers to fix, so with that in mind
>> I've attached a patch (against git head) which resolves a few of them, by
>> targeting the linked list implementation (list.h) used in the GLSL
>> compiler/optimizers. This change slightly increases the storage requirements
>> for a list (adds one word) but resolves the blatant aliasing violation that
>> was caused by the trick used to conserve that word in the first place.
>>
>> (I toyed with another approach - using a single sentinel node for both the
>> head and tail of a list - but this was much more invasive, and meant that
>> you could no longer check whether a particular node was a sentinel node
>> unless you had a reference to the list, so I gave up and went with this
>> simpler approach).
>>
>> The most essential change is in the 'exec_list' structure. Three fields
>> 'head', 'tail' and 'tail_pred' are removed, and two separate sentinel nodes
>> are inserted in their place. The old 'head' is replaced by
>> 'head_sentinel.next', 'tail_pred' by 'tail_sentinel.prev', and tail (always
>> NULL) by 'head_sentinel.prev' and 'tail_sentinel.next' (both always NULL).

NAK.  The datastructure is correct as-is.  It has been in common use
since at least 1985.  See the references in the header file.

>> With this patch, I can build a working (though perhaps not 100% bug-free)
>> Mesa without using -fno-strict-aliasing during compilation. Before the
>> patch, applications using Mesa would hang at runtime.
>>
>> I don't really know the process you have in place so if I need to do
>> anything else to get this patch into the codebase please let me know. Any
>> comments and criticisms welcome.
>>
>> Davin
>>
>>
> 
> Hi Davin,
> 
> Welcome aboard the Mesa-boat!
> I haven't really looked at your patch
> (I'll leave that to someone who knows the code),
> but here's a few pointers on how things work around here.
> (I see Ilia already answered you)
> 
> Have a look at http://www.mesa3d.org/devinfo.html.
> This has most of the info you need on how to send patches
> and how your source code should be formatted.
> 
> We try to limit lines to aprox 78 chars (no more than 80).
> Patches also should have a "location" for the change in the subject.
> (In your patch: [PATCH] glsl: Fix strict-aliasing...)
> And subjects in present tense, but you got that right =)
> 
> Until you get commit access someone else will have to
> push the patches to upstream for you (usually the reviewer).
> 
> That's a few points of the top of my head.
> If there's anything else feel free to ask.
> I'm not the most experienced guy in here, but I guess I'm at
> least able to answer most of your practical questions =)
> 
> -Thomas
> ___
> 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] Fix strict-aliasing violations in GLSL shader list implementation

2015-06-23 Thread Ian Romanick
On 06/24/2015 03:59 PM, Davin McCall wrote:
> Hi Ian,
> 
> On 23/06/15 23:26, Ian Romanick wrote:
>> On 06/23/2015 02:36 PM, Thomas Helland wrote:
>>> 2015-06-24 23:05 GMT+02:00 Davin McCall :
>>>> Hi - I'm new here.
>>>>
>>>> I've recently started poking the Mesa codebase for little reason other than
>>>> personal interest. In the "help wanted" section of the website it mentions
>>>> aliasing violations as a target for newcomers to fix, so with that in mind
>>>> I've attached a patch (against git head) which resolves a few of them, by
>>>> targeting the linked list implementation (list.h) used in the GLSL
>>>> compiler/optimizers. This change slightly increases the storage 
>>>> requirements
>>>> for a list (adds one word) but resolves the blatant aliasing violation that
>>>> was caused by the trick used to conserve that word in the first place.
>>>>
>>>> (I toyed with another approach - using a single sentinel node for both the
>>>> head and tail of a list - but this was much more invasive, and meant that
>>>> you could no longer check whether a particular node was a sentinel node
>>>> unless you had a reference to the list, so I gave up and went with this
>>>> simpler approach).
>>>>
>>>> The most essential change is in the 'exec_list' structure. Three fields
>>>> 'head', 'tail' and 'tail_pred' are removed, and two separate sentinel nodes
>>>> are inserted in their place. The old 'head' is replaced by
>>>> 'head_sentinel.next', 'tail_pred' by 'tail_sentinel.prev', and tail (always
>>>> NULL) by 'head_sentinel.prev' and 'tail_sentinel.next' (both always NULL).
>> NAK.  The datastructure is correct as-is.  It has been in common use
>> since at least 1985.  See the references in the header file.
> 
> I understand the data structure and how it is supposed to work; the
> issue is that the trick it employs cannot be implemented in C without
> breaking the strict aliasing rules (or at least, the current
> implementation in Mesa breaks the strict aliasing rules). The current
> code works correctly only with the -fno-strict-aliasing compiler option.
> The issue is that a pair of 'exec_node *' do not constitute an exec_node
> in the eyes of the language spec, even though exec_node is declared as
> holding two such pointers. Consider (from src/glsl/list.h):
> 
> static inline void
> exec_list_make_empty(struct exec_list *list)
> {
>list->head = (struct exec_node *) & list->tail;
>list->tail = NULL;
>list->tail_pred = (struct exec_node *) & list->head;
> }
> 
> 
> 'list->head' is of type 'struct exec_node *', and so should point at a
> 'struct  exec_node'. In the code above it is instead co-erced to point
> at a 'struct exec_node *' (list->tail). That in itself doesn't break the
> alias rules, but then:
> 
> static inline bool
> exec_node_is_tail_sentinel(const struct exec_node *n)
> {
>return n->next == NULL;
> }
> 
> 
> In 'exec_node_is_tail_sentinel', the sentinel is not actually an
> exec_node - it is &list->tail. So, if the parameter n does refer to the
> sentinel, then it does not point to an actual exec_node structure.
> However, it is de-referenced (by 'n->next') which breaks the strict
> aliasing rules. This means that the method above can only ever return
> false, unless it violates the aliasing rules.
> 
> (The above method could be fixed by casting n to an 'struct exec_node
> **' and then comparing '**n' against NULL. However, there are other
> similar examples throughout the code that I do not think would be so
> trivial).
> 
> I can quote the relevant parts of the standard if necessary, but your
> tone somewhat implies that you wouldn't even consider this patch?

Please quote the spec.  I have a hard time believing that the compiler
magically decides that an exec_node* is not really an exec_node* and
just does whatever it wants (which sounds like what you're describing).
 That sounds pretty rubbish... and I'm surprised that anything works in
such an environment.

Mesa has also had -fno-strict-aliasing for as long as I can remember,
and this structure has only been used here for a few years.  The whole
thing just doesn't smell right.

> Davin

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Fix strict-aliasing violations in GLSL shader list implementation

2015-06-23 Thread Ian Romanick
On 06/23/2015 07:01 PM, Dave Airlie wrote:
> On 24 June 2015 at 11:44, Ian Romanick  wrote:
>> On 06/24/2015 03:59 PM, Davin McCall wrote:
>>> Hi Ian,
>>>
>>> On 23/06/15 23:26, Ian Romanick wrote:
>>>> On 06/23/2015 02:36 PM, Thomas Helland wrote:
>>>>> 2015-06-24 23:05 GMT+02:00 Davin McCall :
>>>>>> Hi - I'm new here.
>>>>>>
>>>>>> I've recently started poking the Mesa codebase for little reason other 
>>>>>> than
>>>>>> personal interest. In the "help wanted" section of the website it 
>>>>>> mentions
>>>>>> aliasing violations as a target for newcomers to fix, so with that in 
>>>>>> mind
>>>>>> I've attached a patch (against git head) which resolves a few of them, by
>>>>>> targeting the linked list implementation (list.h) used in the GLSL
>>>>>> compiler/optimizers. This change slightly increases the storage 
>>>>>> requirements
>>>>>> for a list (adds one word) but resolves the blatant aliasing violation 
>>>>>> that
>>>>>> was caused by the trick used to conserve that word in the first place.
>>>>>>
>>>>>> (I toyed with another approach - using a single sentinel node for both 
>>>>>> the
>>>>>> head and tail of a list - but this was much more invasive, and meant that
>>>>>> you could no longer check whether a particular node was a sentinel node
>>>>>> unless you had a reference to the list, so I gave up and went with this
>>>>>> simpler approach).
>>>>>>
>>>>>> The most essential change is in the 'exec_list' structure. Three fields
>>>>>> 'head', 'tail' and 'tail_pred' are removed, and two separate sentinel 
>>>>>> nodes
>>>>>> are inserted in their place. The old 'head' is replaced by
>>>>>> 'head_sentinel.next', 'tail_pred' by 'tail_sentinel.prev', and tail 
>>>>>> (always
>>>>>> NULL) by 'head_sentinel.prev' and 'tail_sentinel.next' (both always 
>>>>>> NULL).
>>>> NAK.  The datastructure is correct as-is.  It has been in common use
>>>> since at least 1985.  See the references in the header file.
>>>
>>> I understand the data structure and how it is supposed to work; the
>>> issue is that the trick it employs cannot be implemented in C without
>>> breaking the strict aliasing rules (or at least, the current
>>> implementation in Mesa breaks the strict aliasing rules). The current
>>> code works correctly only with the -fno-strict-aliasing compiler option.
>>> The issue is that a pair of 'exec_node *' do not constitute an exec_node
>>> in the eyes of the language spec, even though exec_node is declared as
>>> holding two such pointers. Consider (from src/glsl/list.h):
>>>
>>> static inline void
>>> exec_list_make_empty(struct exec_list *list)
>>> {
>>>list->head = (struct exec_node *) & list->tail;
>>>list->tail = NULL;
>>>list->tail_pred = (struct exec_node *) & list->head;
>>> }
>>>
>>>
>>> 'list->head' is of type 'struct exec_node *', and so should point at a
>>> 'struct  exec_node'. In the code above it is instead co-erced to point
>>> at a 'struct exec_node *' (list->tail). That in itself doesn't break the
>>> alias rules, but then:
>>>
>>> static inline bool
>>> exec_node_is_tail_sentinel(const struct exec_node *n)
>>> {
>>>return n->next == NULL;
>>> }
>>>
>>>
>>> In 'exec_node_is_tail_sentinel', the sentinel is not actually an
>>> exec_node - it is &list->tail. So, if the parameter n does refer to the
>>> sentinel, then it does not point to an actual exec_node structure.
>>> However, it is de-referenced (by 'n->next') which breaks the strict
>>> aliasing rules. This means that the method above can only ever return
>>> false, unless it violates the aliasing rules.
>>>
>>> (The above method could be fixed by casting n to an 'struct exec_node
>>> **' and then comparing '**n' against 

Re: [Mesa-dev] [PATCH 03/11] radeon: remove dri_mirror state

2015-07-09 Thread Ian Romanick
On 07/08/2015 10:07 AM, Emil Velikov wrote:
> Most of the data stored(duplicated) was unused, and for the one that is
> follow the approach set by other drivers.
> This eliminates the use of legacy (dri1) types.
> 
> XXX: The radeon code is the only user of __DRIscreen::drm_version (the
> only __DRIversion outside of dri1 land). Should we move it into radeon
> and/or bump the min. required drm module version ?
> 
> Cc: Ian Romanick 

Reviewed-by: Ian Romanick 

I think the cleanups suggested by Michel and Emil sound like a good idea
too, FWIW.

> Cc: Marek Olšák 
> Cc: Michel Dänzer 
> Signed-off-by: Emil Velikov 
> ---
>  src/mesa/drivers/dri/radeon/radeon_common.c | 18 +-
>  src/mesa/drivers/dri/radeon/radeon_common_context.c |  7 ++-
>  src/mesa/drivers/dri/radeon/radeon_common_context.h | 19 +++
>  src/mesa/drivers/dri/radeon/radeon_texture.c|  2 +-
>  4 files changed, 15 insertions(+), 31 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/radeon/radeon_common.c 
> b/src/mesa/drivers/dri/radeon/radeon_common.c
> index 2a8bd6c9..d834d9b 100644
> --- a/src/mesa/drivers/dri/radeon/radeon_common.c
> +++ b/src/mesa/drivers/dri/radeon/radeon_common.c
> @@ -164,7 +164,7 @@ uint32_t radeonGetAge(radeonContextPtr radeon)
>  
>   gp.param = RADEON_PARAM_LAST_CLEAR;
>   gp.value = (int *)&age;
> - ret = drmCommandWriteRead(radeon->dri.fd, DRM_RADEON_GETPARAM,
> + ret = drmCommandWriteRead(radeon->radeonScreen->driScreen->fd, 
> DRM_RADEON_GETPARAM,
> &gp, sizeof(gp));
>   if (ret) {
>   fprintf(stderr, "%s: drmRadeonGetParam: %d\n", __func__,
> @@ -358,8 +358,8 @@ void radeonDrawBuffer( struct gl_context *ctx, GLenum 
> mode )
> * that the front-buffer has actually been allocated.
> */
>   if (!was_front_buffer_rendering && 
> radeon->is_front_buffer_rendering) {
> - radeon_update_renderbuffers(radeon->dri.context,
> - radeon->dri.context->driDrawablePriv, GL_FALSE);
> + radeon_update_renderbuffers(radeon->driContext,
> + radeon->driContext->driDrawablePriv, GL_FALSE);
>}
>   }
>  
> @@ -375,8 +375,8 @@ void radeonReadBuffer( struct gl_context *ctx, GLenum 
> mode )
>   || (mode == GL_FRONT);
>  
>   if (!was_front_buffer_reading && 
> rmesa->is_front_buffer_reading) {
> - radeon_update_renderbuffers(rmesa->dri.context,
> - 
> rmesa->dri.context->driReadablePriv, GL_FALSE);
> + radeon_update_renderbuffers(rmesa->driContext,
> + 
> rmesa->driContext->driReadablePriv, GL_FALSE);
>   }
>   }
>   /* nothing, until we implement h/w glRead/CopyPixels or CopyTexImage */
> @@ -399,7 +399,7 @@ void radeon_window_moved(radeonContextPtr radeon)
>  void radeon_viewport(struct gl_context *ctx)
>  {
>   radeonContextPtr radeon = RADEON_CONTEXT(ctx);
> - __DRIcontext *driContext = radeon->dri.context;
> + __DRIcontext *driContext = radeon->driContext;
>   void (*old_viewport)(struct gl_context *ctx);
>  
>   if (_mesa_is_winsys_fbo(ctx->DrawBuffer)) {
> @@ -693,6 +693,7 @@ void rcommonInitCmdBuf(radeonContextPtr rmesa)
>  {
>   GLuint size;
>   struct drm_radeon_gem_info mminfo = { 0 };
> + int fd = rmesa->radeonScreen->driScreen->fd;
>  
>   /* Initialize command buffer */
>   size = 256 * driQueryOptioni(&rmesa->optionCache,
> @@ -711,8 +712,7 @@ void rcommonInitCmdBuf(radeonContextPtr rmesa)
>   "Allocating %d bytes command buffer (max state is %d 
> bytes)\n",
>   size * 4, rmesa->hw.max_state_size * 4);
>  
> - rmesa->cmdbuf.csm =
> - radeon_cs_manager_gem_ctor(rmesa->radeonScreen->driScreen->fd);
> + rmesa->cmdbuf.csm = radeon_cs_manager_gem_ctor(fd);
>   if (rmesa->cmdbuf.csm == NULL) {
>   /* FIXME: fatal error */
>   return;
> @@ -725,7 +725,7 @@ void rcommonInitCmdBuf(radeonContextPtr rmesa)
> (void (*)(void *))rmesa->glCtx.Driver.Flush, 
> &rmesa->glCtx);
>  
>  
> - if (!drmCommandWriteRead(rmesa->dri.fd, DRM_RADEON_GEM_INFO,
> + if (!drmCommandWriteRead(fd, DRM_RADEON_GEM_INFO,
>&mminfo, sizeof(mminfo))) {
>   

Re: [Mesa-dev] [PATCH 04/11] dri_interface: drop __NOT_HAVE_DRM_H magic

2015-07-09 Thread Ian Romanick
On 07/08/2015 10:07 AM, Emil Velikov wrote:
> Signed-off-by: Emil Velikov 
> ---
>  include/GL/internal/dri_interface.h | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index c827bb6..c0545b1 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -40,20 +40,9 @@
>  #ifndef DRI_INTERFACE_H
>  #define DRI_INTERFACE_H
>  
> -/* For archs with no drm.h */
> -#if defined(__APPLE__) || defined(__CYGWIN__) || defined(__GNU__)
> -#ifndef __NOT_HAVE_DRM_H
> -#define __NOT_HAVE_DRM_H
> -#endif
> -#endif
> -
> -#ifndef __NOT_HAVE_DRM_H

Shouldn't this get changed to use HAVE_LIBDRM as in later patches?  I
guess drm_context_t and drm_drawable_t are ABI, so they shouldn't ever
change.  It does feel a little icky to redefine them when not necessary.

> -#include 
> -#else
>  typedef unsigned int drm_context_t;
>  typedef unsigned int drm_drawable_t;
>  typedef struct drm_clip_rect drm_clip_rect_t;
> -#endif
>  
>  /**
>   * \name DRI interface structures
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 06/11] loader: use HAVE_LIBDRM instead of ! __NOT_HAVE_DRM_H

2015-07-09 Thread Ian Romanick
I can't really speak to the Android.mk or SConscript changes, but the
rest of this patch is

Reviewed-by: Ian Romanick 

You might also see what Jeremy Huddleston Sequoia 
thinks, since most of this exists to support his platform. :)

On 07/08/2015 10:07 AM, Emil Velikov wrote:
> Double negatives in English language are normally avoided, plus the
> former seems cleaner and more consistent.
> 
> Signed-off-by: Emil Velikov 
> ---
>  src/loader/Android.mk  | 6 ++
>  src/loader/Makefile.am | 5 +
>  src/loader/SConscript  | 2 --
>  src/loader/loader.c| 8 
>  src/loader/pci_id_driver_map.c | 2 +-
>  5 files changed, 8 insertions(+), 15 deletions(-)
> 
> diff --git a/src/loader/Android.mk b/src/loader/Android.mk
> index 92d9fd2..8690565 100644
> --- a/src/loader/Android.mk
> +++ b/src/loader/Android.mk
> @@ -33,10 +33,8 @@ include $(CLEAR_VARS)
>  LOCAL_SRC_FILES := \
>   $(LOADER_C_FILES)
>  
> -# swrast only
> -ifeq ($(MESA_GPU_DRIVERS),swrast)
> -LOCAL_CFLAGS += -D__NOT_HAVE_DRM_H
> -else
> +ifneq ($(filter-out swrast,$(MESA_GPU_DRIVERS)),)
> +LOCAL_CFLAGS += -DHAVE_LIBDRM
>  LOCAL_SHARED_LIBRARIES := libdrm
>  endif
>  
> diff --git a/src/loader/Makefile.am b/src/loader/Makefile.am
> index aef1bd6..5190f7f 100644
> --- a/src/loader/Makefile.am
> +++ b/src/loader/Makefile.am
> @@ -48,10 +48,7 @@ libloader_la_CPPFLAGS += \
>  
>  endif
>  
> -if !HAVE_LIBDRM
> -libloader_la_CPPFLAGS += \
> - -D__NOT_HAVE_DRM_H
> -else
> +if HAVE_LIBDRM
>  libloader_la_CPPFLAGS += \
>   $(LIBDRM_CFLAGS)
>  
> diff --git a/src/loader/SConscript b/src/loader/SConscript
> index 16d1053..d98f11e 100644
> --- a/src/loader/SConscript
> +++ b/src/loader/SConscript
> @@ -8,8 +8,6 @@ env.Prepend(CPPPATH = [
>  '#include'
>  ])
>  
> -env.Append(CPPDEFINES = ['__NOT_HAVE_DRM_H'])
> -
>  if env['udev']:
>  env.PkgUseModules('UDEV')
>  env.Append(CPPDEFINES = ['HAVE_LIBUDEV'])
> diff --git a/src/loader/loader.c b/src/loader/loader.c
> index 8780587..4ed0a1f 100644
> --- a/src/loader/loader.c
> +++ b/src/loader/loader.c
> @@ -85,7 +85,7 @@
>  #endif
>  #include "loader.h"
>  
> -#ifndef __NOT_HAVE_DRM_H
> +#ifdef HAVE_LIBDRM
>  #include 
>  #endif
>  
> @@ -501,7 +501,7 @@ sysfs_get_pci_id_for_fd(int fd, int *vendor_id, int 
> *chip_id)
>  }
>  #endif
>  
> -#if !defined(__NOT_HAVE_DRM_H)
> +#if defined(HAVE_LIBDRM)
>  /* for i915 */
>  #include 
>  /* for radeon */
> @@ -584,7 +584,7 @@ loader_get_pci_id_for_fd(int fd, int *vendor_id, int 
> *chip_id)
> if (sysfs_get_pci_id_for_fd(fd, vendor_id, chip_id))
>return 1;
>  #endif
> -#if !defined(__NOT_HAVE_DRM_H)
> +#if HAVE_LIBDRM
> if (drm_get_pci_id_for_fd(fd, vendor_id, chip_id))
>return 1;
>  #endif
> @@ -695,7 +695,7 @@ loader_get_driver_for_fd(int fd, unsigned driver_types)
>  
> if (!loader_get_pci_id_for_fd(fd, &vendor_id, &chip_id)) {
>  
> -#ifndef __NOT_HAVE_DRM_H
> +#if HAVE_LIBDRM
>/* fallback to drmGetVersion(): */
>drmVersionPtr version = drmGetVersion(fd);
>  
> diff --git a/src/loader/pci_id_driver_map.c b/src/loader/pci_id_driver_map.c
> index cb6f705..3c4657f 100644
> --- a/src/loader/pci_id_driver_map.c
> +++ b/src/loader/pci_id_driver_map.c
> @@ -23,7 +23,7 @@
>  
>  int is_nouveau_vieux(int fd);
>  
> -#ifndef __NOT_HAVE_DRM_H
> +#ifdef HAVE_LIBDRM
>  
>  #include 
>  #include 
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/6] mesa: move check for no-op glFrontFace call earlier

2015-07-20 Thread Ian Romanick
Patches 1, 2, and 3 are

Reviewed-by: Ian Romanick 

The other patches look correct too, but the whole series is
optimizations, so do you have any before / after performance data?

On 07/17/2015 05:48 PM, Brian Paul wrote:
> If the new mode matches the current mode, there can be no error.
> ---
>  src/mesa/main/polygon.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/main/polygon.c b/src/mesa/main/polygon.c
> index a1f0aa0..6be6f33 100644
> --- a/src/mesa/main/polygon.c
> +++ b/src/mesa/main/polygon.c
> @@ -93,14 +93,14 @@ _mesa_FrontFace( GLenum mode )
> if (MESA_VERBOSE&VERBOSE_API)
>_mesa_debug(ctx, "glFrontFace %s\n", _mesa_lookup_enum_by_nr(mode));
>  
> +   if (ctx->Polygon.FrontFace == mode)
> +  return;
> +
> if (mode!=GL_CW && mode!=GL_CCW) {
>_mesa_error( ctx, GL_INVALID_ENUM, "glFrontFace" );
>return;
> }
>  
> -   if (ctx->Polygon.FrontFace == mode)
> -  return;
> -
> FLUSH_VERTICES(ctx, _NEW_POLYGON);
> ctx->Polygon.FrontFace = mode;
>  
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 4/6] mesa: optimize _math_matrix_set_identity() and return a bool result

2015-07-20 Thread Ian Romanick
On 07/17/2015 05:48 PM, Brian Paul wrote:
> Skip memcpy() calls, etc. if the matrix is already the identity.  Return
> true/false to indicate if we're really changing the matrix or not.
> ---
>  src/mesa/math/m_matrix.c | 23 +++
>  src/mesa/math/m_matrix.h |  2 +-
>  2 files changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/src/mesa/math/m_matrix.c b/src/mesa/math/m_matrix.c
> index ecf564c..37c7612 100644
> --- a/src/mesa/math/m_matrix.c
> +++ b/src/mesa/math/m_matrix.c
> @@ -1132,17 +1132,24 @@ _math_matrix_viewport(GLmatrix *m, const double 
> scale[3],
>   *
>   * Copies ::Identity into \p GLmatrix::m, and into GLmatrix::inv if not NULL.
>   * Sets the matrix type to identity, and clear the dirty flags.
> + * \return true if prev matrix wasn't identity, false otherwise
>   */
> -void
> -_math_matrix_set_identity( GLmatrix *mat )
> +bool
> +_math_matrix_set_identity(GLmatrix *mat)
>  {
> -   memcpy( mat->m, Identity, 16*sizeof(GLfloat) );
> -   memcpy( mat->inv, Identity, 16*sizeof(GLfloat) );
> +   if (mat->type != MATRIX_IDENTITY || mat->flags) {
> +  memcpy(mat->m, Identity, 16 * sizeof(GLfloat));
> +  memcpy(mat->inv, Identity, 16 * sizeof(GLfloat));
> +
> +  mat->type = MATRIX_IDENTITY;
> +  mat->flags = 0;
>  
> -   mat->type = MATRIX_IDENTITY;
> -   mat->flags &= ~(MAT_DIRTY_FLAGS|
> -MAT_DIRTY_TYPE|
> -MAT_DIRTY_INVERSE);
> +  return true;
> +   }
> +   else {

Most places use

   } else {

these days.

> +  /* no change */
> +  return false;
> +   }
>  }
>  
>  /*@}*/
> diff --git a/src/mesa/math/m_matrix.h b/src/mesa/math/m_matrix.h
> index 778d716..0bb63c8 100644
> --- a/src/mesa/math/m_matrix.h
> +++ b/src/mesa/math/m_matrix.h
> @@ -125,7 +125,7 @@ extern void
>  _math_matrix_viewport( GLmatrix *m, const double scale[3],
> const double translate[3], double depthMax );
>  
> -extern void
> +extern bool
>  _math_matrix_set_identity( GLmatrix *dest );
>  
>  extern void
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 04/11] dri_interface: drop __NOT_HAVE_DRM_H magic

2015-07-20 Thread Ian Romanick
On 07/09/2015 01:12 PM, Emil Velikov wrote:
> On 9 July 2015 at 18:50, Ian Romanick  wrote:
>> On 07/08/2015 10:07 AM, Emil Velikov wrote:
>>> Signed-off-by: Emil Velikov 
>>> ---
>>>  include/GL/internal/dri_interface.h | 11 ---
>>>  1 file changed, 11 deletions(-)
>>>
>>> diff --git a/include/GL/internal/dri_interface.h 
>>> b/include/GL/internal/dri_interface.h
>>> index c827bb6..c0545b1 100644
>>> --- a/include/GL/internal/dri_interface.h
>>> +++ b/include/GL/internal/dri_interface.h
>>> @@ -40,20 +40,9 @@
>>>  #ifndef DRI_INTERFACE_H
>>>  #define DRI_INTERFACE_H
>>>
>>> -/* For archs with no drm.h */
>>> -#if defined(__APPLE__) || defined(__CYGWIN__) || defined(__GNU__)
>>> -#ifndef __NOT_HAVE_DRM_H
>>> -#define __NOT_HAVE_DRM_H
>>> -#endif
>>> -#endif
>>> -
>>> -#ifndef __NOT_HAVE_DRM_H
>>
>> Shouldn't this get changed to use HAVE_LIBDRM as in later patches?
> I thought about that, but that depends on if the versions of xserver
> that we care about define it. From a quick look that is not the case
> for older xservers, on the other hand drm* users which explicitly
> include drm.h. If others don't mind when/if things break, I'm fine
> using HAVE_LIBDRM here.

Two questions come to mind...

1. Which X server versions build?

2. How hard would it be to patch the broken versions to work?  It seems
like it should be pretty easy, right?

If all of the versions that we think people actually care about work,
then I don't think we should worry.

>> I
>> guess drm_context_t and drm_drawable_t are ABI, so they shouldn't ever
>> change.  It does feel a little icky to redefine them when not necessary.
>>
> Yes it is rather nasty. Note that all of the "junk" is DRI1 stuff. I
> was thinking about nuking/moving it, but with the see the "old dri
> loader new module, and vice versa" topic still open, I've decided to
> leave thing as is.
> 
> -Emil

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 06/18] i965: Pass the map-mode along to intel_mipmap_tree_map_raw()

2015-07-20 Thread Ian Romanick
On 07/06/2015 03:33 AM, Chris Wilson wrote:
> Since we can distinguish when mapping between READ and WRITE, we can
> pass along the map mode to avoid stalls and flushes where possible.
> 
> Signed-off-by: Chris Wilson 
> ---
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 28 
> ++-
>  src/mesa/drivers/dri/i965/intel_mipmap_tree.h |  3 ++-
>  2 files changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c 
> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> index e8bbc04..fcad043 100644
> --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
> @@ -1401,7 +1401,7 @@ intel_miptree_alloc_mcs(struct brw_context *brw,
>  *
>  * Note: the clear value for MCS buffers is all 1's, so we memset to 0xff.
>  */
> -   void *data = intel_miptree_map_raw(brw, mt->mcs_mt);
> +   void *data = intel_miptree_map_raw(brw, mt->mcs_mt, GL_MAP_WRITE_BIT);
> memset(data, 0xff, mt->mcs_mt->total_height * mt->mcs_mt->pitch);
> intel_miptree_unmap_raw(brw, mt->mcs_mt);
> mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_CLEAR;
> @@ -2053,13 +2053,15 @@ intel_miptree_updownsample(struct brw_context *brw,
>  }
>  
>  void *
> -intel_miptree_map_raw(struct brw_context *brw, struct intel_mipmap_tree *mt)
> +intel_miptree_map_raw(struct brw_context *brw,
> +   struct intel_mipmap_tree *mt,
> +   GLbitfield mode)

No tabs, only spaces. :)

>  {
> /* CPU accesses to color buffers don't understand fast color clears, so
>  * resolve any pending fast color clears before we map.
>  */
> intel_miptree_resolve_color(brw, mt);
> -   return brw_bo_map(mt->bo, MAP_WRITE);
> +   return brw_bo_map(mt->bo, mode & GL_MAP_WRITE_BIT ? MAP_WRITE : MAP_READ);
>  }
>  
>  void
> @@ -2088,7 +2090,7 @@ intel_miptree_map_gtt(struct brw_context *brw,
> assert(y % bh == 0);
> y /= bh;
>  
> -   base = intel_miptree_map_raw(brw, mt) + mt->offset;
> +   base = intel_miptree_map_raw(brw, mt, map->mode) + mt->offset;
>  
> if (base == NULL)
>map->ptr = NULL;
> @@ -2155,7 +2157,7 @@ intel_miptree_map_blit(struct brw_context *brw,
>}
> }
>  
> -   map->ptr = intel_miptree_map_raw(brw, map->mt);
> +   map->ptr = intel_miptree_map_raw(brw, map->mt, map->mode);
>  
> DBG("%s: %d,%d %dx%d from mt %p (%s) %d,%d = %p/%d\n", __func__,
> map->x, map->y, map->w, map->h,
> @@ -2219,7 +2221,7 @@ intel_miptree_map_movntdqa(struct brw_context *brw,
> image_x += map->x;
> image_y += map->y;
>  
> -   void *src = intel_miptree_map_raw(brw, mt);
> +   void *src = intel_miptree_map_raw(brw, mt, map->mode);
> if (!src)
>return;
> src += image_y * mt->pitch;
> @@ -2285,7 +2287,7 @@ intel_miptree_map_s8(struct brw_context *brw,
>  */
> if (!(map->mode & GL_MAP_INVALIDATE_RANGE_BIT)) {
>uint8_t *untiled_s8_map = map->ptr;
> -  uint8_t *tiled_s8_map = intel_miptree_map_raw(brw, mt);
> +  uint8_t *tiled_s8_map = intel_miptree_map_raw(brw, mt, 
> GL_MAP_READ_BIT);
>unsigned int image_x, image_y;
>  
>intel_miptree_get_image_offset(mt, level, slice, &image_x, &image_y);
> @@ -2322,7 +2324,7 @@ intel_miptree_unmap_s8(struct brw_context *brw,
> if (map->mode & GL_MAP_WRITE_BIT) {
>unsigned int image_x, image_y;
>uint8_t *untiled_s8_map = map->ptr;
> -  uint8_t *tiled_s8_map = intel_miptree_map_raw(brw, mt);
> +  uint8_t *tiled_s8_map = intel_miptree_map_raw(brw, mt, 
> GL_MAP_WRITE_BIT);
>  
>intel_miptree_get_image_offset(mt, level, slice, &image_x, &image_y);
>  
> @@ -2377,7 +2379,7 @@ intel_miptree_unmap_etc(struct brw_context *brw,
> image_x += map->x;
> image_y += map->y;
>  
> -   uint8_t *dst = intel_miptree_map_raw(brw, mt)
> +   uint8_t *dst = intel_miptree_map_raw(brw, mt, GL_MAP_WRITE_BIT)
>  + image_y * mt->pitch
>  + image_x * mt->cpp;
>  
> @@ -2428,8 +2430,8 @@ intel_miptree_map_depthstencil(struct brw_context *brw,
>  */
> if (!(map->mode & GL_MAP_INVALIDATE_RANGE_BIT)) {
>uint32_t *packed_map = map->ptr;
> -  uint8_t *s_map = intel_miptree_map_raw(brw, s_mt);
> -  uint32_t *z_map = intel_miptree_map_raw(brw, z_mt);
> +  uint8_t *s_map = intel_miptree_map_raw(brw, s_mt, GL_MAP_READ_BIT);
> +  uint32_t *z_map = intel_miptree_map_raw(brw, z_mt, GL_MAP_READ_BIT);
>unsigned int s_image_x, s_image_y;
>unsigned int z_image_x, z_image_y;
>  
> @@ -2489,8 +2491,8 @@ intel_miptree_unmap_depthstencil(struct brw_context 
> *brw,
>  
> if (map->mode & GL_MAP_WRITE_BIT) {
>uint32_t *packed_map = map->ptr;
> -  uint8_t *s_map = intel_miptree_map_raw(brw, s_mt);
> -  uint32_t *z_map = intel_miptree_map_raw(brw, z_mt);
> +  uint8_t *s_map = intel_miptree_map_raw(brw, s_mt, GL_MAP_WRITE_BIT);
> +  uint32_t *z_map = intel_miptree_map_raw(brw, z_mt

Re: [Mesa-dev] [PATCH v2] dri_interface: drop __NOT_HAVE_DRM_H magic

2015-07-21 Thread Ian Romanick
Reviewed-by: Ian Romanick 

On 07/21/2015 09:07 AM, Emil Velikov wrote:
> v2: use HAVE_LIBDRM macro.
> 
> Cc: Ian Romanick 
> Signed-off-by: Emil Velikov 
> ---
>  include/GL/internal/dri_interface.h | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/include/GL/internal/dri_interface.h 
> b/include/GL/internal/dri_interface.h
> index c827bb6..7266071 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -40,14 +40,7 @@
>  #ifndef DRI_INTERFACE_H
>  #define DRI_INTERFACE_H
>  
> -/* For archs with no drm.h */
> -#if defined(__APPLE__) || defined(__CYGWIN__) || defined(__GNU__)
> -#ifndef __NOT_HAVE_DRM_H
> -#define __NOT_HAVE_DRM_H
> -#endif
> -#endif
> -
> -#ifndef __NOT_HAVE_DRM_H
> +#ifdef HAVE_LIBDRM
>  #include 
>  #else
>  typedef unsigned int drm_context_t;
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v4 3/6] mesa/es3.1: enable GL_ARB_texture_multisample for GLES 3.1

2015-07-22 Thread Ian Romanick
On 06/26/2015 07:38 AM, Ilia Mirkin wrote:
> On Fri, Jun 26, 2015 at 4:18 AM, Tapani Pälli  wrote:
>>
>>
>> On 06/26/2015 01:06 AM, Ilia Mirkin wrote:
>>>
>>> On Thu, Jun 25, 2015 at 4:22 PM, Ilia Mirkin  wrote:

 On Thu, Jun 25, 2015 at 5:08 AM, Marta Lofstedt
  wrote:
>
> From: Marta Lofstedt 
>
> v4 : only expose GL_ARB_texture_multisample enums
> for gles 3.1 and desktop GL.


 I was suspicious of this logic. Based on my reading of the code, what
 your ARB_texture_multisample_es31 thing does is expose those enums
 when *either* the driver enables ARB_texture_multisample *or* the
 current context is ES3.1.

 ARB_draw_indirect_es31 has the same problem, btw.
>>
>>
>> I'm not sure I understand the issue. It should work fine with 'OR', if we
>> have either of these then we expose the enum?
>>
 I could have misread the get.c extra_ext() logic, but I don't think I
 have. As far as I can tell there's no way to (generically) AND these
 things.
>>
>>
>> Why do we need AND? If you have 3.1 context then you *need* to support this
>> enum. There is no such condition where you would have gles 3.1 context but
>> not the enum, right?
>>
>>
 What you really need to do is create a whole new [GL, GL_CORE, ES31]
 section in get_hash_params and update get_hash_generator.py
 accordingly.
>>>
>>>
>>> An alternative, BTW, is to just say "screw it" and expose the enums in
>>> GL ES 3.0. In that case, just move the enums into a section that
>>> includes GLES3. I'm not sure how big of a deal it is. But your current
>>> patches are definitely wrong.
>>
>>
>> We do this, but we have explicit version check against version 3.1.
> 
> OK, well, at the end of the day, the things anyone says don't matter,
> it just has to work, right? So here are the scenarios:
> 
> Let's take it as a given that the driver sets
> Ext.ARB_texture_multisample to true, we have the following situations:
> 
> GL compat glGet(SAMPLE_MASK)
> GL core glGet(SAMPLE_MASK)
> GL ES3.0 glGet(SAMPLE_MASK)
> GL ES3.1 glGet(SAMPLE_MASK)
> 
> Where the ES3.0 one should fail, and all the others should succeed.
> OK, so first off, this is in the GL/GL_CORE/GLES3 section, which means
> that the logic will get hit for all 4, right? Then you do a check for

Yes, I think you're right, and I think I led Marta and Tapani astray.  I
think they originally had separate sections, and I told them to change
at least some of them.  The whole separate section mechanism is
confusing and leads to code churn (imagine if an ES3.0 extension comes
along that enables this functionality).

I think a good Python project for someone would be to reorganize that
file so that all the enums are in a single list.  Each enum would have a
list of minterms to describe its availability.  These would include
profile and version.  Instead of having a flat array of integers, we'd
have an array of structures:

struct requirement {
gl_api  API;
unsigned Version;   /**< Minimum version required. */
unsigned extension[2];  /**< Offsets of required extensions.  Use
 * dummy_true if none.
 */
enum value_extra extra; /**< Other requirements. */
};

This is equivalent to the current system (which is also a maximum of
minterms), but I think it's a lot easier to specify things.

Either way, I think that can be follow-up work.

> Ext.ARB_texture_multisample || ES3.1
> 
> and if that doesn't get set to true, then you return INVALID_ENUM,
> right? So tell me, given that the driver *always* sets
> Ext.ARB_texture_multisample to true, how can that ever be false? The
> ES3.1 thing could be useful for drivers that don't actually support
> ARB_texture_multisample and you want to fake it, but in practice all
> the relevant drivers support it. But none of that cause a
> GL_INVALID_ENUM to get returned in ES3.0 as it was before the patch.
> 
> Hope that clears things up.
> 
>   -ilia
> ___
> 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] glsl: Allow built-in functions as constant expressions in OpenGL ES 1.00

2015-10-12 Thread Ian Romanick
On 10/09/2015 07:01 PM, Matt Turner wrote:
> On Fri, Oct 9, 2015 at 6:52 PM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> In d4a24745 (August 2012), Paul made functions calls not be constant
>> expressions in GLSL ES 1.00.  Since this feature was added in desktop
>> GLSL 1.20, we believed that it was added in GLSL ES 3.00.  That turns
>> out to be completely wrong.  Built-in functions have always been allowed
>> as constant expressions in GLSL ES, and the patch adds the (many) spec
>> quotations to prove it.
>>
>> While we never previously encountered this, a later patch enfoces a GLSL
> 
> typo: enforces
> 
>> ES 1.00 rule that global variable initializers must be constant
>> expressions.  Without this fix, severl dEQP tests fail.
> 
> typo: several

Heh... piglit was running, and there were a couple tests stealing focus.
 I think those tests got the missing characters. :)

> Reviewed-by: Matt Turner 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/9] ff_fragment_shader: Use binding to set the sampler unit

2015-10-12 Thread Ian Romanick
On 10/09/2015 07:03 PM, Matt Turner wrote:
> On Fri, Oct 9, 2015 at 6:52 PM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> This is the way layout(binding=xxx) works from GLSL.  The old method
>> just happened to work (and significantly predated support for
>> layout(binding=xxx)), but future changes will break this.
>>
>> Signed-off-by: Ian Romanick 
>> Cc: "10.6 11.0" 
>> ---
>>  src/mesa/main/ff_fragment_shader.cpp | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/main/ff_fragment_shader.cpp 
>> b/src/mesa/main/ff_fragment_shader.cpp
>> index e4e2a18..f5a4fa5 100644
>> --- a/src/mesa/main/ff_fragment_shader.cpp
>> +++ b/src/mesa/main/ff_fragment_shader.cpp
>> @@ -981,7 +981,8 @@ static void load_texture( texenv_fragment_program *p, 
>> GLuint unit )
>>  * NOTE: The cast to int is important.  Without it, the constant will 
>> have
>>  * type uint, and things later on may get confused.
>>  */
>> -   sampler->constant_value = new(p->mem_ctx) ir_constant(int(unit));
>> +   sampler->data.explicit_binding = true;
>> +   sampler->data.binding = unit;
> 
> With the comment immediately above removed,

Yes... I had meant to do that, but I forgot.

> Reviewed-by: Matt Turner 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 8/9] glsl: In later GLSL versions, sequence operator is cannot be a constant expression

2015-10-12 Thread Ian Romanick
On 10/09/2015 07:14 PM, Matt Turner wrote:
> On Fri, Oct 9, 2015 at 6:53 PM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> Fixes:
>> ES3-CTS.shaders.negative.constant_sequence
>>
>> spec/glsl-es-3.00/compiler/global-initializer/from-sequence.vert
>> spec/glsl-es-3.00/compiler/global-initializer/from-sequence.frag
>>
>> Signed-off-by: Ian Romanick 
>> Cc: "10.6 11.0" 
>> ---
>>  src/glsl/ast_to_hir.cpp | 43 ++-
>>  1 file changed, 42 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
>> index 6af0f80..f34cbe0 100644
>> --- a/src/glsl/ast_to_hir.cpp
>> +++ b/src/glsl/ast_to_hir.cpp
>> @@ -3311,8 +3311,49 @@ process_initializer(ir_variable *var, ast_declaration 
>> *decl,
>>if (new_rhs != NULL) {
>>   rhs = new_rhs;
>>
>> + /* Section 4.3.3 (Constant Expressions) of the GLSL ES 3.00.4 spec
>> +  * says:
>> +  *
>> +  * "A constant expression is one of
>> +  *
>> +  *...
>> +  *
>> +  *- an expression formed by an operator on operands that 
>> are
>> +  *  all constant expressions, including getting an element 
>> of
>> +  *  a constant array, or a field of a constant structure, 
>> or
>> +  *  components of a constant vector.  However, the sequence
>> +  *  operator ( , ) and the assignment operators ( =, +=, 
>> ...)
>> +  *  are not included in the operators that can create a
>> +  *  constant expression."
>> +  *
>> +  * Section 12.43 (Sequence operator and constant expressions) says:
>> +  *
>> +  * "Should the following construct be allowed?
>> +  *
>> +  * float a[2,3];
>> +  *
>> +  * The expression within the brackets uses the sequence 
>> operator
>> +  * (',') and returns the integer 3 so the construct is decl 
>> aring
> 
> There's a space in the middle of "declaring"
> 
>> +  * a single-dimensional array of size 3.  In some languages, 
>> the
>> +  * construct declares a two-dimensional array.  It would be
>> +  * preferable to make this construct illegal to avoid 
>> confusion.
>> +  *
>> +  * One possibility is to change the definition of the sequence
>> +  * operator so that it does not return a constant- expression 
>> and
> 
> Presumably the space after the - comes from a line break and isn't 
> intentional.

Both of those are from copy-and-pasting from the PDF of the spec... and
not fixing it afterwards.  I'll fix them both.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] i965: Fix is-renderable check in intel_image_target_renderbuffer_storage

2015-10-15 Thread Ian Romanick
From: Ian Romanick 

Previously we could create a renderbuffer with format
MESA_FORMAT_R8G8B8A8_UNORM, convert that renderbuffer to an EGLImage,
then FAIL to convert the EGLImage back to a renderbuffer because
reasons.  Just use the same check in
intel_image_target_renderbuffer_storage that brw_render_target_supported
uses.

There are more checks in brw_render_target_supported, but I don't think
they are necessary here.  A different approach would be to refactor
brw_render_target_supported to take rb->Format and rb->NumSamples as
parameters (instead of a gl_renderbuffer) and use the new function here.

Fixes:

ES2-CTS.gtf.GL2ExtensionTests.egl_image.egl_image

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92476
Cc: "10.3 10.4 10.5 10.6 11.0" 
---
 src/mesa/drivers/dri/i965/intel_fbo.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c 
b/src/mesa/drivers/dri/i965/intel_fbo.c
index 5a6b0dd..7f281fa 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -348,14 +348,10 @@ intel_image_target_renderbuffer_storage(struct gl_context 
*ctx,
}
 
/* __DRIimage is opaque to the core so it has to be checked here */
-   switch (image->format) {
-   case MESA_FORMAT_R8G8B8A8_UNORM:
+   if (!brw->format_supported_as_render_target[image->format]) {
   _mesa_error(ctx, GL_INVALID_OPERATION,
 "glEGLImageTargetRenderbufferStorage(unsupported image format");
   return;
-  break;
-   default:
-  break;
}
 
irb = intel_renderbuffer(rb);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [Mesa-stable] [RFC 01/21] mesa/texcompress: Restrict FXT1 format to desktop GL subset

2015-10-20 Thread Ian Romanick
On 10/19/2015 05:36 PM, Nanley Chery wrote:
> From: Nanley Chery 
> 
> In agreement with the extension spec and commit
> dd0eb004874645135b9aaac3ebbd0aaf274079ea, filter FXT1 formats to the
> desktop GL profiles. Now we no longer advertise such formats as supported
> in an ES context and then throw an INVALID_ENUM error when the client
> tries to use such formats with CompressedTexImage2D.
> 
> Fixes the following 26 dEQP tests:
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_neg_x
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_neg_y
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_neg_z
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_pos_x
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_pos_y
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_pos_z
> * dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_size
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_level_max_cube_pos
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_level_max_tex2d
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_level_cube
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_level_tex2d
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_neg_x
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_neg_y
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_neg_z
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_pos_x
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_pos_y
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_pos_z
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_tex2d
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_neg_x
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_neg_y
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_neg_z
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_pos_x
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_pos_y
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_pos_z
> * 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_tex2d
> 
> Cc: Ian Romanick 
> Cc: Mark Janes 
> Cc: "11.0" 
> Signed-off-by: Nanley Chery 
> ---
>  src/mesa/main/texcompress.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
> index feaf061..1615f4f 100644
> --- a/src/mesa/main/texcompress.c
> +++ b/src/mesa/main/texcompress.c
> @@ -286,7 +286,9 @@ GLuint
>  _mesa_get_compressed_formats(struct gl_context *ctx, GLint *formats)
>  {
> GLuint n = 0;
> -   if (ctx->Extensions.TDFX_texture_compression_FXT1) {
> +   if (ctx->Extensions.TDFX_texture_compression_FXT1 &&
> +  (ctx->API == API_OPENGL_CORE ||
> +  (ctx->API == API_OPENGL_COMPAT && ctx->Version > 10))) {

Eh... the lowest possible desktop OpenGL version is 1.2, so the version
check is unnecessary.  You should just use _mesa_is_desktop_gl.

>if (formats) {
>   formats[n++] = GL_COMPRESSED_RGB_FXT1_3DFX;
>   formats[n++] = GL_COMPRESSED_RGBA_FXT1_3DFX;
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [RFC 01/21] mesa/texcompress: Restrict FXT1 format to desktop GL subset

2015-10-20 Thread Ian Romanick
On 10/19/2015 05:58 PM, Nanley Chery wrote:
> 
> 
> On Mon, Oct 19, 2015 at 3:47 PM, Ilia Mirkin  <mailto:imir...@alum.mit.edu>> wrote:
> 
> On Mon, Oct 19, 2015 at 6:36 PM, Nanley Chery  <mailto:nanleych...@gmail.com>> wrote:
> > From: Nanley Chery  <mailto:nanley.g.ch...@intel.com>>
> >
> > In agreement with the extension spec and commit
> > dd0eb004874645135b9aaac3ebbd0aaf274079ea, filter FXT1 formats to the
> > desktop GL profiles. Now we no longer advertise such formats as
> supported
> > in an ES context and then throw an INVALID_ENUM error when the client
> > tries to use such formats with CompressedTexImage2D.
> >
> > Fixes the following 26 dEQP tests:
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_neg_x
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_neg_y
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_neg_z
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_pos_x
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_pos_y
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_border_cube_pos_z
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_invalid_size
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_level_max_cube_pos
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_level_max_tex2d
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_level_cube
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_level_tex2d
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_neg_x
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_neg_y
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_neg_z
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_pos_x
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_pos_y
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_cube_pos_z
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_neg_width_height_tex2d
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_neg_x
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_neg_y
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_neg_z
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_pos_x
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_pos_y
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_cube_pos_z
> > *
> 
> dEQP-GLES2.functional.negative_api.texture.compressedteximage2d_width_height_max_tex2d
> >
> > Cc: Ian Romanick  <mailto:ian.d.roman...@intel.com>>
> > Cc: Mark Janes  <mailto:mark.a.ja...@intel.com>>
> > Cc: "11.0"  <mailto:mesa-sta...@lists.freedesktop.org>>
> > Signed-off-by: Nanley Chery  <mailto:nanley.g.ch...@intel.com>>
> > ---
> >  src/mesa/main/texcompress.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
> > index feaf061..1615f4f 100644
> > --- a/src/mesa/main/texcompress.c
> > +++ b/src/mesa/main/texcompress.c
> > @@ -286,7 +286,9 @@ GLuint
> >  _mesa_get_compressed_formats(struct gl_context *ctx, GLint *formats)
> >  {
> > GLuint n = 0;
> > -   if (ctx->Extensions.TDFX_texture_compression_FXT1) {
> > +   if (ctx->Extensions.TDFX_texture_compression_FXT1 &&
> > +

Re: [Mesa-dev] [PATCH 1/4] mesa: Draw indirect is not allowed if the default VAO is bound.

2015-10-21 Thread Ian Romanick
On 10/20/2015 10:22 AM, Ilia Mirkin wrote:
> On Tue, Oct 20, 2015 at 10:19 AM, Marta Lofstedt
>  wrote:
>> From: Marta Lofstedt 
>>
>> From OpenGL ES 3.1 specification, section 10.5:
>> "DrawArraysIndirect requires that all data sourced for the
>> command, including the DrawArraysIndirectCommand
>> structure,  be in buffer objects,  and may not be called when
>> the default vertex array object is bound."
> 
> Is it possible to do this with desktop GL? AFAIK ARB_draw_indirect is
> only enabled for core profiles, and you can't draw at all in core
> without a VAO bound. So I think you can remove the _mesa_is_gles31
> check. [Might want to wait on confirmation for that, or double-check
> my claim yourself.]

Correct.  We do this check for core profile in check_valid_to_render
because a VAO is always required.

>> Signed-off-by: Marta Lofstedt 
>> ---
>>  src/mesa/main/api_validate.c | 13 +
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
>> index a46c194..c5628f5 100644
>> --- a/src/mesa/main/api_validate.c
>> +++ b/src/mesa/main/api_validate.c
>> @@ -698,6 +698,19 @@ valid_draw_indirect(struct gl_context *ctx,
>>  {
>> const GLsizeiptr end = (GLsizeiptr)indirect + size;
>>
>> +   /*
>> +* OpenGL ES 3.1 spec. section 10.5:
>> +* "DrawArraysIndirect requires that all data sourced for the
>> +* command, including the DrawArraysIndirectCommand
>> +* structure,  be in buffer objects,  and may not be called when
>> +* the default vertex array object is bound."
>> +*/
>> +   if (_mesa_is_gles31(ctx) && (ctx->Array.VAO == ctx->Array.DefaultVAO)) {
>> +  _mesa_error(ctx, GL_INVALID_OPERATION,
>> +  "%s(The default VAO is bound)", name);

We should use the same error here that is used in check_valid_to_render
for core profile:

 _mesa_error(ctx, GL_INVALID_OPERATION, "%s(no VAO bound)",
function);

>> +  return GL_FALSE;
>> +   }
>> +
>> if (!_mesa_valid_prim_mode(ctx, mode, name))
>>return GL_FALSE;
>>
>> --
>> 2.1.4
>>
>> ___
>> 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

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 2/4] mesa: Draw Indirect is not allowed when no vertex array binding exists.

2015-10-21 Thread Ian Romanick
On 10/21/2015 07:32 AM, Lofstedt, Marta wrote:
>> -Original Message-
>> From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On
>> Behalf Of Tapani Pälli
>> Sent: Wednesday, October 21, 2015 1:25 PM
>> To: Marek Olšák
>> Cc: mesa-dev@lists.freedesktop.org
>> Subject: Re: [Mesa-dev] [PATCH 2/4] mesa: Draw Indirect is not allowed
>> when no vertex array binding exists.
>>
>> On 10/21/2015 01:41 PM, Marek Olšák wrote:
>>> On Wed, Oct 21, 2015 at 7:16 AM, Tapani Pälli 
>> wrote:
 On 10/20/2015 08:54 PM, Marek Olšák wrote:
> On Tue, Oct 20, 2015 at 4:19 PM, Marta Lofstedt
>  wrote:
>> From: Marta Lofstedt 
>>
>> OpenGL ES 3.1 spec. section 10.5:
>> "An INVALID_OPERATION error is generated if zero is bound to
>> VERTEX_ARRAY_BINDING, DRAW_INDIRECT_BUFFER or to any enabled
>> vertex
>> array."
>>
>> Signed-off-by: Marta Lofstedt 
>> ---
>>src/mesa/main/api_validate.c | 14 ++
>>1 file changed, 14 insertions(+)
>>
>> diff --git a/src/mesa/main/api_validate.c
>> b/src/mesa/main/api_validate.c index c5628f5..7062cbd 100644
>> --- a/src/mesa/main/api_validate.c
>> +++ b/src/mesa/main/api_validate.c
>> @@ -711,6 +711,20 @@ valid_draw_indirect(struct gl_context *ctx,
>>  return GL_FALSE;
>>   }
>>
>> +   /*
>> +* OpenGL ES 3.1 spec. section 10.5:
>> +* "An INVALID_OPERATION error is generated if zero is bound to
>> +* VERTEX_ARRAY_BINDING, DRAW_INDIRECT_BUFFER or to any
>> enabled
>> +* vertex array."
>> +* OpenGL 4.5 spec. section 10.4:
>> +* "An INVALID_OPERATION error is generated if  zero is bound to
>> +* DRAW_INDIRECT_BUFFER, or if  no element array buffer is bound"
>> +*/
>> +   if (!_mesa_is_bufferobj(ctx->Array.ArrayBufferObj)) {
>> +  _mesa_error(ctx, GL_INVALID_OPERATION,
>> +  "%s(No VBO is bound)", name);
>> +   }
> NAK.
>
> VERTEX_ARRAY_BINDING is a VAO. Array.ArrayBufferObj is from
>> glBindBuffer.

 This check is valid, it is not against VERTEX_ARRAY_BINDING. Note
 "any enabled vertex array", we hit this weird situation when client
 has a VAO bound and has enabled vertex attrib array but has not bound
>> any VBO to it.
>>> No, it's invalid. The check has absolutely nothing to do with enabled
>>> vertex arrays and draw calls. Absolutely nothing. glBindBuffer changes
>>> a latched state, which means it doesn't do anything by itself, it only
>>> affects other functions that change states. The functions affected by
>>> glBindBuffer(GL_ARRAY_BUFFER, ..) are glVertexAttribPointer, etc. not
>>> glDraw*. If you called glBindBuffer(GL_ARRAY_BUFFER, ..) right before
>>> a Draw call, it wouldn't do anything to vertex arrays and buffers, but
>>> it would pass the check.
>>
>> OK my understanding was that reason why this change fixes the bug is that
>> ctx->Array.ArrayBufferObj is 0 for the default VAO and never 0 when vertex
>> array buffer binding has been set, and this would happen when we would
>> have an VBO bound. I will spend some more time to understand this.

Core profile has the same sort of limitation. I really hope we're
enforcing it there. It's probably worth finding that check. I expected
to find it in either check_valid_to_render or _mesa_valid_to_render, but
I didn't see it in either place. Hmm... it may just happen in
_mesa_VertexAttribPointer.

> If you have access to the CTS it is these tests that this fixed:
> ES31-CTS.draw_indirect.negative-noVBO-arrays
> ES31-CTS.draw_indirect.negative-noVBO-elements
> 
> My understanding is as Tapanis above, I was trying to come up with a method
> of not needing to loop through the VertexAttribPointers.
> Also, I have mis-quoted the spec. I should have only quoted the:
>  "or any enabled vertex arrays" and limit to gles 3.1.

Since this is a hot path, avoiding a loop would be good.  We already
have such a loop in the driver, and it hurts.  See

http://patchwork.freedesktop.org/patch/56772/

If we were to track some bitmasks of enabled arrays and vbo-backed
arrays, we could simplify the check on non-core profile.  That should
help performance.

>>> Now, where does this patch check "enabled vertex arrays"? Nowhere. It
>>> doesn't check VERTEX_ARRAY_BINDING, it doesn't check
>>> DRAW_INDIRECT_BUFFER, and it doesn't check enabled vertex arrays. That
>>> whole comment is completely useless there.
>>>
>>> Sorry if I'm too direct, but you should really think more before
>>> making such statements and giving Reviewed-by.
>>
>> // Tapani
>>
>> ___
>> 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 3/4] mesa: Draw Indirect return wrong error code on unalinged

2015-10-21 Thread Ian Romanick
On 10/20/2015 01:03 PM, Ilia Mirkin wrote:
> On Tue, Oct 20, 2015 at 10:19 AM, Marta Lofstedt
>  wrote:
>> From: Marta Lofstedt 
>>
>> From OpenGL 4.4 specification, section 10.4 and
>> Open GL Es 3.1 section 10.5:
>> "An INVALID_VALUE error is generated if indirect is not a multiple
>> of the size, in basic machine units, of uint."
>>
>> However, the current code follow the ARB_draw_indirect:
>> https://www.opengl.org/registry/specs/ARB/draw_indirect.txt
>> "INVALID_OPERATION is generated by DrawArraysIndirect and
>> DrawElementsIndirect if commands source data beyond the end
>> of a buffer object or if  is not word aligned."
>>
>> Signed-off-by: Marta Lofstedt 
>> ---
>>  src/mesa/main/api_validate.c | 13 +++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
>> index 7062cbd..a084362 100644
>> --- a/src/mesa/main/api_validate.c
>> +++ b/src/mesa/main/api_validate.c
>> @@ -732,10 +732,19 @@ valid_draw_indirect(struct gl_context *ctx,
>> /* From the ARB_draw_indirect specification:
>>  * "An INVALID_OPERATION error is generated [...] if  is no
>>  *  word aligned."
>> +* However, from OpenGL version 4.4. section 10.5
> 
> 4.4,
> 
> I double-checked and you're right -- it was INVALID_OPERATION in GL
> 4.3, but INVALID_VALUE in GL 4.4. Weird.

We (Khronos) changed the error because, in fact, the value is invalid.
Generating GL_INVALID_VALUE is more consistent with other similar errors. :)

Since Khronos doesn't usually update older specs, we (Mesa) usually
interpret such changes as clarifications that should be retroactively
applied.  I really hate having a mess of "if this API generate this
error otherwise generate that error."

Let's just always generate GL_INVALID_VALUE.

> Reviewed-by: Ilia Mirkin 
> 
> Should probably fix up the piglit test as well, if any.

Yes.  My recommendation would be to accept either error in desktop GL <=
4.3, but only accept GL_INVALID_VALUE in other versions / APIs.

>> +* and OpenGL ES 3.1, section 10.6:
>> +* "An INVALID_VALUE error is generated if indirect is not a multiple
>> +* of the size, in basic machine units, of uint."
>>  */
>> if ((GLsizeiptr)indirect & (sizeof(GLuint) - 1)) {
>> -  _mesa_error(ctx, GL_INVALID_OPERATION,
>> -  "%s(indirect is not aligned)", name);
>> +  if ((_mesa_is_desktop_gl(ctx) && ctx->Version >= 44) ||
>> +  _mesa_is_gles31(ctx))
>> + _mesa_error(ctx, GL_INVALID_VALUE,
>> + "%s(indirect is not aligned)", name);
>> +  else
>> + _mesa_error(ctx, GL_INVALID_OPERATION,
>> + "%s(indirect is not aligned)", name);
>>return GL_FALSE;
>> }
>>
>> --
>> 2.1.4
>>
>> ___
>> 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

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] mesa/meta: Use interpolateAtOffset for 16x MSAA copy blit

2015-10-21 Thread Ian Romanick
On 09/29/2015 07:57 AM, Neil Roberts wrote:
> Previously there was a problem in i965 where if 16x MSAA is used then
> some of the sample positions are exactly on the 0 x or y axis. When
> the MSAA copy blit shader interpolates the texture coordinates at
> these sample positions it was possible that it would jump to a
> neighboring texel due to rounding errors. It is likely that these
> positions would be used on 16x MSAA because that is where they are
> defined to be in D3D.
> 
> To fix that this patch makes it use interpolateAtOffset in the blit
> shader whenever 16x MSAA is used and the GL_ARB_gpu_shader5 extension
> is available. This forces it to interpolate the texture coordinates at
> the pixel center to avoid these problematic positions.

Would it also work to use "centroid in" interpolation qualifier?  Do we
have any data about the relative cost of the three interpolation methods?

> This fixes ext_framebuffer_multisample-unaligned-blit and
> ext_framebuffer_multisample-clip-and-scissor-blit with 16x MSAA on
> SKL+.
> ---
>  src/mesa/drivers/common/meta_blit.c | 64 
> ++---
>  1 file changed, 52 insertions(+), 12 deletions(-)
> 
> diff --git a/src/mesa/drivers/common/meta_blit.c 
> b/src/mesa/drivers/common/meta_blit.c
> index 1f9515a..e812ecb 100644
> --- a/src/mesa/drivers/common/meta_blit.c
> +++ b/src/mesa/drivers/common/meta_blit.c
> @@ -352,17 +352,27 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
> shader_index == BLIT_MSAA_SHADER_2D_MULTISAMPLE_ARRAY_DEPTH_COPY ||
> shader_index == BLIT_MSAA_SHADER_2D_MULTISAMPLE_DEPTH_COPY) {
>char *sample_index;
> -  const char *arb_sample_shading_extension_string;
> +  const char *extra_extensions;
> +  const char *tex_coords = "texCoords";
>  
>if (dst_is_msaa) {
> - arb_sample_shading_extension_string = "#extension 
> GL_ARB_sample_shading : enable";
>   sample_index = "gl_SampleID";
>   name = "depth MSAA copy";
> +
> + if (ctx->Extensions.ARB_gpu_shader5 && samples >= 16) {
> +extra_extensions =
> +   "#extension GL_ARB_sample_shading : enable\n"
> +   "#extension GL_ARB_gpu_shader5 : enable\n";

You can unconditionally add the enables.  If the implementation doesn't
support the extension, enable will still succeed while require will not.

> +/* See comment below for the color copy */
> +tex_coords = "interpolateAtOffset(texCoords, vec2(0.0))";
> + } else {
> +extra_extensions = "#extension GL_ARB_sample_shading : enable\n";
> + }
>} else {
> - /* Don't need that extension, since we're drawing to a 
> single-sampled
> -  * destination.
> + /* Don't need any extra extensions, since we're drawing to a
> +  * single-sampled destination.
>*/
> - arb_sample_shading_extension_string = "";
> + extra_extensions = "";
>   /* From the GL 4.3 spec:
>*
>* "If there is a multisample buffer (the value of 
> SAMPLE_BUFFERS
> @@ -399,27 +409,57 @@ setup_glsl_msaa_blit_shader(struct gl_context *ctx,
>"\n"
>"void main()\n"
>"{\n"
> -  "   gl_FragDepth = texelFetch(texSampler, 
> i%s(texCoords), %s).r;\n"
> +  "   gl_FragDepth = texelFetch(texSampler, 
> i%s(%s), %s).r;\n"
>"}\n",
> -  arb_sample_shading_extension_string,
> +  extra_extensions,
>sampler_array_suffix,
>texcoord_type,
>texcoord_type,
> +  tex_coords,
>sample_index);
> } else {
>/* You can create 2D_MULTISAMPLE textures with 0 sample count (meaning 
> 1
> * sample).  Yes, this is ridiculous.
> */
>char *sample_resolve;
> -  const char *arb_sample_shading_extension_string;
> +  const char *extra_extensions;
>const char *merge_function;
>name = ralloc_asprintf(mem_ctx, "%svec4 MSAA %s",
>   vec4_prefix,
>   dst_is_msaa ? "copy" : "resolve");
>  
>if (dst_is_msaa) {
> - arb_sample_shading_extension_string = "#extension 
> GL_ARB_sample_shading : enable";
> - sample_resolve = ralloc_asprintf(mem_ctx, "   out_color = 
> texelFetch(texSampler, i%s(texCoords), gl_SampleID);", texcoord_type);
> + const char *tex_coords;
> +
> + if (ctx->Extensions.ARB_gpu_shader5 && samples >= 16) {
> +/* If interpolateAtOffset is available then it will be used to
> + * force the interpolation to the center. Thi

Re: [Mesa-dev] [PATCH v2] mesa: Draw Indirect return wrong error code on unalinged

2015-10-26 Thread Ian Romanick
Reviewed-by: Ian Romanick 

On 10/26/2015 03:22 AM, Marta Lofstedt wrote:
> From: Marta Lofstedt 
> 
> From OpenGL 4.4 specification, section 10.4 and
> Open GL Es 3.1 section 10.5:
> "An INVALID_VALUE error is generated if indirect is not a multiple
> of the size, in basic machine units, of uint."
> 
> However, the current code follow the ARB_draw_indirect:
> https://www.opengl.org/registry/specs/ARB/draw_indirect.txt
> "INVALID_OPERATION is generated by DrawArraysIndirect and
> DrawElementsIndirect if commands source data beyond the end
> of a buffer object or if  is not word aligned."
> 
> V2: After discussions on the list, it was suggested to
> only keep the INVALID_VALUE error.
> 
> Signed-off-by: Marta Lofstedt 
> ---
>  src/mesa/main/api_validate.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> index 40a2f43..19b6a73 100644
> --- a/src/mesa/main/api_validate.c
> +++ b/src/mesa/main/api_validate.c
> @@ -714,12 +714,14 @@ valid_draw_indirect(struct gl_context *ctx,
>return GL_FALSE;
>  
>  
> -   /* From the ARB_draw_indirect specification:
> -* "An INVALID_OPERATION error is generated [...] if  is no
> -*  word aligned."
> +   /* From OpenGL version 4.4. section 10.5
> +* and OpenGL ES 3.1, section 10.6:
> +*
> +*  "An INVALID_VALUE error is generated if indirect is not a
> +*   multiple of the size, in basic machine units, of uint."
>  */
> if ((GLsizeiptr)indirect & (sizeof(GLuint) - 1)) {
> -  _mesa_error(ctx, GL_INVALID_OPERATION,
> +  _mesa_error(ctx, GL_INVALID_VALUE,
>"%s(indirect is not aligned)", name);
>return GL_FALSE;
> }
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v2] mesa: Draw indirect is not allowed when xfb is active and unpaused

2015-10-26 Thread Ian Romanick
Reviewed-by: Ian Romanick 

On 10/26/2015 03:50 AM, Marta Lofstedt wrote:
> From: Marta Lofstedt 
> 
> OpenGL ES 3.1 specification, section 10.5:
> "An INVALID_OPERATION error is generated if
> transform feedback is active and not paused."
> 
> Signed-off-by: Marta Lofstedt 
> ---
>  src/mesa/main/api_validate.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c
> index fa6c1b5..303d5e8 100644
> --- a/src/mesa/main/api_validate.c
> +++ b/src/mesa/main/api_validate.c
> @@ -710,6 +710,16 @@ valid_draw_indirect(struct gl_context *ctx,
>return GL_FALSE;
> }
>  
> +   /* OpenGL ES 3.1 specification, section 10.5:
> +*
> +*  "An INVALID_OPERATION error is generated if
> +*  transform feedback is active and not paused."
> +*/
> +   if (_mesa_is_gles31(ctx) && _mesa_is_xfb_active_and_unpaused(ctx)) {
> +  _mesa_error(ctx, GL_INVALID_OPERATION,
> +  "%s(TransformFeedback is active but not paused)", name);
> +   }
> +
> /*
>  * OpenGL ES 3.1 spec. section 10.5:
>  * "An INVALID_OPERATION error is generated if zero is bound to
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: Enable ASTC in GLES' [NUM_]COMPRESSED_TEXTURE_FORMATS queries

2015-10-26 Thread Ian Romanick
Reviewed-by: Ian Romanick 

On 10/21/2015 03:06 PM, Nanley Chery wrote:
> From: Nanley Chery 
> 
> In OpenGL ES, the COMPRESSED_TEXTURE_FORMATS query returns the set of
> supported specific compressed formats. Since ASTC formats fit within
> that category, include them in the set and update the
> NUM_COMPRESSED_TEXTURE_FORMATS query as well.
> 
> This enables GLES2-based ASTC dEQP tests to run. See the Bugzilla for
> more info.
> 
> Cc: "11.0" 

I think we were mistaken about this... ASTC isn't actually in 11.0, is it?

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92193
> Reported-by: Tapani Pälli 
> Suggested-by: Ian Romanick 
> Signed-off-by: Nanley Chery 
> ---
>  src/mesa/main/texcompress.c | 85 
> +
>  1 file changed, 63 insertions(+), 22 deletions(-)
> 
> diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
> index 84973d3..9d22586 100644
> --- a/src/mesa/main/texcompress.c
> +++ b/src/mesa/main/texcompress.c
> @@ -243,28 +243,6 @@ _mesa_gl_compressed_format_base_format(GLenum format)
>   *what GL_NUM_COMPRESSED_TEXTURE_FORMATS and
>   *GL_COMPRESSED_TEXTURE_FORMATS return."
>   *
> - * The KHR_texture_compression_astc_hdr spec says:
> - *
> - *"Interactions with OpenGL 4.2
> - *
> - *OpenGL 4.2 supports the feature that compressed textures can be
> - *compressed online, by passing the compressed texture format enum as
> - *the internal format when uploading a texture using TexImage1D,
> - *TexImage2D or TexImage3D (see Section 3.9.3, Texture Image
> - *Specification, subsection Encoding of Special Internal Formats).
> - *
> - *Due to the complexity of the ASTC compression algorithm, it is not
> - *usually suitable for online use, and therefore ASTC support will be
> - *limited to pre-compressed textures only. Where on-device 
> compression
> - *is required, a domain-specific limited compressor will typically
> - *be used, and this is therefore not suitable for implementation in
> - *the driver.
> - *
> - *In particular, the ASTC format specifiers will not be added to
> - *Table 3.14, and thus will not be accepted by the TexImage*D
> - *functions, and will not be returned by the (already deprecated)
> - *COMPRESSED_TEXTURE_FORMATS query."
> - *
>   * There is no formal spec for GL_ATI_texture_compression_3dc.  Since the
>   * formats added by this extension are luminance-alpha formats, it is
>   * reasonable to expect them to follow the same rules as
> @@ -396,6 +374,69 @@ _mesa_get_compressed_formats(struct gl_context *ctx, 
> GLint *formats)
>   n += 10;
>}
> }
> +
> +   /* The KHR_texture_compression_astc_hdr spec says:
> +*
> +*"Interactions with OpenGL 4.2
> +*
> +*OpenGL 4.2 supports the feature that compressed textures can be
> +*compressed online, by passing the compressed texture format 
> enum as
> +*the internal format when uploading a texture using TexImage1D,
> +*TexImage2D or TexImage3D (see Section 3.9.3, Texture Image
> +*Specification, subsection Encoding of Special Internal Formats).
> +*
> +*Due to the complexity of the ASTC compression algorithm, it is 
> not
> +*usually suitable for online use, and therefore ASTC support 
> will be
> +*limited to pre-compressed textures only. Where on-device 
> compression
> +*is required, a domain-specific limited compressor will typically
> +*be used, and this is therefore not suitable for implementation 
> in
> +*the driver.
> +*
> +*In particular, the ASTC format specifiers will not be added to
> +*Table 3.14, and thus will not be accepted by the TexImage*D
> +*functions, and will not be returned by the (already deprecated)
> +*COMPRESSED_TEXTURE_FORMATS query."
> +*
> +* The ES and the desktop specs diverge here. In OpenGL ES, the 
> COMPRESSED_TEXTURE_FORMATS
> +* query returns the set of supported specific compressed formats.
> +*/
> +   if (ctx->API == API_OPENGLES2 &&
> +   ctx->Extensions.KHR_texture_compression_astc_ldr) {
> +  if (formats) {
> + formats[n++] = GL_COMPRESSED_RGBA_ASTC_4x4_KHR;
> + formats[n++] = GL_COMPRESSED_RGBA_ASTC_5x4_KHR;
> + formats[n++] = GL_COMPRESSED_RGBA_ASTC_5x5_KHR;
> + formats[n++] = GL_COMPRESSED_RGBA_ASTC_6x5_KHR;
> + formats[n++] = GL_CO

Re: [Mesa-dev] [PATCH 3/5] glsl: Mark gl_ViewportIndex and gl_Layer varyings as flat.

2015-10-26 Thread Ian Romanick
On 10/26/2015 11:03 AM, Kenneth Graunke wrote:
> Integer varyings need to be flat qualified - all others were already.
> I think we just missed this.  Presumably some hardware passes this via
> sideband and ignores attribute interpolation, so no one has noticed.
> 
> Signed-off-by: Kenneth Graunke 
> Cc: Chris Forbes 
> ---
>  src/glsl/builtin_variables.cpp | 39 ++-
>  1 file changed, 26 insertions(+), 13 deletions(-)
> 
> diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
> index a6ad105..07aacd4 100644
> --- a/src/glsl/builtin_variables.cpp
> +++ b/src/glsl/builtin_variables.cpp
> @@ -887,16 +887,22 @@ builtin_variable_generator::generate_uniforms()
>  void
>  builtin_variable_generator::generate_vs_special_vars()
>  {
> +   ir_variable *var;
> +
> if (state->is_version(130, 300))
>add_system_value(SYSTEM_VALUE_VERTEX_ID, int_t, "gl_VertexID");
> if (state->ARB_draw_instanced_enable)
>add_system_value(SYSTEM_VALUE_INSTANCE_ID, int_t, "gl_InstanceIDARB");
> if (state->ARB_draw_instanced_enable || state->is_version(140, 300))
>add_system_value(SYSTEM_VALUE_INSTANCE_ID, int_t, "gl_InstanceID");
> -   if (state->AMD_vertex_shader_layer_enable)
> -  add_output(VARYING_SLOT_LAYER, int_t, "gl_Layer");
> -   if (state->AMD_vertex_shader_viewport_index_enable)
> -  add_output(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
> +   if (state->AMD_vertex_shader_layer_enable) {
> +  var = add_output(VARYING_SLOT_LAYER, int_t, "gl_Layer");
> +  var->data.interpolation = INTERP_QUALIFIER_FLAT;
> +   }
> +   if (state->AMD_vertex_shader_viewport_index_enable) {
> +  var = add_output(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
> +  var->data.interpolation = INTERP_QUALIFIER_FLAT;
> +   }
> if (compatibility) {
>add_input(VERT_ATTRIB_POS, vec4_t, "gl_Vertex");
>add_input(VERT_ATTRIB_NORMAL, vec3_t, "gl_Normal");
> @@ -954,11 +960,16 @@ builtin_variable_generator::generate_tes_special_vars()
>  void
>  builtin_variable_generator::generate_gs_special_vars()
>  {
> -   add_output(VARYING_SLOT_LAYER, int_t, "gl_Layer");
> -   if (state->is_version(410, 0) || state->ARB_viewport_array_enable)
> -  add_output(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
> +   ir_variable *var;
> +
> +   var = add_output(VARYING_SLOT_LAYER, int_t, "gl_Layer");
> +   var->data.interpolation = INTERP_QUALIFIER_FLAT;
> +   if (state->is_version(410, 0) || state->ARB_viewport_array_enable) {
> +  var = add_output(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
> +  var->data.interpolation = INTERP_QUALIFIER_FLAT;
> +   }
> if (state->is_version(400, 0) || state->ARB_gpu_shader5_enable)
> -  add_system_value(SYSTEM_VALUE_INVOCATION_ID, int_t, "gl_InvocationID");
> +  var = add_system_value(SYSTEM_VALUE_INVOCATION_ID, int_t, 
> "gl_InvocationID");

Shouldn't this set var->data.interpolation?  It looks like you only made
half the change.

>  
> /* Although gl_PrimitiveID appears in tessellation control and 
> tessellation
>  * evaluation shaders, it has a different function there than it has in
> @@ -970,7 +981,6 @@ builtin_variable_generator::generate_gs_special_vars()
>  * the specific case of gl_PrimitiveIDIn.  So we don't need to treat
>  * gl_PrimitiveIDIn as an {ARB,EXT}_geometry_shader4-only variable.
>  */
> -   ir_variable *var;
> var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t, "gl_PrimitiveIDIn");
> var->data.interpolation = INTERP_QUALIFIER_FLAT;
> var = add_output(VARYING_SLOT_PRIMITIVE_ID, int_t, "gl_PrimitiveID");
> @@ -984,14 +994,15 @@ builtin_variable_generator::generate_gs_special_vars()
>  void
>  builtin_variable_generator::generate_fs_special_vars()
>  {
> +   ir_variable *var;
> +
> add_input(VARYING_SLOT_POS, vec4_t, "gl_FragCoord");
> add_input(VARYING_SLOT_FACE, bool_t, "gl_FrontFacing");
> if (state->is_version(120, 100))
>add_input(VARYING_SLOT_PNTC, vec2_t, "gl_PointCoord");
>  
> if (state->is_version(150, 0)) {
> -  ir_variable *var =
> - add_input(VARYING_SLOT_PRIMITIVE_ID, int_t, "gl_PrimitiveID");
> +  var = add_input(VARYING_SLOT_PRIMITIVE_ID, int_t, "gl_PrimitiveID");
>var->data.interpolation = INTERP_QUALIFIER_FLAT;
> }
>  
> @@ -1043,8 +1054,10 @@ builtin_variable_generator::generate_fs_special_vars()
> }
>  
> if (state->is_version(430, 0) || 
> state->ARB_fragment_layer_viewport_enable) {
> -  add_input(VARYING_SLOT_LAYER, int_t, "gl_Layer");
> -  add_input(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
> +  var = add_input(VARYING_SLOT_LAYER, int_t, "gl_Layer");
> +  var->data.interpolation = INTERP_QUALIFIER_FLAT;
> +  var = add_input(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
> +  var->data.interpolation = INTERP_QUALIFIER_FLAT;
> }
>  }
>  
> 

___
mesa-d

Re: [Mesa-dev] [PATCH] i965: Set correct field for indirect align16 addrimm.

2015-10-26 Thread Ian Romanick
On 10/26/2015 11:10 AM, Matt Turner wrote:
> This has been wrong since the initial import of the i965 driver.

That is awesome.  Other than using the assembly validator, is there any
way to trigger this?  I assume you discovered this bug by inspection...

> ---
>  src/mesa/drivers/dri/i965/brw_eu_emit.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c 
> b/src/mesa/drivers/dri/i965/brw_eu_emit.c
> index ebd811f..df48590 100644
> --- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
> +++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
> @@ -410,7 +410,7 @@ brw_set_src0(struct brw_codegen *p, brw_inst *inst, 
> struct brw_reg reg)
>   if (brw_inst_access_mode(devinfo, inst) == BRW_ALIGN_1) {
>  brw_inst_set_src0_ia1_addr_imm(devinfo, inst, 
> reg.dw1.bits.indirect_offset);
>} else {
> -brw_inst_set_src0_ia_subreg_nr(devinfo, inst, 
> reg.dw1.bits.indirect_offset);
> +brw_inst_set_src0_ia16_addr_imm(devinfo, inst, 
> reg.dw1.bits.indirect_offset);
>}
>}
>  
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: fix error type for GetFramebufferAttachmentParameteriv

2015-10-27 Thread Ian Romanick
On 10/27/2015 12:11 AM, Tapani Pälli wrote:
> Fixes following failing dEQP test:
>dEQP-GLES3.functional.fbo.api.attachment_query_empty_fbo
> 
> Signed-off-by: Tapani Pälli 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92649
> Cc: "11.0" 
> ---
>  src/mesa/main/fbobject.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index fe6bdc2..d91fb4a 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -3540,8 +3540,9 @@ _mesa_get_framebuffer_attachment_parameter(struct 
> gl_context *ctx,
> const struct gl_renderbuffer_attachment *att;
> GLenum err;
>  
> -   /* The error differs in GL and GLES. */
> -   err = _mesa_is_desktop_gl(ctx) ? GL_INVALID_OPERATION : GL_INVALID_ENUM;
> +   /* The error differs between GL/GLES3 and GLES 2.0. */

Could we get quotations from the various specs here? That would have
saved me some time. The commit log for 000896c0 as the GLES2 reference.
For GLES 3.0,

Section 6.1.13 (Framebuffer Object Queries) of the OpenGL ES 3.0.4 spec
says:

"If the value of FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is NONE, no
framebuffer is bound to target. In this case querying pname
FRAMEBUFFER_ATTACHMENT_OBJECT_NAME will return zero, and all other
queries will generate an INVALID_OPERATION error."

The GLES2 reference in the commit above is Section 6.1.3 (Enumerated
Queries).

I feel a bit conflicted about this change.  Section F.2 (Differences in
Runtime Behavior) of the OpenGL ES 3.0.4 spec lists three subtle (but
possibly important) differences between ES2 and ES3.  This list does
*not* include changed errors.  I don't have any specific recollection
about these changes, but this causes me to believe that these are
corrects to ES2.

What do the CTS and dEQP do if you...

- Always generate GL_INVALID_OPERATION.

- Only return an ES2 context.

If all the GLES2 conformance tests and the dEQP-GLES2 tests still pass,
I would be inclined to just always do GL_INVALID_OPERATION.

> +   err = _mesa_is_desktop_gl(ctx) || _mesa_is_gles3(ctx) ?
> +  GL_INVALID_OPERATION : GL_INVALID_ENUM;
>  
> if (_mesa_is_winsys_fbo(buffer)) {
>/* Page 126 (page 136 of the PDF) of the OpenGL ES 2.0.25 spec
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] i965: Do legacy userclipping in OpenGL ES 1.x contexts.

2015-10-27 Thread Ian Romanick
From: Ian Romanick 

Commit fba4823a disabled user clipping for everything except
compatibility profile.  Core profile and OpenGL ES 2.0+ have all removed
the classic, OpenGL 1.0 user clip planes.  ES 1.x, however, still has
them.

Fixes OpenGL ES 1.1 conformance mustpass.c and userclip.c

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92639
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92641
---
 src/mesa/drivers/dri/i965/brw_vs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_vs.c 
b/src/mesa/drivers/dri/i965/brw_vs.c
index 5db4b3a..0b805b1 100644
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -311,7 +311,8 @@ brw_vs_populate_key(struct brw_context *brw,
key->program_string_id = vp->id;
 
if (ctx->Transform.ClipPlanesEnabled != 0 &&
-   ctx->API == API_OPENGL_COMPAT &&
+   (ctx->API == API_OPENGL_COMPAT ||
+ctx->API == API_OPENGLES) &&
vp->program.Base.ClipDistanceArraySize == 0) {
   key->nr_userclip_plane_consts =
  _mesa_logbase2(ctx->Transform.ClipPlanesEnabled) + 1;
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa/teximage: Fix ASTC-caused S3TC regression

2015-10-28 Thread Ian Romanick
On 10/28/2015 09:52 AM, Nanley Chery wrote:
> From: Nanley Chery 
> 
> The ASTC spec forbids other compressed formats from being used against
> the targets: TEXTURE_CUBE_MAP_ARRAY and TEXTURE_3D. Because other

I apologize for not paying very much attention to this previously.

I think we're taking too literal of a reading of the spec.  The ASTC
extension extends the core OpenGL ES and desktop OpenGL specifications.
 It does not interact with other extensions that are not part of the
core.  I see no interactions in the ASTC specification with any S3TC
spec, GL_3DFX_texture_compression_FXT1, GL_EXT_texture_compression_latc,
or GL_ATI_texture_compression_3dc.  As a result, the existence of ASTC
should have *no* affect on what is allowed with those compression formats.

Judging from table 8.17 in the OpenGL ES 3.2 spec, I think the only
formats that should ever be disallowed for cubemap arrays is the ETC
formats.  From reading the errors in section 8.5.3 (Texture Image
Structure) of the OpenGL 4.5 spec, even that limitation should only
apply to OpenGL ES.

> compressed formats were previously supported for these targets in
> desktop GL, it's considered to be a spec bug and Mesa will diverge from
> this behavior for desktop GL.
> 
> Fixes the following Piglit tests on Gen9:
> piglit.spec.arb_direct_state_access.getcompressedtextureimage
> piglit.spec.arb_get_texture_sub_image.arb_get_texture_sub_image-getcompressed
> piglit.spec.arb_texture_cube_map_array.fbo-generatemipmap-cubemap array 
> s3tc_dxt1
> piglit.spec.ext_texture_compression_s3tc.getteximage-targets cube_array s3tc
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91927
> Suggested-by: Neil Roberts 
> Signed-off-by: Nanley Chery 
> ---
>  src/mesa/main/teximage.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index d9453e3..eccf009 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
> @@ -1373,7 +1373,8 @@ _mesa_target_can_be_compressed(const struct gl_context 
> *ctx, GLenum target,
>/* Throw an INVALID_OPERATION error if the target is
> * TEXTURE_CUBE_MAP_ARRAY and the format is not ASTC.
> */
> -  if (target_can_be_compresed &&
> +  /* FIXME: Correct the spec to restrict this behavior to GLES as well. 
> */
> +  if (target_can_be_compresed && _mesa_is_gles(ctx) &&
>ctx->Extensions.KHR_texture_compression_astc_ldr &&
>layout != MESA_FORMAT_LAYOUT_ASTC)
>   return write_error(error, GL_INVALID_OPERATION);
> @@ -1405,7 +1406,9 @@ _mesa_target_can_be_compressed(const struct gl_context 
> *ctx, GLenum target,
>* the format is not ASTC.
>* See comment in switch case GL_TEXTURE_CUBE_MAP_ARRAY for more 
> info.

I'm a bit confused about the comment above and the strangeness with the
error codes.  I'll dig a bit into the specs.

>*/
> - if (ctx->Extensions.KHR_texture_compression_astc_ldr)
> + /* FIXME: Correct the spec to restrict this behavior to GLES as 
> well. */
> + if (_mesa_is_gles(ctx) &&
> + ctx->Extensions.KHR_texture_compression_astc_ldr)
>  return write_error(error, GL_INVALID_OPERATION);
>   break;
>}
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/11] nir: Add a pass-running infastructure

2015-10-28 Thread Ian Romanick
On 10/28/2015 02:32 PM, Jason Ekstrand wrote:
> ---
>  src/glsl/nir/nir.h  | 19 +++
>  src/glsl/nir/nir_pass.c | 64 
> -
>  2 files changed, 82 insertions(+), 1 deletion(-)
> 
> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
> index e3777f9..069c7c1 100644
> --- a/src/glsl/nir/nir.h
> +++ b/src/glsl/nir/nir.h
> @@ -1582,6 +1582,25 @@ typedef struct nir_shader {
>foreach_list_typed(nir_function_overload, overload, node, \
>   &(func)->overload_list)
>  
> +typedef struct nir_pass {

A couple years ago Kristian, with the support of everyone, waged a war
on 'typedef struct foo { ... } foo;'  Has this awful idiom really risen
from the dead?  Can we please send it back to the grave?

> +   bool (*shader_pass_func)(nir_shader *shader, void *data);
> +   bool (*impl_pass_func)(nir_function_impl *impl, void *data);
> +   nir_metadata metadata_preserved;
> +   void *data;
> +} nir_pass;
> +
> +static inline nir_pass
> +nir_pass_with_data(nir_pass pass, void *data)
> +{
> +   pass.data = data;
> +   return pass;
> +}
> +
> +bool nir_shader_run_pass(nir_shader *shader, const nir_pass *pass);
> +bool nir_function_impl_run_pass(nir_function_impl *impl, const nir_pass 
> *pass);
> +bool nir_shader_optimize(nir_shader *shader,
> + const nir_pass *passes, unsigned num_passes);
> +
>  nir_shader *nir_shader_create(void *mem_ctx,
>gl_shader_stage stage,
>const nir_shader_compiler_options *options);
> diff --git a/src/glsl/nir/nir_pass.c b/src/glsl/nir/nir_pass.c
> index a03e124..059d016 100644
> --- a/src/glsl/nir/nir_pass.c
> +++ b/src/glsl/nir/nir_pass.c
> @@ -27,7 +27,7 @@
>  #include "nir.h"
>  
>  /*
> - * Handles management of the metadata.
> + * Handles management of NIR passes and metadata.
>   */
>  
>  void
> @@ -52,3 +52,65 @@ nir_metadata_preserve(nir_function_impl *impl, 
> nir_metadata preserved)
>  {
> impl->valid_metadata &= preserved;
>  }
> +
> +static bool
> +_function_impl_run_pass(nir_function_impl *impl, const nir_pass *pass)
> +{
> +   bool progress = pass->impl_pass_func(impl, pass->data);
> +   if (progress)
> +  nir_metadata_preserve(impl, pass->metadata_preserved);
> +
> +   return progress;
> +}
> +
> +bool
> +nir_function_impl_run_pass(nir_function_impl *impl, const nir_pass *pass)
> +{
> +   bool progress = _function_impl_run_pass(impl, pass);
> +
> +   /* TODO: Add a way to validate a single function_impl */
> +   nir_validate_shader(impl->overload->function->shader);
> +
> +   return progress;
> +}
> +
> +bool
> +nir_shader_run_pass(nir_shader *shader, const nir_pass *pass)
> +{
> +   bool progress;
> +   if (pass->shader_pass_func) {
> +  progress = pass->shader_pass_func(shader, pass->data);
> +
> +  if (progress) {
> + nir_foreach_overload(shader, overload) {
> +if (overload->impl)
> +   nir_metadata_preserve(overload->impl, 
> pass->metadata_preserved);
> + }
> +  }
> +   } else {
> +  progress = false;
> +  nir_foreach_overload(shader, overload) {
> + if (overload->impl)
> +progress |= _function_impl_run_pass(overload->impl, pass);
> +  }
> +   }
> +
> +   return progress;
> +}
> +
> +bool
> +nir_shader_optimize(nir_shader *shader,
> +const nir_pass *passes, unsigned num_passes)
> +{
> +   bool progress, total_progress = false;
> +
> +   do {
> +  progress = false;
> +  for (unsigned p = 0; p < num_passes; p++)
> + progress |= nir_shader_run_pass(shader, &passes[p]);
> +
> +  total_progress |= progress;
> +   } while (progress);
> +
> +   return total_progress;
> +}
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 05/11] nir/phis_to_scalar: Use the nir_pass framework internally

2015-10-28 Thread Ian Romanick
On 10/28/2015 02:32 PM, Jason Ekstrand wrote:
> ---
>  src/glsl/nir/nir_lower_phis_to_scalar.c | 25 -
>  1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/src/glsl/nir/nir_lower_phis_to_scalar.c 
> b/src/glsl/nir/nir_lower_phis_to_scalar.c
> index aa124d9..909a743 100644
> --- a/src/glsl/nir/nir_lower_phis_to_scalar.c
> +++ b/src/glsl/nir/nir_lower_phis_to_scalar.c
> @@ -41,6 +41,8 @@ struct lower_phis_to_scalar_state {
>  * scalarizable or non-null for scalarizable.
>  */
> struct hash_table *phi_table;
> +
> +   bool progress;
>  };
>  
>  static bool
> @@ -192,6 +194,8 @@ lower_phis_to_scalar_block(nir_block *block, void 
> *void_state)
>if (!should_lower_phi(phi, state))
>   continue;
>  
> +  state->progress = true;
> +
>/* Create a vecN operation to combine the results.  Most of these
> * will be redundant, but copy propagation should clean them up for
> * us.  No need to add the complexity here.
> @@ -262,8 +266,8 @@ lower_phis_to_scalar_block(nir_block *block, void 
> *void_state)
> return true;
>  }
>  
> -static void
> -lower_phis_to_scalar_impl(nir_function_impl *impl)
> +static bool
> +lower_phis_to_scalar_impl(nir_function_impl *impl, void *unused)

Please add a '(void) unused;' in the function so that other people don't
get added, spurious warnings... and have to submit a patch that adds it
anyway.  I really hope a future C standard enables the C++ idiom of
leaving the names off unused parameters.

>  {
> struct lower_phis_to_scalar_state state;
>  
> @@ -271,13 +275,13 @@ lower_phis_to_scalar_impl(nir_function_impl *impl)
> state.dead_ctx = ralloc_context(NULL);
> state.phi_table = _mesa_hash_table_create(state.dead_ctx, 
> _mesa_hash_pointer,
>   _mesa_key_pointer_equal);
> +   state.progress = false;
>  
> nir_foreach_block(impl, lower_phis_to_scalar_block, &state);
>  
> -   nir_metadata_preserve(impl, nir_metadata_block_index |
> -   nir_metadata_dominance);
> -
> ralloc_free(state.dead_ctx);
> +
> +   return state.progress;
>  }
>  
>  /** A pass that lowers vector phi nodes to scalar
> @@ -287,11 +291,14 @@ lower_phis_to_scalar_impl(nir_function_impl *impl)
>   * instance, if one of the sources is a non-scalarizable vector, then we
>   * don't bother lowering because that would generate hard-to-coalesce movs.
>   */
> +static const nir_pass nir_lower_phis_to_scalar_pass = {
> +   NULL, /* shader_pass_func */
> +   lower_phis_to_scalar_impl,
> +   nir_metadata_block_index | nir_metadata_dominance,
> +};
> +
>  void
>  nir_lower_phis_to_scalar(nir_shader *shader)
>  {
> -   nir_foreach_overload(shader, overload) {
> -  if (overload->impl)
> - lower_phis_to_scalar_impl(overload->impl);
> -   }
> +   nir_shader_run_pass(shader, &nir_lower_phis_to_scalar_pass);
>  }
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 07/11] nir: Use the nir_pass framework internally for copy_prop, dce, and cse

2015-10-28 Thread Ian Romanick
On 10/28/2015 02:32 PM, Jason Ekstrand wrote:
> ---
>  src/glsl/nir/nir_opt_copy_propagate.c | 17 -
>  src/glsl/nir/nir_opt_cse.c| 21 -
>  src/glsl/nir/nir_opt_dce.c| 20 
>  3 files changed, 24 insertions(+), 34 deletions(-)
> 
> diff --git a/src/glsl/nir/nir_opt_copy_propagate.c 
> b/src/glsl/nir/nir_opt_copy_propagate.c
> index 96520f8..7ee86d4 100644
> --- a/src/glsl/nir/nir_opt_copy_propagate.c
> +++ b/src/glsl/nir/nir_opt_copy_propagate.c
> @@ -257,7 +257,7 @@ copy_prop_block(nir_block *block, void *_state)
>  }
>  
>  static bool
> -nir_copy_prop_impl(nir_function_impl *impl)
> +nir_copy_prop_impl(nir_function_impl *impl, void *unused)
>  {
> bool progress = false;
>  
> @@ -265,15 +265,14 @@ nir_copy_prop_impl(nir_function_impl *impl)
> return progress;
>  }
>  
> +static const nir_pass nir_opt_copy_prop_pass = {
> +   NULL, /* shader_pass_func */
> +   nir_copy_prop_impl,
> +   nir_metadata_block_index | nir_metadata_dominance,
> +};
> +
>  bool
>  nir_copy_prop(nir_shader *shader)
>  {
> -   bool progress = false;
> -
> -   nir_foreach_overload(shader, overload) {
> -  if (overload->impl && nir_copy_prop_impl(overload->impl))
> - progress = true;
> -   }
> -
> -   return progress;
> +   return nir_shader_run_pass(shader, &nir_opt_copy_prop_pass);
>  }
> diff --git a/src/glsl/nir/nir_opt_cse.c b/src/glsl/nir/nir_opt_cse.c
> index 93a6635..453aa38 100644
> --- a/src/glsl/nir/nir_opt_cse.c
> +++ b/src/glsl/nir/nir_opt_cse.c
> @@ -62,7 +62,7 @@ cse_block(nir_block *block, struct set *instr_set)
>  }
>  
>  static bool
> -nir_opt_cse_impl(nir_function_impl *impl)
> +nir_opt_cse_impl(nir_function_impl *impl, void *unused)

Same comment here as on patch 5.

>  {
> struct set *instr_set = nir_instr_set_create(NULL);
>  
> @@ -70,24 +70,19 @@ nir_opt_cse_impl(nir_function_impl *impl)
>  
> bool progress = cse_block(nir_start_block(impl), instr_set);
>  
> -   if (progress)
> -  nir_metadata_preserve(impl, nir_metadata_block_index |
> -  nir_metadata_dominance);
> -
> nir_instr_set_destroy(instr_set);
> return progress;
>  }
>  
> +static const nir_pass nir_opt_cse_pass = {
> +   NULL, /* shader_pass_func */
> +   nir_opt_cse_impl,
> +   nir_metadata_block_index | nir_metadata_dominance,
> +};
> +
>  bool
>  nir_opt_cse(nir_shader *shader)
>  {
> -   bool progress = false;
> -
> -   nir_foreach_overload(shader, overload) {
> -  if (overload->impl)
> - progress |= nir_opt_cse_impl(overload->impl);
> -   }
> -
> -   return progress;
> +   return nir_shader_run_pass(shader, &nir_opt_cse_pass);
>  }
>  
> diff --git a/src/glsl/nir/nir_opt_dce.c b/src/glsl/nir/nir_opt_dce.c
> index 6032528..9d133cd 100644
> --- a/src/glsl/nir/nir_opt_dce.c
> +++ b/src/glsl/nir/nir_opt_dce.c
> @@ -146,7 +146,7 @@ delete_block_cb(nir_block *block, void *_state)
>  }
>  
>  static bool
> -nir_opt_dce_impl(nir_function_impl *impl)
> +nir_opt_dce_impl(nir_function_impl *impl, void *unused)

Ditto.

>  {
> struct exec_list *worklist = ralloc(NULL, struct exec_list);
> exec_list_make_empty(worklist);
> @@ -163,21 +163,17 @@ nir_opt_dce_impl(nir_function_impl *impl)
> bool progress = false;
> nir_foreach_block(impl, delete_block_cb, &progress);
>  
> -   if (progress)
> -  nir_metadata_preserve(impl, nir_metadata_block_index |
> -  nir_metadata_dominance);
> -
> return progress;
>  }
>  
> +static const nir_pass nir_opt_dce_pass = {
> +   NULL, /* shader_pass_func */
> +   nir_opt_dce_impl,
> +   nir_metadata_block_index | nir_metadata_dominance,
> +};
> +
>  bool
>  nir_opt_dce(nir_shader *shader)
>  {
> -   bool progress = false;
> -   nir_foreach_overload(shader, overload) {
> -  if (overload->impl && nir_opt_dce_impl(overload->impl))
> - progress = true;
> -   }
> -
> -   return progress;
> +   return nir_shader_run_pass(shader, &nir_opt_dce_pass);
>  }
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/11] nir: Add a pass-running infastructure

2015-10-28 Thread Ian Romanick
On 10/28/2015 04:43 PM, Connor Abbott wrote:
> On Wed, Oct 28, 2015 at 7:06 PM, Ian Romanick  wrote:
>> On 10/28/2015 02:32 PM, Jason Ekstrand wrote:
>>> ---
>>>  src/glsl/nir/nir.h  | 19 +++
>>>  src/glsl/nir/nir_pass.c | 64 
>>> -
>>>  2 files changed, 82 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>>> index e3777f9..069c7c1 100644
>>> --- a/src/glsl/nir/nir.h
>>> +++ b/src/glsl/nir/nir.h
>>> @@ -1582,6 +1582,25 @@ typedef struct nir_shader {
>>>foreach_list_typed(nir_function_overload, overload, node, \
>>>   &(func)->overload_list)
>>>
>>> +typedef struct nir_pass {
>>
>> A couple years ago Kristian, with the support of everyone, waged a war
>> on 'typedef struct foo { ... } foo;'  Has this awful idiom really risen
>> from the dead?  Can we please send it back to the grave?
> 
> (flamewar incoming!)
> 
> Yes, it has, and no.
> 
> In case you haven't read any NIR code, NIR uses this all over the
> place -- all of the core datastructures are typedef'd. The only
> argument I've heard against this practice, from Linus, is that it
> makes telling if a value is a lightweight thing, like an integer, or
> not. But this isn't the kernel; we don't use typedefs for integers at

But that it is the way *this* project has done things.  We made a
conscious decision to do them that way.  I don't think you guys had any
right to unilaterally decide to change that.

Saying that not having to type 'struct' is some huge time savings is
just pure rubbish.  I have a lot of trouble believing that you could
even say it out loud with a straight face.  Seriously.

What is real is the difficulty of maintaining a project with 238
different coding styles.  As soon as look in a different part of the
code, you have to relearn things in order to get any work done.  This is
already a really, really big problem in Mesa.  We constantly give people
review feedback like, "You did this the way other things in that file
are done, but that's not how we do it in the rest of the project now.
Please change."

I'll go out on a limb and guess that the amount of time spent trying to
figure out what the coding style is in an particular part of the project
is, rejecting patches that didn't properly meet those standards in spite
of the author's best effort, and re-spinning patches outweighs the time
spent typing 'struct' by a margin of 10:1.

People often complain about the way that open-source projects are so nit
picky about coding standards.  It's a necessary survival tactic.  Mesa
is 22 years old.  It has had dozens of contributors.  Imagine how much
worse it would be if every contributor, or even just the major
contributors, got to change aspects of the coding standards that they
didn't like or thought was too much work.  It would be a completely
maintainable disaster.  I plan to work on this project for another 14
years, and I'm going to do my best to keep it from falling apart into
that disaster.

> all, and the only place where we use nir_* and it *isn't* a structure
> is the enums. Pretty much the entire time, it's fairly obvious these
> are enums, either because they have "type" in the name (e.g.
> nir_instr_type), indicating C-style subclassing, or they're some kind
> of operation code (nir_op and nir_intrinsic_op). This is fairly
> subjective, but if you're not able to look at a nir_* type and know
> whether it's a lightweight thing or not, then you probably don't know
> the code well enough to understand it anyways. The amount of typing
> they save is just way too large compared to the potential
> (theoretical) inconvenience of not knowing how the type is declared.
> But if this bikeshed seriously disturbs you, then I'd much rather
> change the enums to not be typedef'd, since you have to type out their
> types a lot less often.
> 
>>
>>> +   bool (*shader_pass_func)(nir_shader *shader, void *data);
>>> +   bool (*impl_pass_func)(nir_function_impl *impl, void *data);
>>> +   nir_metadata metadata_preserved;
>>> +   void *data;
>>> +} nir_pass;
>>> +
>>> +static inline nir_pass
>>> +nir_pass_with_data(nir_pass pass, void *data)
>>> +{
>>> +   pass.data = data;
>>> +   return pass;
>>> +}
>>> +
>>> +bool nir_shader_run_pass(nir_shader *shader, const nir_pass *pass);
>>> +bool nir_function_impl_run_pass(nir_function_impl *impl, const nir_pass 

Re: [Mesa-dev] [Mesa-stable] [PATCH 1/2] [v3] i965/skl: Add GT4 PCI IDs

2015-10-30 Thread Ian Romanick
On 10/29/2015 05:30 PM, Ben Widawsky wrote:
> Like other gen8+ hardware, the hardware automatically scales up thread counts
> and URB sizes, so there is no need to do anything but add the PCI IDs.

Give the v3 change, is that really true?

> FINISHME: This patch still needs testing before merge.
> 
> v2: Remove the PCI ID removal. That should be done as part of the next patch.
> 
> v3: Update the wm thread count to support GT4.
> 
> Cc: mesa-sta...@lists.freedesktop.org
> Signed-off-by: Ben Widawsky 
> ---
>  include/pci_ids/i965_pci_ids.h  | 4 
>  src/mesa/drivers/dri/i965/brw_device_info.c | 6 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> index 8a42599..626064a 100644
> --- a/include/pci_ids/i965_pci_ids.h
> +++ b/include/pci_ids/i965_pci_ids.h
> @@ -124,6 +124,10 @@ CHIPSET(0x1921, skl_gt2, "Intel(R) Skylake ULT GT2F")
>  CHIPSET(0x1926, skl_gt3, "Intel(R) Skylake ULT GT3")
>  CHIPSET(0x192A, skl_gt3, "Intel(R) Skylake SRV GT3")
>  CHIPSET(0x192B, skl_gt3, "Intel(R) Skylake Halo GT3")
> +CHIPSET(0x1932, skl_gt4, "Intel(R) Skylake GT4")
> +CHIPSET(0x193A, skl_gt4, "Intel(R) Skylake GT4")
> +CHIPSET(0x193B, skl_gt4, "Intel(R) Skylake GT4")
> +CHIPSET(0x193D, skl_gt4, "Intel(R) Skylake GT4")
>  CHIPSET(0x22B0, chv, "Intel(R) HD Graphics (Cherryview)")
>  CHIPSET(0x22B1, chv, "Intel(R) HD Graphics (Cherryview)")
>  CHIPSET(0x22B2, chv, "Intel(R) HD Graphics (Cherryview)")
> diff --git a/src/mesa/drivers/dri/i965/brw_device_info.c 
> b/src/mesa/drivers/dri/i965/brw_device_info.c
> index e86b530..2ebc084 100644
> --- a/src/mesa/drivers/dri/i965/brw_device_info.c
> +++ b/src/mesa/drivers/dri/i965/brw_device_info.c
> @@ -311,7 +311,7 @@ static const struct brw_device_info brw_device_info_chv = 
> {
> .max_gs_threads = 336,   \
> .max_hs_threads = 336,   \
> .max_ds_threads = 336,   \
> -   .max_wm_threads = 64 * 6,\
> +   .max_wm_threads = 64 * 9,\
> .max_cs_threads = 56,\
> .urb = { \
>.size = 384,  \
> @@ -335,6 +335,10 @@ static const struct brw_device_info 
> brw_device_info_skl_gt3 = {
> GEN9_FEATURES, .gt = 3,
>  };
>  
> +static const struct brw_device_info brw_device_info_skl_gt4 = {
> +   GEN9_FEATURES, .gt = 4,
> +};
> +
>  static const struct brw_device_info brw_device_info_bxt = {
> GEN9_FEATURES,
> .is_broxton = 1,
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/11] nir: Add a pass-running infastructure

2015-10-30 Thread Ian Romanick
On 10/28/2015 09:26 PM, Ilia Mirkin wrote:
> On Wed, Oct 28, 2015 at 8:04 PM, Ian Romanick  wrote:
>> People often complain about the way that open-source projects are so nit
>> picky about coding standards.  It's a necessary survival tactic.  Mesa
>> is 22 years old.  It has had dozens of contributors.  Imagine how much
> 
> There are like 10 different areas in mesa and they all have their own
> styles. Each area is often strict on its style, but that style is
> strictly different from other areas. 3-space indent, 4-space tabs,
> 8-space tabs, indent next line to some (imho) weird rule, case
> indented from switch, case not indented. Not to mention the places
> that are one line with tabs, one without, one with some tabs and some
> spaces, etc.

I know, and it's terrible.  Every time I do some sort of infrastructure
work that requires changes in the r200 driver I have to spend extra
effort to be sure I'm formatting thing the right way for that area.
That's a big part of the reason I don't want it to get worse.

> In past lives, I've often been on the side of "oh noes, fixing it all
> will mess up history", but experience with a few times where I've lost
> that battle(/not cared enough) has taught me that it's not such a big
> deal. Even if you go and change *every single line* in the project,

When we have made style changes or noted inconsistencies, we generally
haven't gone and fixed everything.  This wasn't because of messing up
history.  It has been because going and fixing everything is a lot of
tedious, often time consuming work... and that hasn't been compatible
with people's stuff-to-do:time-to-do-stuff ratio.  It can also making
cherry picking to stable and rebasing pending branches annoying, but
that's generally a minor issue compared to the effort of changing 3,000
files to make style changes.

> it's not that big of a deal. git blame -w ignores whitespace changes,
> and even for more substantial churn all you end up having to do is run
> one extra command in some situations. I find that I write/modify code
> a lot more often than I do git blames. And I spend even more time
> thinking about the code I write, so typing "struct" or anything like
> that is never an issue.
> 
> I would definitely be in favor of doing a major cleanup if some
> baseline rules can be agreed upon.
> 
>   -ilia

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/11] nir: Add a pass-running infastructure

2015-10-30 Thread Ian Romanick
On 10/28/2015 06:30 PM, Kenneth Graunke wrote:
> On Wednesday, October 28, 2015 05:04:07 PM Ian Romanick wrote:
>> On 10/28/2015 04:43 PM, Connor Abbott wrote:
>>> On Wed, Oct 28, 2015 at 7:06 PM, Ian Romanick  wrote:
>>>> On 10/28/2015 02:32 PM, Jason Ekstrand wrote:
>>>>> ---
>>>>>  src/glsl/nir/nir.h  | 19 +++
>>>>>  src/glsl/nir/nir_pass.c | 64 
>>>>> -
>>>>>  2 files changed, 82 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>>>>> index e3777f9..069c7c1 100644
>>>>> --- a/src/glsl/nir/nir.h
>>>>> +++ b/src/glsl/nir/nir.h
>>>>> @@ -1582,6 +1582,25 @@ typedef struct nir_shader {
>>>>>foreach_list_typed(nir_function_overload, overload, node, \
>>>>>   &(func)->overload_list)
>>>>>
>>>>> +typedef struct nir_pass {
>>>>
>>>> A couple years ago Kristian, with the support of everyone, waged a war
>>>> on 'typedef struct foo { ... } foo;'  Has this awful idiom really risen
>>>> from the dead?  Can we please send it back to the grave?
>>>
>>> (flamewar incoming!)
>>>
>>> Yes, it has, and no.
>>>
>>> In case you haven't read any NIR code, NIR uses this all over the
>>> place -- all of the core datastructures are typedef'd. The only
>>> argument I've heard against this practice, from Linus, is that it
>>> makes telling if a value is a lightweight thing, like an integer, or
>>> not. But this isn't the kernel; we don't use typedefs for integers at
>>
>> But that it is the way *this* project has done things.  We made a
>> conscious decision to do them that way.  I don't think you guys had any
>> right to unilaterally decide to change that.
> 
> I don't think it's as clear cut as that.  Most of the GLSL compiler was
> written in C++, and so the compiler code constantly referred to objects
> without using 'struct' or 'class'.  See every piece of code that deals
> with ir_variable, ir_assignment, and so on.

That is true, but I think that's okay.  Not saying struct or,
especially, class is "the" C++ idiom.  Just like not using this-> in
member functions is "the" C++ idiom.  I don't really care for either,
but it's what people who write C++ expect.  I recall that we started by
saying struct and class everywhere.  We stopped because people who write
more C++ added code that didn't say it, and the compiler complained
about the inconsistency.

In the end, we picked the idiom more common to that language.
Regardless of individual style choices, an overall strategy of lowering
the per-language barrier of entry for people familiar with that language
is sound.  Certainly none of the unusual Mesa style choices have found
their way into our Python code. :)

> When Connor wrote NIR in C, he chose to make this similar to the
> existing code.  Instead of ir_variable, you have nir_variable - not
> "struct nir_variable".  Yes, it's different than most Mesa C code.
> But it's more similar to existing Mesa compiler code.
> 
> If people are that passionate about typedefs being good-or-evil, then
> we should just make a decision, and write patches to make the style
> what the majority of people working on the project want.
> 
> Personally, I think it would be much more interesting and worthwhile
> to discuss the merits of a pass management infrastructure, and offer
> feedback about Jason's design and implementation...
> 
> Let's try to keep it civil...burning bridges with our fellow hackers
> is another great way to wound a project...
> 
> --Ken
> 




signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/11] nir: Add a pass-running infastructure

2015-10-30 Thread Ian Romanick
On 10/28/2015 06:15 PM, Connor Abbott wrote:
> On Wed, Oct 28, 2015 at 8:04 PM, Ian Romanick  wrote:
>> On 10/28/2015 04:43 PM, Connor Abbott wrote:
>>> On Wed, Oct 28, 2015 at 7:06 PM, Ian Romanick  wrote:
>>>> On 10/28/2015 02:32 PM, Jason Ekstrand wrote:
>>>>> ---
>>>>>  src/glsl/nir/nir.h  | 19 +++
>>>>>  src/glsl/nir/nir_pass.c | 64 
>>>>> -
>>>>>  2 files changed, 82 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>>>>> index e3777f9..069c7c1 100644
>>>>> --- a/src/glsl/nir/nir.h
>>>>> +++ b/src/glsl/nir/nir.h
>>>>> @@ -1582,6 +1582,25 @@ typedef struct nir_shader {
>>>>>foreach_list_typed(nir_function_overload, overload, node, \
>>>>>   &(func)->overload_list)
>>>>>
>>>>> +typedef struct nir_pass {
>>>>
>>>> A couple years ago Kristian, with the support of everyone, waged a war
>>>> on 'typedef struct foo { ... } foo;'  Has this awful idiom really risen
>>>> from the dead?  Can we please send it back to the grave?
>>>
>>> (flamewar incoming!)
>>>
>>> Yes, it has, and no.
>>>
>>> In case you haven't read any NIR code, NIR uses this all over the
>>> place -- all of the core datastructures are typedef'd. The only
>>> argument I've heard against this practice, from Linus, is that it
>>> makes telling if a value is a lightweight thing, like an integer, or
>>> not. But this isn't the kernel; we don't use typedefs for integers at
>>
>> But that it is the way *this* project has done things.  We made a
>> conscious decision to do them that way.  I don't think you guys had any
>> right to unilaterally decide to change that.
> 
> I didn't "unilaterally decide to change it" at all. It was the style I
> was more familiar with, and as I explained, it saved me time and I
> liked it better, so I did it. I didn't even have experience with Mesa

Yes, that's what I said.  You made a break from the project norm without
the input or acceptance of other people on the project.

> then outside GLSL IR, which obviously doesn't have this concern, so I
> didn't consider whether it meshed with the rest of Mesa. There were
> several points before the code was merged where someone could've
> complained loud enough to get it changed, but no one did. Most
> significantly, no one else significantly involved with core NIR has
> felt strongly enough to complain about it since. But now that NIR is a
> fairly large project with more than 30kloc (according to sloccount),
> do you really want to mass-rename everything? Whatever the extra time
> needed to acclimatize yourself to NIR vs. time/frustration typing and
> line-wrapping, the time spent bikeshedding on this and the pain of
> rewriting everything and muddling up the history is going to be much
> larger. But if you're only here to complain, then we're wasting time
> here too.
> 
>>
>> Saying that not having to type 'struct' is some huge time savings is
>> just pure rubbish.  I have a lot of trouble believing that you could
>> even say it out loud with a straight face.  Seriously.
>>
>> What is real is the difficulty of maintaining a project with 238
>> different coding styles.  As soon as look in a different part of the
>> code, you have to relearn things in order to get any work done.  This is
>> already a really, really big problem in Mesa.  We constantly give people
>> review feedback like, "You did this the way other things in that file
>> are done, but that's not how we do it in the rest of the project now.
>> Please change."
>>
>> I'll go out on a limb and guess that the amount of time spent trying to
>> figure out what the coding style is in an particular part of the project
>> is, rejecting patches that didn't properly meet those standards in spite
>> of the author's best effort, and re-spinning patches outweighs the time
>> spent typing 'struct' by a margin of 10:1.
>>
>> People often complain about the way that open-source projects are so nit
>> picky about coding standards.  It's a necessary survival tactic.  Mesa
>> is 22 years old.  It has had dozens of contributors.  Imagine how much
>> worse it would be if every contributor, or even just the major
>> contributors, got to

Re: [Mesa-dev] [PATCH 00/11] nir: Add a pass management framework

2015-10-30 Thread Ian Romanick
On 10/28/2015 10:01 PM, Jason Ekstrand wrote:
> 
> On Oct 28, 2015 9:12 PM, "Kenneth Graunke"  > wrote:
>>
>> On Wednesday, October 28, 2015 02:58:07 PM Kristian Høgsberg wrote:
>> > On Wed, Oct 28, 2015 at 2:34 PM, Jason Ekstrand
> mailto:ja...@jlekstrand.net>> wrote:
>> > > On Wed, Oct 28, 2015 at 2:32 PM, Jason Ekstrand
> mailto:ja...@jlekstrand.net>> wrote:
>> > >> This series adds a nir_pass datastructure and some helpers for
> managing
>> > >> optimization and lowering passes.  I've been meaning to get
> around to this
>> > >> for some time.  There are a couple of primary benifits to this:
>> > >>
>> > >> First, this gives us a central place to put things such as
> validating the
>> > >> shader, printing it if it changes, etc.  Right now, the i965
> backend calls
>> > >> nir_validate_shader after each pass.  We would also like to add
> something
>> > >> like we have in the i965 backend where it can be set to dump the
> IR to a
>> > >> file after every pass that changess it.
>> > >>
>> > >> Mor importantly, though, it moves metadata out of the passes them
> selves
>> > >> and into the runner.  In the process of putting this series
> together, I
>> > >> found at least 3 or 4 optimization passes that don't properly
> invalidate
>> > >> metadata.  By putting a metadata_preserved field in nir_pass and
> handling
>> > >> metadata in the pass runner, we make it much less likely that a
> pass will
>> > >> get this wrong.  LLVM has a similar optimization pass
> architecture for
>> > >> precicely this reason.
>> > >>
>> > >> As a nice little side-benifit, we no longer have to iterate over
> all of the
>> > >> overloads with non-NULL impl pointers in each pass.
>> > >
>> > > Once again, git-send-email failed to send the last patch for whatever
>> > > reason.  The entire series can be found here:
>> > >
>> > > http://cgit.freedesktop.org/~jekstrand/mesa/log/?h=wip/nir-pass
>> >
>> > Nice. Series,
>> >
>> > Reviewed-by: Kristian Høgsberg  >
>>
>> I plan to review this as well, so please hold off on pushing it for a
>> little while.  Thanks!
> 
> By all means, go ahead.  It'd also be nice, while you're at it to weigh
> in on how to handle passing arguments to passes.  There are a number of
> ideas thrown back-and-forth between Connor and myself on how to do it

Is it even necessary to sort that out now?  Are there passes that
haven't been ported to this infrastructure that need any of the extra
features that you and Connor were discussing?  I will give keithp credit
for teaching me not to engineer in features that you don't need yet.
When you do need them, the thing you spent a bunch of time putting in
probably won't be what you need.

> (if you can sort through through the bike-shedding).
> 
> --Jason
> 
> ___
> 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 3/5] glsl: Mark gl_ViewportIndex and gl_Layer varyings as flat.

2015-10-30 Thread Ian Romanick
On 10/26/2015 05:29 PM, Kenneth Graunke wrote:
> On Monday, October 26, 2015 05:02:07 PM Ian Romanick wrote:
>> On 10/26/2015 11:03 AM, Kenneth Graunke wrote:
>>> Integer varyings need to be flat qualified - all others were already.
>>> I think we just missed this.  Presumably some hardware passes this via
>>> sideband and ignores attribute interpolation, so no one has noticed.
>>>
>>> Signed-off-by: Kenneth Graunke 
>>> Cc: Chris Forbes 
>>> ---
>>>  src/glsl/builtin_variables.cpp | 39 ++-
>>>  1 file changed, 26 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
>>> index a6ad105..07aacd4 100644
>>> --- a/src/glsl/builtin_variables.cpp
>>> +++ b/src/glsl/builtin_variables.cpp
>>> @@ -887,16 +887,22 @@ builtin_variable_generator::generate_uniforms()
>>>  void
>>>  builtin_variable_generator::generate_vs_special_vars()
>>>  {
>>> +   ir_variable *var;
>>> +
>>> if (state->is_version(130, 300))
>>>add_system_value(SYSTEM_VALUE_VERTEX_ID, int_t, "gl_VertexID");
>>> if (state->ARB_draw_instanced_enable)
>>>add_system_value(SYSTEM_VALUE_INSTANCE_ID, int_t, 
>>> "gl_InstanceIDARB");
>>> if (state->ARB_draw_instanced_enable || state->is_version(140, 300))
>>>add_system_value(SYSTEM_VALUE_INSTANCE_ID, int_t, "gl_InstanceID");
>>> -   if (state->AMD_vertex_shader_layer_enable)
>>> -  add_output(VARYING_SLOT_LAYER, int_t, "gl_Layer");
>>> -   if (state->AMD_vertex_shader_viewport_index_enable)
>>> -  add_output(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
>>> +   if (state->AMD_vertex_shader_layer_enable) {
>>> +  var = add_output(VARYING_SLOT_LAYER, int_t, "gl_Layer");
>>> +  var->data.interpolation = INTERP_QUALIFIER_FLAT;
>>> +   }
>>> +   if (state->AMD_vertex_shader_viewport_index_enable) {
>>> +  var = add_output(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
>>> +  var->data.interpolation = INTERP_QUALIFIER_FLAT;
>>> +   }
>>> if (compatibility) {
>>>add_input(VERT_ATTRIB_POS, vec4_t, "gl_Vertex");
>>>add_input(VERT_ATTRIB_NORMAL, vec3_t, "gl_Normal");
>>> @@ -954,11 +960,16 @@ 
>>> builtin_variable_generator::generate_tes_special_vars()
>>>  void
>>>  builtin_variable_generator::generate_gs_special_vars()
>>>  {
>>> -   add_output(VARYING_SLOT_LAYER, int_t, "gl_Layer");
>>> -   if (state->is_version(410, 0) || state->ARB_viewport_array_enable)
>>> -  add_output(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
>>> +   ir_variable *var;
>>> +
>>> +   var = add_output(VARYING_SLOT_LAYER, int_t, "gl_Layer");
>>> +   var->data.interpolation = INTERP_QUALIFIER_FLAT;
>>> +   if (state->is_version(410, 0) || state->ARB_viewport_array_enable) {
>>> +  var = add_output(VARYING_SLOT_VIEWPORT, int_t, "gl_ViewportIndex");
>>> +  var->data.interpolation = INTERP_QUALIFIER_FLAT;
>>> +   }
>>> if (state->is_version(400, 0) || state->ARB_gpu_shader5_enable)
>>> -  add_system_value(SYSTEM_VALUE_INVOCATION_ID, int_t, 
>>> "gl_InvocationID");
>>> +  var = add_system_value(SYSTEM_VALUE_INVOCATION_ID, int_t, 
>>> "gl_InvocationID");
>>
>> Shouldn't this set var->data.interpolation?  It looks like you only made
>> half the change.
> 
> I actually meant to leave that alone, as I don't think it makes sense to
> set interpolation modes on system values (they aren't varyings!).  Good
> catch, though, I got a bit overzealous in my "var" adding :)
> 
> I've dropped that one line of diff locally.  Thanks!

Cool.  With that change, the series is

Reviewed-by: Ian Romanick 




signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] i965: Replace default case with list of enum values.

2015-10-30 Thread Ian Romanick
On 10/29/2015 05:52 PM, Matt Turner wrote:
> If we add a new file type, we'd like to get warnings if it's not
> handled.
> 
> Unfortuately, gcc seems to have bugs (see the XXX).

Did you submit a GCC bug?

Assuming there are not warnings added, this patch is

Reviewed-by: Ian Romanick 

> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp  | 16 +---
>  src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp |  7 ---
>  src/mesa/drivers/dri/i965/brw_fs_generator.cpp| 11 ---
>  src/mesa/drivers/dri/i965/brw_ir_fs.h |  7 ---
>  src/mesa/drivers/dri/i965/brw_vec4.cpp| 19 
> +++
>  5 files changed, 32 insertions(+), 28 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index c40ca91..0258633 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -88,8 +88,6 @@ fs_inst::init(enum opcode opcode, uint8_t exec_size, const 
> fs_reg &dst,
> case IMM:
> case UNIFORM:
>unreachable("Invalid destination register file");
> -   default:
> -  unreachable("Invalid register file");
> }
>  
> this->writes_accumulator = false;
> @@ -839,10 +837,10 @@ fs_inst::regs_read(int arg) const
>src[arg].component_size(exec_size),
>REG_SIZE);
> case MRF:
> -  unreachable("MRF registers are not allowed as sources");
> -   default:
> -  unreachable("Invalid register file");
> +  break;
> }
> +   /* XXX: gcc warns if this is in the switch */
> +   unreachable("MRF registers are not allowed as sources");
>  }
>  
>  bool
> @@ -4501,9 +4499,8 @@ fs_visitor::dump_instruction(backend_instruction 
> *be_inst, FILE *file)
>if (inst->dst.fixed_hw_reg.subnr)
>   fprintf(file, "+%d", inst->dst.fixed_hw_reg.subnr);
>break;
> -   default:
> -  fprintf(file, "???");
> -  break;
> +   case IMM:
> +  unreachable("not reached");
> }
> fprintf(file, ":%s, ", brw_reg_type_letters(inst->dst.type));
>  
> @@ -4596,9 +4593,6 @@ fs_visitor::dump_instruction(backend_instruction 
> *be_inst, FILE *file)
>   if (inst->src[i].fixed_hw_reg.abs)
>  fprintf(file, "|");
>   break;
> -  default:
> - fprintf(file, "???");
> - break;
>}
>if (inst->src[i].abs)
>   fprintf(file, "|");
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
> index 97e206d..2620482 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
> @@ -416,9 +416,10 @@ fs_visitor::try_copy_propagate(fs_inst *inst, int arg, 
> acp_entry *entry)
>   inst->src[arg].subreg_offset = offset % 32;
>}
>break;
> -   default:
> -  unreachable("Invalid register file");
> -  break;
> +
> +   case MRF:
> +   case IMM:
> +  unreachable("not reached");
> }
>  
> if (has_source_modifiers) {
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> index 139d1dd..4ef86dd 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> @@ -42,9 +42,13 @@ static uint32_t brw_file_from_reg(fs_reg *reg)
>return BRW_MESSAGE_REGISTER_FILE;
> case IMM:
>return BRW_IMMEDIATE_VALUE;
> -   default:
> -  unreachable("not reached");
> +   case BAD_FILE:
> +   case HW_REG:
> +   case ATTR:
> +   case UNIFORM:
> +  break;
> }
> +   unreachable("not reached"); /* XXX: gcc warns if this is in the switch */
>  }
>  
>  static struct brw_reg
> @@ -116,7 +120,8 @@ brw_reg_from_fs_reg(fs_inst *inst, fs_reg *reg, unsigned 
> gen)
>/* Probably unused. */
>brw_reg = brw_null_reg();
>break;
> -   default:
> +   case ATTR:
> +   case UNIFORM:
>unreachable("not reached");
> }
> if (reg->abs)
> diff --git a/src/mesa/drivers/dri/i965/brw_ir_fs.h 
> b/src/mesa/drivers/dri/i965/brw_ir_fs.h
> index 7726e4b..4417555 100644
> --- a/src/mesa/drivers/dri/i965/brw_ir_fs.h
> +++ b/src/mesa/drivers/dri/i965/brw_ir_fs.h
> @@ -97,7 +97,9 @@ byte_offset(fs_reg reg, unsigned delta)
> case MRF:
>  

Re: [Mesa-dev] [PATCH] i965: Clean up FBH code.

2015-10-30 Thread Ian Romanick
On 10/29/2015 05:52 PM, Matt Turner wrote:
> It did a bunch of unnecessary stuff, emitting an extra MOV included.
> ---
>  src/mesa/drivers/dri/i965/brw_fs_nir.cpp   |  7 +++
>  src/mesa/drivers/dri/i965/brw_vec4_nir.cpp | 18 +-
>  2 files changed, 8 insertions(+), 17 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp 
> b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> index 9c1f95c..b596614 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs_nir.cpp
> @@ -906,12 +906,11 @@ fs_visitor::nir_emit_alu(const fs_builder &bld, 
> nir_alu_instr *instr)
> * from the LSB side. If FBH didn't return an error (0x), then
> * subtract the result from 31 to convert the MSB count into an LSB 
> count.
> */
> -
>bld.CMP(bld.null_reg_d(), result, fs_reg(-1), BRW_CONDITIONAL_NZ);
> -  fs_reg neg_result(result);
> -  neg_result.negate = true;
> -  inst = bld.ADD(result, neg_result, fs_reg(31));
> +
> +  inst = bld.ADD(result, result, fs_reg(31));
>inst->predicate = BRW_PREDICATE_NORMAL;
> +  inst->src[0].negate = true;

This seems like a separate cleanup?  If you choose to split it into a
separate patch, that patch is

Reviewed-by: Ian Romanick 

>break;
> }
>  
> diff --git a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp 
> b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> index 33cc02e..5463f3e 100644
> --- a/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_vec4_nir.cpp
> @@ -1291,26 +1291,18 @@ vec4_visitor::nir_emit_alu(nir_alu_instr *instr)
>  
> case nir_op_ufind_msb:
> case nir_op_ifind_msb: {
> -  src_reg temp = src_reg(this, glsl_type::uint_type);
> -
> -  inst = emit(FBH(dst_reg(temp), op[0]));
> -  inst->dst.writemask = WRITEMASK_XYZW;
> +  emit(FBH(retype(dst, BRW_REGISTER_TYPE_UD), op[0]));
>  
>/* FBH counts from the MSB side, while GLSL's findMSB() wants the count
> * from the LSB side. If FBH didn't return an error (0x), then
> * subtract the result from 31 to convert the MSB count into an LSB 
> count.
> */
> +  src_reg src(dst);
> +  emit(CMP(dst_null_d(), src, src_reg(-1), BRW_CONDITIONAL_NZ));
>  
> -  /* FBH only supports UD type for dst, so use a MOV to convert UD to D. 
> */
> -  temp.swizzle = BRW_SWIZZLE_NOOP;
> -  emit(MOV(dst, temp));
> -
> -  src_reg src_tmp = src_reg(dst);
> -  emit(CMP(dst_null_d(), src_tmp, src_reg(-1), BRW_CONDITIONAL_NZ));
> -
> -  src_tmp.negate = true;
> -  inst = emit(ADD(dst, src_tmp, src_reg(31)));
> +  inst = emit(ADD(dst, src, src_reg(31)));
>inst->predicate = BRW_PREDICATE_NORMAL;
> +  inst->src[0].negate = true;
>break;

Did retype() not exist when support for ir_unop_find_msb was added?  The
original code seems... like a weird way to do it.

Reviewed-by: Ian Romanick 

> }
>  
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] Expose support for OES/EXT_draw_elements_base_vertex to OpenGL ES.

2015-11-02 Thread Ian Romanick
t the other bits of it look like.
> 
>> +exec="dynamic">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +> alias="DrawRangeElementsBaseVertex"
>> +es2="3.0" exec="dynamic">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +> alias="MultiDrawElementsBaseVertex"
>> +exec="dynamic">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +> alias="DrawElementsInstancedBaseVertex"
>> +es2="3.0" exec="dynamic">
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>> +
>>  
>> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
>> index 64972fa..d964f03 100644
>> --- a/src/mesa/main/extensions.c
>> +++ b/src/mesa/main/extensions.c
>> @@ -230,6 +230,7 @@ static const struct extension extension_table[] = {
>> { "GL_EXT_depth_bounds_test",   
>> o(EXT_depth_bounds_test),   GL, 2002 },
>> { "GL_EXT_draw_buffers",o(dummy_true),   
>>   ES2, 2012 },
>> { "GL_EXT_draw_buffers2",   o(EXT_draw_buffers2),
>>GL, 2006 },
>> +   { "GL_EXT_draw_elements_base_vertex",   
>> o(ARB_draw_elements_base_vertex),  ES2, 2014 },
>> { "GL_EXT_draw_instanced",  o(ARB_draw_instanced),   
>>GL, 2006 },
>> { "GL_EXT_draw_range_elements", o(dummy_true),   
>>GLL,1997 },
>> { "GL_EXT_fog_coord",   o(dummy_true),   
>>GLL,1999 },
>> @@ -306,6 +307,7 @@ static const struct extension extension_table[] = {
>> { "GL_OES_depth32", o(dummy_false),  
>>DISABLE,2005 },
>> { "GL_OES_depth_texture",   o(ARB_depth_texture),
>>   ES2, 2006 },
>> { "GL_OES_depth_texture_cube_map",  
>> o(OES_depth_texture_cube_map), ES2, 2012 },
>> +   { "GL_OES_draw_elements_base_vertex",   
>> o(ARB_draw_elements_base_vertex),  ES2, 2014 },
>> { "GL_OES_draw_texture",o(OES_draw_texture), 
>> ES1,   2004 },
>> { "GL_OES_EGL_sync",o(dummy_true),   
>> ES1 | ES2, 2010 },
>> /*  FIXME: Mesa expects GL_OES_EGL_image to be available in OpenGL 
>> contexts. */
>> diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
>> index 34d2c1d..af22f0a 100644
>> --- a/src/mesa/vbo/vbo_exec_array.c
>> +++ b/src/mesa/vbo/vbo_exec_array.c
>> @@ -1807,13 +1807,19 @@ vbo_initialize_exec_dispatch(const struct gl_context 
>> *ctx,
>>SET_EvalMesh2(exec, vbo_exec_EvalMesh2);
>> }
>>
>> -   if (_mesa_is_desktop_gl(ctx)) {
>> +   if (ctx->API != API_OPENGLES2 && 
>> ctx->Extensions.ARB_draw_elements_base_vertex) {
> 
> != OPENGLES :)
> 
>>SET_DrawElementsBaseVertex(exec, vbo_exec_DrawElementsBaseVertex);
>> -  SET_DrawRangeElementsBaseVertex(exec, 
>> vbo_exec_DrawRangeElementsBaseVertex);
>>SET_MultiDrawElementsBaseVertex(exec, 
>> vbo_exec_MultiDrawElementsBaseVertex);
>> +
>> +   if (_mesa_is_desktop_gl(ctx) || _mesa_is_gles3(ctx)) {
> 
> indentation still fail.
> 
> I'll fix these up myself before pushing, I guess... it's getting
> trivial enough. But in the future, please pay attention to such
> details.
> 
> Reviewed-by: Ilia Mirkin 

With Ilia's requested changes,

Reviewed-by: Ian Romanick 

Also... please use the [PATCH v2], etc. notation.  When there were four
patches in my inbox with exactly the same subject, it was confusing
which one to review.

> 
>> + SET_DrawRangeElementsBaseVertex(exec, 
>> vbo_exec_DrawRangeElementsBaseVertex);
>> + SET_DrawElementsInstancedBaseVertex(exec, 
>> vbo_exec_DrawElementsInstancedBaseVertex);
>> +   }
>> +   }
>> +
>> +   if (_mesa_is_desktop_gl(ctx)) {
>>SET_DrawArraysInstancedBaseInstance(exec, 
>> vbo_exec_DrawArraysInstancedBaseInstance);
>>SET_DrawElementsInstancedBaseInstance(exec, 
>> vbo_exec_DrawElementsInstancedBaseInstance);
>> -  SET_DrawElementsInstancedBaseVertex(exec, 
>> vbo_exec_DrawElementsInstancedBaseVertex);
>>SET_DrawElementsInstancedBaseVertexBaseInstance(exec, 
>> vbo_exec_DrawElementsInstancedBaseVertexBaseInstance);
>> }
>>
>> --
>> 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
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 1/3] mesa: restrict ES2 from 32-bit blending, add GL_EXT_float_blend

2015-11-02 Thread Ian Romanick
On 11/02/2015 04:50 PM, Ilia Mirkin wrote:
> GL_EXT_color_buffer_float adds support for float buffers in ES3.0+, but
> explicitly disallows 32-bit blending. However this restriction was never
> implemented in mesa.
> 
> Add the restriction, and also allow a driver to expose
> GL_EXT_float_blend which re-enables the functionality.
> 
> Signed-off-by: Ilia Mirkin 
> ---
> 
> Untested... looking for confirmation that this is the right thing to
> do. Will write a piglit if it is.

Some flavor of this probably is the right thing to do.  The question is
whether or not any hardware supported by Mesa can do
GL_EXT_color_buffer_float but not GL_EXT_float_blend... if everyone can
do both or neither, this patch series could be even simpler. :)

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 02/11] nir: Add a pass-running infastructure

2015-11-02 Thread Ian Romanick
On 10/28/2015 04:43 PM, Connor Abbott wrote:
> On Wed, Oct 28, 2015 at 7:06 PM, Ian Romanick  wrote:
>> On 10/28/2015 02:32 PM, Jason Ekstrand wrote:
>>> ---
>>>  src/glsl/nir/nir.h  | 19 +++
>>>  src/glsl/nir/nir_pass.c | 64 
>>> -
>>>  2 files changed, 82 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>>> index e3777f9..069c7c1 100644
>>> --- a/src/glsl/nir/nir.h
>>> +++ b/src/glsl/nir/nir.h
>>> @@ -1582,6 +1582,25 @@ typedef struct nir_shader {
>>>foreach_list_typed(nir_function_overload, overload, node, \
>>>   &(func)->overload_list)
>>>
>>> +typedef struct nir_pass {
>>
>> A couple years ago Kristian, with the support of everyone, waged a war
>> on 'typedef struct foo { ... } foo;'  Has this awful idiom really risen
>> from the dead?  Can we please send it back to the grave?
> 
> (flamewar incoming!)
> 
> Yes, it has, and no.
> 
> In case you haven't read any NIR code, NIR uses this all over the
> place -- all of the core datastructures are typedef'd. The only
> argument I've heard against this practice, from Linus, is that it
> makes telling if a value is a lightweight thing, like an integer, or
> not. But this isn't the kernel; we don't use typedefs for integers at
> all, and the only place where we use nir_* and it *isn't* a structure
> is the enums. Pretty much the entire time, it's fairly obvious these
> are enums, either because they have "type" in the name (e.g.
> nir_instr_type), indicating C-style subclassing, or they're some kind
> of operation code (nir_op and nir_intrinsic_op). This is fairly
> subjective, but if you're not able to look at a nir_* type and know
> whether it's a lightweight thing or not, then you probably don't know
> the code well enough to understand it anyways. The amount of typing
> they save is just way too large compared to the potential
> (theoretical) inconvenience of not knowing how the type is declared.
> But if this bikeshed seriously disturbs you, then I'd much rather
> change the enums to not be typedef'd, since you have to type out their
> types a lot less often.

As I've been going through Meta today, I was reminded the other (much
more important IMO) reason for not doing the typedef business.  I
believe this is part of the reason we did the giant s/GLcontext/struct
gl_context/g a couple years ago.

Meta has a few structures, like meta_clear_state, that nothing outside
meta ever needs to know anything about.  However, instances of these
structures need to be tracked in the gl_context so that they can be used
the next time we enter meta, freed when the context is destroyed, etc.

You really don't want to put the definition of meta_clear_state in
mtypes.h both for encapsulation and avoiding rebuilding the world
whenever you change meta_clear_state.  You also don't want to stick a
'void *meta_clear;' in gl_context.  That sounds awful.

C language lets you use 'struct meta_clear_state *meta_clear;' without
knowing what a 'struct meta_clear_state' is.  If you want to use a
'meta_clear_state_t *' or similar, you at have to sprinkle the typedefs
in multiple places.  Then you have the same information in two places to
maintain.  That also sounds awful.

Or you mix uses of 'meta_clear_state_t *' and 'struct meta_clear_state
*'.  That also sounds awful.

Or you decide that "because reasons" some structures get a typedef and
some don't. That also sounds awful.

Once you eliminate the awful, whatever remains, no matter how much extra
typing, must be the truth.  Or something along those lines.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] glsl: Relax requirement on Centroid matching between shader stages

2015-11-06 Thread Ian Romanick
On 11/04/2015 01:04 AM, Marta Lofstedt wrote:
> From: Marta Lofstedt 
> 
> In OpenGL 4.4, section 4.5, the requirement for interpolation
> qualifiers to match over shader stages was removed.
> In OpenGL ES 3.1, section 9.2.1 there is a table showing that
> centroid does not have to match between shader stages.

I haven't checked this yet... does either spec provide guidance as to
what happens when only the vertex shader stage specifies centroid?  Is
the interpolation centroid or not?

...and are we doing the right thing? :)

> Also see bug 92743 for more discussions.

Please note this, after your s-o-b, as

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92743

I think this is also a candidate for stable:

Cc: mesa-sta...@lists.freedesktop.org

> Signed-off-by: Marta Lofstedt 
> ---
>  src/glsl/link_varyings.cpp | 14 --
>  1 file changed, 14 deletions(-)
> 
> diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
> index 7e77a67..d0edc71 100644
> --- a/src/glsl/link_varyings.cpp
> +++ b/src/glsl/link_varyings.cpp
> @@ -96,20 +96,6 @@ cross_validate_types_and_qualifiers(struct 
> gl_shader_program *prog,
>}
> }
>  
> -   /* Check that all of the qualifiers match between stages.
> -*/
> -   if (input->data.centroid != output->data.centroid) {
> -  linker_error(prog,
> -   "%s shader output `%s' %s centroid qualifier, "
> -   "but %s shader input %s centroid qualifier\n",
> -   _mesa_shader_stage_to_string(producer_stage),
> -   output->name,
> -   (output->data.centroid) ? "has" : "lacks",
> -   _mesa_shader_stage_to_string(consumer_stage),
> -   (input->data.centroid) ? "has" : "lacks");
> -  return;
> -   }
> -
> if (input->data.sample != output->data.sample) {
>linker_error(prog,
> "%s shader output `%s' %s sample qualifier, "
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 1/8] glapi: Add EXT_blend_func_extended XML definitions

2015-11-06 Thread Ian Romanick
On 11/05/2015 06:47 PM, Ryan Houdek wrote:
> ---
>  src/mapi/glapi/gen/EXT_gpu_shader4.xml  |  3 ++-
>  src/mapi/glapi/gen/es_EXT.xml   | 26 ++
>  src/mesa/main/tests/dispatch_sanity.cpp |  8 
>  3 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mapi/glapi/gen/EXT_gpu_shader4.xml 
> b/src/mapi/glapi/gen/EXT_gpu_shader4.xml
> index b1f7eae..b4120b9 100644
> --- a/src/mapi/glapi/gen/EXT_gpu_shader4.xml
> +++ b/src/mapi/glapi/gen/EXT_gpu_shader4.xml
> @@ -232,7 +232,8 @@
>  
>  
>  
> -
> + + es2="3.0">

Is this right?  It looks like patch 8 enables the extension in OpenGL ES
2.0 contexts.

There are more occurrences of this below...

>  
>  
>  
> diff --git a/src/mapi/glapi/gen/es_EXT.xml b/src/mapi/glapi/gen/es_EXT.xml
> index 9a777a2..577d825 100644
> --- a/src/mapi/glapi/gen/es_EXT.xml
> +++ b/src/mapi/glapi/gen/es_EXT.xml
> @@ -914,4 +914,30 @@
>  
>  
>  
> +
> +
> + alias="BindFragDataLocationIndexed"
> +es2="3.0">
> +
> +
> +
> +
> +
> +
> + +es2="3.0">
> +
> +
> +
> +
> +
> + alias="GetProgramResourceLocationIndex"
> +   es2="3.1">
> +
> +
> +
> +
> +
> +
> +
>  
> diff --git a/src/mesa/main/tests/dispatch_sanity.cpp 
> b/src/mesa/main/tests/dispatch_sanity.cpp
> index abe0f43..97f81f9 100644
> --- a/src/mesa/main/tests/dispatch_sanity.cpp
> +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> @@ -2421,6 +2421,11 @@ const struct function gles3_functions_possible[] = {
> { "glProgramUniform4uiEXT", 30, -1 },
> { "glProgramUniform4uivEXT", 30, -1 },
>  
> +   /* GL_EXT_blend_func_extended */
> +   { "glBindFragDataLocationIndexedEXT", 30, -1 },
> +   { "glGetFragDataIndexEXT", 30, -1 },
> +   { "glBindFragDataLocationEXT", 30, -1 },
> +
> { NULL, 0, -1 }
>  };
>  
> @@ -2509,5 +2514,8 @@ const struct function gles31_functions_possible[] = {
> /* GL_EXT_buffer_storage */
> { "glBufferStorageEXT", 31, -1 },
>  
> +   /* GL_EXT_blend_func_extended */
> +   { "glGetProgramResourceLocationIndexEXT", 31, -1 },
> +
> { NULL, 0, -1 },
>   };
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 6/8] mesa: Enable usage of blend_func_extended blend factors

2015-11-06 Thread Ian Romanick
On 11/05/2015 06:47 PM, Ryan Houdek wrote:
> ---
>  src/mesa/main/blend.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/main/blend.c b/src/mesa/main/blend.c
> index 20aa498..185e30e 100644
> --- a/src/mesa/main/blend.c
> +++ b/src/mesa/main/blend.c
> @@ -67,7 +67,7 @@ legal_src_factor(const struct gl_context *ctx, GLenum 
> factor)
> case GL_SRC1_ALPHA:
> case GL_ONE_MINUS_SRC1_COLOR:
> case GL_ONE_MINUS_SRC1_ALPHA:
> -  return _mesa_is_desktop_gl(ctx)
> +  return ctx->API != API_OPENGLES
>   && ctx->Extensions.ARB_blend_func_extended;
> default:
>return GL_FALSE;
> @@ -107,7 +107,7 @@ legal_dst_factor(const struct gl_context *ctx, GLenum 
> factor)
> case GL_SRC1_ALPHA:
> case GL_ONE_MINUS_SRC1_COLOR:
> case GL_ONE_MINUS_SRC1_ALPHA:
> -  return _mesa_is_desktop_gl(ctx)
> +  return ctx->API != API_OPENGLES
>   && ctx->Extensions.ARB_blend_func_extended;
> default:
>return GL_FALSE;
> 

This extension also enables GL_SRC_ALPHA_SATURATE as a destination
weight.  Previously this was only available in OpenGL ES 3.0+ or desktop
OpenGL.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 7/8] mesa: Allow MAX_DUAL_SOURCE_DRAW_BUFFERS to be available to ES

2015-11-06 Thread Ian Romanick
This patch is

Reviewed-by: Ian Romanick 

On 11/05/2015 06:47 PM, Ryan Houdek wrote:
> ---
>  src/mesa/main/get_hash_params.py | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/main/get_hash_params.py 
> b/src/mesa/main/get_hash_params.py
> index fbc7b8f..9b22b91 100644
> --- a/src/mesa/main/get_hash_params.py
> +++ b/src/mesa/main/get_hash_params.py
> @@ -330,6 +330,9 @@ descriptor=[
>  
>  # GL_KHR_context_flush_control
>[ "CONTEXT_RELEASE_BEHAVIOR", "CONTEXT_ENUM(Const.ContextReleaseBehavior), 
> NO_EXTRA" ],
> +
> +# blend_func_extended
> +  [ "MAX_DUAL_SOURCE_DRAW_BUFFERS", 
> "CONTEXT_INT(Const.MaxDualSourceDrawBuffers), extra_ARB_blend_func_extended" 
> ],
>  ]},
>  
>  # GLES3 is not a typo.
> @@ -801,7 +804,6 @@ descriptor=[
>  # GL_ARB_robustness
>[ "RESET_NOTIFICATION_STRATEGY_ARB", "CONTEXT_ENUM(Const.ResetStrategy), 
> NO_EXTRA" ],
>  
> -  [ "MAX_DUAL_SOURCE_DRAW_BUFFERS", 
> "CONTEXT_INT(Const.MaxDualSourceDrawBuffers), extra_ARB_blend_func_extended" 
> ],
>  
>  # GL_ARB_uniform_buffer_object
>[ "MAX_GEOMETRY_UNIFORM_BLOCKS", 
> "CONTEXT_INT(Const.Program[MESA_SHADER_GEOMETRY].MaxUniformBlocks), 
> extra_ARB_uniform_buffer_object_and_geometry_shader" ],
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 4/8] glsl: Add GL_EXT_blend_func_extended preprocessor define

2015-11-06 Thread Ian Romanick
This patch is

Reviewed-by: Ian Romanick 

On 11/05/2015 06:47 PM, Ryan Houdek wrote:
> ---
>  src/glsl/glcpp/glcpp-parse.y | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/glsl/glcpp/glcpp-parse.y b/src/glsl/glcpp/glcpp-parse.y
> index 4acccf7..10bf83f 100644
> --- a/src/glsl/glcpp/glcpp-parse.y
> +++ b/src/glsl/glcpp/glcpp-parse.y
> @@ -2384,6 +2384,8 @@ _glcpp_parser_handle_version_declaration(glcpp_parser_t 
> *parser, intmax_t versio
>   add_builtin_define(parser, "GL_OES_standard_derivatives", 
> 1);
>if (extensions->ARB_texture_multisample)
>   add_builtin_define(parser, 
> "GL_OES_texture_storage_multisample_2d_array", 1);
> +  if (extensions->ARB_blend_func_extended)
> + add_builtin_define(parser, "GL_EXT_blend_func_extended", 1);
>  }
>   } else {
>  add_builtin_define(parser, "GL_ARB_draw_buffers", 1);
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 5/8] glsl: Add a parse check to check for the index layout qualifier

2015-11-06 Thread Ian Romanick
On 11/05/2015 06:47 PM, Ryan Houdek wrote:
> This can only be used if EXT_blend_func_extended is enabled
> ---
>  src/glsl/glsl_parser.yy | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
> index 4636435..40e60e5 100644
> --- a/src/glsl/glsl_parser.yy
> +++ b/src/glsl/glsl_parser.yy
> @@ -1463,6 +1463,11 @@ layout_qualifier_id:
>}
>  
>if (match_layout_qualifier("index", $1, state) == 0) {
> + if (state->es_shader && !state->EXT_blend_func_extended_enable) {
> +_mesa_glsl_error(& @3, state, "index layout qualifier requires 
> EXT_blend_func_extended");
> +YYERROR;
> + }
> +

It seems like more changes should be necessary in this area.  Did we not
previously generate errors in an ES 3.0 shader that used the index
layout qualifier?

>   $$.flags.q.explicit_index = 1;
>  
>   if ($3 >= 0) {
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 3/8] glsl: Add support for the new builtins that EXT_blend_func_extended provides.

2015-11-06 Thread Ian Romanick
On 11/05/2015 06:47 PM, Ryan Houdek wrote:
> gl_MaxDualSourceDrawBuffersEXT - Maximum DS draw buffers supported
> 
> Only for ESSL 1.0 it provides two builtins since you can't have user-defined
> color output variables
> gl_SecondaryFragColorEXT and gl_SecondaryFragDataEXT[MaxDSDrawBuffers]
> ---
>  src/glsl/ast_to_hir.cpp| 16 +++
>  src/glsl/builtin_variables.cpp | 62 
> ++
>  2 files changed, 78 insertions(+)
> 
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 0306530..9ac7d80 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -6973,6 +6973,8 @@ detect_conflicting_assignments(struct 
> _mesa_glsl_parse_state *state,
>  {
> bool gl_FragColor_assigned = false;
> bool gl_FragData_assigned = false;
> +   bool gl_FragSecondaryColor_assigned = false;
> +   bool gl_FragSecondaryData_assigned = false;
> bool user_defined_fs_output_assigned = false;
> ir_variable *user_defined_fs_output = NULL;
>  
> @@ -6990,6 +6992,10 @@ detect_conflicting_assignments(struct 
> _mesa_glsl_parse_state *state,
>   gl_FragColor_assigned = true;
>else if (strcmp(var->name, "gl_FragData") == 0)
>   gl_FragData_assigned = true;
> + else if (strcmp(var->name, "gl_SecondaryFragColorEXT") == 0)
> + gl_FragSecondaryColor_assigned = true;
> + else if (strcmp(var->name, "gl_SecondaryFragDataEXT") == 0)
> + gl_FragSecondaryData_assigned = true;
>else if (!is_gl_identifier(var->name)) {
>   if (state->stage == MESA_SHADER_FRAGMENT &&
>   var->data.mode == ir_var_shader_out) {
> @@ -7021,11 +7027,21 @@ detect_conflicting_assignments(struct 
> _mesa_glsl_parse_state *state,
>_mesa_glsl_error(&loc, state, "fragment shader writes to both "
> "`gl_FragColor' and `%s'",
> user_defined_fs_output->name);
> +   } else if (gl_FragSecondaryColor_assigned && 
> gl_FragSecondaryData_assigned) {
> +  _mesa_glsl_error(&loc, state, "fragment shader writes to both "
> +   "`gl_FragSecondaryColorEXT' and"
> +   " `gl_FragSecondaryDataEXT'");
> } else if (gl_FragData_assigned && user_defined_fs_output_assigned) {
>_mesa_glsl_error(&loc, state, "fragment shader writes to both "
> "`gl_FragData' and `%s'",
> user_defined_fs_output->name);
> }
> +
> +   if ((gl_FragSecondaryColor_assigned || gl_FragSecondaryData_assigned) &&
> +   !state->EXT_blend_func_extended_enable) {
> +  _mesa_glsl_error(&loc, state,
> +   "Dual source blending requires 
> EXT_blend_func_extended");
> +   }

The spec doesn't seem to provide any guidance about a shader like:

#extension GL_EXT_blend_func_extended: require
void main() {
gl_FragData[0] = vec4(0);
glSecondaryFragColorEXT = vec4(0);
}

What does NVIDIA's implementation do?  We should mimic that behavior,
and have a comment here justifying it.  Something like

/* The EXT_blend_func_extended spec doesn't say what to do if
 * gl_FragData and glSecondaryFragColorEXT (or gl_FragColor and
 * glSecondaryFragDataEXT) are written together.  NVIDIA's XXX.YY
 * driver [say what it does], so we mimic that.
 */

We should also have piglit tests that exercise it.

>  }
>  
>  
> diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_variables.cpp
> index c30fb92..4933c8a 100644
> --- a/src/glsl/builtin_variables.cpp
> +++ b/src/glsl/builtin_variables.cpp
> @@ -376,6 +376,11 @@ private:
>return add_variable(name, type, ir_var_shader_out, slot);
> }
>  
> +   ir_variable *add_index_output(int slot, int index, const glsl_type *type, 
> const char *name)
> +   {
> +  return add_index_variable(name, type, ir_var_shader_out, slot, index);
> +   }
> +
> ir_variable *add_system_value(int slot, const glsl_type *type,
>   const char *name)
> {
> @@ -384,6 +389,8 @@ private:
>  
> ir_variable *add_variable(const char *name, const glsl_type *type,
>   enum ir_variable_mode mode, int slot);
> +   ir_variable *add_index_variable(const char *name, const glsl_type *type,
> + enum ir_variable_mode mode, int slot, int 
> index);
> ir_variable *add_uniform(const glsl_type *type, const char *name);
> ir_variable *add_const(const char *name, int value);
> ir_variable *add_const_ivec3(const char *name, int x, int y, int z);
> @@ -429,6 +436,46 @@ builtin_variable_generator::builtin_variable_generator(
>  {
>  }
>  
> +ir_variable *
> +builtin_variable_generator::add_index_variable(const char *name,
> + const glsl_type *type,
> + enum ir_variable_mode mode, int 
> slot, int index)
> +{
> +   ir_variable *var = new(symtab) ir_variable(type, name

Re: [Mesa-dev] FOSDEM16: Graphics DevRoom: call for speakers.

2015-11-09 Thread Ian Romanick
On 10/31/2015 09:43 AM, Luc Verhaegen wrote:
> Hi,
> 
> At FOSDEM on sunday 31st of january 2016, there will be another graphics 
> DevRoom. URL: https://fosdem.org/2016/
> 
> At first, I wanted to skip another year (like in 2011), as speaker 
> turn-out was disgracefully low last year. But when i heard from some 
> usual speaker suspects earlier this month (the first time anyone asked 
> me about a FOSDEM16 devroom btw), followed by the fact that the devroom 
> request deadline was sheduled a month later than the last few years, i 
> did end up filing, but this time for a single day only. Claiming two 
> days would simply not have been fair towards all the other projects 
> that usually get rejected (FOSDEM typically rejects half the requests, 
> leading to only about 25 devrooms in parallel). Anyway...
> 
> The focus of this DevRoom is of course the same as the last few years, 
> namely:
> * Graphics drivers: from display to media to 3d drivers, both in kernel 
>   or userspace. Be it part of DRM, KMS, (direct)FB, V4L, Xorg, Mesa...
> * Input drivers: kernel and userspace.
> * Windowing systems: X, Wayland, Mir, directFB, ...
> * Even colour management, low level toolkit stuff, and other areas which 
>   i might have overlooked above are accepted.
> 
> Slots are 50 minutes long, and scheduled hourly. This partly to avoid 
> confusion and people running all over the place all the time. As a 
> speaker, you do not have to fill your whole hour, gaps are never wasted 
> time.
> 
> Slots will be handed out on a first come, first serve basis. The best 
> slots will go to those who apply the earliest. The amount of slots is 
> currently not known yet, but there are only 8 slots available, so act 
> quickly.
> 
> Talk Submission:
> 
> 
> Like the last few years, the pentabarf system will be used for talk 

Properly pronounced like "pent up barf."  It seems like they should have
a "Replace pentabarf" BoF to just fix it. :)

> submission. It is not perfect from a devroom organizer and talk 
> submitters usability point-of-view, but the new interface is not fully 
> implemented yet, and the fosdem organizers have reverted to the old one 
> for this year. It is however workable and it ended up working out 
> pretty well these last few years.
> 
> https://penta.fosdem.org/submission/FOSDEM16

After you submit, is it supposed to give any sort of feedback that your
submission was received?

> Remember that FOSDEM is not like XDC, it's not some 50 odd people 
> meeting with a sliding schedule which only gets filled out on the last 
> day. Upwards of 8000 people are visiting this event, and most of them 
> get a printed booklet or use the schedule on the FOSDEM website or an 
> app for their phone to figure out what to watch or participate in next. 
> So please put some effort in your talk submission and details.
> 
> Since this an open source community event, please refrain from turning 
> in a talk that is a pure corporate or product commercial. Also, if you 
> are unsure on whether you can come or not (this is FOSDEM, why are you 
> not there anyway?), please wait with submitting your talk. Submitting a 
> talk and then not turning up because you could not be bothered is a 
> sure-fire way to get larted and then to never be allowed to talk again.
> 
> Also, all talks will be recorded, and will be made available as CC-BY 
> after a bit of time. Since we have only a single day devroom, we 
> probably will not end up being streamed live.
> 
> As for deadlines, the fosdem organizers are doing their booklet 
> differently again, and they need to have the schedule finished by the 
> 18th of december. Given that there are only 8 slots, i trust that this 
> will not be an issue this year.
> 
> Don't count on this deadline: first come first serve! There are perhaps 
> only 8 slots. And the worst slots will be assigned to those who come 
> last. Do you really want to talk on sunday at 9:00 when people are still 
> in zombie mode after 2 nights at the delirium bar, if they are here at all?
> 
> Use your account from last year, so you can try to recycle some of your 
> data from last year. If you have forgotten your password, then you can 
> reset it here: https://penta.fosdem.org/user/forgot_password
> 
> Necessary information:
> --
> 
> Below is a list of what i need to see filled in when you apply for a 
> devroom before i consider it a valid submission. Remember: first come, 
> first serve. The best slots are for the earliest submissions and there 
> are only 8 slots.
> 
> On your personal page:
> * General:
>   * First and last name
>   * Nickname
>   * Image
> * Contact:
>   * email
>   * mobile number (this is a very hard requirement as there will be no 
>other reliable form of emergency communication on the day)
> * Description:
>   * Abstract
>   * Description
> 
> Create an event:
> * On the General page:
>   * Event title
>   * Event subtitle.
>   * Track: Graphics Devroom
>   * 

Re: [Mesa-dev] [PATCH 0/3] Fix racy full-vector writes for v[i].x

2015-11-09 Thread Ian Romanick
On 11/04/2015 03:55 PM, Jason Ekstrand wrote:
> Here's some shader-db  numbers:
> 
> total instructions in shared programs: 6236146 -> 6255385 (0.31%)
> instructions in affected programs: 203629 -> 222868 (9.45%)
> helped:118
> HURT:  1989
> GAINED:18
> LOST:  0

I recall from off-line discussions that many (almost all?) of the really
hurt shaders were vertex shaders that we no longer getting benefit from
the vectorizer pass.  How hard would be it be to modify the lowering
pass to have an option to only lower SSBOs and other memories that
actually need the early lowering?  We could then lower those early, do
the vectorizing, the lower the others late (as we do now).

I know we really want a NIR vectorizer, but I think that's a bigger
project than we want to tackle right now.  If we think this stop-gap
could be implemented quickly enough, maybe we should do that for now
instead.

> We should probably look into that.
> 
> 
> On Wed, Nov 4, 2015 at 3:33 PM, Kristian Høgsberg Kristensen
>  wrote:
>> This little series fixes a problem where we lower
>>
>>   v[i] = s
>>
>> to
>>
>>   v = vector_insert(v, s, i)
>>
>> turning a component write into a full vector write. This used to be
>> ok, since none of this was visible to other threads.  Now with SSBOs
>> (and compute shader SLM and tesselation outputs) this rewrite is racy
>> and we have to handle this different in case the vector is in globally
>> visible storage.
>>
>> Kristian Høgsberg Kristensen (3):
>>   glsl: Drop exec_list argument to lower_ubo_reference
>>   glsl: Lower UBO and SSBO access in glsl linker
>>   glsl: Use array deref for access to vector components
>>
>>  src/glsl/Makefile.sources  |   1 +
>>  src/glsl/ast_array_index.cpp   |   5 +-
>>  src/glsl/ast_function.cpp  |  24 ++-
>>  src/glsl/ast_to_hir.cpp|  43 
>>  src/glsl/ir_optimization.h |   3 +-
>>  src/glsl/ir_validate.cpp   |   7 +-
>>  src/glsl/linker.cpp|  10 +++
>>  src/glsl/lower_ubo_reference.cpp   |  18 -
>>  src/glsl/lower_vector_derefs.cpp   | 104 
>> +
>>  src/glsl/opt_dead_code_local.cpp   |   2 +
>>  src/mesa/drivers/dri/i965/brw_link.cpp |   2 -
>>  src/mesa/drivers/dri/i965/brw_shader.cpp   |   2 +
>>  src/mesa/main/mtypes.h |   2 +
>>  src/mesa/state_tracker/st_extensions.c |   1 +
>>  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |   1 -
>>  15 files changed, 151 insertions(+), 74 deletions(-)
>>  create mode 100644 src/glsl/lower_vector_derefs.cpp
>>
>> --
>> 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

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Potential spec change request for EXT_buffer_storage

2015-11-09 Thread Ian Romanick
On 11/04/2015 03:26 PM, Ryan Houdek wrote:
> I'm hoping to potentially convince about lowering the minimum
> requirement of EXT_buffer_storage from ES 3.1 to ES 3.0.
> The only thing that causes it to require ES 3.1 is glMemoryBarrier,
> which shouldn't really be a hard requirement since the extension can be
> used without it.
> This is also a similar situation with ARB_buffer_storage which Mesa
> currently exposes to all GL versions even though it should require GL 4.2.
> I have my attempt at a change to the spec as follows. I've never tried
> changing a spec page before so it's a bit new to me.

I think all of the drivers that support ARB_buffer_storage also support
ARB_texture_barrier.  At the very least I think you'd need to require
GL_MAP_CHOERENT_BIT with GL_MAP_PERSISTENT_BIT.

Also... Mesa is really close to getting OpenGL ES 3.1.  Are there any
drivers with which you want to use this extension that won't have GLES 3.1?

> diff --git a/EXT_buffer_storage.txt b/EXT_buffer_storage.txt
> index 03fcd6e..ea16fae 100644
> --- a/EXT_buffer_storage.txt
> +++ b/EXT_buffer_storage.txt
> @@ -30,8 +30,8 @@ Status
>  
>  Version
>  
> -Last Modified Date:   May 1, 2015
> -Author Revision:  3
> +Last Modified Date:   November 4, 2015
> +Author Revision:  4
>  
>  Number
>  
> @@ -39,10 +39,12 @@ Number
>  
>  Dependencies
>  
> -OpenGL ES 3.1 is required.
> -
>  This extension is written against the OpenGL ES 3.1 (June 4, 2014)
> -Specification.
> +Specification, but can apply to prior specifications
> +
> +Requires OpenGL ES 3.0

I think I'd just change the above to replace the current "required" line
with

   OpenGL ES 3.0 is required.

and leave the rest alone.

I think the rest of the edits look good.

> +
> +This extension interacts with OpenGL ES 3.1.
>  
>  The definition of this extension is affected by the presence of
>  GL_EXT_direct_state_access.
> @@ -350,6 +352,50 @@ Additions to Chapter 7 of the OpenGL ES 3.1
> Specification,
>by shaders prior to the barrier. Note that this may cause
> additional
>synchronization operations.
>  
> +Dependencies on OpenGL ES 3.1
> +
> +If OpenGL ES 3.1 is not supported apply the following modifications
> to the
> +OpenGL ES 3.0.4 specification:
> +
> +Append to the first paragraph of Section 2.10, "Buffer Objects", p. 32:
> +
> +Under certain circumstances, the data store of a buffer object may
> +be shared between the client and server and accessed simultaneously
> +by both.
> +
> +Modify Section 2.10.1 (Creating and Binding Buffer Objects)
> +
> +Append to Table 2.7, "Buffer object parameters and their values", p.34:
> +
> +  
>  +--+-+-+--+
> +|  | | Initial | Legal
>|
> +| Name | Type| Value   | Values
>   |
> +  
>  +--+-+-+--+
> +| BUFFER_IMMUTABLE_STORAGE_EXT | boolean | FALSE   | TRUE,
> FALSE  |
> +| BUFFER_STORAGE_FLAGS_EXT | int | 0   | See
> section 6.2  |
> +  
>  +--+-+-+--+
> +
> +Edits to section 6.2 "Creating and Modifying Buffer Object Data
> Stores" in
> +ES 3.1 become edits to section 2.10.2 "Creating Buffer Object Data
> Stores"
> +in ES 3.0.4.
> +
> +Edits to section 6.3, "Mapping and Unmapping Buffer Data" in ES 3.1
> become
> +edits in section 2.10.3 "Mapping and Unmapping Buffer Data" in ES 3.0.4
> +
> +Edits to p.56, FlushMappedBufferRange, in ES 3.1 become edits in p.40
> +in ES 3.0.4
> +
> +Edits to section 6.3.2, "Effects of Mapping Buffers on Other GL
> Commands"
> +in ES 3.1 become edits in p.41 in ES 3.0.4
> +
> +Edits in section 6.7, "Buffer Object State" in ES 3.1 become edits in
> +section 2.10.8 "Buffer Object State" in ES 3.0.4
> +
> +Edits in section 20.4, "Buffer Object State", p.355 become edits in
> +section 6.4, "Buffer Object State", p.247 in ES 3.0.4
> +
> +If OpenGL ES 3.1 is not supported, ignore all references to
> MemoryBarrier
> +
>  New State
>  
>  Append to Table 20.4, "Buffer Object State", p.355:
> @@ -521,3 +567,5 @@ Revision History
>to make CPU writes visible to the GPU in
>this case without an explicit flush (Bug
>13578, sync w/ ARB_buffer_storage v.25).
> +
> +404/11/15  rhoudekLower minimum dependency to ES 3.0
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 00/23] Don't pollute the buffer object namespace in meta

2015-11-09 Thread Ian Romanick
In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions.  The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.  After calling Gen,
making up your own names is not guaranteed to work.

Meta uses Gen all over the place, and this can conflict with names the
application may try to use.  It's not hard to find OpenGL demos that do
things like:

   glBindTexture(GL_TEXTURE_2D, 1);
   ...

   glBindTexture(GL_TEXTURE_2D, 2);
   ...

I suspect there are even demos in the mesa-demos repository that do
this.

This is, IMO, a case of premature optimization in OpenGL 1.0.  In OpenGL
1.0, almost all implementations were indirect-renderers.  If names had
to be allocated from the server, that meant you had to (queue dramatic
music) have an extra round-trip to the server to get some names.  In
addition, allowing user-defined names meant that you could name the
display list (the only pseudo-object in OpenGL 1.0) that drew the letter
A, (int)'A'.  It was common to see text rendering loops like:

while (*str) {
glCallList((GLuint)*str);
str++;
}

On the systems of 1992, that may have mattered.  It's certainly not an
optimization that has mattered on any system that I've programmed OpenGL
on, and the damage that it does inside drivers is... this is a 23-patch
series to fix a bug that should never have existed!

Here's the problem scenario:

 - Application calls a meta function that generates a name.  The first
   Gen will return 1.

 - Application decides to use the same name for an object of the same
   type without calling Gen.  Many demo programs use names 1, 2, 3,
   etc. without calling Gen.

 - Application calls the meta function again, and the meta function
   replaces the data.  The application's data is lost, and the app
   fails.  Have fun debugging that.

This patch series is longer than is strictly necessary.  I wanted to
make each individual step easy to review.  It's a good thing too.  There
were a couple places where I made typos or cut-and-paste errors that
were much easier to bisect.

This patch series also *only* fixes the problem for buffer objects.
Texture, sampler, framebuffer, renderbuffer, and assembly program
objects still need to be fixed.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 04/23] mesa: Refactor enable_vertex_array_attrib to make _mesa_enable_vertex_array_attrib

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Pulls the parts of enable_vertex_array_attrib that aren't just parameter
validation out into a function that can be called from other parts of
Mesa (e.g., meta).

_mesa_enable_vertex_array_attrib can also be used to enable
fixed-function arrays.

Signed-off-by: Ian Romanick 
---
 src/mesa/main/varray.c | 26 +-
 src/mesa/main/varray.h |  5 +
 2 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index e9f78e9..8836c18 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -770,6 +770,22 @@ _mesa_VertexAttribLPointer(GLuint index, GLint size, 
GLenum type,
 }
 
 
+void
+_mesa_enable_vertex_array_attrib(struct gl_context *ctx,
+ struct gl_vertex_array_object *vao,
+ unsigned attrib)
+{
+   assert(attrib < ARRAY_SIZE(vao->VertexAttrib));
+
+   if (!vao->VertexAttrib[attrib].Enabled) {
+  /* was disabled, now being enabled */
+  FLUSH_VERTICES(ctx, _NEW_ARRAY);
+  vao->VertexAttrib[attrib].Enabled = GL_TRUE;
+  vao->_Enabled |= VERT_BIT(attrib);
+  vao->NewArrays |= VERT_BIT(attrib);
+   }
+}
+
 static void
 enable_vertex_array_attrib(struct gl_context *ctx,
struct gl_vertex_array_object *vao,
@@ -781,15 +797,7 @@ enable_vertex_array_attrib(struct gl_context *ctx,
   return;
}
 
-   assert(VERT_ATTRIB_GENERIC(index) < ARRAY_SIZE(vao->VertexAttrib));
-
-   if (!vao->VertexAttrib[VERT_ATTRIB_GENERIC(index)].Enabled) {
-  /* was disabled, now being enabled */
-  FLUSH_VERTICES(ctx, _NEW_ARRAY);
-  vao->VertexAttrib[VERT_ATTRIB_GENERIC(index)].Enabled = GL_TRUE;
-  vao->_Enabled |= VERT_BIT_GENERIC(index);
-  vao->NewArrays |= VERT_BIT_GENERIC(index);
-   }
+   _mesa_enable_vertex_array_attrib(ctx, vao, VERT_ATTRIB_GENERIC(index));
 }
 
 
diff --git a/src/mesa/main/varray.h b/src/mesa/main/varray.h
index 744b336..a766afa 100644
--- a/src/mesa/main/varray.h
+++ b/src/mesa/main/varray.h
@@ -99,6 +99,11 @@ _mesa_update_array_format(struct gl_context *ctx,
   GLuint relativeOffset, bool flush_vertices);
 
 extern void
+_mesa_enable_vertex_array_attrib(struct gl_context *ctx,
+ struct gl_vertex_array_object *vao,
+ unsigned attrib);
+
+extern void
 _mesa_bind_vertex_buffer(struct gl_context *ctx,
  struct gl_vertex_array_object *vao,
  GLuint index,
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 13/23] meta: Track VBO using gl_buffer_object instead of GL API object handle

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta.c| 69 +++
 src/mesa/drivers/common/meta.h| 19 ---
 src/mesa/drivers/common/meta_blit.c   | 11 ++--
 src/mesa/drivers/common/meta_generate_mipmap.c| 12 ++--
 src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c |  9 +--
 5 files changed, 72 insertions(+), 48 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 8b9bccc..27b860f 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -316,7 +316,7 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
  *
  * \param VAO   Storage for vertex array object handle.  If 0, a new VAO
  *  will be created.
- * \param VBO   Storage for vertex buffer object handle.  If 0, a new VBO
+ * \param buf_obj   Storage for vertex buffer object pointer.  If \c NULL, a 
new VBO
  *  will be created.  The new VBO will have storage for 4
  *  \c vertex structures.
  * \param use_generic_attributes  Should generic attributes 0 and 1 be used,
@@ -334,24 +334,37 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
  */
 void
 _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
-GLuint *VAO, GLuint *VBO,
+GLuint *VAO, struct gl_buffer_object **buf_obj,
 bool use_generic_attributes,
 unsigned vertex_size, unsigned texcoord_size,
 unsigned color_size)
 {
+   GLuint VBO;
+
if (*VAO == 0) {
-  assert(*VBO == 0);
+  assert(*buf_obj == NULL);
 
   /* create vertex array object */
   _mesa_GenVertexArrays(1, VAO);
   _mesa_BindVertexArray(*VAO);
 
   /* create vertex array buffer */
-  _mesa_GenBuffers(1, VBO);
-  _mesa_BindBuffer(GL_ARRAY_BUFFER, *VBO);
+  _mesa_GenBuffers(1, &VBO);
+  _mesa_BindBuffer(GL_ARRAY_BUFFER, VBO);
+  *buf_obj = _mesa_lookup_bufferobj(ctx, VBO);
+
+  /* _mesa_lookup_bufferobj only returns NULL if name is 0.  If the object
+   * does not yet exist (i.e., hasn't been bound) it will return a dummy
+   * object that you can't do anything with.
+   */
+  assert(*buf_obj != NULL && (*buf_obj)->Name == VBO);
+  assert(*buf_obj == ctx->Array.ArrayBufferObj);
+
   _mesa_BufferData(GL_ARRAY_BUFFER, 4 * sizeof(struct vertex), NULL,
GL_DYNAMIC_DRAW);
 
+  assert((*buf_obj)->Size == 4 * sizeof(struct vertex));
+
   /* setup vertex arrays */
   if (use_generic_attributes) {
  assert(color_size == 0);
@@ -1490,10 +1503,11 @@ _mesa_meta_setup_drawpix_texture(struct gl_context *ctx,
 
 void
 _mesa_meta_setup_ff_tnl_for_blit(struct gl_context *ctx,
- GLuint *VAO, GLuint *VBO,
+ GLuint *VAO, struct gl_buffer_object 
**buf_obj,
  unsigned texcoord_size)
 {
-   _mesa_meta_setup_vertex_objects(ctx, VAO, VBO, false, 2, texcoord_size, 0);
+   _mesa_meta_setup_vertex_objects(ctx, VAO, buf_obj, false, 2, texcoord_size,
+   0);
 
/* setup projection matrix */
_mesa_MatrixMode(GL_PROJECTION);
@@ -1538,7 +1552,7 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
GLuint vs, fs;
bool has_integer_textures;
 
-   _mesa_meta_setup_vertex_objects(ctx, &clear->VAO, &clear->VBO, true,
+   _mesa_meta_setup_vertex_objects(ctx, &clear->VAO, &clear->buf_obj, true,
3, 0, 0);
 
if (clear->ShaderProg != 0)
@@ -1626,8 +1640,8 @@ meta_glsl_clear_cleanup(struct clear_state *clear)
   return;
_mesa_DeleteVertexArrays(1, &clear->VAO);
clear->VAO = 0;
-   _mesa_DeleteBuffers(1, &clear->VBO);
-   clear->VBO = 0;
+   _mesa_DeleteBuffers(1, &clear->buf_obj->Name);
+   clear->buf_obj = NULL;
_mesa_DeleteProgram(clear->ShaderProg);
clear->ShaderProg = 0;
 
@@ -1735,7 +1749,7 @@ meta_clear(struct gl_context *ctx, GLbitfield buffers, 
bool glsl)
   y1 = ((float) fb->_Ymax / fb->Height) * 2.0f - 1.0f;
   z = -invert_z(ctx->Depth.Clear);
} else {
-  _mesa_meta_setup_vertex_objects(ctx, &clear->VAO, &clear->VBO, false,
+  _mesa_meta_setup_vertex_objects(ctx, &clear->VAO, &clear->buf_obj, false,
   3, 0, 4);
 
   x0 = (float) fb->_Xmin;
@@ -1819,7 +1833,8 @@ meta_clear(struct gl_context *ctx, GLbitfield buffers, 
bool glsl)
}
 
/* upload new vertex data */
-   _mesa_NamedBufferData(clear->VBO, sizeof(verts), verts, GL_DYNAMIC_DRAW);
+   _mesa_buffer_data(ctx, clear->buf_obj, GL_NONE, sizeof(verts), verts,
+ 

[Mesa-dev] [PATCH 20/23] meta: Don't pollute the buffer object namespace in _mesa_meta_DrawTex

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

tl;dr: For many types of GL object, we can *NEVER* use the Gen function.

In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions.  The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.

Here's the problem scenario:

 - Application calls a meta function that generates a name.  The first
   Gen will probably return 1.

 - Application decides to use the same name for an object of the same
   type without calling Gen.  Many demo programs use names 1, 2, 3,
   etc. without calling Gen.

 - Application calls the meta function again, and the meta function
   replaces the data.  The application's data is lost, and the app
   fails.  Have fun debugging that.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
---
 src/mesa/drivers/common/meta.c | 51 +++---
 src/mesa/drivers/common/meta.h |  5 ++-
 src/mesa/drivers/common/meta_blit.c|  5 +--
 src/mesa/drivers/common/meta_generate_mipmap.c |  6 +--
 4 files changed, 29 insertions(+), 38 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 57993cf..b06f683 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -95,9 +95,12 @@ static struct blit_shader *
 choose_blit_shader(GLenum target, struct blit_shader_table *table);
 
 static void cleanup_temp_texture(struct temp_texture *tex);
-static void meta_glsl_clear_cleanup(struct clear_state *clear);
-static void meta_decompress_cleanup(struct decompress_state *decompress);
-static void meta_drawpix_cleanup(struct drawpix_state *drawpix);
+static void meta_glsl_clear_cleanup(struct gl_context *ctx,
+struct clear_state *clear);
+static void meta_decompress_cleanup(struct gl_context *ctx,
+struct decompress_state *decompress);
+static void meta_drawpix_cleanup(struct gl_context *ctx,
+ struct drawpix_state *drawpix);
 
 void
 _mesa_meta_bind_fbo_image(GLenum fboTarget, GLenum attachment,
@@ -435,12 +438,12 @@ _mesa_meta_free(struct gl_context *ctx)
 {
GET_CURRENT_CONTEXT(old_context);
_mesa_make_current(ctx, NULL, NULL);
-   _mesa_meta_glsl_blit_cleanup(&ctx->Meta->Blit);
-   meta_glsl_clear_cleanup(&ctx->Meta->Clear);
-   _mesa_meta_glsl_generate_mipmap_cleanup(&ctx->Meta->Mipmap);
+   _mesa_meta_glsl_blit_cleanup(ctx, &ctx->Meta->Blit);
+   meta_glsl_clear_cleanup(ctx, &ctx->Meta->Clear);
+   _mesa_meta_glsl_generate_mipmap_cleanup(ctx, &ctx->Meta->Mipmap);
cleanup_temp_texture(&ctx->Meta->TempTex);
-   meta_decompress_cleanup(&ctx->Meta->Decompress);
-   meta_drawpix_cleanup(&ctx->Meta->DrawPix);
+   meta_decompress_cleanup(ctx, &ctx->Meta->Decompress);
+   meta_drawpix_cleanup(ctx, &ctx->Meta->DrawPix);
if (old_context)
   _mesa_make_current(old_context, old_context->WinSysDrawBuffer, 
old_context->WinSysReadBuffer);
else
@@ -1638,14 +1641,13 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
 }
 
 static void
-meta_glsl_clear_cleanup(struct clear_state *clear)
+meta_glsl_clear_cleanup(struct gl_context *ctx, struct clear_state *clear)
 {
if (clear->VAO == 0)
   return;
_mesa_DeleteVertexArrays(1, &clear->VAO);
clear->VAO = 0;
-   _mesa_DeleteBuffers(1, &clear->buf_obj->Name);
-   clear->buf_obj = NULL;
+   _mesa_reference_buffer_object(ctx, &clear->buf_obj, NULL);
_mesa_DeleteProgram(clear->ShaderProg);
clear->ShaderProg = 0;
 
@@ -1939,14 +1941,13 @@ _mesa_meta_CopyPixels(struct gl_context *ctx, GLint 
srcX, GLint srcY,
 }
 
 static void
-meta_drawpix_cleanup(struct drawpix_state *drawpix)
+meta_drawpix_cleanup(struct gl_context *ctx, struct drawpix_state *drawpix)
 {
if (drawpix->VAO != 0) {
   _mesa_DeleteVertexArrays(1, &drawpix->VAO);
   drawpix->VAO = 0;
 
-  _mesa_DeleteBuffers(1, &drawpix->buf_obj->Name);
-  drawpix->buf_obj = NULL;
+  _mesa_reference_buffer_object(ctx, &drawpix->buf_obj, NULL);
}
 
if (drawpix->StencilFP != 0) {
@@ -2975,14 +2976,15 @@ meta_decompress_fbo_cleanup(struct decompress_fbo_state 
*decompress_fbo)
 }
 
 static void
-meta_decompress_cleanup(struct decompress_state *decompress)
+meta_decompress_cleanup(struct gl_context *ctx,
+struct decompress_state *decompress)
 {
meta_decompress_fbo_cleanup(&decompress->byteFBO);
meta_decompress_fbo_cleanup(&decompress->floatFBO);
 
if (decompress->VAO != 0) {
   _mesa_DeleteVe

[Mesa-dev] [PATCH 15/23] meta: Use internal functions for buffer object and VAO access

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta.c | 76 --
 1 file changed, 43 insertions(+), 33 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 8cf0bf9..3507927 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -342,12 +342,16 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
GLuint VBO;
 
if (*VAO == 0) {
+  struct gl_vertex_array_object *array_obj;
   assert(*buf_obj == NULL);
 
   /* create vertex array object */
   _mesa_GenVertexArrays(1, VAO);
   _mesa_BindVertexArray(*VAO);
 
+  array_obj = _mesa_lookup_vao(ctx, *VAO);
+  assert(array_obj != NULL);
+
   /* create vertex array buffer */
   _mesa_CreateBuffers(1, &VBO);
   *buf_obj = _mesa_lookup_bufferobj(ctx, VBO);
@@ -360,8 +364,8 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
   assert(*buf_obj != NULL && (*buf_obj)->Name == VBO);
   assert(*buf_obj != ctx->Array.ArrayBufferObj);
 
-  _mesa_NamedBufferData(VBO, 4 * sizeof(struct vertex), NULL,
-GL_DYNAMIC_DRAW);
+  _mesa_buffer_data(ctx, *buf_obj, GL_NONE, 4 * sizeof(struct vertex), 
NULL,
+GL_DYNAMIC_DRAW, __func__);
 
   assert((*buf_obj)->Size == 4 * sizeof(struct vertex));
 
@@ -369,45 +373,51 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
   if (use_generic_attributes) {
  assert(color_size == 0);
 
- _mesa_VertexArrayAttribFormat(*VAO, 0, vertex_size, GL_FLOAT,
-   GL_FALSE, OFFSET(x));
- _mesa_VertexArrayVertexBuffer(*VAO, 0, VBO, 0,
-   sizeof(struct vertex));
- _mesa_EnableVertexAttribArray(0);
-
+ _mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_GENERIC(0),
+   vertex_size, GL_FLOAT, GL_RGBA, GL_FALSE,
+   GL_FALSE, GL_FALSE,
+   offsetof(struct vertex, x), true);
+ _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_GENERIC(0),
+  *buf_obj, 0, sizeof(struct vertex));
+ _mesa_enable_vertex_array_attrib(ctx, array_obj,
+  VERT_ATTRIB_GENERIC(0));
  if (texcoord_size > 0) {
-_mesa_VertexArrayAttribFormat(*VAO, 1, texcoord_size, GL_FLOAT,
-  GL_FALSE, OFFSET(tex));
-_mesa_VertexArrayVertexBuffer(*VAO, 1, VBO, 0,
-  sizeof(struct vertex));
-_mesa_EnableVertexAttribArray(1);
+_mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_GENERIC(1),
+  texcoord_size, GL_FLOAT, GL_RGBA,
+  GL_FALSE, GL_FALSE, GL_FALSE,
+  offsetof(struct vertex, tex), false);
+_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_GENERIC(1),
+ *buf_obj, 0, sizeof(struct vertex));
+_mesa_enable_vertex_array_attrib(ctx, array_obj,
+ VERT_ATTRIB_GENERIC(1));
  }
   } else {
- _mesa_BindBuffer(GL_ARRAY_BUFFER, VBO);
- _mesa_VertexPointer(vertex_size, GL_FLOAT, sizeof(struct vertex),
- OFFSET(x));
- _mesa_EnableClientState(GL_VERTEX_ARRAY);
+ _mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_POS,
+   vertex_size, GL_FLOAT, GL_RGBA, GL_FALSE,
+   GL_FALSE, GL_FALSE,
+   offsetof(struct vertex, x), true);
+ _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_POS,
+  *buf_obj, 0, sizeof(struct vertex));
+ _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_POS);
 
  if (texcoord_size > 0) {
-_mesa_TexCoordPointer(texcoord_size, GL_FLOAT,
-  sizeof(struct vertex), OFFSET(tex));
-_mesa_EnableClientState(GL_TEXTURE_COORD_ARRAY);
+_mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_TEX(0),
+  vertex_size, GL_FLOAT, GL_RGBA, GL_FALSE,
+  GL_FALSE, GL_FALSE,
+  offsetof(struct vertex, tex), false);
+_mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_TEX(0),
+ *buf_obj, 0, sizeof(struct vertex));
+_mesa_enable_vertex_array_attrib(ctx, array_obj, 
VERT_ATTRIB_TEX(0));
  }
 
  if (color_size > 0) {
-_mesa_ColorPointer(color_size, GL_FLOAT,
- 

[Mesa-dev] [PATCH 22/23] meta: Don't save or restore the VBO binding

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Nothing left in meta does anything with the VBO binding, so we don't
need to save or restore it.  The VAO binding is still modified.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta.c | 6 --
 src/mesa/drivers/common/meta.h | 1 -
 2 files changed, 7 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index b06f683..b774d3c 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -735,8 +735,6 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
   /* save vertex array object state */
   _mesa_reference_vao(ctx, &save->VAO,
ctx->Array.VAO);
-  _mesa_reference_buffer_object(ctx, &save->ArrayBufferObj,
-ctx->Array.ArrayBufferObj);
   /* set some default state? */
}
 
@@ -1146,10 +1144,6 @@ _mesa_meta_end(struct gl_context *ctx)
}
 
if (state & MESA_META_VERTEX) {
-  /* restore vertex buffer object */
-  _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, save->ArrayBufferObj->Name);
-  _mesa_reference_buffer_object(ctx, &save->ArrayBufferObj, NULL);
-
   /* restore vertex array object */
   _mesa_BindVertexArray(save->VAO->Name);
   _mesa_reference_vao(ctx, &save->VAO, NULL);
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index 503e743..8121ed4 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -155,7 +155,6 @@ struct save_state
 
/** MESA_META_VERTEX */
struct gl_vertex_array_object *VAO;
-   struct gl_buffer_object *ArrayBufferObj;
 
/** MESA_META_VIEWPORT */
GLfloat ViewportX, ViewportY, ViewportW, ViewportH;
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 16/23] meta: Don't pollute the buffer object namespace in _mesa_meta_setup_vertex_objects

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

tl;dr: For many types of GL object, we can *NEVER* use the Gen function.

In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions.  The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.

Here's the problem scenario:

 - Application calls a meta function that generates a name.  The first
   Gen will probably return 1.

 - Application decides to use the same name for an object of the same
   type without calling Gen.  Many demo programs use names 1, 2, 3,
   etc. without calling Gen.

 - Application calls the meta function again, and the meta function
   replaces the data.  The application's data is lost, and the app
   fails.  Have fun debugging that.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
---
 src/mesa/drivers/common/meta.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 3507927..8249eda 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -339,8 +339,6 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
 unsigned vertex_size, unsigned texcoord_size,
 unsigned color_size)
 {
-   GLuint VBO;
-
if (*VAO == 0) {
   struct gl_vertex_array_object *array_obj;
   assert(*buf_obj == NULL);
@@ -353,22 +351,13 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
   assert(array_obj != NULL);
 
   /* create vertex array buffer */
-  _mesa_CreateBuffers(1, &VBO);
-  *buf_obj = _mesa_lookup_bufferobj(ctx, VBO);
-
-  /* _mesa_lookup_bufferobj only returns NULL if name is 0.  If the object
-   * does not yet exist (i.e., hasn't been bound) it will return a dummy
-   * object that you can't do anything with.  _mesa_CreateBuffers also
-   * makes the object exist.
-   */
-  assert(*buf_obj != NULL && (*buf_obj)->Name == VBO);
-  assert(*buf_obj != ctx->Array.ArrayBufferObj);
+  *buf_obj = ctx->Driver.NewBufferObject(ctx, 0xDEADBEEF);
+  if (*buf_obj == NULL)
+ return;
 
   _mesa_buffer_data(ctx, *buf_obj, GL_NONE, 4 * sizeof(struct vertex), 
NULL,
 GL_DYNAMIC_DRAW, __func__);
 
-  assert((*buf_obj)->Size == 4 * sizeof(struct vertex));
-
   /* setup vertex arrays */
   if (use_generic_attributes) {
  assert(color_size == 0);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 01/23] i965: Silence unused parameter warnings in get_buffer_rect

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

brw_meta_fast_clear.c: In function 'get_buffer_rect':
brw_meta_fast_clear.c:318:37: warning: unused parameter 'brw' 
[-Wunused-parameter]
 get_buffer_rect(struct brw_context *brw, struct gl_framebuffer *fb,
 ^
brw_meta_fast_clear.c:319:44: warning: unused parameter 'irb' 
[-Wunused-parameter]
 struct intel_renderbuffer *irb, struct rect *rect)
    ^

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c 
b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
index 69fe7b4..12e7c32 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
@@ -314,8 +314,7 @@ get_fast_clear_rect(struct gl_framebuffer *fb,
 }
 
 static void
-get_buffer_rect(struct brw_context *brw, struct gl_framebuffer *fb,
-struct intel_renderbuffer *irb, struct rect *rect)
+get_buffer_rect(const struct gl_framebuffer *fb, struct rect *rect)
 {
rect->x0 = fb->_Xmin;
rect->x1 = fb->_Xmax;
@@ -526,12 +525,12 @@ brw_meta_fast_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
 
   case REP_CLEAR:
  rep_clear_buffers |= 1 << index;
- get_buffer_rect(brw, fb, irb, &clear_rect);
+ get_buffer_rect(fb, &clear_rect);
  break;
 
   case PLAIN_CLEAR:
  plain_clear_buffers |= 1 << index;
- get_buffer_rect(brw, fb, irb, &clear_rect);
+ get_buffer_rect(fb, &clear_rect);
  continue;
   }
}
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 21/23] meta/TexSubImage: Don't pollute the buffer object namespace

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

tl;dr: For many types of GL object, we can *NEVER* use the Gen function.

In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions.  The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.

Here's the problem scenario:

 - Application calls a meta function that generates a name.  The first
   Gen will probably return 1.

 - Application decides to use the same name for an object of the same
   type without calling Gen.  Many demo programs use names 1, 2, 3,
   etc. without calling Gen.

 - Application calls the meta function again, and the meta function
   replaces the data.  The application's data is lost, and the app
   fails.  Have fun debugging that.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
---
 src/mesa/drivers/common/meta_tex_subimage.c | 42 -
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/src/mesa/drivers/common/meta_tex_subimage.c 
b/src/mesa/drivers/common/meta_tex_subimage.c
index b0ac677..4adaad7 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -69,7 +69,7 @@ create_texture_for_pbo(struct gl_context *ctx,
int dims, int width, int height, int depth,
GLenum format, GLenum type, const void *pixels,
const struct gl_pixelstore_attrib *packing,
-   GLuint *tmp_pbo, GLuint *tmp_tex)
+   struct gl_buffer_object **tmp_pbo, GLuint *tmp_tex)
 {
uint32_t pbo_format;
GLenum internal_format;
@@ -101,7 +101,7 @@ create_texture_for_pbo(struct gl_context *ctx,
row_stride = _mesa_image_row_stride(packing, width, format, type);
 
if (_mesa_is_bufferobj(packing->BufferObj)) {
-  *tmp_pbo = 0;
+  *tmp_pbo = NULL;
   buffer_obj = packing->BufferObj;
   first_pixel += (intptr_t)pixels;
} else {
@@ -109,23 +109,27 @@ create_texture_for_pbo(struct gl_context *ctx,
 
   assert(create_pbo);
 
-  _mesa_CreateBuffers(1, tmp_pbo);
+  *tmp_pbo = ctx->Driver.NewBufferObject(ctx, 0xDEADBEEF);
+  if (*tmp_pbo == NULL)
+ return NULL;
 
   /* In case of GL_PIXEL_PACK_BUFFER, pass null pointer for the pixel
-   * data to avoid unnecessary data copying in _mesa_NamedBufferData().
+   * data to avoid unnecessary data copying in _mesa_buffer_data.
*/
   if (is_pixel_pack)
- _mesa_NamedBufferData(*tmp_pbo,
-   last_pixel - first_pixel,
-   NULL,
-   GL_STREAM_READ);
+ _mesa_buffer_data(ctx, *tmp_pbo, GL_NONE,
+   last_pixel - first_pixel,
+   NULL,
+   GL_STREAM_READ,
+   __func__);
   else
- _mesa_NamedBufferData(*tmp_pbo,
-   last_pixel - first_pixel,
-   (char *)pixels + first_pixel,
-   GL_STREAM_DRAW);
+ _mesa_buffer_data(ctx, *tmp_pbo, GL_NONE,
+   last_pixel - first_pixel,
+   (char *)pixels + first_pixel,
+   GL_STREAM_DRAW,
+   __func__);
 
-  buffer_obj = _mesa_lookup_bufferobj(ctx, *tmp_pbo);
+  buffer_obj = *tmp_pbo;
   first_pixel = 0;
}
 
@@ -157,7 +161,7 @@ create_texture_for_pbo(struct gl_context *ctx,
  row_stride,
  read_only)) {
   _mesa_DeleteTextures(1, tmp_tex);
-  _mesa_DeleteBuffers(1, tmp_pbo);
+  _mesa_reference_buffer_object(ctx, tmp_pbo, NULL);
   return NULL;
}
 
@@ -173,7 +177,8 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint 
dims,
bool allocate_storage, bool create_pbo,
const struct gl_pixelstore_attrib *packing)
 {
-   GLuint pbo = 0, pbo_tex = 0, fbos[2] = { 0, 0 };
+   struct gl_buffer_object *pbo = NULL;
+   GLuint pbo_tex = 0, fbos[2] = { 0, 0 };
int image_height;
struct gl_texture_image *pbo_tex_image;
GLenum status;
@@ -276,7 +281,7 @@ _mesa_meta_pbo_TexSubImage(struct gl_context *ctx, GLuint 
dims,
 fail:
_mesa_DeleteFramebuffers(2, fbos);
_mesa_DeleteTextures(1, &pbo_tex);
-   _mesa_DeleteBuffers(1, &pbo);
+   _mesa_reference_buffer_object(ctx, &pbo, NULL);
 
_mesa_meta_end(ctx);
 
@@ -291,7 +296,8 @@ _mesa_meta_pbo_GetTexSubImage(struct gl_context *ctx, 
GLuint dims,
   GLenum format, GLenum type, const void *pixels,
   

[Mesa-dev] [PATCH 07/23] i965: Use internal functions for buffer object access

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Instead of going through the GL API implementation functions, use the
lower-level functions.  This means that we have to keep track of a
pointer to the gl_buffer_object and the gl_vertex_array_object.

This has two advantages.  First, it avoids a bunch of CPU overhead in
looking up objects and validing API parameters.  Second, and much more
importantly, it will allow us to stop calling _mesa_GenBuffers /
_mesa_CreateBuffers and pollute the buffer namespace (next patch).

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c 
b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
index 7350f6c..7817f0b 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
@@ -54,6 +54,8 @@
 #include "brw_blorp.h"
 
 struct brw_fast_clear_state {
+   struct gl_buffer_object *buf_obj;
+   struct gl_vertex_array_object *array_obj;
GLuint vao;
GLuint vbo;
GLuint shader_prog;
@@ -64,6 +66,7 @@ static bool
 brw_fast_clear_init(struct brw_context *brw)
 {
struct brw_fast_clear_state *clear;
+   struct gl_context *ctx = &brw->ctx;
 
if (brw->fast_clear_state) {
   clear = brw->fast_clear_state;
@@ -79,10 +82,19 @@ brw_fast_clear_init(struct brw_context *brw)
_mesa_GenVertexArrays(1, &clear->vao);
_mesa_BindVertexArray(clear->vao);
_mesa_CreateBuffers(1, &clear->vbo);
-   _mesa_VertexArrayAttribFormat(clear->vao, 0, 2, GL_FLOAT, GL_FALSE, 0);
-   _mesa_VertexArrayVertexBuffer(clear->vao, 0, clear->vbo, 0,
- sizeof(float) * 2);
-   _mesa_EnableVertexAttribArray(0);
+
+   clear->buf_obj = _mesa_lookup_bufferobj(ctx, clear->vbo);
+   assert(clear->buf_obj != NULL);
+   clear->array_obj = _mesa_lookup_vao(ctx, clear->vao);
+   assert(clear->array_obj != NULL);
+
+   _mesa_update_array_format(ctx, clear->array_obj, VERT_ATTRIB_GENERIC(0),
+ 2, GL_FLOAT, GL_RGBA, GL_FALSE, GL_FALSE, 
GL_FALSE,
+ 0, true);
+   _mesa_bind_vertex_buffer(ctx, clear->array_obj, VERT_ATTRIB_GENERIC(0),
+clear->buf_obj, 0, sizeof(float) * 2);
+   _mesa_enable_vertex_array_attrib(ctx, clear->array_obj,
+VERT_ATTRIB_GENERIC(0));
 
return true;
 }
@@ -181,8 +193,8 @@ brw_draw_rectlist(struct brw_context *brw, struct rect 
*rect, int num_instances)
verts[5] = rect->y0;
 
/* upload new vertex data */
-   _mesa_NamedBufferData(clear->vbo, sizeof(verts), verts,
- GL_DYNAMIC_DRAW);
+   _mesa_buffer_data(ctx, clear->buf_obj, GL_NONE, sizeof(verts), verts,
+ GL_DYNAMIC_DRAW, __func__);
 
if (ctx->NewState)
   _mesa_update_state(ctx);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 14/23] meta: Use DSA functions for VBOs in _mesa_meta_setup_vertex_objects

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

The fixed-function attribute paths don't get the DSA treatment because
there are no DSA entry-points for fixed-function attributes.  These
could have been added, but this is a temporary patch intended to make
later patches easier to review.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta.c | 43 +++---
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 27b860f..8cf0bf9 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -349,19 +349,19 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
   _mesa_BindVertexArray(*VAO);
 
   /* create vertex array buffer */
-  _mesa_GenBuffers(1, &VBO);
-  _mesa_BindBuffer(GL_ARRAY_BUFFER, VBO);
+  _mesa_CreateBuffers(1, &VBO);
   *buf_obj = _mesa_lookup_bufferobj(ctx, VBO);
 
   /* _mesa_lookup_bufferobj only returns NULL if name is 0.  If the object
* does not yet exist (i.e., hasn't been bound) it will return a dummy
-   * object that you can't do anything with.
+   * object that you can't do anything with.  _mesa_CreateBuffers also
+   * makes the object exist.
*/
   assert(*buf_obj != NULL && (*buf_obj)->Name == VBO);
-  assert(*buf_obj == ctx->Array.ArrayBufferObj);
+  assert(*buf_obj != ctx->Array.ArrayBufferObj);
 
-  _mesa_BufferData(GL_ARRAY_BUFFER, 4 * sizeof(struct vertex), NULL,
-   GL_DYNAMIC_DRAW);
+  _mesa_NamedBufferData(VBO, 4 * sizeof(struct vertex), NULL,
+GL_DYNAMIC_DRAW);
 
   assert((*buf_obj)->Size == 4 * sizeof(struct vertex));
 
@@ -369,16 +369,21 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
   if (use_generic_attributes) {
  assert(color_size == 0);
 
- _mesa_VertexAttribPointer(0, vertex_size, GL_FLOAT, GL_FALSE,
-   sizeof(struct vertex), OFFSET(x));
+ _mesa_VertexArrayAttribFormat(*VAO, 0, vertex_size, GL_FLOAT,
+   GL_FALSE, OFFSET(x));
+ _mesa_VertexArrayVertexBuffer(*VAO, 0, VBO, 0,
+   sizeof(struct vertex));
  _mesa_EnableVertexAttribArray(0);
 
  if (texcoord_size > 0) {
-_mesa_VertexAttribPointer(1, texcoord_size, GL_FLOAT, GL_FALSE,
-  sizeof(struct vertex), OFFSET(tex));
+_mesa_VertexArrayAttribFormat(*VAO, 1, texcoord_size, GL_FLOAT,
+  GL_FALSE, OFFSET(tex));
+_mesa_VertexArrayVertexBuffer(*VAO, 1, VBO, 0,
+  sizeof(struct vertex));
 _mesa_EnableVertexAttribArray(1);
  }
   } else {
+ _mesa_BindBuffer(GL_ARRAY_BUFFER, VBO);
  _mesa_VertexPointer(vertex_size, GL_FLOAT, sizeof(struct vertex),
  OFFSET(x));
  _mesa_EnableClientState(GL_VERTEX_ARRAY);
@@ -394,16 +399,16 @@ _mesa_meta_setup_vertex_objects(struct gl_context *ctx,
sizeof(struct vertex), OFFSET(r));
 _mesa_EnableClientState(GL_COLOR_ARRAY);
  }
-  }
 
-  /* Restore the old VBO.  This is done because we don't want the new VBO
-   * to be bound on exit.  It would be nicer to use DSA type functions,
-   * but there are no DSA functions to bind a VBO to a VAO for
-   * fixed-function vertex attributes.
-   */
-  {
- struct save_state *save = &ctx->Meta->Save[ctx->Meta->SaveStackDepth 
- 1];
- _mesa_BindBuffer(GL_ARRAY_BUFFER, save->ArrayBufferObj->Name);
+ /* Restore the old VBO.  This is done because we don't want the new 
VBO
+  * to be bound on exit.  It would be nicer to use DSA type functions,
+  * but there are no DSA functions to bind a VBO to a VAO for
+  * fixed-function vertex attributes.
+  */
+ {
+struct save_state *save = 
&ctx->Meta->Save[ctx->Meta->SaveStackDepth - 1];
+_mesa_BindBuffer(GL_ARRAY_BUFFER, save->ArrayBufferObj->Name);
+ }
   }
} else {
   _mesa_BindVertexArray(*VAO);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 18/23] meta: Track VBO using gl_buffer_object instead of GL API object handle in _mesa_meta_DrawTex

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta.c | 23 ++-
 src/mesa/drivers/common/meta.h |  2 +-
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 1bf3d52..6927ae9 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3299,20 +3299,32 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
if (drawtex->VAO == 0) {
   /* one-time setup */
   GLint active_texture;
+  GLuint VBO;
 
   /* create vertex array object */
   _mesa_GenVertexArrays(1, &drawtex->VAO);
   _mesa_BindVertexArray(drawtex->VAO);
 
   /* create vertex array buffer */
-  _mesa_CreateBuffers(1, &drawtex->VBO);
-  _mesa_NamedBufferData(drawtex->VBO, sizeof(verts),
-NULL, GL_DYNAMIC_DRAW_ARB);
+  _mesa_CreateBuffers(1, &VBO);
+  drawtex->buf_obj = _mesa_lookup_bufferobj(ctx, VBO);
+
+  /* _mesa_lookup_bufferobj only returns NULL if name is 0.  If the object
+   * does not yet exist (i.e., hasn't been bound) it will return a dummy
+   * object that you can't do anything with.
+   */
+  assert(drawtex->buf_obj != NULL && (drawtex->buf_obj)->Name == VBO);
+  assert(drawtex->buf_obj == ctx->Array.ArrayBufferObj);
+
+  _mesa_buffer_data(ctx, drawtex->buf_obj, GL_NONE, sizeof(verts), verts,
+GL_DYNAMIC_DRAW, __func__);
+
+  assert(drawtex->buf_obj->Size == sizeof(verts));
 
   /* client active texture is not part of the array object */
   active_texture = ctx->Array.ActiveTexture;
 
-  _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, drawtex->VBO);
+  _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, VBO);
 
   /* setup vertex arrays */
   _mesa_VertexPointer(3, GL_FLOAT, sizeof(struct vertex), OFFSET(x));
@@ -3392,7 +3404,8 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
  verts[3].st[i][1] = t1;
   }
 
-  _mesa_NamedBufferSubData(drawtex->VBO, 0, sizeof(verts), verts);
+  _mesa_buffer_sub_data(ctx, drawtex->buf_obj, 0, sizeof(verts), verts,
+__func__);
}
 
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index 9ce5d12..4d25957 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -405,7 +405,7 @@ struct decompress_state
 struct drawtex_state
 {
GLuint VAO;
-   GLuint VBO;
+   struct gl_buffer_object *buf_obj;
 };
 
 #define MAX_META_OPS_DEPTH  8
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 08/23] i965: Don't pollute the buffer object namespace in brw_meta_fast_clear

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

tl;dr: For many types of GL object, we can *NEVER* use the Gen function.

In OpenGL ES (all versions!) and OpenGL compatibility profile,
applications don't have to call Gen functions.  The GL spec is very
clear about how you can mix-and-match generated names and non-generated
names: you can use any name you want for a particular object type until
you call the Gen function for that object type.

Here's the problem scenario:

 - Application calls a meta function that generates a name.  The first
   Gen will probably return 1.

 - Application decides to use the same name for an object of the same
   type without calling Gen.  Many demo programs use names 1, 2, 3,
   etc. without calling Gen.

 - Application calls the meta function again, and the meta function
   replaces the data.  The application's data is lost, and the app
   fails.  Have fun debugging that.

Signed-off-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363
---
 src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c 
b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
index 7817f0b..ec810c2 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
@@ -57,7 +57,6 @@ struct brw_fast_clear_state {
struct gl_buffer_object *buf_obj;
struct gl_vertex_array_object *array_obj;
GLuint vao;
-   GLuint vbo;
GLuint shader_prog;
GLint color_location;
 };
@@ -81,10 +80,11 @@ brw_fast_clear_init(struct brw_context *brw)
memset(clear, 0, sizeof *clear);
_mesa_GenVertexArrays(1, &clear->vao);
_mesa_BindVertexArray(clear->vao);
-   _mesa_CreateBuffers(1, &clear->vbo);
 
-   clear->buf_obj = _mesa_lookup_bufferobj(ctx, clear->vbo);
-   assert(clear->buf_obj != NULL);
+   clear->buf_obj = ctx->Driver.NewBufferObject(ctx, 0xDEADBEEF);
+   if (clear->buf_obj == NULL)
+  return false;
+
clear->array_obj = _mesa_lookup_vao(ctx, clear->vao);
assert(clear->array_obj != NULL);
 
@@ -162,7 +162,7 @@ brw_meta_fast_clear_free(struct brw_context *brw)
_mesa_make_current(&brw->ctx, NULL, NULL);
 
_mesa_DeleteVertexArrays(1, &clear->vao);
-   _mesa_DeleteBuffers(1, &clear->vbo);
+   _mesa_reference_buffer_object(&brw->ctx, &clear->buf_obj, NULL);
_mesa_DeleteProgram(clear->shader_prog);
free(clear);
 
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 09/23] meta: Use DSA functions for PBO in create_texture_for_pbo

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta_tex_subimage.c | 30 +++--
 1 file changed, 11 insertions(+), 19 deletions(-)

diff --git a/src/mesa/drivers/common/meta_tex_subimage.c 
b/src/mesa/drivers/common/meta_tex_subimage.c
index 181dde9..b0ac677 100644
--- a/src/mesa/drivers/common/meta_tex_subimage.c
+++ b/src/mesa/drivers/common/meta_tex_subimage.c
@@ -109,32 +109,24 @@ create_texture_for_pbo(struct gl_context *ctx,
 
   assert(create_pbo);
 
-  _mesa_GenBuffers(1, tmp_pbo);
-
-  /* We are not doing this inside meta_begin/end.  However, we know the
-   * client doesn't have the given target bound, so we can go ahead and
-   * squash it.  We'll set it back when we're done.
-   */
-  _mesa_BindBuffer(pbo_target, *tmp_pbo);
+  _mesa_CreateBuffers(1, tmp_pbo);
 
   /* In case of GL_PIXEL_PACK_BUFFER, pass null pointer for the pixel
-   * data to avoid unnecessary data copying in _mesa_BufferData().
+   * data to avoid unnecessary data copying in _mesa_NamedBufferData().
*/
   if (is_pixel_pack)
- _mesa_BufferData(pbo_target,
-  last_pixel - first_pixel,
-  NULL,
-  GL_STREAM_READ);
+ _mesa_NamedBufferData(*tmp_pbo,
+   last_pixel - first_pixel,
+   NULL,
+   GL_STREAM_READ);
   else
- _mesa_BufferData(pbo_target,
-  last_pixel - first_pixel,
-  (char *)pixels + first_pixel,
-  GL_STREAM_DRAW);
+ _mesa_NamedBufferData(*tmp_pbo,
+   last_pixel - first_pixel,
+   (char *)pixels + first_pixel,
+   GL_STREAM_DRAW);
 
-  buffer_obj = packing->BufferObj;
+  buffer_obj = _mesa_lookup_bufferobj(ctx, *tmp_pbo);
   first_pixel = 0;
-
-  _mesa_BindBuffer(pbo_target, 0);
}
 
_mesa_GenTextures(1, tmp_tex);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 23/23] meta: Don't save or restore the active client texture

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

This setting is only used by glTexCoordPointer and related glEnable
calls.  Since the preceeding commits removed all of those, it is not
necessary to save, reset to default, or restore this state.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta.c | 3 ---
 src/mesa/drivers/common/meta.h | 1 -
 2 files changed, 4 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index b774d3c..5183648 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -650,7 +650,6 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
   GLuint u, tgt;
 
   save->ActiveUnit = ctx->Texture.CurrentUnit;
-  save->ClientActiveUnit = ctx->Array.ActiveTexture;
   save->EnvMode = ctx->Texture.Unit[0].EnvMode;
 
   /* Disable all texture units */
@@ -683,7 +682,6 @@ _mesa_meta_begin(struct gl_context *ctx, GLbitfield state)
 
   /* set defaults for unit[0] */
   _mesa_ActiveTexture(GL_TEXTURE0);
-  _mesa_ClientActiveTexture(GL_TEXTURE0);
   _mesa_TexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
}
 
@@ -1110,7 +1108,6 @@ _mesa_meta_end(struct gl_context *ctx)
 
   /* restore current unit state */
   _mesa_ActiveTexture(GL_TEXTURE0 + save->ActiveUnit);
-  _mesa_ClientActiveTexture(GL_TEXTURE0 + save->ClientActiveUnit);
}
 
if (state & MESA_META_TRANSFORM) {
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index 8121ed4..d2c22f0 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -145,7 +145,6 @@ struct save_state
 
/** MESA_META_TEXTURE */
GLuint ActiveUnit;
-   GLuint ClientActiveUnit;
/** for unit[0] only */
struct gl_texture_object *CurrentTexture[NUM_TEXTURE_TARGETS];
/** mask of TEXTURE_2D_BIT, etc */
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 03/23] mesa: Refactor update_array_format to make _mesa_update_array_format_public

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Pulls the parts of update_array_format that aren't just parameter
validation out into a function that can be called from other parts of
Mesa (e.g., meta).

Signed-off-by: Ian Romanick 
---
 src/mesa/main/varray.c | 68 --
 src/mesa/main/varray.h |  8 ++
 2 files changed, 57 insertions(+), 19 deletions(-)

diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 5e0534a..e9f78e9 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -248,6 +248,52 @@ get_legal_types_mask(const struct gl_context *ctx)
 
 
 /**
+ * \param attrib The index of the attribute array
+ * \param size   Components per element (1, 2, 3 or 4)
+ * \param type   Datatype of each component (GL_FLOAT, GL_INT, etc)
+ * \param format Either GL_RGBA or GL_BGRA.
+ * \param normalized Whether integer types are converted to floats in [-1, 
1]
+ * \param integerInteger-valued values (will not be normalized to [-1, 
1])
+ * \param doublesDouble values not reduced to floats
+ * \param relativeOffset Offset of the first element relative to the binding
+ *   offset.
+ * \param flush_verties  Should \c FLUSH_VERTICES be invoked before updating
+ *   state?
+ */
+void
+_mesa_update_array_format(struct gl_context *ctx,
+  struct gl_vertex_array_object *vao,
+  GLuint attrib, GLint size, GLenum type,
+  GLenum format, GLboolean normalized,
+  GLboolean integer, GLboolean doubles,
+  GLuint relativeOffset, bool flush_vertices)
+{
+   struct gl_vertex_attrib_array *const array = &vao->VertexAttrib[attrib];
+   GLint elementSize;
+
+   assert(size <= 4);
+
+   if (flush_vertices) {
+  FLUSH_VERTICES(ctx, 0);
+   }
+
+   elementSize = _mesa_bytes_per_vertex_attrib(size, type);
+   assert(elementSize != -1);
+
+   array->Size = size;
+   array->Type = type;
+   array->Format = format;
+   array->Normalized = normalized;
+   array->Integer = integer;
+   array->Doubles = doubles;
+   array->RelativeOffset = relativeOffset;
+   array->_ElementSize = elementSize;
+
+   vao->NewArrays |= VERT_BIT(attrib);
+   ctx->NewState |= _NEW_ARRAY;
+}
+
+/**
  * Does error checking and updates the format in an attrib array.
  *
  * Called by update_array() and VertexAttrib*Format().
@@ -274,9 +320,7 @@ update_array_format(struct gl_context *ctx,
 GLboolean normalized, GLboolean integer, GLboolean doubles,
 GLuint relativeOffset)
 {
-   struct gl_vertex_attrib_array *array;
GLbitfield typeBit;
-   GLint elementSize;
GLenum format = GL_RGBA;
 
if (ctx->Array.LegalTypesMask == 0 || ctx->Array.LegalTypesMaskAPI != 
ctx->API) {
@@ -377,23 +421,9 @@ update_array_format(struct gl_context *ctx,
   return false;
}
 
-   assert(size <= 4);
-
-   elementSize = _mesa_bytes_per_vertex_attrib(size, type);
-   assert(elementSize != -1);
-
-   array = &vao->VertexAttrib[attrib];
-   array->Size = size;
-   array->Type = type;
-   array->Format = format;
-   array->Normalized = normalized;
-   array->Integer = integer;
-   array->Doubles = doubles;
-   array->RelativeOffset = relativeOffset;
-   array->_ElementSize = elementSize;
-
-   vao->NewArrays |= VERT_BIT(attrib);
-   ctx->NewState |= _NEW_ARRAY;
+   _mesa_update_array_format(ctx, vao, attrib, size, type, format,
+ normalized, integer, doubles, relativeOffset,
+ false);
 
return true;
 }
diff --git a/src/mesa/main/varray.h b/src/mesa/main/varray.h
index 1579b76..744b336 100644
--- a/src/mesa/main/varray.h
+++ b/src/mesa/main/varray.h
@@ -91,6 +91,14 @@ _mesa_attr_zero_aliases_vertex(struct gl_context *ctx)
 }
 
 extern void
+_mesa_update_array_format(struct gl_context *ctx,
+  struct gl_vertex_array_object *vao,
+  GLuint attrib, GLint size, GLenum type,
+  GLenum format, GLboolean normalized,
+  GLboolean integer, GLboolean doubles,
+  GLuint relativeOffset, bool flush_vertices);
+
+extern void
 _mesa_bind_vertex_buffer(struct gl_context *ctx,
  struct gl_vertex_array_object *vao,
  GLuint index,
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 05/23] i965: Pass brw_context instead of gl_context to brw_draw_rectlist

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Future patches will use the brw_context instead.  Keeping this
non-functional change separate should make the function changes easier
to review.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c 
b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
index 12e7c32..847824c 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
@@ -165,8 +165,9 @@ struct rect {
 };
 
 static void
-brw_draw_rectlist(struct gl_context *ctx, struct rect *rect, int num_instances)
+brw_draw_rectlist(struct brw_context *brw, struct rect *rect, int 
num_instances)
 {
+   struct gl_context *ctx = &brw->ctx;
int start = 0, count = 3;
struct _mesa_prim prim;
float verts[6];
@@ -588,14 +589,14 @@ brw_meta_fast_clear(struct brw_context *brw, struct 
gl_framebuffer *fb,
   _mesa_meta_drawbuffers_from_bitfield(fast_clear_buffers);
   brw_bind_rep_write_shader(brw, (float *) fast_clear_color);
   set_fast_clear_op(brw, GEN7_PS_RENDER_TARGET_FAST_CLEAR_ENABLE);
-  brw_draw_rectlist(ctx, &fast_clear_rect, layers);
+  brw_draw_rectlist(brw, &fast_clear_rect, layers);
   set_fast_clear_op(brw, 0);
}
 
if (rep_clear_buffers) {
   _mesa_meta_drawbuffers_from_bitfield(rep_clear_buffers);
   brw_bind_rep_write_shader(brw, ctx->Color.ClearColor.f);
-  brw_draw_rectlist(ctx, &clear_rect, layers);
+  brw_draw_rectlist(brw, &clear_rect, layers);
}
 
/* Now set the mts we cleared to INTEL_FAST_CLEAR_STATE_CLEAR so we'll
@@ -707,7 +708,7 @@ brw_meta_resolve_color(struct brw_context *brw,
mt->fast_clear_state = INTEL_FAST_CLEAR_STATE_RESOLVED;
get_resolve_rect(brw, mt, &rect);
 
-   brw_draw_rectlist(ctx, &rect, 1);
+   brw_draw_rectlist(brw, &rect, 1);
 
set_fast_clear_op(brw, 0);
use_rectlist(brw, false);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 10/23] meta: Use _mesa_NamedBufferData and _mesa_NamedBufferSubData for users of _mesa_meta_setup_vertex_objects

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta.c | 12 +---
 src/mesa/drivers/common/meta_blit.c|  2 +-
 src/mesa/drivers/common/meta_generate_mipmap.c |  4 ++--
 3 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index e27489d..270933f 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -1806,8 +1806,7 @@ meta_clear(struct gl_context *ctx, GLbitfield buffers, 
bool glsl)
}
 
/* upload new vertex data */
-   _mesa_BufferData(GL_ARRAY_BUFFER_ARB, sizeof(verts), verts,
-  GL_DYNAMIC_DRAW_ARB);
+   _mesa_NamedBufferData(clear->VBO, sizeof(verts), verts, GL_DYNAMIC_DRAW);
 
/* draw quad(s) */
if (fb->MaxNumLayers > 0) {
@@ -1893,7 +1892,7 @@ _mesa_meta_CopyPixels(struct gl_context *ctx, GLint srcX, 
GLint srcY,
   verts[3].tex[1] = tex->Ttop;
 
   /* upload new vertex data */
-  _mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
+  _mesa_NamedBufferSubData(copypix->VBO, 0, sizeof(verts), verts);
}
 
_mesa_set_enable(ctx, tex->Target, GL_TRUE);
@@ -2211,8 +2210,7 @@ _mesa_meta_DrawPixels(struct gl_context *ctx,
}
 
/* upload new vertex data */
-   _mesa_BufferData(GL_ARRAY_BUFFER_ARB, sizeof(verts),
-   verts, GL_DYNAMIC_DRAW_ARB);
+   _mesa_NamedBufferData(drawpix->VBO, sizeof(verts), verts, GL_DYNAMIC_DRAW);
 
/* set given unpack params */
ctx->Unpack = *unpack;
@@ -2412,7 +2410,7 @@ _mesa_meta_Bitmap(struct gl_context *ctx,
   }
 
   /* upload new vertex data */
-  _mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
+  _mesa_NamedBufferSubData(bitmap->VBO, 0, sizeof(verts), verts);
}
 
/* choose different foreground/background alpha values */
@@ -3117,7 +3115,7 @@ decompress_texture_image(struct gl_context *ctx,
_mesa_set_viewport(ctx, 0, 0, 0, width, height);
 
/* upload new vertex data */
-   _mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
+   _mesa_NamedBufferSubData(decompress->VBO, 0, sizeof(verts), verts);
 
/* setup texture state */
_mesa_BindTexture(target, texObj->Name);
diff --git a/src/mesa/drivers/common/meta_blit.c 
b/src/mesa/drivers/common/meta_blit.c
index 5972a5a..1d661b5 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -757,7 +757,7 @@ blitframebuffer_texture(struct gl_context *ctx,
   verts[3].tex[1] = t1;
   verts[3].tex[2] = readAtt->Zoffset;
 
-  _mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
+  _mesa_NamedBufferSubData(blit->VBO, 0, sizeof(verts), verts);
}
 
/* setup viewport */
diff --git a/src/mesa/drivers/common/meta_generate_mipmap.c 
b/src/mesa/drivers/common/meta_generate_mipmap.c
index 4800278..bee38e4 100644
--- a/src/mesa/drivers/common/meta_generate_mipmap.c
+++ b/src/mesa/drivers/common/meta_generate_mipmap.c
@@ -328,8 +328,8 @@ _mesa_meta_GenerateMipmap(struct gl_context *ctx, GLenum 
target,
  verts[3].tex);
 
  /* upload vertex data */
- _mesa_BufferData(GL_ARRAY_BUFFER_ARB, sizeof(verts),
-  verts, GL_DYNAMIC_DRAW_ARB);
+ _mesa_NamedBufferData(mipmap->VBO, sizeof(verts), verts,
+   GL_DYNAMIC_DRAW);
 
  _mesa_meta_bind_fbo_image(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, 
dstImage, layer);
 
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 06/23] i965: Use DSA functions for VBOs in brw_meta_fast_clear

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_meta_fast_clear.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c 
b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
index 847824c..7350f6c 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_fast_clear.c
@@ -68,7 +68,6 @@ brw_fast_clear_init(struct brw_context *brw)
if (brw->fast_clear_state) {
   clear = brw->fast_clear_state;
   _mesa_BindVertexArray(clear->vao);
-  _mesa_BindBuffer(GL_ARRAY_BUFFER, clear->vbo);
   return true;
}
 
@@ -79,9 +78,10 @@ brw_fast_clear_init(struct brw_context *brw)
memset(clear, 0, sizeof *clear);
_mesa_GenVertexArrays(1, &clear->vao);
_mesa_BindVertexArray(clear->vao);
-   _mesa_GenBuffers(1, &clear->vbo);
-   _mesa_BindBuffer(GL_ARRAY_BUFFER, clear->vbo);
-   _mesa_VertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, sizeof(float) * 2, 0);
+   _mesa_CreateBuffers(1, &clear->vbo);
+   _mesa_VertexArrayAttribFormat(clear->vao, 0, 2, GL_FLOAT, GL_FALSE, 0);
+   _mesa_VertexArrayVertexBuffer(clear->vao, 0, clear->vbo, 0,
+ sizeof(float) * 2);
_mesa_EnableVertexAttribArray(0);
 
return true;
@@ -168,6 +168,7 @@ static void
 brw_draw_rectlist(struct brw_context *brw, struct rect *rect, int 
num_instances)
 {
struct gl_context *ctx = &brw->ctx;
+   struct brw_fast_clear_state *clear = brw->fast_clear_state;
int start = 0, count = 3;
struct _mesa_prim prim;
float verts[6];
@@ -180,8 +181,8 @@ brw_draw_rectlist(struct brw_context *brw, struct rect 
*rect, int num_instances)
verts[5] = rect->y0;
 
/* upload new vertex data */
-   _mesa_BufferData(GL_ARRAY_BUFFER_ARB, sizeof(verts), verts,
-GL_DYNAMIC_DRAW_ARB);
+   _mesa_NamedBufferData(clear->vbo, sizeof(verts), verts,
+ GL_DYNAMIC_DRAW);
 
if (ctx->NewState)
   _mesa_update_state(ctx);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 02/23] mesa: Make bind_vertex_buffer avilable outside varray.c

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/main/varray.c | 29 +++--
 src/mesa/main/varray.h |  7 +++
 2 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 887d0c0..5e0534a 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -154,12 +154,12 @@ vertex_attrib_binding(struct gl_context *ctx,
  * Binds a buffer object to the vertex buffer binding point given by index,
  * and sets the Offset and Stride fields.
  */
-static void
-bind_vertex_buffer(struct gl_context *ctx,
-   struct gl_vertex_array_object *vao,
-   GLuint index,
-   struct gl_buffer_object *vbo,
-   GLintptr offset, GLsizei stride)
+void
+_mesa_bind_vertex_buffer(struct gl_context *ctx,
+ struct gl_vertex_array_object *vao,
+ GLuint index,
+ struct gl_buffer_object *vbo,
+ GLintptr offset, GLsizei stride)
 {
struct gl_vertex_buffer_binding *binding = &vao->VertexBinding[index];
 
@@ -491,8 +491,9 @@ update_array(struct gl_context *ctx,
 
/* Update the vertex buffer binding */
effectiveStride = stride != 0 ? stride : array->_ElementSize;
-   bind_vertex_buffer(ctx, ctx->Array.VAO, attrib, ctx->Array.ArrayBufferObj,
-  (GLintptr) ptr, effectiveStride);
+   _mesa_bind_vertex_buffer(ctx, ctx->Array.VAO, attrib,
+ctx->Array.ArrayBufferObj, (GLintptr) ptr,
+effectiveStride);
 }
 
 
@@ -1716,8 +1717,8 @@ vertex_array_vertex_buffer(struct gl_context *ctx,
   vbo = ctx->Shared->NullBufferObj;
}
 
-   bind_vertex_buffer(ctx, vao, VERT_ATTRIB_GENERIC(bindingIndex),
-  vbo, offset, stride);
+   _mesa_bind_vertex_buffer(ctx, vao, VERT_ATTRIB_GENERIC(bindingIndex),
+vbo, offset, stride);
 }
 
 
@@ -1804,8 +1805,8 @@ vertex_array_vertex_buffers(struct gl_context *ctx,
   struct gl_buffer_object *vbo = ctx->Shared->NullBufferObj;
 
   for (i = 0; i < count; i++)
- bind_vertex_buffer(ctx, vao, VERT_ATTRIB_GENERIC(first + i),
-vbo, 0, 16);
+ _mesa_bind_vertex_buffer(ctx, vao, VERT_ATTRIB_GENERIC(first + i),
+  vbo, 0, 16);
 
   return;
}
@@ -1876,8 +1877,8 @@ vertex_array_vertex_buffers(struct gl_context *ctx,
  vbo = ctx->Shared->NullBufferObj;
   }
 
-  bind_vertex_buffer(ctx, vao, VERT_ATTRIB_GENERIC(first + i),
- vbo, offsets[i], strides[i]);
+  _mesa_bind_vertex_buffer(ctx, vao, VERT_ATTRIB_GENERIC(first + i),
+   vbo, offsets[i], strides[i]);
}
 
_mesa_end_bufferobj_lookups(ctx);
diff --git a/src/mesa/main/varray.h b/src/mesa/main/varray.h
index 5583ed5..1579b76 100644
--- a/src/mesa/main/varray.h
+++ b/src/mesa/main/varray.h
@@ -90,6 +90,13 @@ _mesa_attr_zero_aliases_vertex(struct gl_context *ctx)
&& !is_forward_compatible_context));
 }
 
+extern void
+_mesa_bind_vertex_buffer(struct gl_context *ctx,
+ struct gl_vertex_array_object *vao,
+ GLuint index,
+ struct gl_buffer_object *vbo,
+ GLintptr offset, GLsizei stride);
+
 extern void GLAPIENTRY
 _mesa_VertexPointer(GLint size, GLenum type, GLsizei stride,
 const GLvoid *ptr);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 12/23] meta: Don't leave the VBO bound after _mesa_meta_setup_vertex_objects

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Meta currently does this, but future changes will make this impossible.
Explicitly do it as a step in the patch series now to catch any possible
kinks.

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta.c| 42 +++
 src/mesa/drivers/common/meta.h|  6 ++--
 src/mesa/drivers/common/meta_blit.c   |  5 +--
 src/mesa/drivers/common/meta_generate_mipmap.c|  4 +--
 src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c |  2 +-
 5 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 270933f..8b9bccc 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -310,9 +310,9 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
 /**
  * Configure vertex buffer and vertex array objects for tests
  *
- * Regardless of whether a new VAO and new VBO are created, the objects
- * referenced by \c VAO and \c VBO will be bound into the GL state vector
- * when this function terminates.
+ * Regardless of whether a new VAO is created, the object referenced by \c VAO
+ * will be bound into the GL state vector when this function terminates.  The
+ * object referenced by \c VBO will \b not be bound.
  *
  * \param VAO   Storage for vertex array object handle.  If 0, a new VAO
  *  will be created.
@@ -333,7 +333,8 @@ _mesa_meta_setup_blit_shader(struct gl_context *ctx,
  * Use \c texcoord_size instead.
  */
 void
-_mesa_meta_setup_vertex_objects(GLuint *VAO, GLuint *VBO,
+_mesa_meta_setup_vertex_objects(struct gl_context *ctx,
+GLuint *VAO, GLuint *VBO,
 bool use_generic_attributes,
 unsigned vertex_size, unsigned texcoord_size,
 unsigned color_size)
@@ -381,9 +382,18 @@ _mesa_meta_setup_vertex_objects(GLuint *VAO, GLuint *VBO,
 _mesa_EnableClientState(GL_COLOR_ARRAY);
  }
   }
+
+  /* Restore the old VBO.  This is done because we don't want the new VBO
+   * to be bound on exit.  It would be nicer to use DSA type functions,
+   * but there are no DSA functions to bind a VBO to a VAO for
+   * fixed-function vertex attributes.
+   */
+  {
+ struct save_state *save = &ctx->Meta->Save[ctx->Meta->SaveStackDepth 
- 1];
+ _mesa_BindBuffer(GL_ARRAY_BUFFER, save->ArrayBufferObj->Name);
+  }
} else {
   _mesa_BindVertexArray(*VAO);
-  _mesa_BindBuffer(GL_ARRAY_BUFFER, *VBO);
}
 }
 
@@ -1479,10 +1489,11 @@ _mesa_meta_setup_drawpix_texture(struct gl_context *ctx,
 }
 
 void
-_mesa_meta_setup_ff_tnl_for_blit(GLuint *VAO, GLuint *VBO,
+_mesa_meta_setup_ff_tnl_for_blit(struct gl_context *ctx,
+ GLuint *VAO, GLuint *VBO,
  unsigned texcoord_size)
 {
-   _mesa_meta_setup_vertex_objects(VAO, VBO, false, 2, texcoord_size, 0);
+   _mesa_meta_setup_vertex_objects(ctx, VAO, VBO, false, 2, texcoord_size, 0);
 
/* setup projection matrix */
_mesa_MatrixMode(GL_PROJECTION);
@@ -1527,7 +1538,8 @@ meta_glsl_clear_init(struct gl_context *ctx, struct 
clear_state *clear)
GLuint vs, fs;
bool has_integer_textures;
 
-   _mesa_meta_setup_vertex_objects(&clear->VAO, &clear->VBO, true, 3, 0, 0);
+   _mesa_meta_setup_vertex_objects(ctx, &clear->VAO, &clear->VBO, true,
+   3, 0, 0);
 
if (clear->ShaderProg != 0)
   return;
@@ -1723,7 +1735,8 @@ meta_clear(struct gl_context *ctx, GLbitfield buffers, 
bool glsl)
   y1 = ((float) fb->_Ymax / fb->Height) * 2.0f - 1.0f;
   z = -invert_z(ctx->Depth.Clear);
} else {
-  _mesa_meta_setup_vertex_objects(&clear->VAO, &clear->VBO, false, 3, 0, 
4);
+  _mesa_meta_setup_vertex_objects(ctx, &clear->VAO, &clear->VBO, false,
+  3, 0, 4);
 
   x0 = (float) fb->_Xmin;
   y0 = (float) fb->_Ymin;
@@ -1852,7 +1865,7 @@ _mesa_meta_CopyPixels(struct gl_context *ctx, GLint srcX, 
GLint srcY,
   MESA_META_VERTEX |
   MESA_META_VIEWPORT));
 
-   _mesa_meta_setup_vertex_objects(©pix->VAO, ©pix->VBO, false,
+   _mesa_meta_setup_vertex_objects(ctx, ©pix->VAO, ©pix->VBO, false,
3, 2, 0);
 
/* Silence valgrind warnings about reading uninitialized stack. */
@@ -2173,7 +2186,7 @@ _mesa_meta_DrawPixels(struct gl_context *ctx,
 
newTex = _mesa_meta_alloc_texture(tex, width, height, texIntFormat);
 
-   _mesa_meta_setup_vertex_objects(&drawpix->VAO, &drawpix->VBO, false,
+   _mesa_meta_setup_vertex_objects(ctx, &drawpix->VAO, &drawpix->VBO, false,
3, 2

[Mesa-dev] [PATCH 19/23] meta: Use internal functions for buffer object and VAO access in _mesa_meta_DrawTex

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta.c | 32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 6927ae9..57993cf 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3298,13 +3298,16 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
 
if (drawtex->VAO == 0) {
   /* one-time setup */
-  GLint active_texture;
+  struct gl_vertex_array_object *array_obj;
   GLuint VBO;
 
   /* create vertex array object */
   _mesa_GenVertexArrays(1, &drawtex->VAO);
   _mesa_BindVertexArray(drawtex->VAO);
 
+  array_obj = _mesa_lookup_vao(ctx, drawtex->VAO);
+  assert(array_obj != NULL);
+
   /* create vertex array buffer */
   _mesa_CreateBuffers(1, &VBO);
   drawtex->buf_obj = _mesa_lookup_bufferobj(ctx, VBO);
@@ -3321,22 +3324,27 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
 
   assert(drawtex->buf_obj->Size == sizeof(verts));
 
-  /* client active texture is not part of the array object */
-  active_texture = ctx->Array.ActiveTexture;
-
   _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, VBO);
 
   /* setup vertex arrays */
-  _mesa_VertexPointer(3, GL_FLOAT, sizeof(struct vertex), OFFSET(x));
-  _mesa_EnableClientState(GL_VERTEX_ARRAY);
+  _mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_POS,
+3, GL_FLOAT, GL_RGBA, GL_FALSE,
+GL_FALSE, GL_FALSE,
+offsetof(struct vertex, x), true);
+  _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_POS,
+   drawtex->buf_obj, 0, sizeof(struct vertex));
+  _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_POS);
+
+
   for (i = 0; i < ctx->Const.MaxTextureUnits; i++) {
- _mesa_ClientActiveTexture(GL_TEXTURE0 + i);
- _mesa_TexCoordPointer(2, GL_FLOAT, sizeof(struct vertex), 
OFFSET(st[i]));
- _mesa_EnableClientState(GL_TEXTURE_COORD_ARRAY);
+ _mesa_update_array_format(ctx, array_obj, VERT_ATTRIB_TEX(i),
+   2, GL_FLOAT, GL_RGBA, GL_FALSE,
+   GL_FALSE, GL_FALSE,
+   offsetof(struct vertex, st[i]), true);
+ _mesa_bind_vertex_buffer(ctx, array_obj, VERT_ATTRIB_TEX(i),
+  drawtex->buf_obj, 0, sizeof(struct vertex));
+ _mesa_enable_vertex_array_attrib(ctx, array_obj, VERT_ATTRIB_TEX(i));
   }
-
-  /* restore client active texture */
-  _mesa_ClientActiveTexture(GL_TEXTURE0 + active_texture);
}
else {
   _mesa_BindVertexArray(drawtex->VAO);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 17/23] meta: Partially convert _mesa_meta_DrawTex to DSA

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/common/meta.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 8249eda..1bf3d52 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -3305,14 +3305,15 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
   _mesa_BindVertexArray(drawtex->VAO);
 
   /* create vertex array buffer */
-  _mesa_GenBuffers(1, &drawtex->VBO);
-  _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, drawtex->VBO);
-  _mesa_BufferData(GL_ARRAY_BUFFER_ARB, sizeof(verts),
-  NULL, GL_DYNAMIC_DRAW_ARB);
+  _mesa_CreateBuffers(1, &drawtex->VBO);
+  _mesa_NamedBufferData(drawtex->VBO, sizeof(verts),
+NULL, GL_DYNAMIC_DRAW_ARB);
 
   /* client active texture is not part of the array object */
   active_texture = ctx->Array.ActiveTexture;
 
+  _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, drawtex->VBO);
+
   /* setup vertex arrays */
   _mesa_VertexPointer(3, GL_FLOAT, sizeof(struct vertex), OFFSET(x));
   _mesa_EnableClientState(GL_VERTEX_ARRAY);
@@ -3327,7 +3328,6 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
}
else {
   _mesa_BindVertexArray(drawtex->VAO);
-  _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, drawtex->VBO);
}
 
/* vertex positions, texcoords */
@@ -3392,7 +3392,7 @@ _mesa_meta_DrawTex(struct gl_context *ctx, GLfloat x, 
GLfloat y, GLfloat z,
  verts[3].st[i][1] = t1;
   }
 
-  _mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
+  _mesa_NamedBufferSubData(drawtex->VBO, 0, sizeof(verts), verts);
}
 
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH 11/23] i965: Use _mesa_NamedBufferSubData for users of _mesa_meta_setup_vertex_objects

2015-11-09 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
---
 src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c 
b/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
index cbbb919..62ae4e7 100644
--- a/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
+++ b/src/mesa/drivers/dri/i965/brw_meta_stencil_blit.c
@@ -360,7 +360,7 @@ adjust_mip_level(const struct intel_mipmap_tree *mt,
 }
 
 static void
-prepare_vertex_data(void)
+prepare_vertex_data(GLuint vbo)
 {
static const struct vertex verts[] = {
   { .x = -1.0f, .y = -1.0f },
@@ -368,7 +368,7 @@ prepare_vertex_data(void)
   { .x =  1.0f, .y =  1.0f },
   { .x = -1.0f, .y =  1.0f } };
 
-   _mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
+   _mesa_NamedBufferSubData(vbo, 0, sizeof(verts), verts);
 }
 
 static bool
@@ -448,7 +448,7 @@ brw_meta_stencil_blit(struct brw_context *brw,
_mesa_Uniform1i(_mesa_GetUniformLocation(prog, "dst_num_samples"),
dst_mt->num_samples);
 
-   prepare_vertex_data();
+   prepare_vertex_data(ctx->Meta->Blit.VBO);
_mesa_set_viewport(ctx, 0, dims.dst_x0, dims.dst_y0,
   dims.dst_x1 - dims.dst_x0, dims.dst_y1 - dims.dst_y0);
_mesa_ColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 00/23] Don't pollute the buffer object namespace in meta

2015-11-09 Thread Ian Romanick
Also on the meta-cannot-use-Gen branch of my fd.o Mesa tree.  This
branch will contain all of the current work... including patches beyond
this series.

On 11/09/2015 04:55 PM, Ian Romanick wrote:
> In OpenGL ES (all versions!) and OpenGL compatibility profile,
> applications don't have to call Gen functions.  The GL spec is very
> clear about how you can mix-and-match generated names and non-generated
> names: you can use any name you want for a particular object type until
> you call the Gen function for that object type.  After calling Gen,
> making up your own names is not guaranteed to work.
> 
> Meta uses Gen all over the place, and this can conflict with names the
> application may try to use.  It's not hard to find OpenGL demos that do
> things like:
> 
>glBindTexture(GL_TEXTURE_2D, 1);
>...
> 
>glBindTexture(GL_TEXTURE_2D, 2);
>...
> 
> I suspect there are even demos in the mesa-demos repository that do
> this.
> 
> This is, IMO, a case of premature optimization in OpenGL 1.0.  In OpenGL
> 1.0, almost all implementations were indirect-renderers.  If names had
> to be allocated from the server, that meant you had to (queue dramatic
> music) have an extra round-trip to the server to get some names.  In
> addition, allowing user-defined names meant that you could name the
> display list (the only pseudo-object in OpenGL 1.0) that drew the letter
> A, (int)'A'.  It was common to see text rendering loops like:
> 
> while (*str) {
> glCallList((GLuint)*str);
> str++;
> }
> 
> On the systems of 1992, that may have mattered.  It's certainly not an
> optimization that has mattered on any system that I've programmed OpenGL
> on, and the damage that it does inside drivers is... this is a 23-patch
> series to fix a bug that should never have existed!
> 
> Here's the problem scenario:
> 
>  - Application calls a meta function that generates a name.  The first
>Gen will return 1.
> 
>  - Application decides to use the same name for an object of the same
>type without calling Gen.  Many demo programs use names 1, 2, 3,
>etc. without calling Gen.
> 
>  - Application calls the meta function again, and the meta function
>replaces the data.  The application's data is lost, and the app
>fails.  Have fun debugging that.
> 
> This patch series is longer than is strictly necessary.  I wanted to
> make each individual step easy to review.  It's a good thing too.  There
> were a couple places where I made typos or cut-and-paste errors that
> were much easier to bisect.
> 
> This patch series also *only* fixes the problem for buffer objects.
> Texture, sampler, framebuffer, renderbuffer, and assembly program
> objects still need to be fixed.
> 
> ___
> 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] i965: Map GL_PATCHES to 3DPRIM_PATCHLIST_n.

2015-11-10 Thread Ian Romanick
On 11/10/2015 01:19 AM, Kenneth Graunke wrote:
> Inspired by a patch by Fabian Bieler.
> 
> Fabian defined a _3DPRIM_PATCHLIST_0 macro (which isn't actually a valid
> topology type); I instead chose to make a macro that takes an argument.
> He also took the number of patch vertices from _mesa_prim (which was set
> to ctx->TessCtrlProgram.patch_vertices) - I chose to use it directly to
> avoid the need for the VBO patch.
> 
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_defines.h | 2 ++
>  src/mesa/drivers/dri/i965/brw_draw.c| 9 -
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_defines.h 
> b/src/mesa/drivers/dri/i965/brw_defines.h
> index eb91634..6dfaf8f 100644
> --- a/src/mesa/drivers/dri/i965/brw_defines.h
> +++ b/src/mesa/drivers/dri/i965/brw_defines.h
> @@ -78,6 +78,8 @@
>  #define _3DPRIM_LINESTRIP_BF  0x13
>  #define _3DPRIM_LINESTRIP_CONT_BF 0x14
>  #define _3DPRIM_TRIFAN_NOSTIPPLE  0x16
> +#define _3DPRIM_PATCHLIST(n) ({ assert(n > 0 && n <= 32); 0x1F + n; })
> +

Nice assert. :)

The docs list 3DPRIM_PATCHLIST_1 as 0x20.  It may be trivially better to
use 0x20 + (n - 1) so that the value in the code matches the value in
the docs.

>  /* We use this offset to be able to pass native primitive types in struct
>   * _mesa_prim::mode.  Native primitive types are BRW_PRIM_OFFSET +
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c 
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index 39a26b0..bff484f 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -140,9 +140,16 @@ brw_set_prim(struct brw_context *brw, const struct 
> _mesa_prim *prim)
>  static void
>  gen6_set_prim(struct brw_context *brw, const struct _mesa_prim *prim)
>  {
> +   const struct gl_context *ctx = &brw->ctx;
> +   uint32_t hw_prim;
> +
> DBG("PRIM: %s\n", _mesa_enum_to_string(prim->mode));
>  
> -   const uint32_t hw_prim = get_hw_prim_for_gl_prim(prim->mode);
> +   if (prim->mode == GL_PATCHES)
> +  hw_prim = _3DPRIM_PATCHLIST(ctx->TessCtrlProgram.patch_vertices);
> +   else
> +  hw_prim = get_hw_prim_for_gl_prim(prim->mode);
> +

I'd be tempted to use ?: so that hw_prim could continue to be const, but
it's not a biggie.

With or without either of these changes, this patch is

Reviewed-by: Ian Romanick 

> if (hw_prim != brw->primitive) {
>brw->primitive = hw_prim;
>brw->ctx.NewDriverState |= BRW_NEW_PRIMITIVE;
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Potential spec change request for EXT_buffer_storage

2015-11-10 Thread Ian Romanick
On 11/09/2015 04:10 PM, Ian Romanick wrote:
> On 11/04/2015 03:26 PM, Ryan Houdek wrote:
>> I'm hoping to potentially convince about lowering the minimum
>> requirement of EXT_buffer_storage from ES 3.1 to ES 3.0.
>> The only thing that causes it to require ES 3.1 is glMemoryBarrier,
>> which shouldn't really be a hard requirement since the extension can be
>> used without it.
>> This is also a similar situation with ARB_buffer_storage which Mesa
>> currently exposes to all GL versions even though it should require GL 4.2.
>> I have my attempt at a change to the spec as follows. I've never tried
>> changing a spec page before so it's a bit new to me.
> 
> I think all of the drivers that support ARB_buffer_storage also support
> ARB_texture_barrier.  At the very least I think you'd need to require
> GL_MAP_CHOERENT_BIT with GL_MAP_PERSISTENT_BIT.
> 
> Also... Mesa is really close to getting OpenGL ES 3.1.  Are there any
> drivers with which you want to use this extension that won't have GLES 3.1?
> 
>> diff --git a/EXT_buffer_storage.txt b/EXT_buffer_storage.txt
>> index 03fcd6e..ea16fae 100644
>> --- a/EXT_buffer_storage.txt
>> +++ b/EXT_buffer_storage.txt
>> @@ -30,8 +30,8 @@ Status
>>  
>>  Version
>>  
>> -Last Modified Date:   May 1, 2015
>> -Author Revision:  3
>> +Last Modified Date:   November 4, 2015
>> +Author Revision:  4
>>  
>>  Number
>>  
>> @@ -39,10 +39,12 @@ Number
>>  
>>  Dependencies
>>  
>> -OpenGL ES 3.1 is required.
>> -
>>  This extension is written against the OpenGL ES 3.1 (June 4, 2014)
>> -Specification.
>> +Specification, but can apply to prior specifications
>> +
>> +Requires OpenGL ES 3.0
> 
> I think I'd just change the above to replace the current "required" line
> with
> 
>OpenGL ES 3.0 is required.
> 
> and leave the rest alone.
> 
> I think the rest of the edits look good.

Follow-up question... should the actual requirement be

OpenGL ES 3.0 or GL_EXT_map_buffer_range is required.

Also... you should add yourself to the "Contributors" section.  That
creates a mapping between rhoudek in the history and an actual human. :)

>> +
>> +This extension interacts with OpenGL ES 3.1.
>>  
>>  The definition of this extension is affected by the presence of
>>  GL_EXT_direct_state_access.
>> @@ -350,6 +352,50 @@ Additions to Chapter 7 of the OpenGL ES 3.1
>> Specification,
>>by shaders prior to the barrier. Note that this may cause
>> additional
>>synchronization operations.
>>  
>> +Dependencies on OpenGL ES 3.1
>> +
>> +If OpenGL ES 3.1 is not supported apply the following modifications
>> to the
>> +OpenGL ES 3.0.4 specification:
>> +
>> +Append to the first paragraph of Section 2.10, "Buffer Objects", p. 32:
>> +
>> +Under certain circumstances, the data store of a buffer object may
>> +be shared between the client and server and accessed simultaneously
>> +by both.
>> +
>> +Modify Section 2.10.1 (Creating and Binding Buffer Objects)
>> +
>> +Append to Table 2.7, "Buffer object parameters and their values", p.34:
>> +
>> +  
>>  +--+-+-+--+
>> +|  | | Initial | Legal
>>|
>> +| Name | Type| Value   | Values
>>   |
>> +  
>>  +--+-+-+--+
>> +| BUFFER_IMMUTABLE_STORAGE_EXT | boolean | FALSE   | TRUE,
>> FALSE  |
>> +| BUFFER_STORAGE_FLAGS_EXT | int | 0   | See
>> section 6.2  |
>> +  
>>  +--+-+-+--+
>> +
>> +Edits to section 6.2 "Creating and Modifying Buffer Object Data
>> Stores" in
>> +ES 3.1 become edits to section 2.10.2 "Creating Buffer Object Data
>> Stores"
>> +in ES 3.0.4.
>> +
>> +Edits to section 6.3, "Mapping and Unmapping Buffer Data" in ES 3.1
>> become
>> +edits in section 2.10.3 "Mapping and Unmapping Buffer Data" in ES 3.0.4
>> +
>> +Edits to p.56, FlushMappedBufferRange, in ES 3.1 become edits in p.40
>> +in ES 3.0.4
>> +
>> +Edits to section 6.3.2, "Effects of Mapping Buffers on

Re: [Mesa-dev] Potential spec change request for EXT_buffer_storage

2015-11-10 Thread Ian Romanick
On 11/09/2015 04:29 PM, Ilia Mirkin wrote:
> On Mon, Nov 9, 2015 at 7:10 PM, Ian Romanick  wrote:
>> On 11/04/2015 03:26 PM, Ryan Houdek wrote:
>>> I'm hoping to potentially convince about lowering the minimum
>>> requirement of EXT_buffer_storage from ES 3.1 to ES 3.0.
>>> The only thing that causes it to require ES 3.1 is glMemoryBarrier,
>>> which shouldn't really be a hard requirement since the extension can be
>>> used without it.
>>> This is also a similar situation with ARB_buffer_storage which Mesa
>>> currently exposes to all GL versions even though it should require GL 4.2.
>>> I have my attempt at a change to the spec as follows. I've never tried
>>> changing a spec page before so it's a bit new to me.
>>
>> I think all of the drivers that support ARB_buffer_storage also support
>> ARB_texture_barrier.  At the very least I think you'd need to require
>> GL_MAP_CHOERENT_BIT with GL_MAP_PERSISTENT_BIT.
> 
> Not freedreno (and only very recently for i965). Although I guess it
> shouldn't be too hard to stick a gmem2mem step into the queue for such
> an occasion without interrupting the tiling.
> 
>> Also... Mesa is really close to getting OpenGL ES 3.1.  Are there any
>> drivers with which you want to use this extension that won't have GLES 3.1?
> 
> It'll be quite a while before freedreno supports GLES 3.1, and it's
> unclear to me that the a3xx hardware will even be capable of it
> (although it quite possibly may be).

The goal was that GLES 3.1 would be implementable on any hardware on
which vendors had shipped GLES 3.0.  Although wikipedia
(https://en.wikipedia.org/wiki/Adreno) thinks only A4xx can do GLES 3.1.
 Given that it also lists OpenCL 1.1 and DX 11.1 (although it does also
say only feature level 9_3 is supported), I think the hardware can do
it, but Qualcomm just didn't have customer demand to implement it.

Hmm... I guess whether the hardware is capable or not, freedreno may
never support it.  That means we should proceed with this.

I think the right approach will be to get things to match what we plan
to ship, then attach the patch to a bug in the Khronos public bugzilla.
 I can then follow-up with Daniel and the people who manage the registry
to get the changes through.  This is an EXT, so there's no voting or
committee debates necessary.

> I don't know how far we are from being able to reasonably drop
> freedreno into an android environment, but probably closer and more
> plausibly than other drivers (i.e. adreno hw is on devices you'd run
> android on... you could run android on your desktop pc too, but...
> less likely, and you'd have GL there).
> 
>   -ilia

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 1/8] glapi: Add EXT_blend_func_extended XML definitions

2015-11-10 Thread Ian Romanick
Okay... I see what happened.  I thought it was weird that it added
glBindFragDataLocationEXT to an ES3 context because GLES3 surely already
has glBindFragDataLocation.  It actually doesn't.  The only way to set
the fragment shader output location is using a layout qualifier in the
shader.  GLES generally has a "one way to do things" guiding principle,
so glBindFragDataLocation had to go.  Nice to see NVIDIA sneak it back
in with a mostly unrelated extension. :)

This patch is

Reviewed-by: Ian Romanick 

On 11/06/2015 10:41 AM, Ryan Houdek wrote:
> Yes this is correct. These functions are only available in ES 3.0+ profiles.
> The only things that ES 2.0 gets is the new builtins for the shading
> language.
> 
> On Fri, Nov 6, 2015 at 12:49 PM, Ian Romanick  <mailto:i...@freedesktop.org>> wrote:
> 
> On 11/05/2015 06:47 PM, Ryan Houdek wrote:
> > ---
> >  src/mapi/glapi/gen/EXT_gpu_shader4.xml  |  3 ++-
> >  src/mapi/glapi/gen/es_EXT.xml   | 26 ++
> >  src/mesa/main/tests/dispatch_sanity.cpp |  8 
> >  3 files changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/mapi/glapi/gen/EXT_gpu_shader4.xml 
> b/src/mapi/glapi/gen/EXT_gpu_shader4.xml
> > index b1f7eae..b4120b9 100644
> > --- a/src/mapi/glapi/gen/EXT_gpu_shader4.xml
> > +++ b/src/mapi/glapi/gen/EXT_gpu_shader4.xml
> > @@ -232,7 +232,8 @@
> >  
> >  
> >
> > - alias="BindFragDataLocation">
> > + alias="BindFragDataLocation"
> > + es2="3.0">
> 
> Is this right?  It looks like patch 8 enables the extension in OpenGL ES
> 2.0 contexts.
> 
> There are more occurrences of this below...
> 
> >  
> >  
> >  
> > diff --git a/src/mapi/glapi/gen/es_EXT.xml
> b/src/mapi/glapi/gen/es_EXT.xml
> > index 9a777a2..577d825 100644
> > --- a/src/mapi/glapi/gen/es_EXT.xml
> > +++ b/src/mapi/glapi/gen/es_EXT.xml
> > @@ -914,4 +914,30 @@
> >  
> >  
> >
> > +
> > +
> > + alias="BindFragDataLocationIndexed"
> > +es2="3.0">
> > +
> > +
> > +
> > +
> > +
> > +
> > + > +es2="3.0">
> > +
> > +
> > +
> > +
> > +
> > + alias="GetProgramResourceLocationIndex"
> > +   es2="3.1">
> > +
> > +
> > +
> > +
> > +
> > +
> > +
> >  
> > diff --git a/src/mesa/main/tests/dispatch_sanity.cpp
> b/src/mesa/main/tests/dispatch_sanity.cpp
> > index abe0f43..97f81f9 100644
> > --- a/src/mesa/main/tests/dispatch_sanity.cpp
> > +++ b/src/mesa/main/tests/dispatch_sanity.cpp
> > @@ -2421,6 +2421,11 @@ const struct function
> gles3_functions_possible[] = {
> > { "glProgramUniform4uiEXT", 30, -1 },
> > { "glProgramUniform4uivEXT", 30, -1 },
> >
> > +   /* GL_EXT_blend_func_extended */
> > +   { "glBindFragDataLocationIndexedEXT", 30, -1 },
> > +   { "glGetFragDataIndexEXT", 30, -1 },
> > +   { "glBindFragDataLocationEXT", 30, -1 },
> > +
> > { NULL, 0, -1 }
> >  };
> >
> > @@ -2509,5 +2514,8 @@ const struct function
> gles31_functions_possible[] = {
> > /* GL_EXT_buffer_storage */
> > { "glBufferStorageEXT", 31, -1 },
> >
> > +   /* GL_EXT_blend_func_extended */
> > +   { "glGetProgramResourceLocationIndexEXT", 31, -1 },
> > +
> > { NULL, 0, -1 },
> >   };
> >
> 
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 2/8] glsl: Add required variables to _mesa_glsl_parse_state for EXT_blend_func_extended

2015-11-10 Thread Ian Romanick
This patch is

Reviewed-by: Ian Romanick 

On 11/05/2015 06:47 PM, Ryan Houdek wrote:
> This adds a state for the maximum dual source draw variables available
> and the variable for determining if the extension has been enabled
> in the program shaders.
> ---
>  src/glsl/glsl_parser_extras.cpp | 3 +++
>  src/glsl/glsl_parser_extras.h   | 5 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
> index 14cb9fc..31c0319 100644
> --- a/src/glsl/glsl_parser_extras.cpp
> +++ b/src/glsl/glsl_parser_extras.cpp
> @@ -102,6 +102,8 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct 
> gl_context *_ctx,
>  
> this->Const.MaxDrawBuffers = ctx->Const.MaxDrawBuffers;
>  
> +   this->Const.MaxDualSourceDrawBuffers = 
> ctx->Const.MaxDualSourceDrawBuffers;
> +
> /* 1.50 constants */
> this->Const.MaxVertexOutputComponents = 
> ctx->Const.Program[MESA_SHADER_VERTEX].MaxOutputComponents;
> this->Const.MaxGeometryInputComponents = 
> ctx->Const.Program[MESA_SHADER_GEOMETRY].MaxInputComponents;
> @@ -643,6 +645,7 @@ static const _mesa_glsl_extension 
> _mesa_glsl_supported_extensions[] = {
> EXT(AMD_shader_trinary_minmax,  true,  false, dummy_true),
> EXT(AMD_vertex_shader_layer,true,  false, 
> AMD_vertex_shader_layer),
> EXT(AMD_vertex_shader_viewport_index, true,  false,   
> AMD_vertex_shader_viewport_index),
> +   EXT(EXT_blend_func_extended,false,  true, 
> ARB_blend_func_extended),
> EXT(EXT_draw_buffers,   false,  true, dummy_true),
> EXT(EXT_separate_shader_objects,false, true,  dummy_true),
> EXT(EXT_shader_integer_mix, true,  true,  
> EXT_shader_integer_mix),
> diff --git a/src/glsl/glsl_parser_extras.h b/src/glsl/glsl_parser_extras.h
> index b54c535..7dd9477 100644
> --- a/src/glsl/glsl_parser_extras.h
> +++ b/src/glsl/glsl_parser_extras.h
> @@ -375,6 +375,9 @@ struct _mesa_glsl_parse_state {
>/* ARB_draw_buffers */
>unsigned MaxDrawBuffers;
>  
> +  /* ARB_blend_func_extended */
> +  unsigned MaxDualSourceDrawBuffers;
> +
>/* 3.00 ES */
>int MinProgramTexelOffset;
>int MaxProgramTexelOffset;
> @@ -588,6 +591,8 @@ struct _mesa_glsl_parse_state {
> bool AMD_vertex_shader_layer_warn;
> bool AMD_vertex_shader_viewport_index_enable;
> bool AMD_vertex_shader_viewport_index_warn;
> +   bool EXT_blend_func_extended_enable;
> +   bool EXT_blend_func_extended_warn;
> bool EXT_draw_buffers_enable;
> bool EXT_draw_buffers_warn;
> bool EXT_separate_shader_objects_enable;
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH v3 8/8] mesa: Enable EXT_blend_func_extended if the driver supports the ARB version

2015-11-10 Thread Ian Romanick
Once all the others are ready, this patch is also

Reviewed-by: Ian Romanick 

On 11/05/2015 06:47 PM, Ryan Houdek wrote:
> ---
>  docs/relnotes/11.1.0.html  | 1 +
>  src/mesa/main/extensions.c | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/docs/relnotes/11.1.0.html b/docs/relnotes/11.1.0.html
> index c35d91f..5c2e530 100644
> --- a/docs/relnotes/11.1.0.html
> +++ b/docs/relnotes/11.1.0.html
> @@ -56,6 +56,7 @@ Note: some of the new features are only available with 
> certain drivers.
>  GL_ARB_texture_barrier / GL_NV_texture_barrier on i965
>  GL_ARB_texture_query_lod on softpipe
>  GL_ARB_texture_view on radeonsi
> +GL_EXT_blend_func_extended on all drivers that support the ARB 
> version
>  GL_EXT_buffer_storage implemented for when ES 3.1 support is gained
>  GL_EXT_draw_elements_base_vertex on all drivers
>  GL_OES_draw_elements_base_vertex on all drivers
> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
> index bdc6817..f1692ba 100644
> --- a/src/mesa/main/extensions.c
> +++ b/src/mesa/main/extensions.c
> @@ -221,6 +221,7 @@ static const struct extension extension_table[] = {
> { "GL_EXT_bgra",o(dummy_true),
>   GLL,1995 },
> { "GL_EXT_blend_color", o(EXT_blend_color),   
>   GLL,1995 },
> { "GL_EXT_blend_equation_separate", 
> o(EXT_blend_equation_separate), GL, 2003 },
> +   { "GL_EXT_blend_func_extended", 
> o(ARB_blend_func_extended), ES2, 2015 },
> { "GL_EXT_blend_func_separate", 
> o(EXT_blend_func_separate), GLL,1999 },
> { "GL_EXT_buffer_storage",  o(ARB_buffer_storage),
>  ES31, 2015 },
> { "GL_EXT_discard_framebuffer", o(dummy_true),
> ES1 | ES2, 2009 },
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] mesa/copyimage: allow width/height to not be multiples of block

2015-11-10 Thread Ian Romanick
On 11/08/2015 01:50 AM, Ilia Mirkin wrote:
> For compressed textures, the image size is not necessarily a multiple of
> the block size (e.g. the last mip levels). For example the RGTC spec
> calls out this condition as legal, saying to error only when:
> 
> *  is not a multiple of four, and  plus 
> * is not equal to TEXTURE_WIDTH;
> 
> While the GL_ARB_copy_image spec does not call this out explicitly, it
> appears that some games rely on this. Also it seems like it should be
> possible to copy in the last miplevels of a compressed texture's
> miptree.

I think this is fixed in the core GL spec.  Section 18.3.2 (Copying
Between Images) of the OpenGL 4.5 Core Profile spec says:

An INVALID_VALUE error is generated if the dimensions of either
subregion exceeds the boundaries of the corresponding image object,
or if the image format is compressed and the dimensions of the
subregion fail to meet the alignment constraints of the format.

Section 8.7 (Compressed Texture Images) says:

An INVALID_OPERATION error is generated if any of the following
conditions occurs:

  • width is not a multiple of four, and width + xoffset is not
equal to the value of TEXTURE_WIDTH.
  • height is not a multiple of four, and height + yoffset is not
equal to the value of TEXTURE_HEIGHT.

With the above spec quotations added somewhere (either the commit
message or the code), this patch is

Reviewed-by: Ian Romanick 

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92860
> Signed-off-by: Ilia Mirkin 
> Cc: mesa-sta...@lists.freedesktop.org
> ---
>  src/mesa/main/copyimage.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/main/copyimage.c b/src/mesa/main/copyimage.c
> index f02e842..974de7f 100644
> --- a/src/mesa/main/copyimage.c
> +++ b/src/mesa/main/copyimage.c
> @@ -62,6 +62,8 @@ prepare_target(struct gl_context *ctx, GLuint name, GLenum 
> target,
> struct gl_renderbuffer **renderbuffer,
> mesa_format *format,
> GLenum *internalFormat,
> +   GLuint *width,
> +   GLuint *height,
> const char *dbg_prefix)
>  {
> if (name == 0) {
> @@ -126,6 +128,8 @@ prepare_target(struct gl_context *ctx, GLuint name, 
> GLenum target,
>*renderbuffer = rb;
>*format = rb->Format;
>*internalFormat = rb->InternalFormat;
> +  *width = rb->Width;
> +  *height = rb->Height;
>*tex_image = NULL;
> } else {
>struct gl_texture_object *texObj = _mesa_lookup_texture(ctx, name);
> @@ -194,6 +198,8 @@ prepare_target(struct gl_context *ctx, GLuint name, 
> GLenum target,
>*renderbuffer = NULL;
>*format = (*tex_image)->TexFormat;
>*internalFormat = (*tex_image)->InternalFormat;
> +  *width = (*tex_image)->Width;
> +  *height = (*tex_image)->Height;
> }
>  
> return true;
> @@ -423,6 +429,7 @@ _mesa_CopyImageSubData(GLuint srcName, GLenum srcTarget, 
> GLint srcLevel,
> struct gl_renderbuffer *srcRenderbuffer, *dstRenderbuffer;
> mesa_format srcFormat, dstFormat;
> GLenum srcIntFormat, dstIntFormat;
> +   GLuint src_w, src_h, dst_w, dst_h;
> GLuint src_bw, src_bh, dst_bw, dst_bh;
> int dstWidth, dstHeight, dstDepth;
> int i;
> @@ -445,17 +452,18 @@ _mesa_CopyImageSubData(GLuint srcName, GLenum 
> srcTarget, GLint srcLevel,
>  
> if (!prepare_target(ctx, srcName, srcTarget, srcLevel, srcZ, srcDepth,
> &srcTexImage, &srcRenderbuffer, &srcFormat,
> -   &srcIntFormat, "src"))
> +   &srcIntFormat, &src_w, &src_h, "src"))
>return;
>  
> if (!prepare_target(ctx, dstName, dstTarget, dstLevel, dstZ, srcDepth,
> &dstTexImage, &dstRenderbuffer, &dstFormat,
> -   &dstIntFormat, "dst"))
> +   &dstIntFormat, &dst_w, &dst_h, "dst"))
>return;
>  
> _mesa_get_format_block_size(srcFormat, &src_bw, &src_bh);
> if ((srcX % src_bw != 0) || (srcY % src_bh != 0) ||
> -   (srcWidth % src_bw != 0) || (srcHeight % src_bh != 0)) {
> +   (srcWidth % src_bw != 0 && (srcX + srcWidth) != src_w) ||
> +   (srcHeight % src_bh != 0 && (srcY + srcHeight) != src_h)) {
>_mesa_error(ctx, GL_INVALID_VALUE,
>"glCopyImageSubData(unaligned src rectangle)");
>return;
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [PATCH] meta/generate_mipmap: Don't leak the sampler object

2015-11-10 Thread Ian Romanick
From: Ian Romanick 

Signed-off-by: Ian Romanick 
Cc: "10.6 11.0" 
---
 src/mesa/drivers/common/meta_generate_mipmap.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/mesa/drivers/common/meta_generate_mipmap.c 
b/src/mesa/drivers/common/meta_generate_mipmap.c
index 4800278..a9da0a2 100644
--- a/src/mesa/drivers/common/meta_generate_mipmap.c
+++ b/src/mesa/drivers/common/meta_generate_mipmap.c
@@ -128,6 +128,8 @@ _mesa_meta_glsl_generate_mipmap_cleanup(struct 
gen_mipmap_state *mipmap)
mipmap->VAO = 0;
_mesa_DeleteBuffers(1, &mipmap->VBO);
mipmap->VBO = 0;
+   _mesa_DeleteSamplers(1, &mipmap->Sampler);
+   mipmap->Sampler = 0;
 
_mesa_meta_blit_shader_table_cleanup(&mipmap->shaders);
 }
-- 
2.1.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH] texgetimage: consolidate 1D array handling code.

2015-11-10 Thread Ian Romanick
Reviewed-by: Ian Romanick 

On 11/10/2015 06:34 PM, Dave Airlie wrote:
> From: Dave Airlie 
> 
> This should fix the getteximage-depth test that currently asserts.
> 
> I was hitting problem with virgl as well in this area.
> 
> This moves the 1D array handling code to a single place.
> 
> Signed-off-by: Dave Airlie 
> ---
>  src/mesa/main/texgetimage.c | 24 +---
>  1 file changed, 9 insertions(+), 15 deletions(-)
> 
> diff --git a/src/mesa/main/texgetimage.c b/src/mesa/main/texgetimage.c
> index 945890a..200d1ca 100644
> --- a/src/mesa/main/texgetimage.c
> +++ b/src/mesa/main/texgetimage.c
> @@ -88,12 +88,6 @@ get_tex_depth(struct gl_context *ctx, GLuint dimensions,
>return;
> }
>  
> -   if (texImage->TexObject->Target == GL_TEXTURE_1D_ARRAY) {
> -  depth = height;
> -  height = 1;
> -   }
> -
> -   assert(zoffset + depth <= texImage->Depth);
> for (img = 0; img < depth; img++) {
>GLubyte *srcMap;
>GLint srcRowStride;
> @@ -141,7 +135,6 @@ get_tex_depth_stencil(struct gl_context *ctx, GLuint 
> dimensions,
> assert(type == GL_UNSIGNED_INT_24_8 ||
>type == GL_FLOAT_32_UNSIGNED_INT_24_8_REV);
>  
> -   assert(zoffset + depth <= texImage->Depth);
> for (img = 0; img < depth; img++) {
>GLubyte *srcMap;
>GLint rowstride;
> @@ -233,7 +226,6 @@ get_tex_ycbcr(struct gl_context *ctx, GLuint dimensions,
>  {
> GLint img, row;
>  
> -   assert(zoffset + depth <= texImage->Depth);
> for (img = 0; img < depth; img++) {
>GLubyte *srcMap;
>GLint rowstride;
> @@ -431,13 +423,6 @@ get_tex_rgba_uncompressed(struct gl_context *ctx, GLuint 
> dimensions,
> bool needsRebase;
> void *rgba = NULL;
>  
> -   if (texImage->TexObject->Target == GL_TEXTURE_1D_ARRAY) {
> -  depth = height;
> -  height = 1;
> -  zoffset = yoffset;
> -  yoffset = 0;
> -   }
> -
> /* Depending on the base format involved we may need to apply a rebase
>  * transform (for example: if we download to a Luminance format we want
>  * G=0 and B=0).
> @@ -737,6 +722,15 @@ _mesa_GetTexSubImage_sw(struct gl_context *ctx,
>pixels = ADD_POINTERS(buf, pixels);
> }
>  
> +   if (texImage->TexObject->Target == GL_TEXTURE_1D_ARRAY) {
> +  depth = height;
> +  height = 1;
> +  zoffset = yoffset;
> +  yoffset = 0;
> +  assert(zoffset + depth <= texImage->Height);
> +   } else
> +  assert(zoffset + depth <= texImage->Depth);
> +
> if (get_tex_memcpy(ctx, xoffset, yoffset, zoffset, width, height, depth,
>format, type, pixels, texImage)) {
>/* all done */
> 

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


  1   2   3   4   5   6   7   8   9   10   >