date:20140205

I know, but do you have a better idea? If the buffer isn't evicted, we
should get the correct placement. The code also respects placement of
Prime buffers, which should be in GTT. This is as close to the ideal
solution as it can possibly be. I don't think it can be any better
with our kernel interface.

Marek

On Wed, Feb 5, 2014 at 8:37 AM, Michel Dänzer mic...@daenzer.net wrote:
 On Mit, 2014-02-05 at 00:01 +0100, Marek Olšák wrote:
 From: Marek Olšák marek.ol...@amd.com

 Better then guessing it.

 Yeah we have had this query for a long time...

 [...]

 diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
 b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
 index 2ac060b..7c59f26 100644
 --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
 +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
 @@ -201,6 +201,28 @@ static boolean radeon_bo_is_busy(struct pb_buffer *_buf,
  }
  }

 +static enum radeon_bo_domain radeon_bo_get_current_domain(struct pb_buffer 
 *_buf)
 +{
 +struct radeon_bo *bo = get_radeon_bo(_buf);
 +struct drm_radeon_gem_busy args;
 +
 +memset(args, 0, sizeof(args));
 +args.handle = bo-handle;
 +
 +drmCommandWriteRead(bo-rws-fd, DRM_RADEON_GEM_BUSY,
 +args, sizeof(args));
 +
 +/* Zero domains the driver doesn't understand. */
 +args.domain = ~(RADEON_GEM_DOMAIN_VRAM | RADEON_GEM_DOMAIN_GTT);
 +
 +/* If no domain is set, we must set something... */
 +if (!args.domain)
 +args.domain = RADEON_GEM_DOMAIN_VRAM | RADEON_GEM_DOMAIN_GTT;
 +
 +/* GEM domains and winsys domains are defined the same. */
 +return args.domain;
 +}

 The problem with this is that DRM_RADEON_GEM_BUSY doesn't say where the
 BO is supposed to be, but where it happens to be right now. E.g. it
 could return GTT for a BO that's supposed to be in VRAM but was evicted
 (or couldn't get into VRAM in the first place).


 --
 Earthling Michel Dänzer|  http://www.amd.com
 Libre software enthusiast  |Mesa and X developer

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

Re: [Mesa-dev] [PATCH 1/2] r600g, radeonsi: query the buffer domain from the kernel for DRI2 buffers

2014-02-05 Thread Michel Dänzer

On Mit, 2014-02-05 at 10:13 +0100, Christian König wrote:
 Am 05.02.2014 08:37, schrieb Michel Dänzer:
  On Mit, 2014-02-05 at 00:01 +0100, Marek Olšák wrote:
 
  diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
  b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
  index 2ac060b..7c59f26 100644
  --- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
  +++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
  @@ -201,6 +201,28 @@ static boolean radeon_bo_is_busy(struct pb_buffer 
  *_buf,
}
}

  +static enum radeon_bo_domain radeon_bo_get_current_domain(struct 
  pb_buffer *_buf)
  +{
  +struct radeon_bo *bo = get_radeon_bo(_buf);
  +struct drm_radeon_gem_busy args;
  +
  +memset(args, 0, sizeof(args));
  +args.handle = bo-handle;
  +
  +drmCommandWriteRead(bo-rws-fd, DRM_RADEON_GEM_BUSY,
  +args, sizeof(args));
  +
  +/* Zero domains the driver doesn't understand. */
  +args.domain = ~(RADEON_GEM_DOMAIN_VRAM | RADEON_GEM_DOMAIN_GTT);
  +
  +/* If no domain is set, we must set something... */
  +if (!args.domain)
  +args.domain = RADEON_GEM_DOMAIN_VRAM | RADEON_GEM_DOMAIN_GTT;
  +
  +/* GEM domains and winsys domains are defined the same. */
  +return args.domain;
  +}
  The problem with this is that DRM_RADEON_GEM_BUSY doesn't say where the
  BO is supposed to be, but where it happens to be right now. E.g. it
  could return GTT for a BO that's supposed to be in VRAM but was evicted
  (or couldn't get into VRAM in the first place).
 
 But isn't that exactly what we want here?

Not really. E.g. consider an app's DRI2 front buffer (i.e. normally the
backing pixmap of an X11 window): If the BO happens to be in GTT when
DRM_RADEON_GEM_BUSY is called from the compositor, the compositor will
force the BO to GTT every time it uses the BO for rendering. But the
app's DRI2 buffer swap (or any other accelerated rendering to the window
in the X server) will force the BO to VRAM. BO ping pong.


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

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

Re: [Mesa-dev] [PATCH 1/2] r600g, radeonsi: query the buffer domain from the kernel for DRI2 buffers

2014-02-05 Thread Christian König


Am 05.02.2014 10:57, schrieb Michel Dänzer:

On Mit, 2014-02-05 at 10:13 +0100, Christian König wrote:

Am 05.02.2014 08:37, schrieb Michel Dänzer:

On Mit, 2014-02-05 at 00:01 +0100, Marek Olšák wrote:

diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c 
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 2ac060b..7c59f26 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
@@ -201,6 +201,28 @@ static boolean radeon_bo_is_busy(struct pb_buffer *_buf,
   }
   }
   
+static enum radeon_bo_domain radeon_bo_get_current_domain(struct pb_buffer *_buf)

+{
+struct radeon_bo *bo = get_radeon_bo(_buf);
+struct drm_radeon_gem_busy args;
+
+memset(args, 0, sizeof(args));
+args.handle = bo-handle;
+
+drmCommandWriteRead(bo-rws-fd, DRM_RADEON_GEM_BUSY,
+args, sizeof(args));
+
+/* Zero domains the driver doesn't understand. */
+args.domain = ~(RADEON_GEM_DOMAIN_VRAM | RADEON_GEM_DOMAIN_GTT);
+
+/* If no domain is set, we must set something... */
+if (!args.domain)
+args.domain = RADEON_GEM_DOMAIN_VRAM | RADEON_GEM_DOMAIN_GTT;
+
+/* GEM domains and winsys domains are defined the same. */
+return args.domain;
+}

The problem with this is that DRM_RADEON_GEM_BUSY doesn't say where the
BO is supposed to be, but where it happens to be right now. E.g. it
could return GTT for a BO that's supposed to be in VRAM but was evicted
(or couldn't get into VRAM in the first place).

But isn't that exactly what we want here?

Not really. E.g. consider an app's DRI2 front buffer (i.e. normally the
backing pixmap of an X11 window): If the BO happens to be in GTT when
DRM_RADEON_GEM_BUSY is called from the compositor, the compositor will
force the BO to GTT every time it uses the BO for rendering. But the
app's DRI2 buffer swap (or any other accelerated rendering to the window
in the X server) will force the BO to VRAM. BO ping pong.


Oh, yeah that makes sense. Instead of defining where the buffer should 
be on command submission we should rather define how badly we want to 
move it around. No good idea either how to handle this without a kernel 
interface rework.


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

[Mesa-dev] [Bug 74563] New: Surfaceless contexts are not properly released by DRI drivers

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

  Priority: medium
Bug ID: 74563
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: Surfaceless contexts are not properly released by DRI
drivers
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: alexandros.frant...@canonical.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Other
   Product: Mesa

Created attachment 93443
  -- https://bugs.freedesktop.org/attachment.cgi?id=93443action=edit
Example that exhibits the issue

Releasing a surfaceless EGL context doesn't properly release the underlying DRI
context, sometimes leading to crashes. I have attached an example that exhibits
such a crash (run it in a VT).

Without a fix, the example crashes when the main thread tries to make context2
current, because mesa tries to _mesa_flush the invalid (destroyed in the other
thread) context1, left as current in the main thread by the previous make
current operation (and not cleaned by releasing the egl context).

The problem seems to be that the driUnbindContext() function doesn't call the
driver unbind function if the context is surfaceless. Moving the call to the
driver function before the drawable validity checks fixes things for me (see
attached patch), although I am not familiar enough with that code to be
confident that this is indeed the right approach.

Note the absence of _mesa_make_current() calls for context releases in the
logs:

# MESA_VERBOSE=api ./mesa_surfaceless_context_crash
T1: Make current 1
Mesa: _mesa_make_current()
T1: Release current 1
T1: after Release current 1
Main: Make current 1
Mesa: _mesa_make_current()
Main: Release current 1
Main: after Release current 1
Mesa: _mesa_make_current()
Mesa: glDeleteObjectARB(0)
Mesa: glDeleteObjectARB(0)
Mesa: glDeleteTextures 1
Mesa: _mesa_make_current()
Mesa: _mesa_make_current()
Main: Make current 2
crash

I am using latest Mesa git with the i965 driver.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 74563] Surfaceless contexts are not properly released by DRI drivers

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

Alexandros Frantzis alexandros.frant...@canonical.com changed:

   What|Removed |Added

  Attachment #93443|text/plain  |application/x-gtar
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 74563] Surfaceless contexts are not properly released by DRI drivers

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

--- Comment #1 from Alexandros Frantzis alexandros.frant...@canonical.com ---
Created attachment 93444
  -- https://bugs.freedesktop.org/attachment.cgi?id=93444action=edit
Potential fix

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/2] v4: Fix array overrun with too many uniforms

2014-02-05 Thread Petri Latvala


On 12/30/2013 11:44 AM, Petri Latvala wrote:

Fourth version of patch series.

- Fixed vec4_register_coalesce unit test. That test passes NULL for
   prog_data, which Mesa proper doesn't do.
- Renamed uniform_param_count to uniform_array_size.
- Used ALIGN() to round up when dividing buffer size by 4.
- Used MAX2() instead of taking maximum manually.


Petri Latvala (2):
   i965: Allocate vec4_visitor's uniform_size and uniform_vector_size
 arrays dynamically.
   i965: Assert array index on access to vec4_visitor's arrays.

  src/mesa/drivers/dri/i965/brw_vec4.cpp |  2 ++
  src/mesa/drivers/dri/i965/brw_vec4.h   |  5 +++--
  src/mesa/drivers/dri/i965/brw_vec4_gs.c|  5 +
  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 17 +
  src/mesa/drivers/dri/i965/brw_vs.c |  8 
  5 files changed, 35 insertions(+), 2 deletions(-)



Gentle prod and ping.

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

Re: [Mesa-dev] [PATCH] centroid affects interpolation

2014-02-05 Thread Rogovin, Kevin

Hi,

Without my patch, mesa fails to compile:

#version 300 es
centroid in mediump vec2 centr;

gives the error message error: no precision specified this scope for type 
`vec2' 

You are both correct, and I was wrong, making centroid an interpolation 
qualifier; the correct solution is to tweak the rule for type_qualifier; it 
looks like the rule for type_qualifier is the one that needs tweaking to get 
this right; 

Would you like me to do that one, or will one of you like to kill that bug?

-Kevin







From: Kenneth Graunke [kenn...@whitecape.org]
Sent: Wednesday, February 05, 2014 6:02 AM
To: Rogovin, Kevin; mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH] centroid affects interpolation

On 02/04/2014 05:01 AM, Kevin Rogovin wrote:
 Place centroid keyword as an interpolation qualifier.
 Previously was a storage qualifier. Fixes front end
 to accept input of the form centroid in type variable

No, it doesn't.  Without your patch, Mesa successfully compiles the
following shader:

#version 130
centroid in float foo;

which is of the form centroid in type variable.  Chris is right - the
specs are very clear that 'centroid in' was a storage qualifier, and if
420pack is enabled, 'centroid' becomes an auxiliary storage qualifier.

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

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

2014-02-05 Thread neobrain


Hello Marek,

Nice to hear the extension is being tackled! Took me a while to get mesa 
building again, and I did a quick test with your patches - unfortunately 
they outright crash Dolphin at the moment. I'm not quite sure if you 
have sent an updated patch series yet, so I used the one you sent on Jan 
29, applied on current git mesa (5c975966) from today.


Most importantly, our buffer streaming code uses persistent (and 
coherent) mapping in the buffer_storage code path, so maybe that's an 
issue? If you like, I can do some additional debugging, but I'm not very 
familiar with mesa debugging so I'd need some help. For what it's worth, 
I'm usually hanging around in #dri-devel under the nick neobrain.


Regards,
Tony


Am 29.01.2014 01:49, schrieb Marek Olšák:

On Wed, Jan 29, 2014 at 1:42 AM, Ian Romanick i...@freedesktop.org wrote:

On 01/28/2014 05:35 PM, Marek Olšák wrote:

Yes, GL_ARB_buffer_storage is being worked on. We'll support it on all
Radeon cards R300 and up.

Are you guys working on that?  Have an ETA? :)

It's done. I'm writing piglit tests at the moment. I'll send my
patches tomorrow.

Marek


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

[Mesa-dev] [Bug 74563] Surfaceless contexts are not properly released by DRI drivers

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

Alexandros Frantzis alexandros.frant...@canonical.com changed:

   What|Removed |Added

   Hardware|x86-64 (AMD64)  |All
 OS|Linux (All) |All

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] glsl: Change locations from yylloc to appropriate tokens positions.

---
 src/glsl/glsl_parser.yy | 215 +---
 1 file changed, 114 insertions(+), 101 deletions(-)

diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 928c57e..c6a585f 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -386,35 +386,35 @@ primary_expression:
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_identifier, NULL, NULL, NULL);
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   $$-primary_expression.identifier = $1;
}
| INTCONSTANT
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_int_constant, NULL, NULL, NULL);
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   $$-primary_expression.int_constant = $1;
}
| UINTCONSTANT
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_uint_constant, NULL, NULL, NULL);
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   $$-primary_expression.uint_constant = $1;
}
| FLOATCONSTANT
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_float_constant, NULL, NULL, NULL);
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   $$-primary_expression.float_constant = $1;
}
| BOOLCONSTANT
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_bool_constant, NULL, NULL, NULL);
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   $$-primary_expression.bool_constant = $1;
}
| '(' expression ')'
@@ -429,7 +429,7 @@ postfix_expression:
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_array_index, $1, $3, NULL);
-  $$-set_location(yylloc);
+  $$-set_location_range(@1, @4);
}
| function_call
{
@@ -439,20 +439,20 @@ postfix_expression:
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_field_selection, $1, NULL, NULL);
-  $$-set_location(yylloc);
+  $$-set_location_range(@1, @3);
   $$-primary_expression.identifier = $3;
}
| postfix_expression INC_OP
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_post_inc, $1, NULL, NULL);
-  $$-set_location(yylloc);
+  $$-set_location_range(@1, @2);
}
| postfix_expression DEC_OP
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_post_dec, $1, NULL, NULL);
-  $$-set_location(yylloc);
+  $$-set_location_range(@1, @2);
}
;
 
@@ -470,7 +470,7 @@ function_call_or_method:
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_field_selection, $1, $3, NULL);
-  $$-set_location(yylloc);
+  $$-set_location_range(@1, @3);
}
;
 
@@ -488,13 +488,13 @@ function_call_header_with_parameters:
function_call_header assignment_expression
{
   $$ = $1;
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   $$-expressions.push_tail( $2-link);
}
| function_call_header_with_parameters ',' assignment_expression
{
   $$ = $1;
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   $$-expressions.push_tail( $3-link);
}
;
@@ -511,21 +511,23 @@ function_identifier:
{
   void *ctx = state;
   $$ = new(ctx) ast_function_expression($1);
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   }
| variable_identifier
{
   void *ctx = state;
   ast_expression *callee = new(ctx) ast_expression($1);
+  callee-set_location(@1);
   $$ = new(ctx) ast_function_expression(callee);
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   }
| FIELD_SELECTION
{
   void *ctx = state;
   ast_expression *callee = new(ctx) ast_expression($1);
+  callee-set_location(@1);
   $$ = new(ctx) ast_function_expression(callee);
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   }
;
 
@@ -543,13 +545,13 @@ method_call_header_with_parameters:
method_call_header assignment_expression
{
   $$ = $1;
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   $$-expressions.push_tail( $2-link);
}
| method_call_header_with_parameters ',' assignment_expression
{
   $$ = $1;
-  $$-set_location(yylloc);
+  $$-set_location(@1);
   $$-expressions.push_tail( $3-link);
}
;
@@ -562,8 +564,9 @@ method_call_header:
{
   void *ctx = state;
   ast_expression *callee = new(ctx) ast_expression($1);
+  callee-set_location(@1);
   $$ = new(ctx) ast_function_expression(callee);
-  $$-set_location(yylloc);
+  $$-set_location(@1);
}
;
 
@@ -574,19 +577,19 @@ unary_expression:
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_pre_inc, $2, NULL, NULL);
-  $$-set_location(yylloc);
+  $$-set_location(@1);
}
| DEC_OP unary_expression
{
   void *ctx = state;
   $$ = new(ctx) ast_expression(ast_pre_dec, $2, NULL, NULL);
-  $$-set_location(yylloc);
+

[Mesa-dev] [PATCH 0/4] glsl: Precise location positions for ast_node.

These patches changes the ast_node location holding by adding tokens 
end position and assignment of it along with previously tracked start 
position. Bison rules was updated to set appropriate tokens locations 
instead of yylloc. 

Sir Anthony (4):
  glsl: Update lexers in glsl and glcpp to hande end position of token.
  glsl: Extend ast location structure to hande end token position.
  glsl: Add ast_node method to set location range.
  glsl: Change locations from yylloc to appropriate tokens positions.

 src/glsl/ast.h  |  36 +--
 src/glsl/glcpp/glcpp-lex.l  |   3 +-
 src/glsl/glsl_lexer.ll  |   3 +-
 src/glsl/glsl_parser.yy | 215 +---
 src/glsl/glsl_parser_extras.cpp |   6 +-
 5 files changed, 149 insertions(+), 114 deletions(-)

-- 
1.8.3.2

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

[Mesa-dev] [PATCH] glcpp: Do not remove spaces to preserve locations.

After preprocessing by glcpp all adjacent spaces were replaced by
single one and glsl parser received column-shifted shader source. 
It negatively affected ast location set up and produced wrong error 
messages for heavily-spaced shaders.

---
 src/glsl/glcpp/glcpp-lex.l  | 2 +-
 src/glsl/glcpp/tests/000-content-with-spaces.c  | 2 +-
 src/glsl/glcpp/tests/000-content-with-spaces.c.expected | 2 +-
 src/glsl/glcpp/tests/100-macro-with-colon.c.expected| 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index ea3b862..c0709a2 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@ -337,7 +337,7 @@ HEXADECIMAL_INTEGER 0[xX][0-9a-fA-F]+[uU]?
return OTHER;
 }
 
-{HSPACE}+ {
+{HSPACE} {
if (yyextra-space_tokens) {
return SPACE;
}
diff --git a/src/glsl/glcpp/tests/000-content-with-spaces.c 
b/src/glsl/glcpp/tests/000-content-with-spaces.c
index 696cb3a..1f2320e 100644
--- a/src/glsl/glcpp/tests/000-content-with-spaces.c
+++ b/src/glsl/glcpp/tests/000-content-with-spaces.c
@@ -1 +1 @@
-this is  four  tokens
+   this is  four   tokens  with spaces
diff --git a/src/glsl/glcpp/tests/000-content-with-spaces.c.expected 
b/src/glsl/glcpp/tests/000-content-with-spaces.c.expected
index 83f7834..5e17ec9 100644
--- a/src/glsl/glcpp/tests/000-content-with-spaces.c.expected
+++ b/src/glsl/glcpp/tests/000-content-with-spaces.c.expected
@@ -1,2 +1,2 @@
-this is four tokens
+   this is  four  tokens  with spaces
 
diff --git a/src/glsl/glcpp/tests/100-macro-with-colon.c.expected 
b/src/glsl/glcpp/tests/100-macro-with-colon.c.expected
index 6cfac25..36f98aa 100644
--- a/src/glsl/glcpp/tests/100-macro-with-colon.c.expected
+++ b/src/glsl/glcpp/tests/100-macro-with-colon.c.expected
@@ -2,7 +2,7 @@
 
 
 switch (1) {
- case 1 + 2:
- break;
+   case 1 + 2:
+  break;
 }
 
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 1/4] glsl: Update lexers in glsl and glcpp to hande end position of token.

---
 src/glsl/glcpp/glcpp-lex.l | 3 ++-
 src/glsl/glsl_lexer.ll | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/glsl/glcpp/glcpp-lex.l b/src/glsl/glcpp/glcpp-lex.l
index c0709a2..188e454 100644
--- a/src/glsl/glcpp/glcpp-lex.l
+++ b/src/glsl/glcpp/glcpp-lex.l
@@ -47,8 +47,9 @@ void glcpp_set_column (int  column_no , yyscan_t yyscanner);
if (parser-has_new_source_number)  \
yylloc-source = parser-new_source_number; \
yylloc-first_column = yycolumn + 1;\
-   yylloc-first_line = yylineno;  \
+   yylloc-first_line = yylloc-last_line = yylineno;  \
yycolumn += yyleng; \
+   yylloc-last_column = yycolumn + 1; \
parser-has_new_line_number = 0;\
parser-has_new_source_number = 0;  \
  } while(0);
diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
index 50875bf..e7766a8 100644
--- a/src/glsl/glsl_lexer.ll
+++ b/src/glsl/glsl_lexer.ll
@@ -38,8 +38,9 @@ static int classify_identifier(struct _mesa_glsl_parse_state 
*, const char *);
do {\
   yylloc-source = 0;  \
   yylloc-first_column = yycolumn + 1; \
-  yylloc-first_line = yylineno + 1;   \
+  yylloc-first_line = yylloc-last_line = yylineno + 1;   \
   yycolumn += yyleng;  \
+  yylloc-last_column = yycolumn + 1;  \
} while(0);
 
 #define YY_USER_INIT yylineno = 0; yycolumn = 0;
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 3/4] glsl: Add ast_node method to set location range.

---
 src/glsl/ast.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index a9352f9..8e54ddc 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -98,6 +98,20 @@ public:
}
 
/**
+* Set the source location range of an AST node using two location nodes
+*
+* \sa ast_node::set_location
+*/
+   void set_location_range(const struct YYLTYPE begin, const struct YYLTYPE 
end)
+   {
+  this-location.source = begin.source;
+  this-location.first_line = begin.first_line;
+  this-location.last_line = end.last_line;
+  this-location.first_column = begin.first_column;
+  this-location.last_column = end.last_column;
+   }
+
+   /**
 * Source location of the AST node.
 */
struct {
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 2/4] glsl: Extend ast location structure to hande end token position.

---
 src/glsl/ast.h  | 22 +-
 src/glsl/glsl_parser_extras.cpp |  6 --
 2 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 2d6f3a2..a9352f9 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -75,10 +75,10 @@ public:
   struct YYLTYPE locp;
 
   locp.source = this-location.source;
-  locp.first_line = this-location.line;
-  locp.first_column = this-location.column;
-  locp.last_line = locp.first_line;
-  locp.last_column = locp.first_column;
+  locp.first_line = this-location.first_line;
+  locp.first_column = this-location.first_column;
+  locp.last_line = this-location.last_line;
+  locp.last_column = this-location.last_column;
 
   return locp;
}
@@ -91,17 +91,21 @@ public:
void set_location(const struct YYLTYPE locp)
{
   this-location.source = locp.source;
-  this-location.line = locp.first_line;
-  this-location.column = locp.first_column;
+  this-location.first_line = locp.first_line;
+  this-location.first_column = locp.first_column;
+  this-location.last_line = locp.last_line;
+  this-location.last_column = locp.last_column;
}
 
/**
 * Source location of the AST node.
 */
struct {
-  unsigned source;/** GLSL source number. */
-  unsigned line;  /** Line number within the source string. */
-  unsigned column;/** Column in the line. */
+  unsigned source;  /** GLSL source number. */
+  unsigned first_line;  /** Line number within the source string. */
+  unsigned first_column;/** Column in the line. */
+  unsigned last_line;   /** Line number within the source string. */
+  unsigned last_column; /** Column in the line. */
} location;
 
exec_node link;
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 87784ed..7dfae8d 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -788,8 +788,10 @@ ast_node::print(void) const
 ast_node::ast_node(void)
 {
this-location.source = 0;
-   this-location.line = 0;
-   this-location.column = 0;
+   this-location.first_line = 0;
+   this-location.first_column = 0;
+   this-location.last_line = 0;
+   this-location.last_column = 0;
 }
 
 
-- 
1.8.3.2

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

Re: [Mesa-dev] [PATCH RFC 07/11] glsl: add SSA infrastructure

2014-02-05 Thread Connor Abbott

On Tue, Jan 28, 2014 at 2:45 PM, Paul Berry stereotype...@gmail.com wrote:

 On 22 January 2014 09:16, Connor Abbott cwabbo...@gmail.com wrote:

 diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
 index cb732a5..7075579 100644
 --- a/src/glsl/ir_clone.cpp
 +++ b/src/glsl/ir_clone.cpp
 @@ -40,7 +40,15 @@ ir_rvalue::clone(void *mem_ctx, struct hash_table *ht)
 const
  ir_variable *
  ir_variable::clone(void *mem_ctx, struct hash_table *ht) const
  {
 -   ir_variable *var = new(mem_ctx) ir_variable(this-type, this-name,
 +   ir_variable *var;
 +
 +   if (ht) {
 +  var = (ir_variable *)hash_table_find(ht, this);
 +  if (var)
 +return var;
 +   }


 Can you add a comment explaining why it's necessary to do a hashtable
 lookup now?  (I'm guessing it's because a phi node can refer to an SSA
 temporary that occurs later in the instruction stream, and therefore when
 we go to clone an SSA temporary variable, it's possible that we've already
 cloned it, but I'm not 100% certain about that).


Yeah, that's right. Phi nodes at the beginning of loops must be able to
refer to SSA temporaries created during the loop, which means that
variables may be referenced by ir_phi_loop_begin before they are defined.
So, if we clone an ir_phi_loop_begin object, and therefore clone a variable
that it references that's defined inside the loop, we need to make sure
that we use the same variable when we clone it's definition.




 +
 +   var = new(mem_ctx) ir_variable(this-type, this-name,
(ir_variable_mode)
 this-data.mode);


 Let's fix up this line to align the opening paren with the initial t in
 this-type.


 +
 +ir_phi *
 +ir_phi::clone(void *mem_ctx, struct hash_table *ht) const
 +{
 +   /* shouldn't get here */
 +   assert(0);
 +   return new(mem_ctx) ir_phi();
 +}


 There's no need to implement this function.  If we leave it out (and leave
 out the corresponding declaration of clone() in ir.h's declaration of the
 ir_phi class), then ir_phi will be an abstract base class, and the compiler
 will make sure we never instantiate it.


 +static ir_phi_jump_src *
 +clone_phi_jump_src(ir_phi_jump_src *src, void *mem_ctx, struct
 hash_table *ht)
 +{
 +   ir_phi_jump_src *new_src = new(mem_ctx) ir_phi_jump_src();
 +   new_src-src = src-src-clone(mem_ctx, ht);
 +   new_src-jump = src-jump-clone(mem_ctx, ht);
 +   return new_src;


 Let's make a constructor for ir_phi_jump_src that takes src and jump as
 arguments, so that we can just do:

return new(mem_ctx) ir_phi_jump_src(src-src-clone(mem_ctx, ht),
src-jump-clone(mem_ctx, ht));

 +
 +
 +void
 +ir_print_visitor::visit(ir_phi *ir)
 +{
 +   printf(error);
 +}


 I think if we make ir_phi an abstract base class (like I suggested
 earlier) we can drop this function entirely, as well as all the other
 visit(class ir_phi *) functions introduced in this patch.


 +
 +
 +void
 +ir_print_visitor::visit(ir_phi_if *ir)
 +{
 +   printf((phi\n);


 For consistency with the class names, I'd prefer for this to be:

printf((phi_if\n);


 +
 +   indentation++;
 +   indent();
 +   ir-dest-accept(this);
 +   printf(\n);
 +
 +   indent();
 +   if (ir-if_src) {
 +  printf(%s , unique_name(ir-if_src));
 +   } else {
 +  printf((undefined) );
 +   }
 +   if (ir-else_src) {
 +  printf(%s), unique_name(ir-else_src));
 +   } else {
 +  printf((undefined)));
 +   }


 Would it be worth modifying unique_name() so that it returns (undefined)
 if it's passed a null pointer?  That would allow us to simplify the 10
 lines above to:

printf(%s %s, unique_name(ir-if_src), unique_name(ir-else_src));

 As well as similar simplifications in the functions below.


 +   indentation--;
 +}
 +
 +void
 +ir_print_visitor::print_phi_jump_src(ir_phi_jump_src *src)
 +{
 +   printf((%s , unique_name(src-jump));


 I think this is going to make the output IR difficult to follow, since it
 won't be obvious that (break@1 ...) represents a phi node rather than a
 break instruction.  I'd recommend changing this to:

printf((phi_jump_src %s , unique_name(src-jump));


 +   if (src-src) {
 +  printf( %s)\n, unique_name(src-src));
 +   } else {
 +  printf( (undefined))\n);
 +   }
 +}
 +
 +void
 +ir_print_visitor::visit(ir_phi_loop_begin *ir)
 +{
 +   printf((phi\n);


 As with ir_phi_if, I'd recommend changing this to:

printf((phi_loop_begin\n);

 A similar comment applies to ir_print_visitor::visit(ir_phi_loop_end *).


 +
 +   indentation++;
 +   indent();
 +   ir-dest-accept(this);
 +   printf(\n);
 +
 +   indent();
 +   if (ir-enter_src) {
 +  printf(%s , unique_name(ir-enter_src));
 +   } else {
 +  printf((undefined) );
 +   }
 +   if (ir-repeat_src) {
 +  printf(%s\n, unique_name(ir-repeat_src));
 +   } else {
 +  printf((undefined)\n);
 +   }
 +
 +   foreach_list(n, ir-continue_srcs) {
 +  ir_phi_jump_src *src = (ir_phi_jump_src *) n;
 +  indent();

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

I honestly hope that GL_AMD_pinned_memory doesn't become popular. It would have 
been alright if it wasn't for this bit in 
http://www.opengl.org/registry/specs/AMD/pinned_memory.txt which says:

2) Can the application still use the buffer using the CPU address?

RESOLVED: YES. However, this access would be completely
non synchronized to the OpenGL pipeline, unless explicit
synchronization is being used (for example, through glFinish or by using
sync objects).

And I'm imagining apps which are streaming vertex data doing precisely just 
that...

This means that, in order to obtain traces of applications that use 
AMD_pinned_memory like that with Apitrace, we'll need to use heuristics to 
determine when applications touch the memory behind the scenes and emit fake 
memcpies, which means slow tracing and/or bloated trace files... Just like user 
memory pointer arrays...  :(

Instead of that uglyness, maybe Apitrace should just mask out 
GL_AMD_pinned_memory support, so that I don't have to worry about it, and let 
apps and OpenGL drivers support/use it at their own peril.

Jose


- Original Message -
 Yes, GL_ARB_buffer_storage is being worked on. We'll support it on all
 Radeon cards R300 and up.
 
 Anyway, GL_STREAM_DRAW should give you the same behavior as
 GL_CLIENT_STORAGE_BIT on open source Radeon drivers.
 
 Marek
 
 On Sun, Nov 24, 2013 at 1:19 PM, Tony Wasserka neobra...@googlemail.com
 wrote:
  Hello everyone,
  I was told on IRC that my question would get most attention around here -
  so
  bear with me if this is the wrong place to ask
 
  I'm one of the developers of the GC/Wii emulator Dolphin. We recently
  rewrote our OpenGL renderer to use modern OpenGL 3 features, however one
  thing that we stumbled upon are the lack of efficient (vertex/index) buffer
  data streaming mechanisms in OpenGL. Basically, most of our vertex data is
  used once and never again after that (we have to do this for accurate
  emulation) - so all vertex data gets streamed into one huge ring buffer
  (and
  analogously for index data, which uses its own huge ring buffer). For
  buffer
  streaming, we have multiple code paths using a combination of
  glMapBufferRange, glBufferSubData, fences and buffer orphaning, yet none of
  these come anywhere close to the performance of (legacy) rendering from a
  vertex array stored in RAM.
 
  There are two OpenGL extensions which greatly help us in this situation:
  AMD's pinned memory [1], and buffer storage[2] in GL 4.4. We currently have
  no buffer storage code path, but usage of pinned memory gave us a speedup
  of
  up to 60% under heavy workloads when working with AMD's Catalyst driver
  under Windows. We expect the same speedup when using buffer storage
  (specifically we need CLIENT_STORAGE_BIT, if I recall correctly).
 
  So the natural question that arises is: Is either of these two extensions
  going to be supported in mesa anytime soon or is it of lower priority than
  other extensions? Also, is the pinned memory extension AMD hardware
  specific
  or would it be possible to support it for other hardware, too? I'm not sure
  if buffer storage (being a GL 4.4 extension, and I read that it might
  actually depend on some other GL 4.3 extension) is possible to implement on
  older hardware, yet it would be very useful for us to have efficient
  streaming methods for old GPUs, too.
 
  I hope this mail doesn't sound too commanding or anything, it's just
  supposed to be a friendly question on improving the emulator experience for
  our user base
  Thanks in advance!
 
  Best regards,
  Tony
 
  [1]
  https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_memory.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=cv4fRRLbo4swWVoK5KeixmMKacksWBLX%2Bi4XDCp0aDI%3D%0As=ede103da8bd227ae11f6ab3a4a6d6b0c673860dc15b6814055302759bf4ef355
  [2]
  https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/ARB/buffer_storage.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=cv4fRRLbo4swWVoK5KeixmMKacksWBLX%2Bi4XDCp0aDI%3D%0As=7ceb1af3a41882ca6ba4e13bf3df2c8a59b08441835b05174e93968ef8f580f2
 
  ___
  mesa-dev mailing list
  mesa-dev@lists.freedesktop.org
  https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=cv4fRRLbo4swWVoK5KeixmMKacksWBLX%2Bi4XDCp0aDI%3D%0As=5d44af52ecd36e285eff028b59a928ba327a33c57498a7e5d0a3f8e5e12070a9
 ___
 mesa-dev mailing list
 mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [PATCH 30/30] i965/cs: Allow ARB_compute_shader to be enabled via env var.

2014-02-05 Thread Paul Berry

On 4 February 2014 10:03, Jordan Justen jljus...@gmail.com wrote:

 
  What about trying to make use of
  MESA_EXTENSION_OVERRIDE=GL_ARB_compute_shader?
 
  We could add
  extensions.c:bool _mesa_is_extension_override_enabled(char *)
 
  And then
  if (_mesa_is_extension_override_enabled(GL_ARB_compute_shader))
 
  Or, similarly, get overrides shoved into ctx-Extensions to allow
  checking for overrides at this early stage.
 
  -Jordan
 
 
  I looked into what would be necessary to do this, and it's unfortunately
  more complicated than it should be due to some flukes about
 initialization
  order (perhaps this is what you were alluding to when you said get
  overrides shoved into ctx-Extensions to allow checking for overrides at
  this early stage).

 Yeah, I'll admit I looked at it a bit, and decided to keep my feedback
 'hand wavy'. :)

   Currently, our initialization order is:
 
  1. brwCreateContext() calls brw_initialize_context_constants(), which
 needs
  to know whether compute shaders are supported in order to set constants
 like
  MAX_COMPUTE_TEXTURE_IMAGE_UNITS and MAX_UNIFORM_BUFFER_BINDINGS
 correctly.
 
  2. Later, brwCreateContext() calls intelInitExtensions(), which is the
  function where we'll set ctx-Extensions.ARB_compute_shader to true once
  compute shaders are fully supported.
 
  3. Much later in initialization, when the context is being made current
 for
  the first time, core Mesa calls _mesa_make_extension_string(), which
 calls
  get_extension_override() to modify the the ctx-Extensions table based on
  the environment variable override.
 
  To do what you suggested, I would either have to:
 
  A. change 1 to call _mesa_is_extension_override_enabled(); that
 function, in
  turn, would have to parse the MESA_EXTENSION_OVERRIDE string, but we
  couldn't reuse the parsing code in _mesa_make_extension_string(), since
 that
  parsing code updates ctx-Extensions as a side effect, and it's not time
 to
  update ctx-Extensions yet.  In addition to the code duplication, we
 would
  have a danger of bugs, since the override takes effect so late in
  initialization--if we ever accidentally introduced some code in between
  steps 2 and 3 that checked the value of
 ctx-Extensions.ARB_compute_shader,
  it would see false even if compute shaders were enabled by override.
 
  Or:
 
  B. change the order of initialization so that 2 happens first, followed
 by 3
  and then 1.  In the long run I think this would be a good thing, but
 it's a
  big change (since it affects all back ends) and I'm not sure it would be
 a
  good idea to hold up this patch series waiting for it.
 
 
  How would you feel if I landed the patch series as is, and then worked
 on a
  follow up patch to do B?

 Sure, you can have my r-b for this then.

 -Jordan


Great, thanks.  I've pushed the patches.  I'll work on B as soon as I can.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH RFC 07/11] glsl: add SSA infrastructure

2014-02-05 Thread Connor Abbott

On Tue, Jan 28, 2014 at 1:50 PM, Paul Berry stereotype...@gmail.com wrote:

 On 22 January 2014 09:16, Connor Abbott cwabbo...@gmail.com wrote:

 This patch introduces all the changes to the IR that are necessary for
 representing programs in the SSA form. This consists of a new variable
 mode, the SSA temporary, which is guarenteed to be written to exactly
 once, and classes to represent phi nodes in the IR.

 In the current code, variables are first declared using an ir_variable
 instruction inserted into the instruction stream, and then every
 dereference will point to the ir_variable declared earlier. SSA
 temporaries, however, do not work this way. Instead, the variable
 is declared when it is assigned. That is, the variable is owned by
 the one and only instruction where it is defined.

 In SSA, phi nodes may exist at the beginning of any join nodes, or
 basic blocks with more than one predecessor. In our IR, this can happen
 in one of three places:

 - After an if statement, where the then branch and the else branch
 converge.
 - At the beginning of a loop, which can be reached from either before
 the loop (on the first iteration), the end of the loop (when we get to
 the end of the loop and jump back to the beginning), or any continue
 statement.
 - At the end of a loop, which can be reached from any break statement
 within the loop.

 Accordingly, there are three different types of phi nodes: if phi nodes,
 phi nodes at the beginning of a loop, and phi nodes at the end of a
 loop, all of which derive from the ir_phi base class.
 ---
  src/glsl/ir.cpp|  56 +++
  src/glsl/ir.h  | 196
 -
  src/glsl/ir_clone.cpp  | 147 ---
  src/glsl/ir_hierarchical_visitor.cpp   |  36 +
  src/glsl/ir_hierarchical_visitor.h |  11 ++
  src/glsl/ir_hv_accept.cpp  |  55 ++-
  src/glsl/ir_print_visitor.cpp  | 196
 -
  src/glsl/ir_print_visitor.h|  15 ++
  src/glsl/ir_validate.cpp   | 158 +++-
  src/glsl/ir_visitor.h  |   8 +
  src/mesa/drivers/dri/i965/brw_fs.h |   4 +
  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp   |  28 
  src/mesa/drivers/dri/i965/brw_vec4.h   |   4 +
  src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |  24 +++
  src/mesa/program/ir_to_mesa.cpp|  28 
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp |  29 
  16 files changed, 956 insertions(+), 39 deletions(-)

 diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
 index 1a36bd6..f1ded80 100644
 --- a/src/glsl/ir.cpp
 +++ b/src/glsl/ir.cpp
 @@ -1229,6 +1229,37 @@ ir_loop::ir_loop()
  }


 +ir_phi::ir_phi()
 +{
 +   this-dest = NULL;
 +}


 Rather than have a no-argument constructor for ir_phi that sets this-dest
 to NULL, and then have the derived classes set dest to the appropriate
 value, let's just do:

 ir_phi::ir_phi(ir_variable *dest)
: dest(dest)
 {
 }

 Then in the derived classes we can just pass dest on through, e.g.:

 ir_phi_if::ir_phi_if(ir_variable *dest, ir_variable *if_src,
  ir_variable *else_src)
: ir_phi(dest), if_src(if_src), else_src(else_src)
 {
this-ir_type = ir_type_phi_if;
 }



 +
 +
 +ir_phi_if::ir_phi_if(ir_variable *dest, ir_variable *if_src,
 +ir_variable *else_src)
 +   : if_src(if_src), else_src(else_src)
 +{
 +   this-ir_type = ir_type_phi_if;
 +   this-dest = dest;
 +}
 +
 +
 +ir_phi_loop_begin::ir_phi_loop_begin(ir_variable* dest, ir_variable*
 enter_src,
 +ir_variable* repeat_src)
 +   : enter_src(enter_src), repeat_src(repeat_src)
 +{
 +   this-ir_type = ir_type_phi_loop_begin;
 +   this-dest = dest;
 +}
 +
 +
 +ir_phi_loop_end::ir_phi_loop_end(ir_variable *dest)
 +{
 +   this-ir_type = ir_type_phi_loop_end;
 +   this-dest = dest;
 +}
 +
 +
  ir_dereference_variable::ir_dereference_variable(ir_variable *var)
  {
 assert(var != NULL);
 @@ -1554,6 +1585,9 @@ ir_variable::ir_variable(const struct glsl_type
 *type, const char *name,
 this-data.max_array_access = 0;
 this-data.atomic.buffer_index = 0;
 this-data.atomic.offset = 0;
 +   this-ssa_assignment = NULL;
 +   this-ssa_phi = NULL;
 +   this-ssa_call = NULL;

 if (type != NULL) {
if (type-base_type == GLSL_TYPE_SAMPLER)
 @@ -1722,12 +1756,19 @@ steal_memory(ir_instruction *ir, void *new_ctx)
  {
 ir_variable *var = ir-as_variable();
 ir_constant *constant = ir-as_constant();
 +   ir_dereference_variable *deref = ir-as_dereference_variable();
 +   ir_phi *phi = ir-as_phi();
 +   ir_phi_loop_begin *phi_loop_begin = ir-as_phi_loop_begin();
 +   ir_phi_loop_end *phi_loop_end = ir-as_phi_loop_end();
 if (var != NULL  var-constant_value != NULL)
steal_memory(var-constant_value, ir);

 if (var != NULL

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

2014-02-05 Thread Grigori Goronzy


On 05.02.2014 18:08, Jose Fonseca wrote:

I honestly hope that GL_AMD_pinned_memory doesn't become popular. It would have 
been alright if it wasn't for this bit in 
http://www.opengl.org/registry/specs/AMD/pinned_memory.txt which says:

 2) Can the application still use the buffer using the CPU address?

 RESOLVED: YES. However, this access would be completely
 non synchronized to the OpenGL pipeline, unless explicit
 synchronization is being used (for example, through glFinish or by 
using
 sync objects).

And I'm imagining apps which are streaming vertex data doing precisely just 
that...



I don't understand your concern, this is exactly the same behavior 
GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that 
properly. How does apitrace handle it?


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

[Mesa-dev] [Bug 65534] Piglit glx_glx-multithread-shader-compile randomly aborts or core dumps

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

--- Comment #3 from Eric Anholt e...@anholt.net ---
*** Bug 66948 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] gallivm: make sure analysis works with large number of immediates

Let's update LP_MAX_TGSI_IMMEDIATES and use it instead of 4096.

Otherwise looks good.


Jose

- Original Message -
 We need to handle a lot more immediates and in order to do that
 we also switch from allocating this structure on the stack to
 allocating it on the heap.
 
 Signed-off-by: Zack Rusin za...@vmware.com
 ---
  src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c | 17 +
  1 file changed, 9 insertions(+), 8 deletions(-)
 
 diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 index 184790b..ce0598d 100644
 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 @@ -47,7 +47,7 @@ struct analysis_context
 struct lp_tgsi_info *info;
  
 unsigned num_imms;
 -   float imm[128][4];
 +   float imm[4096][4];
  
 struct lp_tgsi_channel_info temp[32][4];
  };
 @@ -487,7 +487,7 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
 struct lp_tgsi_info *info)
  {
 struct tgsi_parse_context parse;
 -   struct analysis_context ctx;
 +   struct analysis_context *ctx;
 unsigned index;
 unsigned chan;
  
 @@ -495,8 +495,8 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
  
 tgsi_scan_shader(tokens, info-base);
  
 -   memset(ctx, 0, sizeof ctx);
 -   ctx.info = info;
 +   ctx = CALLOC(1, sizeof(struct analysis_context));
 +   ctx-info = info;
  
 tgsi_parse_init(parse, tokens);
  
 @@ -518,7 +518,7 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
 goto finished;
  }
  
 -analyse_instruction(ctx, inst);
 +analyse_instruction(ctx, inst);
   }
   break;
  
 @@ -527,16 +527,16 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
  const unsigned size =
parse.FullToken.FullImmediate.Immediate.NrTokens - 1;
  assert(size = 4);
 -if (ctx.num_imms  Elements(ctx.imm)) {
 +if (ctx-num_imms  Elements(ctx-imm)) {
 for (chan = 0; chan  size; ++chan) {
float value = parse.FullToken.FullImmediate.u[chan].Float;
 -  ctx.imm[ctx.num_imms][chan] = value;
 +  ctx-imm[ctx-num_imms][chan] = value;
  
if (value  0.0f || value  1.0f) {
   info-unclamped_immediates = TRUE;
}
 }
 -   ++ctx.num_imms;
 +   ++ctx-num_imms;
  }
   }
   break;
 @@ -551,6 +551,7 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
  finished:
  
 tgsi_parse_free(parse);
 +   FREE(ctx);
  
  
 /*
 --
 1.8.3.2
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

2014-02-05 Thread Patrick Baggett

My understanding is that this is like having MAP_UNSYNCHRONIZED on at all
times, even when it isn't mapped, because it is always mapped (into
memory). Is that correct Jose?

Patrick


On Wed, Feb 5, 2014 at 11:53 AM, Grigori Goronzy g...@chown.ath.cx wrote:

 On 05.02.2014 18:08, Jose Fonseca wrote:

 I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
 would have been alright if it wasn't for this bit in
 http://www.opengl.org/registry/specs/AMD/pinned_memory.txt which says:

  2) Can the application still use the buffer using the CPU address?

  RESOLVED: YES. However, this access would be completely
  non synchronized to the OpenGL pipeline, unless explicit
  synchronization is being used (for example, through glFinish or
 by using
  sync objects).

 And I'm imagining apps which are streaming vertex data doing precisely
 just that...


 I don't understand your concern, this is exactly the same behavior
 GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that properly.
 How does apitrace handle it?

 Grigori

 ___
 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] [Bug 65534] Piglit glx_glx-multithread-shader-compile randomly aborts or core dumps

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

Eric Anholt e...@anholt.net changed:

   What|Removed |Added

   Assignee|i...@freedesktop.org |mesa-dev@lists.freedesktop.
   ||org
Summary|[HSW]Piglit |Piglit
   |glx_glx-multithread-shader- |glx_glx-multithread-shader-
   |compile randomly core   |compile randomly aborts or
   |dumped on 9.1 branch|core dumps
  Component|Drivers/DRI/i965|Mesa core

--- Comment #2 from Eric Anholt e...@anholt.net ---
Renaming the bug so it can be the dupe target of the other QA report about the
test case.  There is general memory corruption due to lack of locking, which
manifests in various ways including aborts and core dumps.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions



- Original Message -
 On 05.02.2014 18:08, Jose Fonseca wrote:
  I honestly hope that GL_AMD_pinned_memory doesn't become popular. It would
  have been alright if it wasn't for this bit in
  https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_memory.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=pA%2FnK9X3xx0wAlMUZ24PfQ1mW6wAMdTUujz%2Bx7LRwCA%3D%0As=ebbe1f51deb46c81578b3c125b16e31b5f4b28c1d47e283bc9ef588e2707024d
  which says:
 
   2) Can the application still use the buffer using the CPU address?
 
   RESOLVED: YES. However, this access would be completely
   non synchronized to the OpenGL pipeline, unless explicit
   synchronization is being used (for example, through glFinish or by
   using
   sync objects).
 
  And I'm imagining apps which are streaming vertex data doing precisely just
  that...
 
 
 I don't understand your concern, this is exactly the same behavior
 GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that
 properly. How does apitrace handle it?

GL_AMD_pinned_memory it's nothing like GL_ARB_map_buffer_range's 
GL_MAP_UNSYCHRONIZED_BIT:

- When an app touches memory returned by 
glMapBufferRange(GL_MAP_UNSYCHRONIZED_BIT) it will communicate back to the 
OpenGL driver which bytes it actually touched via the glFlushMappedBufferRange 
(unless the apps doesn't care about performance and doesn't call 
glFlushMappedBufferRange at all, which is silly as it will force the OpenGL 
driver to assumed the whole range changed)

  In this case, the OpenGL driver (hence apitrace) should get all the 
information it needs about which bytes were updated betwen glMap/glUnmap.

- When an app touches memory bound via GL_AMD_pinned_memory outside 
glMap/glUnmap, there are be _no_ hints whatsever.  The OpenGL driver might not 
care as the memory is shared between CPU and GPU, so all is good as far is it 
is concerned, but all the changes the app does are invisible at an API level, 
hence apitrace will not be able to catch them unless it does onerous heuristics.


So while both extensions allow unsynchronized access, but lack of 
synchronization is not my concern. My concern is that GL_AMD_pinned_memory 
allows *hidden* access to GPU memory. 


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

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

Yes, precisely.

Jose

- Original Message -
 My understanding is that this is like having MAP_UNSYNCHRONIZED on at all
 times, even when it isn't mapped, because it is always mapped (into
 memory). Is that correct Jose?
 
 Patrick
 
 
 On Wed, Feb 5, 2014 at 11:53 AM, Grigori Goronzy g...@chown.ath.cx wrote:
 
  On 05.02.2014 18:08, Jose Fonseca wrote:
 
  I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
  would have been alright if it wasn't for this bit in
  https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_memory.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=vU0qdyo0bT3OlrdDiNzEDE1rwoALRno8drdsy3dobcI%3D%0As=0068372b93924b1324d4b77b80c5deec67683c1a59a9b2e91255c5a041603274
  which says:
 
   2) Can the application still use the buffer using the CPU address?
 
   RESOLVED: YES. However, this access would be completely
   non synchronized to the OpenGL pipeline, unless explicit
   synchronization is being used (for example, through glFinish or
  by using
   sync objects).
 
  And I'm imagining apps which are streaming vertex data doing precisely
  just that...
 
 
  I don't understand your concern, this is exactly the same behavior
  GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that properly.
  How does apitrace handle it?
 
  Grigori
 
  ___
  mesa-dev mailing list
  mesa-dev@lists.freedesktop.org
  https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=vU0qdyo0bT3OlrdDiNzEDE1rwoALRno8drdsy3dobcI%3D%0As=5f37c510dc241c96f7f1918728b86768c5ad61c70a9281e5b46a460197cec9ee
 
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] gallivm: make sure analysis works with large number of immediates

I don't think that will actually work as then the new code will never
get used and we will always have a huge static array.
There doesn't seem to be an explicit limit for immediates we could use -
there's one in patch 3/3 but that's only a ureg limit. Maybe need a new
limit somewhere.

Roland


Am 05.02.2014 19:00, schrieb Jose Fonseca:
 Let's update LP_MAX_TGSI_IMMEDIATES and use it instead of 4096.
 
 Otherwise looks good.
 
 
 Jose
 
 - Original Message -
 We need to handle a lot more immediates and in order to do that
 we also switch from allocating this structure on the stack to
 allocating it on the heap.

 Signed-off-by: Zack Rusin za...@vmware.com
 ---
  src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c | 17 +
  1 file changed, 9 insertions(+), 8 deletions(-)

 diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 index 184790b..ce0598d 100644
 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 @@ -47,7 +47,7 @@ struct analysis_context
 struct lp_tgsi_info *info;
  
 unsigned num_imms;
 -   float imm[128][4];
 +   float imm[4096][4];
  
 struct lp_tgsi_channel_info temp[32][4];
  };
 @@ -487,7 +487,7 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
 struct lp_tgsi_info *info)
  {
 struct tgsi_parse_context parse;
 -   struct analysis_context ctx;
 +   struct analysis_context *ctx;
 unsigned index;
 unsigned chan;
  
 @@ -495,8 +495,8 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
  
 tgsi_scan_shader(tokens, info-base);
  
 -   memset(ctx, 0, sizeof ctx);
 -   ctx.info = info;
 +   ctx = CALLOC(1, sizeof(struct analysis_context));
 +   ctx-info = info;
  
 tgsi_parse_init(parse, tokens);
  
 @@ -518,7 +518,7 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
 goto finished;
  }
  
 -analyse_instruction(ctx, inst);
 +analyse_instruction(ctx, inst);
   }
   break;
  
 @@ -527,16 +527,16 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
  const unsigned size =
parse.FullToken.FullImmediate.Immediate.NrTokens - 1;
  assert(size = 4);
 -if (ctx.num_imms  Elements(ctx.imm)) {
 +if (ctx-num_imms  Elements(ctx-imm)) {
 for (chan = 0; chan  size; ++chan) {
float value = parse.FullToken.FullImmediate.u[chan].Float;
 -  ctx.imm[ctx.num_imms][chan] = value;
 +  ctx-imm[ctx-num_imms][chan] = value;
  
if (value  0.0f || value  1.0f) {
   info-unclamped_immediates = TRUE;
}
 }
 -   ++ctx.num_imms;
 +   ++ctx-num_imms;
  }
   }
   break;
 @@ -551,6 +551,7 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
  finished:
  
 tgsi_parse_free(parse);
 +   FREE(ctx);
  
  
 /*
 --
 1.8.3.2

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

Re: [Mesa-dev] [PATCH 2/3] gallivm: make sure analysis works with large number of immediates

Sorry just saw your other answers so you can forget this.

Roland

Am 05.02.2014 19:19, schrieb Roland Scheidegger:
 I don't think that will actually work as then the new code will never
 get used and we will always have a huge static array.
 There doesn't seem to be an explicit limit for immediates we could use -
 there's one in patch 3/3 but that's only a ureg limit. Maybe need a new
 limit somewhere.
 
 Roland
 
 
 Am 05.02.2014 19:00, schrieb Jose Fonseca:
 Let's update LP_MAX_TGSI_IMMEDIATES and use it instead of 4096.

 Otherwise looks good.


 Jose

 - Original Message -
 We need to handle a lot more immediates and in order to do that
 we also switch from allocating this structure on the stack to
 allocating it on the heap.

 Signed-off-by: Zack Rusin za...@vmware.com
 ---
  src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c | 17 +
  1 file changed, 9 insertions(+), 8 deletions(-)

 diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 index 184790b..ce0598d 100644
 --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_info.c
 @@ -47,7 +47,7 @@ struct analysis_context
 struct lp_tgsi_info *info;
  
 unsigned num_imms;
 -   float imm[128][4];
 +   float imm[4096][4];
  
 struct lp_tgsi_channel_info temp[32][4];
  };
 @@ -487,7 +487,7 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
 struct lp_tgsi_info *info)
  {
 struct tgsi_parse_context parse;
 -   struct analysis_context ctx;
 +   struct analysis_context *ctx;
 unsigned index;
 unsigned chan;
  
 @@ -495,8 +495,8 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
  
 tgsi_scan_shader(tokens, info-base);
  
 -   memset(ctx, 0, sizeof ctx);
 -   ctx.info = info;
 +   ctx = CALLOC(1, sizeof(struct analysis_context));
 +   ctx-info = info;
  
 tgsi_parse_init(parse, tokens);
  
 @@ -518,7 +518,7 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
 goto finished;
  }
  
 -analyse_instruction(ctx, inst);
 +analyse_instruction(ctx, inst);
   }
   break;
  
 @@ -527,16 +527,16 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
  const unsigned size =
parse.FullToken.FullImmediate.Immediate.NrTokens - 1;
  assert(size = 4);
 -if (ctx.num_imms  Elements(ctx.imm)) {
 +if (ctx-num_imms  Elements(ctx-imm)) {
 for (chan = 0; chan  size; ++chan) {
float value = 
 parse.FullToken.FullImmediate.u[chan].Float;
 -  ctx.imm[ctx.num_imms][chan] = value;
 +  ctx-imm[ctx-num_imms][chan] = value;
  
if (value  0.0f || value  1.0f) {
   info-unclamped_immediates = TRUE;
}
 }
 -   ++ctx.num_imms;
 +   ++ctx-num_imms;
  }
   }
   break;
 @@ -551,6 +551,7 @@ lp_build_tgsi_info(const struct tgsi_token *tokens,
  finished:
  
 tgsi_parse_free(parse);
 +   FREE(ctx);
  
  
 /*
 --
 1.8.3.2

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

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions



- Original Message -
 
 
 - Original Message -
  On 05.02.2014 18:08, Jose Fonseca wrote:
   I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
   would
   have been alright if it wasn't for this bit in
   https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_memory.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=pA%2FnK9X3xx0wAlMUZ24PfQ1mW6wAMdTUujz%2Bx7LRwCA%3D%0As=ebbe1f51deb46c81578b3c125b16e31b5f4b28c1d47e283bc9ef588e2707024d
   which says:
  
2) Can the application still use the buffer using the CPU address?
  
RESOLVED: YES. However, this access would be completely
non synchronized to the OpenGL pipeline, unless explicit
synchronization is being used (for example, through glFinish or
by
using
sync objects).
  
   And I'm imagining apps which are streaming vertex data doing precisely
   just
   that...
  
  
  I don't understand your concern, this is exactly the same behavior
  GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that
  properly. How does apitrace handle it?
 
 GL_AMD_pinned_memory it's nothing like GL_ARB_map_buffer_range's
 GL_MAP_UNSYCHRONIZED_BIT:
 
 - When an app touches memory returned by
 glMapBufferRange(GL_MAP_UNSYCHRONIZED_BIT) it will communicate back to the
 OpenGL driver which bytes it actually touched via the
 glFlushMappedBufferRange (unless the apps doesn't care about performance and
 doesn't call glFlushMappedBufferRange at all, which is silly as it will
 force the OpenGL driver to assumed the whole range changed)
 
   In this case, the OpenGL driver (hence apitrace) should get all the
   information it needs about which bytes were updated betwen glMap/glUnmap.
 
 - When an app touches memory bound via GL_AMD_pinned_memory outside
 glMap/glUnmap, there are be _no_ hints whatsever.  The OpenGL driver might
 not care as the memory is shared between CPU and GPU, so all is good as far
 is it is concerned, but all the changes the app does are invisible at an API
 level, hence apitrace will not be able to catch them unless it does onerous
 heuristics.
 
 
 So while both extensions allow unsynchronized access, but lack of
 synchronization is not my concern. My concern is that GL_AMD_pinned_memory
 allows *hidden* access to GPU memory.

Just for the record, the challenges GL_AMD_pinned_memory presents to Apitrace 
are much similar to the old-fashioned OpenGL user array pointers: an app is 
free to change the contents of memory pointed by user arrays pointers at any 
point in time, except during a draw call.  This means that before every draw 
call, Apitrace needs to scavenge all the user memory pointers and write their 
contents to the trace file, just in case the app changed it..

In order to support GL_AMD_pinned_memory, for every draw call Apitrace would 
also need to walk over bound GL_AMD_pinned_memory (and nowadays there are loads 
of bound points!), and check if data changed, and serialize in the trace file 
if it did...


I never care much about performance of Apitrace with user array pointers: it is 
an old paradigm; only old apps use it, or programmers which don't particular 
care about performance -- either way, a performance conscious app developer 
would use VBOs hence never hit the problem at all.  My displeasure with 
GL_AMD_pinned_memory is that it essentially flips everything on its head -- it 
encourages a paradigm which apitrace will never be able to handle properly. 


People often complain that OpenGL development tools are poor compared with 
Direct3D's.  An important fact they often miss is that Direct3D API is several 
orders of mangnitude tool friendlier: it's clear that Direct3D API's cares 
about things like allowing to query all state back, whereas OpenGL is more fire 
and forget and never look back -- the main concern in OpenGL is ensuring that 
state can go from App to Driver fast, but little thought is often given to 
ensuring that one can read whole state back, or ensuring that one can intercept 
all state as it goes between the app and the driver...


In this particular case, if the answer for Can the application still use the 
buffer using the CPU address? was a NO, the world would be a much better place.


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

Re: [Mesa-dev] [PATCH RFC 10/11] glsl: add a pass to convert out of SSA form

2014-02-05 Thread Connor Abbott

On Fri, Jan 31, 2014 at 11:55 AM, Paul Berry stereotype...@gmail.comwrote:

 On 22 January 2014 09:16, Connor Abbott cwabbo...@gmail.com wrote:

 Right now we are being basically as naive as possible, and inserting
 more copies than necessary. It is possible to implement a more
 sophisticated algorithm later, although extending the current copy
 propagation pass to support loops better and/or relying on backends to
 do copy propagation may make this unecessary.
 ---
  src/glsl/Makefile.sources  |   1 +
  src/glsl/ir_optimization.h |   1 +
  src/glsl/opt_from_ssa.cpp  | 198
 +
  3 files changed, 200 insertions(+)
  create mode 100644 src/glsl/opt_from_ssa.cpp

 diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
 index 961784b..55859ed 100644
 --- a/src/glsl/Makefile.sources
 +++ b/src/glsl/Makefile.sources
 @@ -94,6 +94,7 @@ LIBGLSL_FILES = \
 $(GLSL_SRCDIR)/opt_dead_functions.cpp \
 $(GLSL_SRCDIR)/opt_flatten_nested_if_blocks.cpp \
 $(GLSL_SRCDIR)/opt_flip_matrices.cpp \
 +   $(GLSL_SRCDIR)/opt_from_ssa.cpp \
 $(GLSL_SRCDIR)/opt_function_inlining.cpp \
 $(GLSL_SRCDIR)/opt_if_simplification.cpp \
 $(GLSL_SRCDIR)/opt_noop_swizzle.cpp \
 diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
 index 92c8b57..9c0ff31 100644
 --- a/src/glsl/ir_optimization.h
 +++ b/src/glsl/ir_optimization.h
 @@ -66,6 +66,7 @@ enum lower_packing_builtins_op {
  };

  void convert_to_ssa(exec_list *instructions);
 +void convert_from_ssa(exec_list *instructions);

  bool do_common_optimization(exec_list *ir, bool linked,
 bool uniform_locations_assigned,
 diff --git a/src/glsl/opt_from_ssa.cpp b/src/glsl/opt_from_ssa.cpp
 new file mode 100644
 index 000..6071c45
 --- /dev/null
 +++ b/src/glsl/opt_from_ssa.cpp
 @@ -0,0 +1,198 @@
 +/*
 + * Copyright © 2013 Connor Abbott (con...@abbott.cx)
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining
 a
 + * copy of this software and associated documentation files (the
 Software),
 + * to deal in the Software without restriction, including without
 limitation
 + * the rights to use, copy, modify, merge, publish, distribute,
 sublicense,
 + * and/or sell copies of the Software, and to permit persons to whom the
 + * Software is furnished to do so, subject to the following conditions:
 + *
 + * The above copyright notice and this permission notice (including the
 next
 + * paragraph) shall be included in all copies or substantial portions of
 the
 + * Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR
 + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
 SHALL
 + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
 OTHER
 + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
 ARISING
 + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 + * DEALINGS IN THE SOFTWARE.
 + */
 +
 +#include ir.h
 +#include ir_builder.h
 +
 +/**
 + * \file opt_from_ssa.cpp
 + *
 + * This file removes all the SSA temporaries and phi nodes from a
 program. It
 + * immplements Method I of the paper Translating out of Single Static
 + * Assignment Form by Sreedhar et. al., a naive method that inserts
 many more
 + * copies than necessary; it is assumed that later copy propagation
 passes will
 + * clean up the result of this pass.
 + */
 +
 +using namespace ir_builder;
 +
 +static ir_variable *
 +insert_decl(exec_list *instrs, const glsl_type *type, void *mem_ctx)
 +{
 +   ir_variable *var = new(mem_ctx) ir_variable(type, phi_temp,
 +  ir_var_temporary);
 +   instrs-push_head(var);
 +   return var;
 +}
 +
 +static void
 +eliminate_phi_if(ir_phi_if *phi, ir_if *ir, exec_list *instrs)
 +{
 +   ir_variable *var = insert_decl(instrs, phi-dest-type,
 ralloc_parent(ir));
 +
 +   /*
 +* This converts the destination of the phi node into a non-SSA
 variable,
 +* which ir_from_ssa_visitor::visit(ir_dereference_variable *) would
 normally
 +* do. We need to do this here because otherwise, the assignment we're
 +* inserting here will get skipped by the list visitor macro and it
 won't
 +* get converted.
 +*/


 I found this comment confusing because the use of otherwise seems to
 imply that what we're doing here will cause the list visitor to visit the
 new node; in fact what is happening is that we're compensating for the fact
 that it won't.  How about instead saying something like We need to do this
 here because the list visitor uses foreach_list_safe(), so it will skip any
 nodes we insert.


 +
 +   ir-insert_after(phi-dest);
 +   phi-dest-insert_after(assign(phi-dest, var));
 +   phi-dest-data.mode = ir_var_temporary;

 +
 +   if (phi-if_src != NULL)
 +

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

However, GL_ARB_buffer_storage (OpenGL 4.4) with GL_MAP_PERSISTENT_BIT
isn't much different. The only difference I see between
ARB_buffer_storage and AMD_pinned_memory is that AMD_pinned_memory
allows mapping CPU memory to the GPU address space permanently, while
ARB_buffer_storage allows mapping GPU memory to the CPU address
permanently. At the end of the day, both the GPU and the CPU can read
and modify the same buffer and all they need to use for
synchronization is fences.

Marek

On Wed, Feb 5, 2014 at 8:10 PM, Jose Fonseca jfons...@vmware.com wrote:


 - Original Message -


 - Original Message -
  On 05.02.2014 18:08, Jose Fonseca wrote:
   I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
   would
   have been alright if it wasn't for this bit in
   https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_memory.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=pA%2FnK9X3xx0wAlMUZ24PfQ1mW6wAMdTUujz%2Bx7LRwCA%3D%0As=ebbe1f51deb46c81578b3c125b16e31b5f4b28c1d47e283bc9ef588e2707024d
   which says:
  
2) Can the application still use the buffer using the CPU address?
  
RESOLVED: YES. However, this access would be completely
non synchronized to the OpenGL pipeline, unless explicit
synchronization is being used (for example, through glFinish or
by
using
sync objects).
  
   And I'm imagining apps which are streaming vertex data doing precisely
   just
   that...
  
 
  I don't understand your concern, this is exactly the same behavior
  GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that
  properly. How does apitrace handle it?

 GL_AMD_pinned_memory it's nothing like GL_ARB_map_buffer_range's
 GL_MAP_UNSYCHRONIZED_BIT:

 - When an app touches memory returned by
 glMapBufferRange(GL_MAP_UNSYCHRONIZED_BIT) it will communicate back to the
 OpenGL driver which bytes it actually touched via the
 glFlushMappedBufferRange (unless the apps doesn't care about performance and
 doesn't call glFlushMappedBufferRange at all, which is silly as it will
 force the OpenGL driver to assumed the whole range changed)

   In this case, the OpenGL driver (hence apitrace) should get all the
   information it needs about which bytes were updated betwen glMap/glUnmap.

 - When an app touches memory bound via GL_AMD_pinned_memory outside
 glMap/glUnmap, there are be _no_ hints whatsever.  The OpenGL driver might
 not care as the memory is shared between CPU and GPU, so all is good as far
 is it is concerned, but all the changes the app does are invisible at an API
 level, hence apitrace will not be able to catch them unless it does onerous
 heuristics.


 So while both extensions allow unsynchronized access, but lack of
 synchronization is not my concern. My concern is that GL_AMD_pinned_memory
 allows *hidden* access to GPU memory.

 Just for the record, the challenges GL_AMD_pinned_memory presents to Apitrace 
 are much similar to the old-fashioned OpenGL user array pointers: an app is 
 free to change the contents of memory pointed by user arrays pointers at any 
 point in time, except during a draw call.  This means that before every draw 
 call, Apitrace needs to scavenge all the user memory pointers and write their 
 contents to the trace file, just in case the app changed it..

 In order to support GL_AMD_pinned_memory, for every draw call Apitrace would 
 also need to walk over bound GL_AMD_pinned_memory (and nowadays there are 
 loads of bound points!), and check if data changed, and serialize in the 
 trace file if it did...


 I never care much about performance of Apitrace with user array pointers: it 
 is an old paradigm; only old apps use it, or programmers which don't 
 particular care about performance -- either way, a performance conscious app 
 developer would use VBOs hence never hit the problem at all.  My displeasure 
 with GL_AMD_pinned_memory is that it essentially flips everything on its head 
 -- it encourages a paradigm which apitrace will never be able to handle 
 properly.


 People often complain that OpenGL development tools are poor compared with 
 Direct3D's.  An important fact they often miss is that Direct3D API is 
 several orders of mangnitude tool friendlier: it's clear that Direct3D API's 
 cares about things like allowing to query all state back, whereas OpenGL is 
 more fire and forget and never look back -- the main concern in OpenGL is 
 ensuring that state can go from App to Driver fast, but little thought is 
 often given to ensuring that one can read whole state back, or ensuring that 
 one can intercept all state as it goes between the app and the driver...


 In this particular case, if the answer for Can the application still use the 
 buffer using the CPU address? was a NO, the world would be a much better 
 place.


 Jose
 ___
 mesa-dev

[Mesa-dev] [PATCH] glx: Pass NULL DRI drawables into the DRI driver for None GLX drawables

2014-02-05 Thread Kristian Høgsberg

GLX_ARB_create_context allows making a GLX context current with None
drawable and readables, but this was never implemented correctly in GLX.
We would create a __DRIdrawable for the None GLX drawable and pass that
to the DRI driver and that would somehow work.  Now it's somehow broken.

The way this should have worked is that we pass a NULL DRI drawable
to the DRI driver when the GLX user calls glXMakeContextCurrent()
with None for drawable and readables.

https://bugs.freedesktop.org/show_bug.cgi?id=74143
---
 src/glx/dri2_glx.c   | 17 -
 src/glx/dri_common.c |  3 +++
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 0a0dac9..67fe9c1 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -141,6 +141,7 @@ dri2_bind_context(struct glx_context *context, struct 
glx_context *old,
struct dri2_context *pcp = (struct dri2_context *) context;
struct dri2_screen *psc = (struct dri2_screen *) pcp-base.psc;
struct dri2_drawable *pdraw, *pread;
+   __DRIdrawable *dri_draw = NULL, *dri_read = NULL;
struct dri2_display *pdp;
 
pdraw = (struct dri2_drawable *) driFetchDrawable(context, draw);
@@ -148,20 +149,26 @@ dri2_bind_context(struct glx_context *context, struct 
glx_context *old,
 
driReleaseDrawables(pcp-base);
 
-   if (pdraw == NULL || pread == NULL)
+   if (pdraw)
+  dri_draw = pdraw-driDrawable;
+   else if (draw != None)
   return GLXBadDrawable;
 
-   if (!(*psc-core-bindContext) (pcp-driContext,
-  pdraw-driDrawable, pread-driDrawable))
+   if (pread)
+  dri_read = pread-driDrawable;
+   else if (read != None)
+  return GLXBadDrawable;
+
+   if (!(*psc-core-bindContext) (pcp-driContext, dri_draw, dri_read))
   return GLXBadContext;
 
/* If the server doesn't send invalidate events, we may miss a
 * resize before the rendering starts.  Invalidate the buffers now
 * so the driver will recheck before rendering starts. */
pdp = (struct dri2_display *) psc-base.display;
-   if (!pdp-invalidateAvailable) {
+   if (!pdp-invalidateAvailable  pdraw) {
   dri2InvalidateBuffers(psc-base.dpy, pdraw-base.xDrawable);
-  if (pread != pdraw)
+  if (pread != pdraw  pread)
 dri2InvalidateBuffers(psc-base.dpy, pread-base.xDrawable);
}
 
diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
index 0dd8982..012c8f4 100644
--- a/src/glx/dri_common.c
+++ b/src/glx/dri_common.c
@@ -392,6 +392,9 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable 
glxDrawable)
if (priv == NULL)
   return NULL;
 
+   if (glxDrawable == None)
+  return NULL;
+
psc = priv-screens[gc-screen];
if (priv-drawHash == NULL)
   return NULL;
-- 
1.8.4.2

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

[Mesa-dev] [PATCH] glsl/geom-stipple-lines: Pass pattern as int to GS.

Pass pattern as bitmask in a unsigned int instead of as array of floats to the
geometry shader.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/geom-stipple-lines.c | 21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/src/glsl/geom-stipple-lines.c b/src/glsl/geom-stipple-lines.c
index e56d1f3..e5f8879 100644
--- a/src/glsl/geom-stipple-lines.c
+++ b/src/glsl/geom-stipple-lines.c
@@ -41,24 +41,11 @@ CheckError(int line)
  /**
  * Set stipple factor and pattern for geometry shader.
- *
- * We convert the 16-bit stipple pattern into an array of 16 float values
- * then pass the array as a uniform variable.
- *
- * Note: With GLSL 1.30 or later the stipple pattern could be implemented
- * as an ordinary integer since GLSL 1.30 has true integer types and bit
- * shifts and bit masks.
- *
  */
 static void
 SetStippleUniform(GLint factor, GLushort pattern)
 {
-   GLfloat p[16];
-   int i;
-   for (i = 0; i  16; i++) {
-  p[i] = (pattern  (1  i)) ? 1.0f : 0.0f;
-   }
-   glUniform1fv(uStipplePattern, 16, p);
+   glUniform1ui(uStipplePattern, pattern);
glUniform1f(uStippleFactor, factor);
 }
 @@ -270,7 +257,7 @@ Init(void)
 {
static const char *fragShaderText =
   #version 150 \n
-  uniform float StipplePattern[16]; \n
+  uniform uint StipplePattern; \n
   in vec4 g2f_Color; \n
   in float stippleCoord; \n
   out vec4 FragColor; \n
@@ -279,8 +266,8 @@ Init(void)
  // check the stipple pattern and discard if value is zero \n
  // TODO: we should really undo the perspective interpolation here \n
  // so that it's linear. \n
- float stip = StipplePattern[int(fract(stippleCoord) * 16.0)]; \n
- if (stip == 0.0) \n
+ uint stip = (StipplePattern  uint(fract(stippleCoord) * 16.0))  
1u; \n
+ if (stip == 0u) \n
 discard; \n
  FragColor = g2f_Color; \n
   } \n;
-- 
1.8.5.3

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

Re: [Mesa-dev] [PATCH] glsl/geom-stipple-lines: Pass pattern as int to GS.

Please disregard this mail.

Sorry about the noise.

On 2014-02-05 20:50, Fabian Bieler wrote:
 Pass pattern as bitmask in a unsigned int instead of as array of floats to the
 geometry shader.
 
 Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
 ---
   src/glsl/geom-stipple-lines.c | 21 -
   1 file changed, 4 insertions(+), 17 deletions(-)
 
 diff --git a/src/glsl/geom-stipple-lines.c b/src/glsl/geom-stipple-lines.c
 index e56d1f3..e5f8879 100644
 --- a/src/glsl/geom-stipple-lines.c
 +++ b/src/glsl/geom-stipple-lines.c
 @@ -41,24 +41,11 @@ CheckError(int line)
/**
* Set stipple factor and pattern for geometry shader.
 - *
 - * We convert the 16-bit stipple pattern into an array of 16 float values
 - * then pass the array as a uniform variable.
 - *
 - * Note: With GLSL 1.30 or later the stipple pattern could be implemented
 - * as an ordinary integer since GLSL 1.30 has true integer types and bit
 - * shifts and bit masks.
 - *
*/
   static void
   SetStippleUniform(GLint factor, GLushort pattern)
   {
 -   GLfloat p[16];
 -   int i;
 -   for (i = 0; i  16; i++) {
 -  p[i] = (pattern  (1  i)) ? 1.0f : 0.0f;
 -   }
 -   glUniform1fv(uStipplePattern, 16, p);
 +   glUniform1ui(uStipplePattern, pattern);
  glUniform1f(uStippleFactor, factor);
   }
   @@ -270,7 +257,7 @@ Init(void)
   {
  static const char *fragShaderText =
 #version 150 \n
 -  uniform float StipplePattern[16]; \n
 +  uniform uint StipplePattern; \n
 in vec4 g2f_Color; \n
 in float stippleCoord; \n
 out vec4 FragColor; \n
 @@ -279,8 +266,8 @@ Init(void)
// check the stipple pattern and discard if value is zero \n
// TODO: we should really undo the perspective interpolation here 
 \n
// so that it's linear. \n
 - float stip = StipplePattern[int(fract(stippleCoord) * 16.0)]; \n
 - if (stip == 0.0) \n
 + uint stip = (StipplePattern  uint(fract(stippleCoord) * 16.0))  
 1u; \n
 + if (stip == 0u) \n
   discard; \n
FragColor = g2f_Color; \n
 } \n;
 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 72895] Missing trees in flightgear 2.12.1 with r600 driver and mesa 10.0.1

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

--- Comment #11 from Benjamin Bellec b.bel...@gmail.com ---
I confirm the bug with mesa master and r600g (AMD CYPRESS).

You can try with this command (on Fedora 19):
/usr/bin/fgfs --fg-root=/usr/share/flightgear
--fg-scenery=/usr/share/flightgear/Scenery --airport=KPAO
--aircraft=c172p-canvas --enable-random-objects --enable-horizon-effect
--enable-enhanced-lighting --enable-ai-models --enable-ai-traffic
--disable-real-weather-fetch --enable-clouds3d --geometry=1024x768

Maybe, you should then increase the numbers of trees (set trees density to 10.0
in View -- Rendering options).

You will see trees in the scene. You then start the engine (stay pushing S
key) and as soon as the propeller is at full speed (the propeller is
differently rendered), the trees will disappears.

They can reappears later during the flight, quite randomly.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 4/4] glsl: Change locations from yylloc to appropriate tokens positions.

2014-02-05 Thread Carl Worth

Sir Anthony anth...@adsorbtion.org writes:

Thanks for this patch series. It looks great to me. I sent a separate
email with a small comment about some comments. The only other review
comment I have is:

 @@ -2127,7 +2138,7 @@ function_definition:
 {
void *ctx = state;
$$ = new(ctx) ast_function_definition();
 -  $$-set_location(yylloc);
 +  $$-set_location_range(@1, @2);
$$-prototype = $1;
$$-body = $2;

Doesn't this set the range for this definition to the entire range of
the function (declaration and body)? In one sense, that's a correct
range for what is being parsed here. But on the other hand, would this
actually be a useful range to emit in an error message? Or would it be
better to just direct the error message to the location of the prototype
itself?

I don't have strong feelings one way or the other, but just wanted to
raise this issue to see if this is what you actually intended in this
case.

Regardless of whether you restrict the range in this case, the entire
series is:

Reviewed-by: Carl Worth cwo...@cworth.org

-Carl

-- 
carl.d.wo...@intel.com


pgpah60_m9n5b.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/4] glsl: Extend ast location structure to hande end token position.

2014-02-05 Thread Carl Worth

Sir Anthony anth...@adsorbtion.org writes:
 +  unsigned first_line;  /** Line number within the source string. */
 +  unsigned first_column;/** Column in the line. */
 +  unsigned last_line;   /** Line number within the source string. */
 +  unsigned last_column; /** Column in the line. */

The comments here should be updated to distinguish between the first
and last cases.

-Carl


pgpQbtLNfuKDE.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glcpp: Do not remove spaces to preserve locations.

2014-02-05 Thread Carl Worth

Sir Anthony anth...@adsorbtion.org writes:
 After preprocessing by glcpp all adjacent spaces were replaced by
 single one and glsl parser received column-shifted shader source. 
 It negatively affected ast location set up and produced wrong error 
 messages for heavily-spaced shaders.

Thanks!

This commit message and the patch match much better than the previous
version. And thanks for updating the test suite as well.

Reviewed-by: Carl Worth cwo...@cworth.org

-Carl


pgpph5cZLYl_s.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/3] gallium: define the behavior of PIPE_USAGE_* flags properly

2014-02-05 Thread Brian Paul


On 02/04/2014 04:26 PM, Marek Olšák wrote:

From: Marek Olšák marek.ol...@amd.com

STATIC will be removed in the following commit.
---
  src/gallium/docs/source/screen.rst   | 18 --
  src/gallium/include/pipe/p_defines.h | 13 +++--
  2 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/src/gallium/docs/source/screen.rst 
b/src/gallium/docs/source/screen.rst
index c26f98c..5932e3b 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -343,12 +343,18 @@ PIPE_USAGE_*
  

  The PIPE_USAGE enums are hints about the expected usage pattern of a resource.
-
-* ``PIPE_USAGE_DEFAULT``: Expect many uploads to the resource, intermixed with 
draws.
-* ``PIPE_USAGE_DYNAMIC``: Expect many uploads to the resource, intermixed with 
draws.
-* ``PIPE_USAGE_STATIC``: Same as immutable (?)
-* ``PIPE_USAGE_IMMUTABLE``: Resource will not be changed after first upload.
-* ``PIPE_USAGE_STREAM``: Upload will be followed by draw, followed by upload, 
...
+Note that drivers must always support read and write CPU access at any time
+no matter which hint they got.
+
+* ``PIPE_USAGE_DEFAULT``: Optimized for fast GPU access.
+* ``PIPE_USAGE_IMMUTABLE``: Optimized for fast GPU access and the resource is
+  not expected to be mapped after the first upload.


How about mapped or changed?  For example, an immutable resource 
probably shouldn't be the dest of a blit.




+* ``PIPE_USAGE_DYNAMIC``: Expect frequent write-only CPU access. What is
+  uploaded is expected to be used at least several times by the GPU.
+* ``PIPE_USAGE_STATIC``: Same as PIPE_USAGE_DEFAULT.
+* ``PIPE_USAGE_STREAM``: Expect frequent write-only CPU access. What is
+  uploaded is expected to be used only once by the GPU.
+* ``PIPE_USAGE_STAGING``: Optimized for fast CPU access.


  Methods
diff --git a/src/gallium/include/pipe/p_defines.h 
b/src/gallium/include/pipe/p_defines.h
index 52c12df..1c550f8 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -382,13 +382,14 @@ enum pipe_flush_flags {
  #define PIPE_RESOURCE_FLAG_ST_PRIV (1  24) /* state-tracker/winsys 
private */

  /* Hint about the expected lifecycle of a resource.
+ * Sorted according to GPU vs CPU access.
   */
-#define PIPE_USAGE_DEFAULT0 /* many uploads, draws intermixed */
-#define PIPE_USAGE_DYNAMIC1 /* many uploads, draws intermixed */
-#define PIPE_USAGE_STATIC 2 /* same as immutable?? */
-#define PIPE_USAGE_IMMUTABLE  3 /* no change after first upload */
-#define PIPE_USAGE_STREAM 4 /* upload, draw, upload, draw */
-#define PIPE_USAGE_STAGING5 /* supports data transfers from the GPU to 
the CPU */
+#define PIPE_USAGE_DEFAULT0 /* fast GPU access */
+#define PIPE_USAGE_IMMUTABLE  1 /* fast GPU access, immutable */
+#define PIPE_USAGE_DYNAMIC2 /* uploaded data is used multiple times */
+#define PIPE_USAGE_STREAM 3 /* uploaded data is used once */
+#define PIPE_USAGE_STAGING4 /* fast CPU access */
+#define PIPE_USAGE_STATIC 5 /* same as DEFAULT, will be removed */


  /**



Otherwise, the series LGTM.

Reviewed-by: Brian Paul bri...@vmware.com


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

[Mesa-dev] [PATCH 05/12] glsl/gsraytrace: Bind transform feedback buffer.

Bind the transform feedback buffer before drawing into it und unbind it
afterwards.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index eace71b..e76a3a2 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -628,6 +628,7 @@ Draw(void)
printf(%d\n, i);
//gs.fpwQuery-beginQuery();
//gs.pgQuery-beginQuery();
+   glBindBufferBaseNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, dst);
glBeginQuery(GL_PRIMITIVES_GENERATED_NV, pgQuery);
glBeginTransformFeedbackNV(GL_POINTS);
//gs.eyeRaysAsPoints-bindAs(ARRAY);
@@ -675,7 +676,7 @@ Draw(void)
 
 
swap(src, dst);
-   glBindBufferOffsetNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, dst-getID(), 
0); pso_gl_check();
+   glBindBufferBaseNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, 0);
 
clear();
 
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 03/12] glsl/gsraytrace: Use LINE macro to set line numbers in GLSL source strings.

The hardcoded numbers are a few lines off at the moment.
Keeping track of the numbers through further modifications is inconvenient.
The __LINE__ constant takes care of this automatically.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index 62a584d..31e9fda 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -37,6 +37,10 @@
 // TODO: use GL_EXT_transform_feedback or GL3 equivalent
 // TODO: port to piglit too
 
+#define STRINGIFY_(x) #x
+#define STRINGIFY(x) STRINGIFY_(x)
+#define S__LINE__ STRINGIFY(__LINE__)
+
 static const float INF=.9F;
 
 static int Win;
@@ -67,7 +71,7 @@ float rot[9] = {1,0,0,  0,1,0,   0,0,1};
 static const char* vsSource =
   \n
 #version 120  \n
-#line 63 63   \n
+#line  S__LINE__ S__LINE__ \n
 #define SHADOWS   \n
 #define RECURSION \n
   \n
@@ -249,7 +253,7 @@ static const char* vsSource =
 
 static const char* gsSource = 
 #version 120 \n
-#line 245 245\n
+#line  S__LINE__ S__LINE__ \n
 #extension GL_ARB_geometry_shader4: require  \n
  \n
 #define SHADOWS  \n
@@ -388,7 +392,7 @@ static const char* gsSource =
 
 static const char* fsSource = 
 #version 120 \n
-#line 384 384\n
+#line  S__LINE__ S__LINE__ \n
  \n
 #define SHADOWS  \n
 #define RECURSION\n
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 09/12] glsl/gsraytrace: Switch to core profile.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 40 +---
 1 file changed, 29 insertions(+), 11 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index adb6c7a..03d5f30 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -70,7 +70,7 @@ float rot[9] = {1,0,0,  0,1,0,   0,0,1};
 
 static const char* vsSource =
   \n
-#version 150  \n
+#version 150 core \n
 #line  S__LINE__ S__LINE__ \n
 #define SHADOWS   \n
 #define RECURSION \n
@@ -253,7 +253,7 @@ static const char* vsSource =
 
 
 static const char* gsSource = 
-#version 150 \n
+#version 150 core\n
 #line  S__LINE__ S__LINE__ \n
 layout(points) in;   \n
 layout(points, max_vertices = 3) out;\n
@@ -393,7 +393,7 @@ static const char* gsSource =
 }\n;
 
 static const char* fsSource = 
-#version 150 \n
+#version 150 core\n
 #line  S__LINE__ S__LINE__ \n
  \n
 #define SHADOWS  \n
@@ -408,6 +408,7 @@ static const char* fsSource =
 uniform vec4 backgroundColor;\n
 uniform int emitNoMore;  \n
  \n
+out vec4 frag_color; \n
  \n
 //---\n
  \n
@@ -493,7 +494,7 @@ static const char* fsSource =
 Isec eyeHit = isec;\n
 if (eyeHit.idx == -1)\n
 {\n
-  gl_FragColor = vec4(backgroundColor.rgb, 0.0);\n
+  frag_color = vec4(backgroundColor.rgb, 0.0);\n
   return;\n
 }\n
 vec3 eyeHitPosition = eyeRay.orig + eyeRay.dir * eyeHit.t;\n
@@ -503,7 +504,7 @@ static const char* fsSource =
 vec3  L  = normalize(lightVec);   
  \n
 float NdotL  = max(dot(N, L), 0.0);   
  \n
 vec3 diffuse = idx2color(eyeHit.idx); // material color of the visible 
point\n
-gl_FragColor = vec4(diffuse * NdotL, 1.0);
  \n
+frag_color = vec4(diffuse * NdotL, 1.0);  
\n
 return;\n
   }\n
 #ifdef SHADOWS \n
@@ -514,7 +515,7 @@ static const char* fsSource =
 { \n
   discard;\n
 } \n
-gl_FragColor = vec4(-1,-1,-1, 0.0);   \n
+frag_color = vec4(-1,-1,-1, 0.0);   \n
 return;   \n
   }   \n
 #endif\n
@@ -534,7 +535,7 @@ static const char* fsSource =
 vec3  L  = normalize(lightVec);   \n
 float NdotL  = max(dot(N, L), 0.0);   \n
 vec3 diffuse = idx2color(reflHit.idx);\n
-gl_FragColor = vec4(diffuse * NdotL * 0.25, 1.0); // material color of 
the visible point\n
+frag_color = vec4(diffuse * NdotL * 0.25, 1.0); // material color of the 
visible point\n
 return;   \n
   }   \n
 #endif\n
@@ -608,6 +609,8 @@ Draw(void)
dir_idxAttribLoc = glGetAttribLocation(program, dir_idx);
uv_stateAttribLoc = glGetAttribLocation(program, uv_state);
 
+   glBindFragDataLocation(program, 0, frag_color);
+
printf(%d\n, i);
//gs.fpwQuery-beginQuery();
//gs.pgQuery-beginQuery();
@@ -755,10 +758,6 @@ Reshape(int width, int height)
WinWidth = width;
WinHeight = height;
glViewport(0, 0, width, height);
-

[Mesa-dev] [PATCH 02/12] glut_wrapper: Include freeglut.h if available.

The freeglut header only defines the extensions to request an OpenGL core
profile context if freeglut.h (rather than glut.h) is included.

Note that the header is installed to include/GL/freeglut.h on OS X, too.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/util/glut_wrap.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/util/glut_wrap.h b/src/util/glut_wrap.h
index a48a9e8..fa1b8f9 100644
--- a/src/util/glut_wrap.h
+++ b/src/util/glut_wrap.h
@@ -1,7 +1,9 @@
 #ifndef GLUT_WRAP_H
 #define GLUT_WRAP_H
 
-#ifdef __APPLE__
+#ifdef HAVE_FREEGLUT
+#  include GL/freeglut.h
+#elif defined __APPLE__
 #  include GLUT/glut.h
 #else
 #  include GL/glut.h
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 04/12] glsl/gsraytrace: Don't create new Buffer objects everytime the window is resized.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index 31e9fda..eace71b 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -776,7 +776,6 @@ Reshape(int width, int height)
 
{
   size_t nElem = WinWidth*WinHeight*nRayGens;
-  glGenBuffers(1, dst);
   glBindBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV, dst);
   glBufferData(GL_TRANSFORM_FEEDBACK_BUFFER_NV, nElem*sizeof(GSRay), 0, 
GL_STREAM_DRAW);
   GSRay* d = (GSRay*)glMapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 
GL_READ_WRITE);
@@ -790,7 +789,6 @@ Reshape(int width, int height)
}
 
{
-  glGenBuffers(1, eyeRaysAsPoints);
   glBindBuffer(GL_ARRAY_BUFFER, eyeRaysAsPoints);
   glBufferData(GL_ARRAY_BUFFER, WinWidth*WinHeight*sizeof(GSRay), 0, 
GL_STATIC_DRAW);
   GSRay* d = (GSRay*)glMapBuffer(GL_ARRAY_BUFFER, GL_READ_WRITE);
@@ -919,6 +917,8 @@ Init(void)
}
 
glGenQueries(1, pgQuery);
+   glGenBuffers(1, dst);
+   glGenBuffers(1, eyeRaysAsPoints);
 
printf(\nESC = exit demo\nleft mouse + drag   = rotate 
camera\n\n);
 }
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 07/12] glsl/gsraytrace: Use GLSL 1.5 instead of 1.2.

This commit prepares the transition from extension to core geometry shaders.
(Core geometry shaders require GLSL version 1.5 or later.)
This includes using generic vertex attributes instead of built-ins.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 58 +++--
 1 file changed, 32 insertions(+), 26 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index 2d12745..23c0f93 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -56,6 +56,7 @@ static GLuint pgQuery;
 static GLuint dst;
 static GLuint eyeRaysAsPoints;
 
+int posAttribLoc;
 int orig_tAttribLoc;
 int dir_idxAttribLoc;
 int uv_stateAttribLoc;
@@ -69,7 +70,7 @@ float rot[9] = {1,0,0,  0,1,0,   0,0,1};
 
 static const char* vsSource =
   \n
-#version 120  \n
+#version 150  \n
 #line  S__LINE__ S__LINE__ \n
 #define SHADOWS   \n
 #define RECURSION \n
@@ -83,9 +84,10 @@ static const char* vsSource =
 uniform vec4 backgroundColor; \n
 uniform int emitNoMore;   \n
   \n
-attribute vec4 orig_t;\n
-attribute vec4 dir_idx;   \n
-attribute vec4 uv_state;  \n
+in vec4 pos;  \n
+in vec4 orig_t;   \n
+in vec4 dir_idx;  \n
+in vec4 uv_state; \n
 // uv_state.z = state \n
 // uv_state.w = type (ray generation) \n
   \n
@@ -98,9 +100,9 @@ static const char* vsSource =
 //0: not shadow ray, eye ray  \n
 //1: shadow ray   \n
   \n
-varying vec4 orig_t1; \n
-varying vec4 dir_idx1;\n
-varying vec4 uv_state1;   \n
+out vec4 orig_t1; \n
+out vec4 dir_idx1;\n
+out vec4 uv_state1;   \n
   \n
   \n
 //\n
@@ -224,7 +226,7 @@ static const char* vsSource =
   if (state == 0)
\n
   { 
\n
 // generate eye rays\n
-ray = Ray(cameraPos, normalize(vec3(gl_Vertex.x, gl_Vertex.y, -1.0) * 
rot3));\n
+ray = Ray(cameraPos, normalize(vec3(pos.x, pos.y, -1.0) * rot3));   \n
 isec.t = INF;\n
 isec.idx = -1;\n
 state = 1;\n
@@ -240,7 +242,7 @@ static const char* vsSource =
   //else state == 3 \n
 \n
   //outVS();\n
-  gl_Position  = gl_Vertex; \n
+  gl_Position  = pos;   \n
   orig_t1.xyz  = ray.orig;  \n
   orig_t1.w= isec.t;\n
   dir_idx1.xyz = ray.dir;   \n
@@ -251,7 +253,7 @@ static const char* vsSource =
 
 
 static const char* gsSource = 
-#version 120 \n
+#version 150 \n
 #line  S__LINE__ S__LINE__ \n
 #extension GL_ARB_geometry_shader4: require  \n
  \n
@@ -310,13 +312,13 @@ static const char* gsSource =
   return isec;   \n
 }\n
  \n
-varying in vec4 orig_t1[1];  \n
-varying in vec4 dir_idx1[1];

[Mesa-dev] [PATCH 01/12] configure.ac: Check for freeglut.

To get an OpenGL core profile context freeglut 2.6 or later is required.

Note that in spite of it's name HAVE_FREEGLUT is only defined if freeglut 2.6
(released in 2009) or later ist found.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 configure.ac | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configure.ac b/configure.ac
index 0c38f4d..cd523c1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,12 @@ AC_CHECK_LIB([glut],
[],
[glut_enabled=no])
 
+dnl Check for FreeGLUT 2.6 or later
+AC_EGREP_HEADER([glutInitContextProfile],
+   [GL/freeglut.h],
+   [AC_DEFINE(HAVE_FREEGLUT)],
+   [])
+
 dnl Check for GLEW
 PKG_CHECK_MODULES(GLEW, [glew = 1.5.4])
 DEMO_CFLAGS=$DEMO_CFLAGS $GLEW_CFLAGS
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 12/12] geom-outlining-150: Switch to core profile.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/geom-outlining-150.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/glsl/geom-outlining-150.c b/src/glsl/geom-outlining-150.c
index 3dffa16..2e2a54a 100644
--- a/src/glsl/geom-outlining-150.c
+++ b/src/glsl/geom-outlining-150.c
@@ -364,9 +364,22 @@ main(int argc, char *argv[])
 {
glutInit(argc, argv);
glutInitWindowSize(WinWidth, WinHeight);
+#ifdef HAVE_FREEGLUT
+   glutInitContextVersion(3, 2);
+   glutInitContextProfile(GLUT_CORE_PROFILE);
glutInitDisplayMode(GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE);
+#elif defined __APPLE__
+   glutInitDisplayMode(GLUT_3_2_CORE_PROFILE | GLUT_RGB | GLUT_DEPTH | 
GLUT_DOUBLE);
+#else
+   glutInitDisplayMode(GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE);
+#endif
Win = glutCreateWindow(argv[0]);
+   /* glewInit requires glewExperimentel set to true for core profiles.
+* Depending on the glew version it also generates a GL_INVALID_ENUM.
+*/
+   glewExperimental = GL_TRUE;
glewInit();
+   glGetError();
glutReshapeFunc(Reshape);
glutKeyboardFunc(Key);
glutDisplayFunc(Redisplay);
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 10/12] geom-outlining-150: Use a vbo.

Use a vbo for vertex data instead of client-side arrays.
Also bind a vertex array object.

This is necessary for the switch to a core profile context.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/geom-outlining-150.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/src/glsl/geom-outlining-150.c b/src/glsl/geom-outlining-150.c
index 5c2b3c9..0bc20f0 100644
--- a/src/glsl/geom-outlining-150.c
+++ b/src/glsl/geom-outlining-150.c
@@ -23,6 +23,7 @@
 static GLint WinWidth = 500, WinHeight = 500;
 static GLint Win = 0;
 static GLuint VertShader, GeomShader, FragShader, Program;
+static GLuint vao, vbo;
 static GLboolean Anim = GL_TRUE;
 static int uViewportSize = -1, uModelViewProj = -1, uColor = -1;
 
@@ -112,11 +113,6 @@ mat_multiply(GLfloat product[16], const GLfloat a[16], 
const GLfloat b[16])
 static void
 Redisplay(void)
 {
-   static const GLfloat verts[3][2] = {
-  { -1, -1 },
-  {  1, -1 },
-  {  0,  1 }
-   };
GLfloat rot[4][4];
GLfloat trans[16], mvp[16];
 
@@ -131,8 +127,6 @@ Redisplay(void)
glUniformMatrix4fv(uModelViewProj, 1, GL_FALSE, (float *) mvp);
 
/* Draw */
-   glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, 0, verts);
-   glEnableVertexAttribArray(0);
glDrawArrays(GL_TRIANGLES, 0, 3);
 
glutSwapBuffers();
@@ -217,6 +211,8 @@ CleanUp(void)
glDeleteShader(VertShader);
glDeleteShader(GeomShader);
glDeleteProgram(Program);
+   glDeleteVertexArrays(1, vao);
+   glDeleteBuffers(1, vbo);
glutDestroyWindow(Win);
 }
 
@@ -304,6 +300,11 @@ Init(void)
  float m = min(d0, min(d1, d2)); \n
  FragColor = Color * smoothstep(0.0, LINE_WIDTH, m); \n
   } \n;
+   static const GLfloat verts[3][2] = {
+  { -1, -1 },
+  {  1, -1 },
+  {  0,  1 }
+   };
 
if (!ShadersSupported())
   exit(1);
@@ -351,6 +352,16 @@ Init(void)
 
glUniform4fv(uColor, 1, Orange);
 
+   glGenBuffers(1, vbo);
+   glBindBuffer(GL_ARRAY_BUFFER, vbo);
+   glBufferData(GL_ARRAY_BUFFER, sizeof(verts), verts, GL_STATIC_DRAW);
+
+   glGenVertexArrays(1, vao);
+   glBindVertexArray(vao);
+
+   glVertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE, 0, NULL);
+   glEnableVertexAttribArray(0);
+
glClearColor(0.3f, 0.3f, 0.3f, 0.0f);
glEnable(GL_DEPTH_TEST);
 
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 00/12] DEMOS Use core profile in two GS demos.

Hello!

As mesa only supports geometry shaders in core profile contexts this patchset
adjusts the gsraytrace and the geom-outlining-150 demos to use the core
profile.

Fabian


Fabian Bieler (12):
  configure.ac: Check for freeglut.
  glut_wrapper: Include freeglut.h if available.
  glsl/gsraytrace: Use __LINE__ macro to set line numbers in GLSL source
strings.
  glsl/gsraytrace: Don't create new Buffer objects everytime the window
is resized.
  glsl/gsraytrace: Bind transform feedback buffer.
  glsl/gsraytrace: Use core GL3.0 transform feedback
  glsl/gsraytrace: Use GLSL 1.5 instead of 1.2.
  glsl/gsraytrace: Use core geometry shaders.
  glsl/gsraytrace: Switch to core profile.
  geom-outlining-150: Use a vbo.
  geom-outlining-150: Use core geometry shaders.
  geom-outlining-150: Switch to core profile.

 configure.ac  |   6 ++
 src/glsl/geom-outlining-150.c |  64 --
 src/glsl/gsraytrace.cpp   | 191 ++
 src/util/glut_wrap.h  |   4 +-
 4 files changed, 147 insertions(+), 118 deletions(-)

-- 
1.8.3.2

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

[Mesa-dev] [PATCH 08/12] glsl/gsraytrace: Use core geometry shaders.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 30 +-
 1 file changed, 9 insertions(+), 21 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index 23c0f93..adb6c7a 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -255,7 +255,8 @@ static const char* vsSource =
 static const char* gsSource = 
 #version 150 \n
 #line  S__LINE__ S__LINE__ \n
-#extension GL_ARB_geometry_shader4: require  \n
+layout(points) in;   \n
+layout(points, max_vertices = 3) out;\n
  \n
 #define SHADOWS  \n
 #define RECURSION\n
@@ -337,7 +338,7 @@ static const char* gsSource =
 return;  \n
  \n
   // emitPassThrough();  \n
-  gl_Position  = gl_PositionIn[0];   \n
+  gl_Position  = gl_in[0].gl_Position;   \n
   orig_t2  = orig_t1[0]; \n
   dir_idx2 = dir_idx1[0];\n
   uv_state2.xyw= uv_state1[0].xyw;   \n
@@ -362,7 +363,7 @@ static const char* gsSource =
   type = 1;\n
\n
   //emitShadowRay();   \n
-  gl_Position  = gl_PositionIn[0]; \n
+  gl_Position  = gl_in[0].gl_Position; \n
   orig_t2.xyz  = shadowRay.orig;   \n
   orig_t2.w= shadowHit.t;  \n
   dir_idx2.xyz = shadowRay.dir;\n
@@ -379,7 +380,7 @@ static const char* gsSource =
   type  = -1;   \n
 \n
   //emitReflRay();  \n
-  gl_Position  = gl_PositionIn[0];  \n
+  gl_Position  = gl_in[0].gl_Position;  \n
   orig_t2.xyz  = reflRay.orig;  \n
   orig_t2.w= reflHit.t; \n
   dir_idx2.xyz = reflRay.dir;   \n
@@ -838,30 +839,17 @@ Init(void)
 {
glDisable(GL_DEPTH_TEST);
 
-   if (!ShadersSupported())
+   if (!GLEW_VERSION_3_2)
{
-  fprintf(stderr, Shaders are not supported!\n);
-  exit(-1);
-   }
-
-   if (!GLEW_ARB_geometry_shader4)
-   {
-  fprintf(stderr, GS Shaders are not supported!\n);
-  exit(-1);
-   }
-
-   if (!GLEW_VERSION_3_0)
-   {
-  fprintf(stderr, OpenGL 3.0 (needed for transform feedback) not 
-  supported!\n);
+  fprintf(stderr, OpenGL 3.2 (needed for transform feedback and 
+  gemoetry shaders) not supported!\n);
   exit(-1);
}
 
vertShader = CompileShaderText(GL_VERTEX_SHADER, vsSource);
geomShader = CompileShaderText(GL_GEOMETRY_SHADER_ARB, gsSource);
fragShader = CompileShaderText(GL_FRAGMENT_SHADER, fsSource);
-   program = LinkShaders3WithGeometryInfo(vertShader, geomShader, fragShader,
-  3, GL_POINTS, GL_POINTS);
+   program = LinkShaders3(vertShader, geomShader, fragShader);
 
const char *varyings[] = {
   gl_Position,
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 06/12] glsl/gsraytrace: Use core GL3.0 transform feedback

NV_transform_feedback is not supported by mesa.
Use transform feedback from core OpenGL 3.0.

This necessitates binding the transform feedback varyings before linking the
shader.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/gsraytrace.cpp | 72 +
 1 file changed, 31 insertions(+), 41 deletions(-)

diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
index e76a3a2..2d12745 100644
--- a/src/glsl/gsraytrace.cpp
+++ b/src/glsl/gsraytrace.cpp
@@ -34,7 +34,6 @@
 #include math.h
 #include stddef.h // offsetof
 
-// TODO: use GL_EXT_transform_feedback or GL3 equivalent
 // TODO: port to piglit too
 
 #define STRINGIFY_(x) #x
@@ -604,33 +603,12 @@ Draw(void)
dir_idxAttribLoc = glGetAttribLocation(program, dir_idx);
uv_stateAttribLoc = glGetAttribLocation(program, uv_state);
 
-   posVaryingLoc = glGetVaryingLocationNV(program, gl_Position);
-   orig_tVaryingLoc = glGetVaryingLocationNV(program, orig_t2);
-   dir_idxVaryingLoc = glGetVaryingLocationNV(program, dir_idx2);
-   uv_stateVaryingLoc = glGetVaryingLocationNV(program, uv_state2);
-   //gs.gs-getVaryingLocation(gl_Position, gs.posVaryingLoc);
-   //gs.gs-getVaryingLocation(orig_t2, gs.orig_tVaryingLoc);
-   //gs.gs-getVaryingLocation(dir_idx2, gs.dir_idxVaryingLoc);
-   //gs.gs-getVaryingLocation(uv_state2, gs.uv_stateVaryingLoc);
-
-
-   glBindBufferOffsetNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, dst, 0);
-   GLint varyings[4]= {
-  posVaryingLoc,
-  orig_tVaryingLoc,
-  dir_idxVaryingLoc,
-  uv_stateVaryingLoc
-   };
-   // I think it will be a performance win to use multiple buffer objects to 
write to
-   // instead of using the interleaved mode.
-   glTransformFeedbackVaryingsNV(program, 4, varyings, 
GL_INTERLEAVED_ATTRIBS_NV);
-
printf(%d\n, i);
//gs.fpwQuery-beginQuery();
//gs.pgQuery-beginQuery();
-   glBindBufferBaseNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, dst);
-   glBeginQuery(GL_PRIMITIVES_GENERATED_NV, pgQuery);
-   glBeginTransformFeedbackNV(GL_POINTS);
+   glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, 0, dst);
+   glBeginQuery(GL_PRIMITIVES_GENERATED, pgQuery);
+   glBeginTransformFeedback(GL_POINTS);
//gs.eyeRaysAsPoints-bindAs(ARRAY);
glBindBuffer(GL_ARRAY_BUFFER, eyeRaysAsPoints);
{
@@ -653,9 +631,9 @@ Draw(void)
   //gs.gs-set_uniform(emitNoMore, 1, 0);
   glUniform1i(glGetUniformLocation(program, emitNoMore), 0);
 
-  //glEnable(GL_RASTERIZER_DISCARD_NV);
+  //glEnable(GL_RASTERIZER_DISCARD);
   glDrawArrays(GL_POINTS, 0, WinWidth*WinHeight);
-  //glDisable(GL_RASTERIZER_DISCARD_NV);
+  //glDisable(GL_RASTERIZER_DISCARD);
 
   glDisableVertexAttribArray(uv_stateAttribLoc);
 
@@ -667,16 +645,16 @@ Draw(void)
}
//gs.eyeRaysAsPoints-unbindAs(ARRAY);
glBindBuffer(GL_ARRAY_BUFFER, 0);
-   glEndTransformFeedbackNV();
+   glEndTransformFeedback();
//gs.pgQuery-endQuery();
-   glEndQuery(GL_PRIMITIVES_GENERATED_NV);
+   glEndQuery(GL_PRIMITIVES_GENERATED);
//gs.fpwQuery-endQuery();
 
psoLog(LOG_RAW)  1st:   gs.fpwQuery-getQueryResult()  ,   
gs.pgQuery-getQueryResult()  \n;
 
 
swap(src, dst);
-   glBindBufferBaseNV(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0, 0);
+   glBindBufferBase(GL_TRANSFORM_FEEDBACK_BUFFER, 0, 0);
 
clear();
 
@@ -777,15 +755,15 @@ Reshape(int width, int height)
 
{
   size_t nElem = WinWidth*WinHeight*nRayGens;
-  glBindBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV, dst);
-  glBufferData(GL_TRANSFORM_FEEDBACK_BUFFER_NV, nElem*sizeof(GSRay), 0, 
GL_STREAM_DRAW);
-  GSRay* d = (GSRay*)glMapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 
GL_READ_WRITE);
+  glBindBuffer(GL_TRANSFORM_FEEDBACK_BUFFER, dst);
+  glBufferData(GL_TRANSFORM_FEEDBACK_BUFFER, nElem*sizeof(GSRay), 0, 
GL_STREAM_DRAW);
+  GSRay* d = (GSRay*)glMapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER, 
GL_READ_WRITE);
   for (size_t i = 0; i  nElem; i++)
   {
  d[i].dir_idx = vec4(0.0F, 0.0F, 0.0F, -1.0F);
   }
-  glUnmapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV);
-  glBindBuffer(GL_TRANSFORM_FEEDBACK_BUFFER_NV, 0);
+  glUnmapBuffer(GL_TRANSFORM_FEEDBACK_BUFFER);
+  glBindBuffer(GL_TRANSFORM_FEEDBACK_BUFFER, 0);
   //printf(Ping-pong VBO size 2x%d Kbytes.\n, 
(int)nElem*sizeof(GSRay)/1024);
}
 
@@ -866,12 +844,30 @@ Init(void)
   exit(-1);
}
 
+   if (!GLEW_VERSION_3_0)
+   {
+  fprintf(stderr, OpenGL 3.0 (needed for transform feedback) not 
+  supported!\n);
+  exit(-1);
+   }
+
vertShader = CompileShaderText(GL_VERTEX_SHADER, vsSource);
geomShader = CompileShaderText(GL_GEOMETRY_SHADER_ARB, gsSource);
fragShader = CompileShaderText(GL_FRAGMENT_SHADER, fsSource);
program = LinkShaders3WithGeometryInfo(vertShader, geomShader, fragShader,
   3, GL_POINTS, GL_POINTS);
 
+   const char *varyings[] = {
+  gl_Position,
+  orig_t2,
+

[Mesa-dev] [PATCH 11/12] geom-outlining-150: Use core geometry shaders.

Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
---
 src/glsl/geom-outlining-150.c | 26 --
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/src/glsl/geom-outlining-150.c b/src/glsl/geom-outlining-150.c
index 0bc20f0..3dffa16 100644
--- a/src/glsl/geom-outlining-150.c
+++ b/src/glsl/geom-outlining-150.c
@@ -256,7 +256,8 @@ Init(void)
   } \n;
static const char *geomShaderText =
   #version 150 \n
-  #extension GL_ARB_geometry_shader4: enable \n
+  layout(triangles) in; \n
+  layout(triangle_strip, max_vertices = 3) out; \n
   uniform vec2 ViewportSize; \n
   out vec2 Vert0, Vert1, Vert2; \n
   \n
@@ -271,11 +272,11 @@ Init(void)
  Vert0 = vpxform(gl_in[0].gl_Position); \n
  Vert1 = vpxform(gl_in[1].gl_Position); \n
  Vert2 = vpxform(gl_in[2].gl_Position); \n
- gl_Position = gl_PositionIn[0]; \n
+ gl_Position = gl_in[0].gl_Position; \n
  EmitVertex(); \n
- gl_Position = gl_PositionIn[1]; \n
+ gl_Position = gl_in[1].gl_Position; \n
  EmitVertex(); \n
- gl_Position = gl_PositionIn[2]; \n
+ gl_Position = gl_in[2].gl_Position; \n
  EmitVertex(); \n
   } \n;
static const char *fragShaderText =
@@ -309,15 +310,14 @@ Init(void)
if (!ShadersSupported())
   exit(1);
 
-   version = glGetString(GL_VERSION);
-   if (version[0] * 10 + version[2]  32) {
+   if (!GLEW_VERSION_3_2) {
   fprintf(stderr, Sorry, OpenGL 3.2 or later required.\n);
   exit(1);
}
 
VertShader = CompileShaderText(GL_VERTEX_SHADER, vertShaderText);
FragShader = CompileShaderText(GL_FRAGMENT_SHADER, fragShaderText);
-   GeomShader = CompileShaderText(GL_GEOMETRY_SHADER_ARB, geomShaderText);
+   GeomShader = CompileShaderText(GL_GEOMETRY_SHADER, geomShaderText);
 
Program = LinkShaders3(VertShader, GeomShader, FragShader);
assert(Program);
@@ -326,18 +326,8 @@ Init(void)
glBindAttribLocation(Program, 0, Vertex);
glBindFragDataLocation(Program, 0, FragColor);
 
-   /*
-* The geometry shader will receive and emit triangles.
-*/
-   glProgramParameteriARB(Program, GL_GEOMETRY_INPUT_TYPE_ARB,
-  GL_TRIANGLES);
-   glProgramParameteriARB(Program, GL_GEOMETRY_OUTPUT_TYPE_ARB,
-  GL_TRIANGLE_STRIP);
-   glProgramParameteriARB(Program,GL_GEOMETRY_VERTICES_OUT_ARB, 3);
-   CheckError(__LINE__);
-
/* relink */
-   glLinkProgramARB(Program);
+   glLinkProgram(Program);
 
assert(glIsProgram(Program));
assert(glIsShader(FragShader));
-- 
1.8.3.2

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

Re: [Mesa-dev] [PATCH 2/3] gallium: define the behavior of PIPE_USAGE_* flags properly

On Wed, Feb 5, 2014 at 10:00 PM, Brian Paul bri...@vmware.com wrote:
 On 02/04/2014 04:26 PM, Marek Olšák wrote:

 From: Marek Olšák marek.ol...@amd.com

 STATIC will be removed in the following commit.
 ---
   src/gallium/docs/source/screen.rst   | 18 --
   src/gallium/include/pipe/p_defines.h | 13 +++--
   2 files changed, 19 insertions(+), 12 deletions(-)

 diff --git a/src/gallium/docs/source/screen.rst
 b/src/gallium/docs/source/screen.rst
 index c26f98c..5932e3b 100644
 --- a/src/gallium/docs/source/screen.rst
 +++ b/src/gallium/docs/source/screen.rst
 @@ -343,12 +343,18 @@ PIPE_USAGE_*
   

   The PIPE_USAGE enums are hints about the expected usage pattern of a
 resource.
 -
 -* ``PIPE_USAGE_DEFAULT``: Expect many uploads to the resource, intermixed
 with draws.
 -* ``PIPE_USAGE_DYNAMIC``: Expect many uploads to the resource, intermixed
 with draws.
 -* ``PIPE_USAGE_STATIC``: Same as immutable (?)
 -* ``PIPE_USAGE_IMMUTABLE``: Resource will not be changed after first
 upload.
 -* ``PIPE_USAGE_STREAM``: Upload will be followed by draw, followed by
 upload, ...
 +Note that drivers must always support read and write CPU access at any
 time
 +no matter which hint they got.
 +
 +* ``PIPE_USAGE_DEFAULT``: Optimized for fast GPU access.
 +* ``PIPE_USAGE_IMMUTABLE``: Optimized for fast GPU access and the
 resource is
 +  not expected to be mapped after the first upload.


 How about mapped or changed?  For example, an immutable resource probably
 shouldn't be the dest of a blit.

Isn't it too strict? Who would want to have such a strict flag?

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

[Mesa-dev] mesa 10.1 driver specific freeze break request

2014-02-05 Thread Dave Airlie

Since r600g in master now has GL 3.3 support and it would be really
good if we could provide a consistent 3.3 support level (not looking
at you sandybridge).

So I'd like to request that I can backport the r600g specific patches
to enable geom shaders and hence 3.3. I'll use a single squashed patch
to do so. It only affects the r600g driver, so I'd like the other r600
driver maintainers to ack the idea as well as whomever else.

Otherwise I'll just make a 10.1-r600 branch and stick it in Fedora.

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

[Mesa-dev] [PATCH] i965: Fix register types in dump_instructions().

This regressed when I converted BRW_REGISTER_TYPE_* to be an abstract
type that doesn't match the hardware description.  dump_instruction()
was using reg_encoding[] from brw_disasm.c, which no longer matches
(and was incorrect for Gen8+ anyway).

This patch introduces a new function to convert the abstract enum values
into the letter suffix we expect.

Reported-by: Matt Turner matts...@gmail.com
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/brw_eu.c | 29 +
 src/mesa/drivers/dri/i965/brw_fs.cpp   |  2 +-
 src/mesa/drivers/dri/i965/brw_reg.h|  1 +
 src/mesa/drivers/dri/i965/brw_vec4.cpp |  2 +-
 4 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/brw_eu.c 
b/src/mesa/drivers/dri/i965/brw_eu.c
index dee9112..bb84029 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.c
+++ b/src/mesa/drivers/dri/i965/brw_eu.c
@@ -36,6 +36,35 @@
 
 #include glsl/ralloc.h
 
+/**
+ * Converts a BRW_REGISTER_TYPE_* enum to a short string (F, UD, and so on).
+ *
+ * This is different than reg_encoding from brw_disasm.c in that it operates
+ * on the abstract enum values, rather than the generation-specific encoding.
+ */
+const char *
+brw_reg_type_letters(unsigned type)
+{
+   const char *names[] = {
+  [BRW_REGISTER_TYPE_UD] = UD,
+  [BRW_REGISTER_TYPE_D]  = D,
+  [BRW_REGISTER_TYPE_UW] = UW,
+  [BRW_REGISTER_TYPE_W]  = W,
+  [BRW_REGISTER_TYPE_F]  = F,
+  [BRW_REGISTER_TYPE_UB] = UB,
+  [BRW_REGISTER_TYPE_B]  = B,
+  [BRW_REGISTER_TYPE_UV] = UV,
+  [BRW_REGISTER_TYPE_V]  = V,
+  [BRW_REGISTER_TYPE_VF] = VF,
+  [BRW_REGISTER_TYPE_DF] = DF,
+  [BRW_REGISTER_TYPE_HF] = HF,
+  [BRW_REGISTER_TYPE_UQ] = UQ,
+  [BRW_REGISTER_TYPE_Q]  = Q,
+   };
+   assert(type = BRW_REGISTER_TYPE_UQ);
+   return names[type];
+}
+
 /* Returns the corresponding conditional mod for swapping src0 and
  * src1 in e.g. CMP.
  */
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp 
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index d7301dd..b4675b8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3127,7 +3127,7 @@ fs_visitor::dump_instruction(backend_instruction *be_inst)
  printf(|);
 
   if (inst-src[i].file != IMM) {
- printf(:%s, reg_encoding[inst-src[i].type]);
+ printf(:%s, brw_reg_type_letters(inst-src[i].type));
   }
 
   if (i  2  inst-src[i + 1].file != BAD_FILE)
diff --git a/src/mesa/drivers/dri/i965/brw_reg.h 
b/src/mesa/drivers/dri/i965/brw_reg.h
index 9673210..978dd3f 100644
--- a/src/mesa/drivers/dri/i965/brw_reg.h
+++ b/src/mesa/drivers/dri/i965/brw_reg.h
@@ -116,6 +116,7 @@ enum brw_reg_type {
 
 unsigned brw_reg_type_to_hw_type(const struct brw_context *brw,
  enum brw_reg_type type, unsigned file);
+const char *brw_reg_type_letters(unsigned brw_reg_type);
 
 #define REG_SIZE (8*4)
 
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp 
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index d566ea1..9205081 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1168,7 +1168,7 @@ vec4_visitor::dump_instruction(backend_instruction 
*be_inst)
   if (inst-dst.writemask  8)
  printf(w);
}
-   printf(:%s, , reg_encoding[inst-dst.type]);
+   printf(:%s, , brw_reg_type_letters(inst-dst.type));
 
for (int i = 0; i  3  inst-src[i].file != BAD_FILE; i++) {
   if (inst-src[i].negate)
-- 
1.8.5.2

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

Re: [Mesa-dev] mesa 10.1 driver specific freeze break request

2014-02-05 Thread Alex Deucher

On Wed, Feb 5, 2014 at 4:23 PM, Dave Airlie airl...@gmail.com wrote:
 Since r600g in master now has GL 3.3 support and it would be really
 good if we could provide a consistent 3.3 support level (not looking
 at you sandybridge).

 So I'd like to request that I can backport the r600g specific patches
 to enable geom shaders and hence 3.3. I'll use a single squashed patch
 to do so. It only affects the r600g driver, so I'd like the other r600
 driver maintainers to ack the idea as well as whomever else.


I'd like to see it in 10.1 as well. so add my ack.

Alex

 Otherwise I'll just make a 10.1-r600 branch and stick it in Fedora.

 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] i965: Fix register types in dump_instructions().

2014-02-05 Thread Matt Turner

Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium: add geometry shader output limits

2014-02-05 Thread Grigori Goronzy

---
 src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
 src/gallium/drivers/i915/i915_screen.c   | 5 +
 src/gallium/drivers/ilo/ilo_screen.c | 3 +++
 src/gallium/drivers/llvmpipe/lp_screen.c | 3 +++
 src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 2 ++
 src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 3 +++
 src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 3 +++
 src/gallium/drivers/r300/r300_screen.c   | 2 ++
 src/gallium/drivers/r600/r600_pipe.c | 6 ++
 src/gallium/drivers/radeonsi/si_pipe.c   | 6 ++
 src/gallium/drivers/softpipe/sp_screen.c | 3 +++
 src/gallium/drivers/svga/svga_screen.c   | 2 ++
 src/gallium/include/pipe/p_defines.h | 4 +++-
 src/mesa/state_tracker/st_extensions.c   | 2 ++
 14 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
b/src/gallium/drivers/freedreno/freedreno_screen.c
index aa294b3..e1b5dae 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -212,6 +212,11 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
return 0;
 
+   /* Geometry shader output, unsupported. */
+   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
+   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
+   return 0;
+
/* Texturing. */
case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
diff --git a/src/gallium/drivers/i915/i915_screen.c 
b/src/gallium/drivers/i915/i915_screen.c
index a658b1b..9f08f86 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -257,6 +257,11 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
cap)
case PIPE_CAP_MAX_RENDER_TARGETS:
   return 1;
 
+   /* Geometry shader output, unsupported. */
+   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
+   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
+  return 0;
+
/* Fragment coordinate conventions. */
case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT:
case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
diff --git a/src/gallium/drivers/ilo/ilo_screen.c 
b/src/gallium/drivers/ilo/ilo_screen.c
index bc8f62d..9c363ac 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_screen.c
@@ -372,6 +372,9 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap 
param)
   return ILO_MAX_SO_BINDINGS / ILO_MAX_SO_BUFFERS;
case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
   return ILO_MAX_SO_BINDINGS;
+   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
+   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
+  return 0;
case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
   if (is-dev.gen = ILO_GEN(7))
  return is-dev.has_gen7_sol_reset;
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
b/src/gallium/drivers/llvmpipe/lp_screen.c
index 3f84d74..62be5c8 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -187,6 +187,9 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
pipe_cap param)
case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
   return 16*4;
+   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
+   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
+  return 0;
case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
   return 1;
case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
index 787802d..9e2a90c 100644
--- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
+++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
@@ -106,6 +106,8 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_MAX_TEXEL_OFFSET:
case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
+   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
+   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
case PIPE_CAP_TEXTURE_BARRIER:
case PIPE_CAP_SEAMLESS_CUBE_MAP:
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
index 2b6ec3a..a740adf 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
@@ -141,6 +141,9 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum 
pipe_cap param)
case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
   return 64;
+   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
+   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
+  return 1024;
case

Re: [Mesa-dev] [PATCH 2/3] gallium: define the behavior of PIPE_USAGE_* flags properly

2014-02-05 Thread Fredrik Höglund

On Wednesday 05 February 2014, Marek Olšák wrote:
 On Wed, Feb 5, 2014 at 10:00 PM, Brian Paul bri...@vmware.com wrote:
  On 02/04/2014 04:26 PM, Marek Olšák wrote:
 
  From: Marek Olšák marek.ol...@amd.com
 
  STATIC will be removed in the following commit.
  ---
src/gallium/docs/source/screen.rst   | 18 --
src/gallium/include/pipe/p_defines.h | 13 +++--
2 files changed, 19 insertions(+), 12 deletions(-)
 
  diff --git a/src/gallium/docs/source/screen.rst
  b/src/gallium/docs/source/screen.rst
  index c26f98c..5932e3b 100644
  --- a/src/gallium/docs/source/screen.rst
  +++ b/src/gallium/docs/source/screen.rst
  @@ -343,12 +343,18 @@ PIPE_USAGE_*

 
The PIPE_USAGE enums are hints about the expected usage pattern of a
  resource.
  -
  -* ``PIPE_USAGE_DEFAULT``: Expect many uploads to the resource, intermixed
  with draws.
  -* ``PIPE_USAGE_DYNAMIC``: Expect many uploads to the resource, intermixed
  with draws.
  -* ``PIPE_USAGE_STATIC``: Same as immutable (?)
  -* ``PIPE_USAGE_IMMUTABLE``: Resource will not be changed after first
  upload.
  -* ``PIPE_USAGE_STREAM``: Upload will be followed by draw, followed by
  upload, ...
  +Note that drivers must always support read and write CPU access at any
  time
  +no matter which hint they got.
  +
  +* ``PIPE_USAGE_DEFAULT``: Optimized for fast GPU access.
  +* ``PIPE_USAGE_IMMUTABLE``: Optimized for fast GPU access and the
  resource is
  +  not expected to be mapped after the first upload.
 
 
  How about mapped or changed?  For example, an immutable resource probably
  shouldn't be the dest of a blit.
 
 Isn't it too strict? Who would want to have such a strict flag?

It matches D3D11_USAGE_IMMUTABLE.  But the ARB_buffer_storage spec
explicitly says that immutable buffers can be updated with calls such as
glCopyBufferSubData and glClearBuffer.

Fredrik

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

[Mesa-dev] [RFC PATCH] mesa: add support for multiple buffer mappings

From: Marek Olšák marek.ol...@amd.com

OpenGL allows a buffer to be mapped only once, but we also map buffers
internally, e.g. in the software primitive restart fallback, for PBOs,
vbo_get_minmax_index, etc. This has always been a problem, but it will
be a bigger problem with persistent buffer mappings, which will prevent
all Mesa functions from mapping buffers for internal purposes.

This adds a driver inteface to core Mesa which supports multiple buffer
mappings and allows 2 mappings: one for the GL user and one for Mesa.

Note that Gallium supports an unlimited number of buffer and texture
mappings, so it's not really an issue for Gallium.

This is just the interface change. Please review. If you don't like it,
feel free to propose how you would do it. Thank you.

---
 src/mesa/main/dd.h |  9 ++---
 src/mesa/main/mtypes.h | 25 ++---
 2 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index ab135f4..fdd0d94 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -598,14 +598,17 @@ struct dd_function_table {
 */
void * (*MapBufferRange)( struct gl_context *ctx, GLintptr offset,
  GLsizeiptr length, GLbitfield access,
- struct gl_buffer_object *obj);
+ struct gl_buffer_object *obj,
+ enum gl_map_buffer_index index);
 
void (*FlushMappedBufferRange)(struct gl_context *ctx,
   GLintptr offset, GLsizeiptr length,
-  struct gl_buffer_object *obj);
+  struct gl_buffer_object *obj,
+  enum gl_map_buffer_index index);
 
GLboolean (*UnmapBuffer)( struct gl_context *ctx,
-struct gl_buffer_object *obj );
+struct gl_buffer_object *obj,
+ enum gl_map_buffer_index index);
/*@}*/
 
/**
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 4aaad16..5200377 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -1437,6 +1437,22 @@ struct gl_viewport_attrib
GLmatrix _WindowMap;/** Mapping transformation as a 
matrix. */
 };
 
+enum gl_map_buffer_index {
+   MAP_CTX_USER,
+   MAP_CTX_INTERNAL,
+
+   NUM_MAP_BUFFER_CONTEXTS
+};
+
+/**
+ * Fields describing a mapped buffer range.
+ */
+struct gl_map_buffer_context {
+   GLbitfield AccessFlags; /** Mask of GL_MAP_x_BIT flags */
+   GLvoid *Pointer; /** User-space address of mapping */
+   GLintptr Offset; /** Mapped offset */
+   GLsizeiptr Length;   /** Mapped length */
+};
 
 /**
  * GL_ARB_vertex/pixel_buffer_object buffer object
@@ -1451,17 +1467,12 @@ struct gl_buffer_object
GLbitfield StorageFlags; /** GL_MAP_PERSISTENT_BIT, etc. */
GLsizeiptrARB Size;  /** Size of buffer storage in bytes */
GLubyte *Data;   /** Location of storage either in RAM or VRAM. */
-   /** Fields describing a mapped buffer */
-   /*@{*/
-   GLbitfield AccessFlags; /** Mask of GL_MAP_x_BIT flags */
-   GLvoid *Pointer; /** User-space address of mapping */
-   GLintptr Offset; /** Mapped offset */
-   GLsizeiptr Length;   /** Mapped length */
-   /*@}*/
GLboolean DeletePending;   /** true if buffer object is removed from the 
hash */
GLboolean Written;   /** Ever written to? (for debugging) */
GLboolean Purgeable; /** Is the buffer purgeable under memory pressure? */
GLboolean Immutable; /** GL_ARB_buffer_storage */
+
+   struct gl_map_buffer_context Mappings[NUM_MAP_BUFFER_CONTEXTS];
 };
 
 
-- 
1.8.3.2

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

Re: [Mesa-dev] [PATCH 2/3] gallium: define the behavior of PIPE_USAGE_* flags properly

Okay, sounds good.

Marek

On Wed, Feb 5, 2014 at 11:03 PM, Fredrik Höglund fred...@kde.org wrote:
 On Wednesday 05 February 2014, Marek Olšák wrote:
 On Wed, Feb 5, 2014 at 10:00 PM, Brian Paul bri...@vmware.com wrote:
  On 02/04/2014 04:26 PM, Marek Olšák wrote:
 
  From: Marek Olšák marek.ol...@amd.com
 
  STATIC will be removed in the following commit.
  ---
src/gallium/docs/source/screen.rst   | 18 --
src/gallium/include/pipe/p_defines.h | 13 +++--
2 files changed, 19 insertions(+), 12 deletions(-)
 
  diff --git a/src/gallium/docs/source/screen.rst
  b/src/gallium/docs/source/screen.rst
  index c26f98c..5932e3b 100644
  --- a/src/gallium/docs/source/screen.rst
  +++ b/src/gallium/docs/source/screen.rst
  @@ -343,12 +343,18 @@ PIPE_USAGE_*

 
The PIPE_USAGE enums are hints about the expected usage pattern of a
  resource.
  -
  -* ``PIPE_USAGE_DEFAULT``: Expect many uploads to the resource, intermixed
  with draws.
  -* ``PIPE_USAGE_DYNAMIC``: Expect many uploads to the resource, intermixed
  with draws.
  -* ``PIPE_USAGE_STATIC``: Same as immutable (?)
  -* ``PIPE_USAGE_IMMUTABLE``: Resource will not be changed after first
  upload.
  -* ``PIPE_USAGE_STREAM``: Upload will be followed by draw, followed by
  upload, ...
  +Note that drivers must always support read and write CPU access at any
  time
  +no matter which hint they got.
  +
  +* ``PIPE_USAGE_DEFAULT``: Optimized for fast GPU access.
  +* ``PIPE_USAGE_IMMUTABLE``: Optimized for fast GPU access and the
  resource is
  +  not expected to be mapped after the first upload.
 
 
  How about mapped or changed?  For example, an immutable resource probably
  shouldn't be the dest of a blit.

 Isn't it too strict? Who would want to have such a strict flag?

 It matches D3D11_USAGE_IMMUTABLE.  But the ARB_buffer_storage spec
 explicitly says that immutable buffers can be updated with calls such as
 glCopyBufferSubData and glClearBuffer.

 Fredrik

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

Re: [Mesa-dev] mesa 10.1 driver specific freeze break request

2014-02-05 Thread Ian Romanick

On 02/05/2014 01:23 PM, Dave Airlie wrote:
 Since r600g in master now has GL 3.3 support and it would be really
 good if we could provide a consistent 3.3 support level (not looking
 at you sandybridge).
 
 So I'd like to request that I can backport the r600g specific patches
 to enable geom shaders and hence 3.3. I'll use a single squashed patch
 to do so. It only affects the r600g driver, so I'd like the other r600
 driver maintainers to ack the idea as well as whomever else.
 
 Otherwise I'll just make a 10.1-r600 branch and stick it in Fedora.

FWIW... I think it's better to have it in 10.1 than to have Fedora's
10.1 be different.

 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] gallium: add geometry shader output limits

Am 05.02.2014 22:58, schrieb Grigori Goronzy:
 ---
  src/gallium/drivers/freedreno/freedreno_screen.c | 5 +
  src/gallium/drivers/i915/i915_screen.c   | 5 +
  src/gallium/drivers/ilo/ilo_screen.c | 3 +++
  src/gallium/drivers/llvmpipe/lp_screen.c | 3 +++
  src/gallium/drivers/nouveau/nv30/nv30_screen.c   | 2 ++
  src/gallium/drivers/nouveau/nv50/nv50_screen.c   | 3 +++
  src/gallium/drivers/nouveau/nvc0/nvc0_screen.c   | 3 +++
  src/gallium/drivers/r300/r300_screen.c   | 2 ++
  src/gallium/drivers/r600/r600_pipe.c | 6 ++
  src/gallium/drivers/radeonsi/si_pipe.c   | 6 ++
  src/gallium/drivers/softpipe/sp_screen.c | 3 +++
  src/gallium/drivers/svga/svga_screen.c   | 2 ++
  src/gallium/include/pipe/p_defines.h | 4 +++-
  src/mesa/state_tracker/st_extensions.c   | 2 ++
  14 files changed, 48 insertions(+), 1 deletion(-)
 
 diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c 
 b/src/gallium/drivers/freedreno/freedreno_screen.c
 index aa294b3..e1b5dae 100644
 --- a/src/gallium/drivers/freedreno/freedreno_screen.c
 +++ b/src/gallium/drivers/freedreno/freedreno_screen.c
 @@ -212,6 +212,11 @@ fd_screen_get_param(struct pipe_screen *pscreen, enum 
 pipe_cap param)
   case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
   return 0;
  
 + /* Geometry shader output, unsupported. */
 + case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
 + case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
 + return 0;
 +
   /* Texturing. */
   case PIPE_CAP_MAX_TEXTURE_2D_LEVELS:
   case PIPE_CAP_MAX_TEXTURE_3D_LEVELS:
 diff --git a/src/gallium/drivers/i915/i915_screen.c 
 b/src/gallium/drivers/i915/i915_screen.c
 index a658b1b..9f08f86 100644
 --- a/src/gallium/drivers/i915/i915_screen.c
 +++ b/src/gallium/drivers/i915/i915_screen.c
 @@ -257,6 +257,11 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap 
 cap)
 case PIPE_CAP_MAX_RENDER_TARGETS:
return 1;
  
 +   /* Geometry shader output, unsupported. */
 +   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
 +   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
 +  return 0;
 +
 /* Fragment coordinate conventions. */
 case PIPE_CAP_TGSI_FS_COORD_ORIGIN_UPPER_LEFT:
 case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_HALF_INTEGER:
 diff --git a/src/gallium/drivers/ilo/ilo_screen.c 
 b/src/gallium/drivers/ilo/ilo_screen.c
 index bc8f62d..9c363ac 100644
 --- a/src/gallium/drivers/ilo/ilo_screen.c
 +++ b/src/gallium/drivers/ilo/ilo_screen.c
 @@ -372,6 +372,9 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap 
 param)
return ILO_MAX_SO_BINDINGS / ILO_MAX_SO_BUFFERS;
 case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
return ILO_MAX_SO_BINDINGS;
 +   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
 +   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
 +  return 0;
 case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
if (is-dev.gen = ILO_GEN(7))
   return is-dev.has_gen7_sol_reset;
 diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c 
 b/src/gallium/drivers/llvmpipe/lp_screen.c
 index 3f84d74..62be5c8 100644
 --- a/src/gallium/drivers/llvmpipe/lp_screen.c
 +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
 @@ -187,6 +187,9 @@ llvmpipe_get_param(struct pipe_screen *screen, enum 
 pipe_cap param)
 case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
 case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
return 16*4;
 +   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
 +   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
 +  return 0;
I think this should be 1024 for llvmpipe (for both). Not that we claim
to support GL 3.2 right now...



 case PIPE_CAP_STREAM_OUTPUT_PAUSE_RESUME:
return 1;
 case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
 diff --git a/src/gallium/drivers/nouveau/nv30/nv30_screen.c 
 b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
 index 787802d..9e2a90c 100644
 --- a/src/gallium/drivers/nouveau/nv30/nv30_screen.c
 +++ b/src/gallium/drivers/nouveau/nv30/nv30_screen.c
 @@ -106,6 +106,8 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum 
 pipe_cap param)
 case PIPE_CAP_MAX_TEXEL_OFFSET:
 case PIPE_CAP_MAX_STREAM_OUTPUT_SEPARATE_COMPONENTS:
 case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
 +   case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
 +   case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
 case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS:
 case PIPE_CAP_TEXTURE_BARRIER:
 case PIPE_CAP_SEAMLESS_CUBE_MAP:
 diff --git a/src/gallium/drivers/nouveau/nv50/nv50_screen.c 
 b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
 index 2b6ec3a..a740adf 100644
 --- a/src/gallium/drivers/nouveau/nv50/nv50_screen.c
 +++ b/src/gallium/drivers/nouveau/nv50/nv50_screen.c
 @@ -141,6 +141,9 @@ nv50_screen_get_param(struct pipe_screen *pscreen, enum 
 pipe_cap param)
 case

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

I hadn't looked at GL_ARB_buffer_storage. I need to read more closely, but at a 
glance i looks like GL_MAP_PERSISTENT_BIT alone is okay (app needs to call 
FlushMappedBufferRange must be called to guarantee coherence) but if 
GL_MAP_COHERENCE_BIT is set we are indeed in face of the same issue... :-(

Even worse, being part of GL 4.4 and there being no way for the implementation 
to fail GL_MAP_COHERENCE_BIT mappings, it means there is no way to avoid 
supporting it...

Jose

Note to self: my time would be better spent on reviewing extensions before they 
are ratified, than ranting after the fact...


- Original Message -
 However, GL_ARB_buffer_storage (OpenGL 4.4) with GL_MAP_PERSISTENT_BIT
 isn't much different. The only difference I see between
 ARB_buffer_storage and AMD_pinned_memory is that AMD_pinned_memory
 allows mapping CPU memory to the GPU address space permanently, while
 ARB_buffer_storage allows mapping GPU memory to the CPU address
 permanently. At the end of the day, both the GPU and the CPU can read
 and modify the same buffer and all they need to use for
 synchronization is fences.
 
 Marek
 
 On Wed, Feb 5, 2014 at 8:10 PM, Jose Fonseca jfons...@vmware.com wrote:
 
 
  - Original Message -
 
 
  - Original Message -
   On 05.02.2014 18:08, Jose Fonseca wrote:
I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
would
have been alright if it wasn't for this bit in
https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_memory.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=pA%2FnK9X3xx0wAlMUZ24PfQ1mW6wAMdTUujz%2Bx7LRwCA%3D%0As=ebbe1f51deb46c81578b3c125b16e31b5f4b28c1d47e283bc9ef588e2707024d
which says:
   
 2) Can the application still use the buffer using the CPU
 address?
   
 RESOLVED: YES. However, this access would be completely
 non synchronized to the OpenGL pipeline, unless explicit
 synchronization is being used (for example, through glFinish
 or
 by
 using
 sync objects).
   
And I'm imagining apps which are streaming vertex data doing precisely
just
that...
   
  
   I don't understand your concern, this is exactly the same behavior
   GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that
   properly. How does apitrace handle it?
 
  GL_AMD_pinned_memory it's nothing like GL_ARB_map_buffer_range's
  GL_MAP_UNSYCHRONIZED_BIT:
 
  - When an app touches memory returned by
  glMapBufferRange(GL_MAP_UNSYCHRONIZED_BIT) it will communicate back to the
  OpenGL driver which bytes it actually touched via the
  glFlushMappedBufferRange (unless the apps doesn't care about performance
  and
  doesn't call glFlushMappedBufferRange at all, which is silly as it will
  force the OpenGL driver to assumed the whole range changed)
 
In this case, the OpenGL driver (hence apitrace) should get all the
information it needs about which bytes were updated betwen
glMap/glUnmap.
 
  - When an app touches memory bound via GL_AMD_pinned_memory outside
  glMap/glUnmap, there are be _no_ hints whatsever.  The OpenGL driver might
  not care as the memory is shared between CPU and GPU, so all is good as
  far
  is it is concerned, but all the changes the app does are invisible at an
  API
  level, hence apitrace will not be able to catch them unless it does
  onerous
  heuristics.
 
 
  So while both extensions allow unsynchronized access, but lack of
  synchronization is not my concern. My concern is that GL_AMD_pinned_memory
  allows *hidden* access to GPU memory.
 
  Just for the record, the challenges GL_AMD_pinned_memory presents to
  Apitrace are much similar to the old-fashioned OpenGL user array pointers:
  an app is free to change the contents of memory pointed by user arrays
  pointers at any point in time, except during a draw call.  This means that
  before every draw call, Apitrace needs to scavenge all the user memory
  pointers and write their contents to the trace file, just in case the app
  changed it..
 
  In order to support GL_AMD_pinned_memory, for every draw call Apitrace
  would also need to walk over bound GL_AMD_pinned_memory (and nowadays
  there are loads of bound points!), and check if data changed, and
  serialize in the trace file if it did...
 
 
  I never care much about performance of Apitrace with user array pointers:
  it is an old paradigm; only old apps use it, or programmers which don't
  particular care about performance -- either way, a performance conscious
  app developer would use VBOs hence never hit the problem at all.  My
  displeasure with GL_AMD_pinned_memory is that it essentially flips
  everything on its head -- it encourages a paradigm which apitrace will
  never be able to handle properly.
 
 
  People often complain that OpenGL development tools are poor compared with
  Direct3D's.

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

The synchronization for non-coherent persistent mappings can also be done using:

glMemoryBarrier(GL_CLIENT_MAPPED_BUFFER_BARRIER_BIT);

In which case you don't know the range either. However I fully support
the addition of coherent persistent mappings to GL. It's perfect for
uploading data without the GL API overhead.

Marek

On Thu, Feb 6, 2014 at 12:49 AM, Jose Fonseca jfons...@vmware.com wrote:
 I hadn't looked at GL_ARB_buffer_storage. I need to read more closely, but at 
 a glance i looks like GL_MAP_PERSISTENT_BIT alone is okay (app needs to call 
 FlushMappedBufferRange must be called to guarantee coherence) but if 
 GL_MAP_COHERENCE_BIT is set we are indeed in face of the same issue... :-(

 Even worse, being part of GL 4.4 and there being no way for the 
 implementation to fail GL_MAP_COHERENCE_BIT mappings, it means there is no 
 way to avoid supporting it...

 Jose

 Note to self: my time would be better spent on reviewing extensions before 
 they are ratified, than ranting after the fact...


 - Original Message -
 However, GL_ARB_buffer_storage (OpenGL 4.4) with GL_MAP_PERSISTENT_BIT
 isn't much different. The only difference I see between
 ARB_buffer_storage and AMD_pinned_memory is that AMD_pinned_memory
 allows mapping CPU memory to the GPU address space permanently, while
 ARB_buffer_storage allows mapping GPU memory to the CPU address
 permanently. At the end of the day, both the GPU and the CPU can read
 and modify the same buffer and all they need to use for
 synchronization is fences.

 Marek

 On Wed, Feb 5, 2014 at 8:10 PM, Jose Fonseca jfons...@vmware.com wrote:
 
 
  - Original Message -
 
 
  - Original Message -
   On 05.02.2014 18:08, Jose Fonseca wrote:
I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
would
have been alright if it wasn't for this bit in
https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_memory.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=pA%2FnK9X3xx0wAlMUZ24PfQ1mW6wAMdTUujz%2Bx7LRwCA%3D%0As=ebbe1f51deb46c81578b3c125b16e31b5f4b28c1d47e283bc9ef588e2707024d
which says:
   
 2) Can the application still use the buffer using the CPU
 address?
   
 RESOLVED: YES. However, this access would be completely
 non synchronized to the OpenGL pipeline, unless explicit
 synchronization is being used (for example, through glFinish
 or
 by
 using
 sync objects).
   
And I'm imagining apps which are streaming vertex data doing precisely
just
that...
   
  
   I don't understand your concern, this is exactly the same behavior
   GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that
   properly. How does apitrace handle it?
 
  GL_AMD_pinned_memory it's nothing like GL_ARB_map_buffer_range's
  GL_MAP_UNSYCHRONIZED_BIT:
 
  - When an app touches memory returned by
  glMapBufferRange(GL_MAP_UNSYCHRONIZED_BIT) it will communicate back to the
  OpenGL driver which bytes it actually touched via the
  glFlushMappedBufferRange (unless the apps doesn't care about performance
  and
  doesn't call glFlushMappedBufferRange at all, which is silly as it will
  force the OpenGL driver to assumed the whole range changed)
 
In this case, the OpenGL driver (hence apitrace) should get all the
information it needs about which bytes were updated betwen
glMap/glUnmap.
 
  - When an app touches memory bound via GL_AMD_pinned_memory outside
  glMap/glUnmap, there are be _no_ hints whatsever.  The OpenGL driver might
  not care as the memory is shared between CPU and GPU, so all is good as
  far
  is it is concerned, but all the changes the app does are invisible at an
  API
  level, hence apitrace will not be able to catch them unless it does
  onerous
  heuristics.
 
 
  So while both extensions allow unsynchronized access, but lack of
  synchronization is not my concern. My concern is that GL_AMD_pinned_memory
  allows *hidden* access to GPU memory.
 
  Just for the record, the challenges GL_AMD_pinned_memory presents to
  Apitrace are much similar to the old-fashioned OpenGL user array pointers:
  an app is free to change the contents of memory pointed by user arrays
  pointers at any point in time, except during a draw call.  This means that
  before every draw call, Apitrace needs to scavenge all the user memory
  pointers and write their contents to the trace file, just in case the app
  changed it..
 
  In order to support GL_AMD_pinned_memory, for every draw call Apitrace
  would also need to walk over bound GL_AMD_pinned_memory (and nowadays
  there are loads of bound points!), and check if data changed, and
  serialize in the trace file if it did...
 
 
  I never care much about performance of Apitrace with user array pointers:
  it is an old paradigm; only old apps use it, or programmers which don't

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

2014-02-05 Thread Ian Romanick

On 02/05/2014 11:10 AM, Jose Fonseca wrote:
 
 
 - Original Message -


 - Original Message -
 On 05.02.2014 18:08, Jose Fonseca wrote:
 I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
 would
 have been alright if it wasn't for this bit in
 https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_memory.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=pA%2FnK9X3xx0wAlMUZ24PfQ1mW6wAMdTUujz%2Bx7LRwCA%3D%0As=ebbe1f51deb46c81578b3c125b16e31b5f4b28c1d47e283bc9ef588e2707024d
 which says:

  2) Can the application still use the buffer using the CPU address?

  RESOLVED: YES. However, this access would be completely
  non synchronized to the OpenGL pipeline, unless explicit
  synchronization is being used (for example, through glFinish or
  by
  using
  sync objects).

 And I'm imagining apps which are streaming vertex data doing precisely
 just
 that...


 I don't understand your concern, this is exactly the same behavior
 GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that
 properly. How does apitrace handle it?

 GL_AMD_pinned_memory it's nothing like GL_ARB_map_buffer_range's
 GL_MAP_UNSYCHRONIZED_BIT:

 - When an app touches memory returned by
 glMapBufferRange(GL_MAP_UNSYCHRONIZED_BIT) it will communicate back to the
 OpenGL driver which bytes it actually touched via the
 glFlushMappedBufferRange (unless the apps doesn't care about performance and
 doesn't call glFlushMappedBufferRange at all, which is silly as it will
 force the OpenGL driver to assumed the whole range changed)

   In this case, the OpenGL driver (hence apitrace) should get all the
   information it needs about which bytes were updated betwen glMap/glUnmap.

 - When an app touches memory bound via GL_AMD_pinned_memory outside
 glMap/glUnmap, there are be _no_ hints whatsever.  The OpenGL driver might
 not care as the memory is shared between CPU and GPU, so all is good as far
 is it is concerned, but all the changes the app does are invisible at an API
 level, hence apitrace will not be able to catch them unless it does onerous
 heuristics.


 So while both extensions allow unsynchronized access, but lack of
 synchronization is not my concern. My concern is that GL_AMD_pinned_memory
 allows *hidden* access to GPU memory.
 
 Just for the record, the challenges GL_AMD_pinned_memory presents to Apitrace 
 are much similar to the old-fashioned OpenGL user array pointers: an app is 
 free to change the contents of memory pointed by user arrays pointers at any 
 point in time, except during a draw call.  This means that before every draw 
 call, Apitrace needs to scavenge all the user memory pointers and write their 
 contents to the trace file, just in case the app changed it..
 
 In order to support GL_AMD_pinned_memory, for every draw call Apitrace would 
 also need to walk over bound GL_AMD_pinned_memory (and nowadays there are 
 loads of bound points!), and check if data changed, and serialize in the 
 trace file if it did...
 
 
 I never care much about performance of Apitrace with user array pointers: it 
 is an old paradigm; only old apps use it, or programmers which don't 
 particular care about performance -- either way, a performance conscious app 
 developer would use VBOs hence never hit the problem at all.  My displeasure 
 with GL_AMD_pinned_memory is that it essentially flips everything on its head 
 -- it encourages a paradigm which apitrace will never be able to handle 
 properly. 
 
 
 People often complain that OpenGL development tools are poor compared with 
 Direct3D's.  An important fact they often miss is that Direct3D API is 
 several orders of mangnitude tool friendlier: it's clear that Direct3D API's 
 cares about things like allowing to query all state back, whereas OpenGL is 
 more fire and forget and never look back -- the main concern in OpenGL is 
 ensuring that state can go from App to Driver fast, but little thought is 
 often given to ensuring that one can read whole state back, or ensuring that 
 one can intercept all state as it goes between the app and the driver...
 
 
 In this particular case, if the answer for Can the application still use the 
 buffer using the CPU address? was a NO, the world would be a much better 
 place.

I suspect the reason that they didn't do that is it would imply a very
expensive validation step at draw time.  There are a whole bunch of
technologies in newer GL implementations that will make tracing a
miserable prospect. :(

 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

Re: [Mesa-dev] [PATCH 03/12] glsl/gsraytrace: Use LINE macro to set line numbers in GLSL source strings.

2014-02-05 Thread Ian Romanick

On 02/05/2014 01:07 PM, Fabian Bieler wrote:
 The hardcoded numbers are a few lines off at the moment.
 Keeping track of the numbers through further modifications is inconvenient.
 The __LINE__ constant takes care of this automatically.
 
 Signed-off-by: Fabian Bieler fabianbie...@fastmail.fm
 ---
  src/glsl/gsraytrace.cpp | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)
 
 diff --git a/src/glsl/gsraytrace.cpp b/src/glsl/gsraytrace.cpp
 index 62a584d..31e9fda 100644
 --- a/src/glsl/gsraytrace.cpp
 +++ b/src/glsl/gsraytrace.cpp
 @@ -37,6 +37,10 @@
  // TODO: use GL_EXT_transform_feedback or GL3 equivalent
  // TODO: port to piglit too
  
 +#define STRINGIFY_(x) #x
 +#define STRINGIFY(x) STRINGIFY_(x)
 +#define S__LINE__ STRINGIFY(__LINE__)
 +
  static const float INF=.9F;
  
  static int Win;
 @@ -67,7 +71,7 @@ float rot[9] = {1,0,0,  0,1,0,   0,0,1};
  static const char* vsSource =
\n
  #version 120  \n
 -#line 63 63   \n
 +#line  S__LINE__ S__LINE__ \n

I don't think this is correct before or after.  The first value is the
line number, and the second value is the source number (like the file
name in C or C++).  Setting the source number to the line number
seems... weird, at best.

I think

 #line  S__LINE__ \n

is correct.

  #define SHADOWS   \n
  #define RECURSION \n
\n
 @@ -249,7 +253,7 @@ static const char* vsSource =
  
  static const char* gsSource = 
  #version 120 \n
 -#line 245 245\n
 +#line  S__LINE__ S__LINE__ \n
  #extension GL_ARB_geometry_shader4: require  \n
   \n
  #define SHADOWS  \n
 @@ -388,7 +392,7 @@ static const char* gsSource =
  
  static const char* fsSource = 
  #version 120 \n
 -#line 384 384\n
 +#line  S__LINE__ S__LINE__ \n
   \n
  #define SHADOWS  \n
  #define RECURSION\n
 

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

[Mesa-dev] Fwd: [GSoC2014] Call for projects ideas and mentors

2014-02-05 Thread Martin Peres

Re-send to include the wayland and mesa mailing lists.

Sorry for the noise

 Original Message 
Subject:[GSoC2014] Call for projects ideas and mentors
Date:   Thu, 06 Feb 2014 01:03:05 +0100
From:   Martin Peres martin.pe...@free.fr
To: 	dri-de...@lists.freedesktop.org dri-de...@lists.freedesktop.org, 
xorg-de...@lists.x.org, x...@lists.x.org, nouveau 
nouv...@lists.freedesktop.org

Hi, fellow graphics stack developers,

Now that FOSDEM is over, it is time to think about the
Google Summer of Code 2014!

If you would like to propose a project for the GSoC 2014, please
write your proposals at [1], before the 14th of February, in order
to increase our chances of being an accepted organization.

If you simply would potentially be interested in being a mentor,
please also contact me as Google wants to have an estimate of
the number of potential mentors we would have.

If you have any questions regarding the GSoC or need any additional
information, please answer in this thread.

Cheers,
Martin

[1] http://xorg.freedesktop.org/wiki/SummerOfCodeIdeas/

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

[Mesa-dev] [PATCH] st/mesa: fix crash when a shader uses a TBO and it's not bound

From: Marek Olšák marek.ol...@amd.com

This binds a NULL sampler view in that case.

Cc: 10.1 10.0 mesa-sta...@lists.freedesktop.org
---
 src/mesa/state_tracker/st_cb_texture.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/mesa/state_tracker/st_cb_texture.c 
b/src/mesa/state_tracker/st_cb_texture.c
index 81a5d9b..824a13e 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -1483,6 +1483,12 @@ st_finalize_texture(struct gl_context *ctx,
if (tObj-Target == GL_TEXTURE_BUFFER) {
   struct st_buffer_object *st_obj = st_buffer_object(tObj-BufferObject);
 
+  if (!st_obj) {
+ pipe_resource_reference(stObj-pt, NULL);
+ pipe_sampler_view_reference(stObj-sampler_view, NULL);
+ return GL_TRUE;
+  }
+
   if (st_obj-buffer != stObj-pt) {
  pipe_resource_reference(stObj-pt, st_obj-buffer);
  pipe_sampler_view_release(st-pipe, stObj-sampler_view);
-- 
1.8.3.2

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

[Mesa-dev] [PATCH 09/11] meta: Drop the src == dst restriction on meta glBlitFramebuffer().

From the GL_ARB_fbo spec:

If the source and destination buffers are identical, and the
source and destination rectangles overlap, the result of the blit
operation is undefined.

As far as I know, that's the only thing that would have been of concern
for this.
---
 src/mesa/drivers/common/meta_blit.c | 24 +---
 1 file changed, 1 insertion(+), 23 deletions(-)

diff --git a/src/mesa/drivers/common/meta_blit.c 
b/src/mesa/drivers/common/meta_blit.c
index 973ee1b..9c3ff9b 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -267,8 +267,7 @@ setup_glsl_blit_framebuffer(struct gl_context *ctx,
  * Try to do a color-only glBlitFramebuffer using texturing.
  *
  * We can do this when the src renderbuffer is actually a texture, or when the
- * driver expposes BindRenderbufferTexImage().  But if the src buffer == dst
- * buffer we cannot do this.
+ * driver expposes BindRenderbufferTexImage().
  */
 static bool
 blitframebuffer_texture(struct gl_context *ctx,
@@ -277,9 +276,7 @@ blitframebuffer_texture(struct gl_context *ctx,
 GLenum filter, GLint flipX, GLint flipY,
 GLboolean glsl_version)
 {
-   const struct gl_framebuffer *drawFb = ctx-DrawBuffer;
const struct gl_framebuffer *readFb = ctx-ReadBuffer;
-   const struct gl_renderbuffer_attachment *drawAtt;
const struct gl_renderbuffer_attachment *readAtt =
   readFb-Attachment[readFb-_ColorReadBufferIndex];
struct blit_state *blit = ctx-Meta-Blit;
@@ -295,7 +292,6 @@ blitframebuffer_texture(struct gl_context *ctx,
GLuint sampler, samplerSave =
   ctx-Texture.Unit[ctx-Texture.CurrentUnit].Sampler ?
   ctx-Texture.Unit[ctx-Texture.CurrentUnit].Sampler-Name : 0;
-   int i;
GLuint tempTex = 0;
 
if (readAtt  readAtt-Texture) {
@@ -346,24 +342,6 @@ blitframebuffer_texture(struct gl_context *ctx,
baseLevelSave = texObj-BaseLevel;
maxLevelSave = texObj-MaxLevel;
 
-   /* Iterate through all draw buffers */
-   for (i = 0; i  ctx-DrawBuffer-_NumColorDrawBuffers; i++) {
-  int idx = ctx-DrawBuffer-_ColorDrawBufferIndexes[i];
-  if (idx == -1)
- continue;
-  drawAtt = drawFb-Attachment[idx];
-
-  if (drawAtt-Texture == readAtt-Texture) {
- /* Can't use same texture as both the source and dest.  We need
-  * to handle overlapping blits and besides, some hw may not
-  * support this.
-  */
- if (tempTex)
-_mesa_DeleteTextures(1, tempTex);
- return false;
-  }
-   }
-
/* Choose between glsl version and fixed function version of
 * BlitFramebuffer function.
 */
-- 
1.9.rc1

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

[Mesa-dev] [PATCH 10/11] meta: Add acceleration for depth glBlitFramebuffer().

Surprisingly, the GLSL shaders already wrote the sampled r value to
FragDepth.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51600
---
 src/mesa/drivers/common/meta_blit.c | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/common/meta_blit.c 
b/src/mesa/drivers/common/meta_blit.c
index 9c3ff9b..46c8efd 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -264,7 +264,7 @@ setup_glsl_blit_framebuffer(struct gl_context *ctx,
 }
 
 /**
- * Try to do a color-only glBlitFramebuffer using texturing.
+ * Try to do a color or depth glBlitFramebuffer using texturing.
  *
  * We can do this when the src renderbuffer is actually a texture, or when the
  * driver expposes BindRenderbufferTexImage().
@@ -274,11 +274,12 @@ blitframebuffer_texture(struct gl_context *ctx,
 GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1,
 GLint dstX0, GLint dstY0, GLint dstX1, GLint dstY1,
 GLenum filter, GLint flipX, GLint flipY,
-GLboolean glsl_version)
+GLboolean glsl_version, GLboolean do_depth)
 {
const struct gl_framebuffer *readFb = ctx-ReadBuffer;
+   int att_index = do_depth ? BUFFER_DEPTH : readFb-_ColorReadBufferIndex;
const struct gl_renderbuffer_attachment *readAtt =
-  readFb-Attachment[readFb-_ColorReadBufferIndex];
+  readFb-Attachment[att_index];
struct blit_state *blit = ctx-Meta-Blit;
const GLint dstX = MIN2(dstX0, dstX1);
const GLint dstY = MIN2(dstY0, dstY1);
@@ -441,8 +442,11 @@ blitframebuffer_texture(struct gl_context *ctx,
 
/* setup viewport */
_mesa_set_viewport(ctx, 0, dstX, dstY, dstW, dstH);
-   _mesa_ColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);
-   _mesa_DepthMask(GL_FALSE);
+   _mesa_ColorMask(!do_depth, !do_depth, !do_depth, !do_depth);
+   _mesa_set_enable(ctx, GL_DEPTH_TEST, do_depth);
+   _mesa_DepthMask(do_depth);
+   _mesa_DepthFunc(GL_ALWAYS);
+
_mesa_DrawArrays(GL_TRIANGLE_FAN, 0, 4);
 
/* Restore texture object state, the texture binding will
@@ -520,7 +524,7 @@ _mesa_meta_BlitFramebuffer(struct gl_context *ctx,
   if (blitframebuffer_texture(ctx, srcX0, srcY0, srcX1, srcY1,
   dstX0, dstY0, dstX1, dstY1,
   filter, dstFlipX, dstFlipY,
-  use_glsl_version)) {
+  use_glsl_version, false)) {
  mask = ~GL_COLOR_BUFFER_BIT;
  if (mask == 0x0) {
 _mesa_meta_end(ctx);
@@ -529,6 +533,19 @@ _mesa_meta_BlitFramebuffer(struct gl_context *ctx,
   }
}
 
+   if (mask  GL_DEPTH_BUFFER_BIT  use_glsl_version) {
+  if (blitframebuffer_texture(ctx, srcX0, srcY0, srcX1, srcY1,
+  dstX0, dstY0, dstX1, dstY1,
+  filter, dstFlipX, dstFlipY,
+  use_glsl_version, true)) {
+ mask = ~GL_DEPTH_BUFFER_BIT;
+ if (mask == 0x0) {
+_mesa_meta_end(ctx);
+return;
+ }
+  }
+   }
+
/* Choose between glsl version and fixed function version of
 * BlitFramebuffer function.
 */
-- 
1.9.rc1

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

[Mesa-dev] meta: single-copy glBlitFramebuffer from renderbuffers, depth.

We're looking at the option of using meta to implement glBlitFramebuffer()
on gen8, to avoid writing another set of blorp code.  I think it's looking
pretty promising.  Here's a first patch series that gets us to the point
of fixing glBlitFramebuffer(DEPTH) performance on gm45, which seems like a
nice concrete improvement for the meta path.

Note that for patch 6, if you're reviewing, you'll want to git show -b
instead.  It can be found on the meta-blit branch of my tree.  (Note:
there are a couple of other commits on that tree that are not sent for
review).

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

[Mesa-dev] [PATCH 04/11] meta: Fold the texture setup into _mesa_meta_setup_copypix_texture().

There was this funny argument passed to setup for did alloc decide we
need to allocate new texture storage?, which goes away if we don't have
the caller do alloc as a separate step.
---
 src/mesa/drivers/common/meta.c  | 15 +++
 src/mesa/drivers/common/meta.h  |  1 -
 src/mesa/drivers/common/meta_blit.c |  4 +---
 3 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 33ea67f..ea1eb29 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -1067,18 +1067,21 @@ _mesa_meta_alloc_texture(struct temp_texture *tex,
 void
 _mesa_meta_setup_copypix_texture(struct gl_context *ctx,
  struct temp_texture *tex,
- GLboolean newTex,
  GLint srcX, GLint srcY,
  GLsizei width, GLsizei height,
  GLenum intFormat,
  GLenum filter)
 {
+   bool newTex;
+
_mesa_BindTexture(tex-Target, tex-TexObj);
_mesa_TexParameteri(tex-Target, GL_TEXTURE_MIN_FILTER, filter);
_mesa_TexParameteri(tex-Target, GL_TEXTURE_MAG_FILTER, filter);
if (ctx-API == API_OPENGL_COMPAT || ctx-API == API_OPENGLES)
   _mesa_TexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
 
+   newTex = _mesa_meta_alloc_texture(tex, width, height, intFormat);
+
/* copy framebuffer image to texture */
if (newTex) {
   /* create new tex image */
@@ -1582,8 +1585,6 @@ _mesa_meta_CopyPixels(struct gl_context *ctx, GLint srcX, 
GLint srcY,
   GLfloat x, y, z, s, t;
};
struct vertex verts[4];
-   GLboolean newTex;
-   GLenum intFormat = GL_RGBA;
 
if (type != GL_COLOR ||
ctx-_ImageTransferState ||
@@ -1630,7 +1631,9 @@ _mesa_meta_CopyPixels(struct gl_context *ctx, GLint srcX, 
GLint srcY,
   _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, copypix-VBO);
}
 
-   newTex = _mesa_meta_alloc_texture(tex, width, height, intFormat);
+   /* Alloc/setup texture */
+   _mesa_meta_setup_copypix_texture(ctx, tex, srcX, srcY, width, height,
+GL_RGBA, GL_NEAREST);
 
/* vertex positions, texcoords (after texture allocation!) */
{
@@ -1665,10 +1668,6 @@ _mesa_meta_CopyPixels(struct gl_context *ctx, GLint 
srcX, GLint srcY,
   _mesa_BufferSubData(GL_ARRAY_BUFFER_ARB, 0, sizeof(verts), verts);
}
 
-   /* Alloc/setup texture */
-   _mesa_meta_setup_copypix_texture(ctx, tex, newTex, srcX, srcY, width, 
height,
-GL_RGBA, GL_NEAREST);
-
_mesa_set_enable(ctx, tex-Target, GL_TRUE);
 
/* draw textured quad */
diff --git a/src/mesa/drivers/common/meta.h b/src/mesa/drivers/common/meta.h
index 64925ff..f9d1f7c 100644
--- a/src/mesa/drivers/common/meta.h
+++ b/src/mesa/drivers/common/meta.h
@@ -432,7 +432,6 @@ _mesa_meta_setup_drawpix_texture(struct gl_context *ctx,
 void
 _mesa_meta_setup_copypix_texture(struct gl_context *ctx,
  struct temp_texture *tex,
- GLboolean newTex,
  GLint srcX, GLint srcY,
  GLsizei width, GLsizei height,
  GLenum intFormat,
diff --git a/src/mesa/drivers/common/meta_blit.c 
b/src/mesa/drivers/common/meta_blit.c
index 5f7cad7..5a0b2ca 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -556,9 +556,7 @@ _mesa_meta_BlitFramebuffer(struct gl_context *ctx,
* linear filtering along the edges. So, allocate the texture extended 
along
* edges by one pixel in x, y directions.
*/
-  newTex = _mesa_meta_alloc_texture(tex, srcW + 2, srcH + 2,
-rb_base_format);
-  _mesa_meta_setup_copypix_texture(ctx, tex, newTex,
+  _mesa_meta_setup_copypix_texture(ctx, tex,
srcX - 1, srcY - 1, srcW + 2, srcH + 2,
rb_base_format, filter);
   /* texcoords (after texture allocation!) */
-- 
1.9.rc1

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

[Mesa-dev] [PATCH 11/11] meta: Don't try to enable FF texturing when we're using GLSL.

On a core context, this would throw an error.
---
 src/mesa/drivers/common/meta_blit.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/src/mesa/drivers/common/meta_blit.c 
b/src/mesa/drivers/common/meta_blit.c
index 46c8efd..4e48e74 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -389,7 +389,7 @@ blitframebuffer_texture(struct gl_context *ctx,
   GL_SKIP_DECODE_EXT);
}
 
-   if (ctx-API == API_OPENGL_COMPAT || ctx-API == API_OPENGLES) {
+   if (!glsl_version) {
   _mesa_TexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
   _mesa_set_enable(ctx, target, GL_TRUE);
}
@@ -579,10 +579,7 @@ _mesa_meta_BlitFramebuffer(struct gl_context *ctx,
 
}
 
-   /* glEnable() in gles2 and gles3 doesn't allow GL_TEXTURE_{1D, 2D, etc.}
-* tokens.
-*/
-   if (_mesa_is_desktop_gl(ctx) || ctx-API == API_OPENGLES)
+   if (!use_glsl_version)
   _mesa_set_enable(ctx, tex-Target, GL_TRUE);
 
if (mask  GL_COLOR_BUFFER_BIT) {
@@ -677,7 +674,7 @@ _mesa_meta_BlitFramebuffer(struct gl_context *ctx,
   /* XXX can't easily do stencil */
}
 
-   if (_mesa_is_desktop_gl(ctx) || ctx-API == API_OPENGLES)
+   if (!use_glsl_version)
   _mesa_set_enable(ctx, tex-Target, GL_FALSE);
 
_mesa_meta_end(ctx);
-- 
1.9.rc1

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

[Mesa-dev] [PATCH 02/11] meta: De-static some of meta's functions.

I want split some meta.c code off to a separate file, so these functions
can't be static any more.
---
 src/mesa/drivers/common/meta.c | 139 ++---
 src/mesa/drivers/common/meta.h |  37 +++
 2 files changed, 113 insertions(+), 63 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index 71bd25d3..e2321eb 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -89,8 +89,9 @@ static void meta_glsl_generate_mipmap_cleanup(struct 
gen_mipmap_state *mipmap);
 static void meta_decompress_cleanup(struct decompress_state *decompress);
 static void meta_drawpix_cleanup(struct drawpix_state *drawpix);
 
-static GLuint
-compile_shader_with_debug(struct gl_context *ctx, GLenum target, const 
GLcharARB *source)
+GLuint
+_mesa_meta_compile_shader_with_debug(struct gl_context *ctx, GLenum target,
+ const GLcharARB *source)
 {
GLuint shader;
GLint ok, size;
@@ -128,8 +129,8 @@ compile_shader_with_debug(struct gl_context *ctx, GLenum 
target, const GLcharARB
return 0;
 }
 
-static GLuint
-link_program_with_debug(struct gl_context *ctx, GLuint program)
+GLuint
+_mesa_meta_link_program_with_debug(struct gl_context *ctx, GLuint program)
 {
GLint ok, size;
GLchar *info;
@@ -956,8 +957,8 @@ cleanup_temp_texture(struct temp_texture *tex)
  * Return pointer to temp_texture info for non-bitmap ops.
  * This does some one-time init if needed.
  */
-static struct temp_texture *
-get_temp_texture(struct gl_context *ctx)
+struct temp_texture *
+_mesa_meta_get_temp_texture(struct gl_context *ctx)
 {
struct temp_texture *tex = ctx-Meta-TempTex;
 
@@ -990,8 +991,8 @@ get_bitmap_temp_texture(struct gl_context *ctx)
  * Return pointer to depth temp_texture.
  * This does some one-time init if needed.
  */
-static struct temp_texture *
-get_temp_depth_texture(struct gl_context *ctx)
+struct temp_texture *
+_mesa_meta_get_temp_depth_texture(struct gl_context *ctx)
 {
struct temp_texture *tex = ctx-Meta-Blit.depthTex;
 
@@ -1011,9 +1012,9 @@ get_temp_depth_texture(struct gl_context *ctx)
  *
  * \return GL_TRUE if new texture is needed, GL_FALSE otherwise
  */
-static GLboolean
-alloc_texture(struct temp_texture *tex,
-  GLsizei width, GLsizei height, GLenum intFormat)
+GLboolean
+_mesa_meta_alloc_texture(struct temp_texture *tex,
+ GLsizei width, GLsizei height, GLenum intFormat)
 {
GLboolean newTex = GL_FALSE;
 
@@ -1064,13 +1065,14 @@ alloc_texture(struct temp_texture *tex,
 /**
  * Setup/load texture for glCopyPixels or glBlitFramebuffer.
  */
-static void
-setup_copypix_texture(struct gl_context *ctx,
-  struct temp_texture *tex,
-  GLboolean newTex,
-  GLint srcX, GLint srcY,
-  GLsizei width, GLsizei height, GLenum intFormat,
-  GLenum filter)
+void
+_mesa_meta_setup_copypix_texture(struct gl_context *ctx,
+ struct temp_texture *tex,
+ GLboolean newTex,
+ GLint srcX, GLint srcY,
+ GLsizei width, GLsizei height,
+ GLenum intFormat,
+ GLenum filter)
 {
_mesa_BindTexture(tex-Target, tex-TexObj);
_mesa_TexParameteri(tex-Target, GL_TEXTURE_MIN_FILTER, filter);
@@ -1107,14 +1109,14 @@ setup_copypix_texture(struct gl_context *ctx,
 /**
  * Setup/load texture for glDrawPixels.
  */
-static void
-setup_drawpix_texture(struct gl_context *ctx,
- struct temp_texture *tex,
-  GLboolean newTex,
-  GLenum texIntFormat,
-  GLsizei width, GLsizei height,
-  GLenum format, GLenum type,
-  const GLvoid *pixels)
+void
+_mesa_meta_setup_drawpix_texture(struct gl_context *ctx,
+ struct temp_texture *tex,
+ GLboolean newTex,
+ GLenum texIntFormat,
+ GLsizei width, GLsizei height,
+ GLenum format, GLenum type,
+ const GLvoid *pixels)
 {
_mesa_BindTexture(tex-Target, tex-TexObj);
_mesa_TexParameteri(tex-Target, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
@@ -1168,7 +1170,7 @@ init_blit_depth_pixels(struct gl_context *ctx)
   END \n;
char program2[200];
struct blit_state *blit = ctx-Meta-Blit;
-   struct temp_texture *tex = get_temp_texture(ctx);
+   struct temp_texture *tex = _mesa_meta_get_temp_texture(ctx);
const char *texTarget;
 
assert(blit-DepthFP == 0);
@@ -1328,8 +1330,9 @@ setup_glsl_blit_framebuffer(struct gl_context *ctx,
   texture_2d ? texture : texture2DRect);
}
 
-   vs =

[Mesa-dev] [PATCH 03/11] meta: Move glBlitFramebuffer() to a separate file.

---
 src/mesa/Makefile.sources   |   1 +
 src/mesa/drivers/common/meta.c  | 608 +---
 src/mesa/drivers/common/meta.h  |   3 +
 src/mesa/drivers/common/meta_blit.c | 675 
 4 files changed, 680 insertions(+), 607 deletions(-)
 create mode 100644 src/mesa/drivers/common/meta_blit.c

diff --git a/src/mesa/Makefile.sources b/src/mesa/Makefile.sources
index bd02d3e..1ce94de 100644
--- a/src/mesa/Makefile.sources
+++ b/src/mesa/Makefile.sources
@@ -319,6 +319,7 @@ SPARC_FILES =   \
 
 COMMON_DRIVER_FILES =  \
$(SRCDIR)drivers/common/driverfuncs.c   \
+   $(SRCDIR)drivers/common/meta_blit.c \
$(SRCDIR)drivers/common/meta.c
 
 
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index e2321eb..33ea67f 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -82,7 +82,6 @@
 /** Return offset in bytes of the field within a vertex struct */
 #define OFFSET(FIELD) ((void *) offsetof(struct vertex, FIELD))
 
-static void meta_glsl_blit_cleanup(struct blit_state *blit);
 static void cleanup_temp_texture(struct temp_texture *tex);
 static void meta_glsl_clear_cleanup(struct clear_state *clear);
 static void meta_glsl_generate_mipmap_cleanup(struct gen_mipmap_state *mipmap);
@@ -179,7 +178,7 @@ _mesa_meta_free(struct gl_context *ctx)
 {
GET_CURRENT_CONTEXT(old_context);
_mesa_make_current(ctx, NULL, NULL);
-   meta_glsl_blit_cleanup(ctx-Meta-Blit);
+   _mesa_meta_glsl_blit_cleanup(ctx-Meta-Blit);
meta_glsl_clear_cleanup(ctx-Meta-Clear);
meta_glsl_generate_mipmap_cleanup(ctx-Meta-Mipmap);
cleanup_temp_texture(ctx-Meta-TempTex);
@@ -1156,611 +1155,6 @@ _mesa_meta_setup_drawpix_texture(struct gl_context *ctx,
}
 }
 
-
-
-/**
- * One-time init for drawing depth pixels.
- */
-static void
-init_blit_depth_pixels(struct gl_context *ctx)
-{
-   static const char *program =
-  !!ARBfp1.0\n
-  TEX result.depth, fragment.texcoord[0], texture[0], %s; \n
-  END \n;
-   char program2[200];
-   struct blit_state *blit = ctx-Meta-Blit;
-   struct temp_texture *tex = _mesa_meta_get_temp_texture(ctx);
-   const char *texTarget;
-
-   assert(blit-DepthFP == 0);
-
-   /* replace %s with RECT or 2D */
-   assert(strlen(program) + 4  sizeof(program2));
-   if (tex-Target == GL_TEXTURE_RECTANGLE)
-  texTarget = RECT;
-   else
-  texTarget = 2D;
-   _mesa_snprintf(program2, sizeof(program2), program, texTarget);
-
-   _mesa_GenProgramsARB(1, blit-DepthFP);
-   _mesa_BindProgramARB(GL_FRAGMENT_PROGRAM_ARB, blit-DepthFP);
-   _mesa_ProgramStringARB(GL_FRAGMENT_PROGRAM_ARB, GL_PROGRAM_FORMAT_ASCII_ARB,
-  strlen(program2), (const GLubyte *) program2);
-}
-
-static void
-setup_ff_blit_framebuffer(struct blit_state *blit)
-{
-   struct vertex {
-  GLfloat x, y, s, t;
-   };
-   struct vertex verts[4];
-
-   if (blit-VAO == 0) {
-  /* one-time setup */
-
-  /* create vertex array object */
-  _mesa_GenVertexArrays(1, blit-VAO);
-  _mesa_BindVertexArray(blit-VAO);
-
-  /* create vertex array buffer */
-  _mesa_GenBuffers(1, blit-VBO);
-  _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, blit-VBO);
-  _mesa_BufferData(GL_ARRAY_BUFFER_ARB, sizeof(verts),
-  NULL, GL_DYNAMIC_DRAW_ARB);
-
-  /* setup vertex arrays */
-  _mesa_VertexPointer(2, GL_FLOAT, sizeof(struct vertex), OFFSET(x));
-  _mesa_TexCoordPointer(2, GL_FLOAT, sizeof(struct vertex), OFFSET(s));
-  _mesa_EnableClientState(GL_VERTEX_ARRAY);
-  _mesa_EnableClientState(GL_TEXTURE_COORD_ARRAY);
-   }
-
-   /* setup projection matrix */
-   _mesa_MatrixMode(GL_PROJECTION);
-   _mesa_LoadIdentity();
-   _mesa_Ortho(-1.0, 1.0, -1.0, 1.0, -1.0, 1.0);
-
-}
-
-static void
-setup_glsl_blit_framebuffer(struct gl_context *ctx,
-struct blit_state *blit,
-GLenum target)
-{
-   struct vertex {
-  GLfloat x, y, s, t;
-   };
-   struct vertex verts[4];
-   const char *vs_source;
-   char *fs_source;
-   GLuint vs, fs;
-   void *mem_ctx;
-   GLuint ShaderProg;
-   GLboolean texture_2d = (target == GL_TEXTURE_2D);
-
-   /* target = GL_TEXTURE_RECTANGLE is not supported in GLES 3.0 */
-   assert(_mesa_is_desktop_gl(ctx) || texture_2d);
-
-   /* Check if already initialized */
-   if (blit-VAO == 0) {
-
-  /* create vertex array object */
-  _mesa_GenVertexArrays(1, blit-VAO);
-  _mesa_BindVertexArray(blit-VAO);
-
-  /* create vertex array buffer */
-  _mesa_GenBuffers(1, blit-VBO);
-  _mesa_BindBuffer(GL_ARRAY_BUFFER_ARB, blit-VBO);
-  _mesa_BufferData(GL_ARRAY_BUFFER_ARB, sizeof(verts),
-  NULL, GL_DYNAMIC_DRAW_ARB);
-
-  /* setup vertex arrays */
-  _mesa_VertexAttribPointer(0, 2, GL_FLOAT, GL_FALSE,
-   sizeof(struct vertex), OFFSET(x));
-

[Mesa-dev] [PATCH 08/11] meta: Use BindRenderbufferTexture() for meta glBlitFramebuffer().

This avoids a CopyTexImage() on Intel i965 hardware without blorp.
---
 src/mesa/drivers/common/meta_blit.c | 59 ++---
 1 file changed, 49 insertions(+), 10 deletions(-)

diff --git a/src/mesa/drivers/common/meta_blit.c 
b/src/mesa/drivers/common/meta_blit.c
index 3c6998f..973ee1b 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -264,9 +264,11 @@ setup_glsl_blit_framebuffer(struct gl_context *ctx,
 }
 
 /**
- * Try to do a glBlitFramebuffer using no-copy texturing.
- * We can do this when the src renderbuffer is actually a texture.
- * But if the src buffer == dst buffer we cannot do this.
+ * Try to do a color-only glBlitFramebuffer using texturing.
+ *
+ * We can do this when the src renderbuffer is actually a texture, or when the
+ * driver expposes BindRenderbufferTexImage().  But if the src buffer == dst
+ * buffer we cannot do this.
  */
 static bool
 blitframebuffer_texture(struct gl_context *ctx,
@@ -285,7 +287,7 @@ blitframebuffer_texture(struct gl_context *ctx,
const GLint dstY = MIN2(dstY0, dstY1);
const GLint dstW = abs(dstX1 - dstX0);
const GLint dstH = abs(dstY1 - dstY0);
-   const struct gl_texture_object *texObj;
+   struct gl_texture_object *texObj;
GLuint srcLevel;
GLint baseLevelSave;
GLint maxLevelSave;
@@ -294,17 +296,55 @@ blitframebuffer_texture(struct gl_context *ctx,
   ctx-Texture.Unit[ctx-Texture.CurrentUnit].Sampler ?
   ctx-Texture.Unit[ctx-Texture.CurrentUnit].Sampler-Name : 0;
int i;
+   GLuint tempTex = 0;
 
if (readAtt  readAtt-Texture) {
+  /* If there's a texture attached of a type we can handle, then just use
+   * it directly.
+   */
   srcLevel = readAtt-TextureLevel;
   texObj = readAtt-Texture;
+  target = texObj-Target;
+
+  if (target != GL_TEXTURE_2D  target != GL_TEXTURE_RECTANGLE_ARB)
+ return false;
+   } else if (ctx-Driver.BindRenderbufferTexImage) {
+  /* Otherwise, we need the driver to be able to bind a renderbuffer as
+   * a texture image.
+   */
+  struct gl_texture_image *texImage;
+  struct gl_renderbuffer *rb = readAtt-Renderbuffer;
+
+  target = GL_TEXTURE_2D;
+  _mesa_GenTextures(1, tempTex);
+  _mesa_BindTexture(target, tempTex);
+  srcLevel = 0;
+  texObj = _mesa_lookup_texture(ctx, tempTex);
+  texImage = _mesa_get_tex_image(ctx, texObj, target, srcLevel);
+
+  if (!ctx-Driver.BindRenderbufferTexImage(ctx, rb, texImage)) {
+ _mesa_DeleteTextures(1, tempTex);
+ return false;
+  } else {
+ if (ctx-Driver.FinishRenderTexture 
+ !rb-NeedsFinishRenderTexture) {
+rb-NeedsFinishRenderTexture = true;
+ctx-Driver.FinishRenderTexture(ctx, rb);
+ }
+
+ if (_mesa_is_winsys_fbo(readFb)) {
+GLint temp = srcY0;
+srcY0 = rb-Height - srcY1;
+srcY1 = rb-Height - temp;
+flipY = -flipY;
+ }
+  }
} else {
   return false;
}
 
baseLevelSave = texObj-BaseLevel;
maxLevelSave = texObj-MaxLevel;
-   target = texObj-Target;
 
/* Iterate through all draw buffers */
for (i = 0; i  ctx-DrawBuffer-_NumColorDrawBuffers; i++) {
@@ -318,15 +358,12 @@ blitframebuffer_texture(struct gl_context *ctx,
   * to handle overlapping blits and besides, some hw may not
   * support this.
   */
+ if (tempTex)
+_mesa_DeleteTextures(1, tempTex);
  return false;
   }
}
 
-   if (target != GL_TEXTURE_2D  target != GL_TEXTURE_RECTANGLE_ARB) {
-  /* Can't handle other texture types at this time */
-  return false;
-   }
-
/* Choose between glsl version and fixed function version of
 * BlitFramebuffer function.
 */
@@ -440,6 +477,8 @@ blitframebuffer_texture(struct gl_context *ctx,
 
_mesa_BindSampler(ctx-Texture.CurrentUnit, samplerSave);
_mesa_DeleteSamplers(1, sampler);
+   if (tempTex)
+  _mesa_DeleteTextures(1, tempTex);
 
return true;
 }
-- 
1.9.rc1

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

[Mesa-dev] [PATCH 05/11] mesa: Make TexImage error cases about internalFormat more informative.

I tripped over one of these when debugging meta, and it's a lot nicer to
just see the internalFormat being complained about.
---
 src/mesa/main/teximage.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 4d635fe..0d0bbc6 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -2254,9 +2254,10 @@ compressed_texture_error_check(struct gl_context *ctx, 
GLint dimensions,
 
/* This will detect any invalid internalFormat value */
if (!_mesa_is_compressed_format(ctx, internalFormat)) {
-  reason = internalFormat;
-  error = GL_INVALID_ENUM;
-  goto error;
+  _mesa_error(ctx, GL_INVALID_ENUM,
+  glCompressedTexImage%dD(internalFormat=%s),
+  dimensions, _mesa_lookup_enum_by_nr(internalFormat));
+  return GL_TRUE;
}
 
switch (internalFormat) {
@@ -2563,7 +2564,8 @@ copytexture_error_check( struct gl_context *ctx, GLuint 
dimensions,
  break;
   default:
  _mesa_error(ctx, GL_INVALID_VALUE,
- glCopyTexImage%dD(internalFormat), dimensions);
+ glCopyTexImage%dD(internalFormat=%s), dimensions,
+ _mesa_lookup_enum_by_nr(internalFormat));
  return GL_TRUE;
   }
}
@@ -2571,7 +2573,8 @@ copytexture_error_check( struct gl_context *ctx, GLuint 
dimensions,
baseFormat = _mesa_base_tex_format(ctx, internalFormat);
if (baseFormat  0) {
   _mesa_error(ctx, GL_INVALID_OPERATION,
-  glCopyTexImage%dD(internalFormat), dimensions);
+  glCopyTexImage%dD(internalFormat=%s), dimensions,
+  _mesa_lookup_enum_by_nr(internalFormat));
   return GL_TRUE;
}
 
@@ -2580,7 +2583,8 @@ copytexture_error_check( struct gl_context *ctx, GLuint 
dimensions,
if (_mesa_is_color_format(internalFormat)) {
   if (rb_base_format  0) {
  _mesa_error(ctx, GL_INVALID_VALUE,
- glCopyTexImage%dD(internalFormat), dimensions);
+ glCopyTexImage%dD(internalFormat=%s), dimensions,
+ _mesa_lookup_enum_by_nr(internalFormat));
  return GL_TRUE;
   }
}
@@ -2606,7 +2610,8 @@ copytexture_error_check( struct gl_context *ctx, GLuint 
dimensions,
   }
   if (!valid) {
  _mesa_error(ctx, GL_INVALID_OPERATION,
- glCopyTexImage%dD(internalFormat), dimensions);
+ glCopyTexImage%dD(internalFormat=%s), dimensions,
+ _mesa_lookup_enum_by_nr(internalFormat));
  return GL_TRUE;
   }
}
-- 
1.9.rc1

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

[Mesa-dev] [PATCH 06/11] meta: Do a massive unindent (and rename) of blitframebuffer_texture().

This function is only handling the color case.  We can just unindent as
long as we're willing to do the check for the bit outside of the
function.
---
 src/mesa/drivers/common/meta_blit.c | 331 ++--
 1 file changed, 168 insertions(+), 163 deletions(-)

diff --git a/src/mesa/drivers/common/meta_blit.c 
b/src/mesa/drivers/common/meta_blit.c
index 5a0b2ca..3c6998f 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -267,181 +267,181 @@ setup_glsl_blit_framebuffer(struct gl_context *ctx,
  * Try to do a glBlitFramebuffer using no-copy texturing.
  * We can do this when the src renderbuffer is actually a texture.
  * But if the src buffer == dst buffer we cannot do this.
- *
- * \return new buffer mask indicating the buffers left to blit using the
- * normal path.
  */
-static GLbitfield
+static bool
 blitframebuffer_texture(struct gl_context *ctx,
 GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1,
 GLint dstX0, GLint dstY0, GLint dstX1, GLint dstY1,
-GLbitfield mask, GLenum filter, GLint flipX,
-GLint flipY, GLboolean glsl_version)
+GLenum filter, GLint flipX, GLint flipY,
+GLboolean glsl_version)
 {
-   if (mask  GL_COLOR_BUFFER_BIT) {
-  const struct gl_framebuffer *drawFb = ctx-DrawBuffer;
-  const struct gl_framebuffer *readFb = ctx-ReadBuffer;
-  const struct gl_renderbuffer_attachment *drawAtt;
-  const struct gl_renderbuffer_attachment *readAtt =
- readFb-Attachment[readFb-_ColorReadBufferIndex];
-
-  if (readAtt  readAtt-Texture) {
- struct blit_state *blit = ctx-Meta-Blit;
- const GLint dstX = MIN2(dstX0, dstX1);
- const GLint dstY = MIN2(dstY0, dstY1);
- const GLint dstW = abs(dstX1 - dstX0);
- const GLint dstH = abs(dstY1 - dstY0);
- const struct gl_texture_object *texObj = readAtt-Texture;
- const GLuint srcLevel = readAtt-TextureLevel;
- const GLint baseLevelSave = texObj-BaseLevel;
- const GLint maxLevelSave = texObj-MaxLevel;
- const GLenum target = texObj-Target;
- GLuint sampler, samplerSave =
-ctx-Texture.Unit[ctx-Texture.CurrentUnit].Sampler ?
-ctx-Texture.Unit[ctx-Texture.CurrentUnit].Sampler-Name : 0;
- int i;
-
- /* Iterate through all draw buffers */
- for (i = 0; i  ctx-DrawBuffer-_NumColorDrawBuffers; i++) {
-int idx = ctx-DrawBuffer-_ColorDrawBufferIndexes[i];
-if (idx == -1)
-   continue;
-drawAtt = drawFb-Attachment[idx];
-
-if (drawAtt-Texture == readAtt-Texture) {
-   /* Can't use same texture as both the source and dest.  We need
-* to handle overlapping blits and besides, some hw may not
-* support this.
-*/
-   return mask;
-}
- }
-
- if (target != GL_TEXTURE_2D  target != GL_TEXTURE_RECTANGLE_ARB) {
-/* Can't handle other texture types at this time */
-return mask;
- }
+   const struct gl_framebuffer *drawFb = ctx-DrawBuffer;
+   const struct gl_framebuffer *readFb = ctx-ReadBuffer;
+   const struct gl_renderbuffer_attachment *drawAtt;
+   const struct gl_renderbuffer_attachment *readAtt =
+  readFb-Attachment[readFb-_ColorReadBufferIndex];
+   struct blit_state *blit = ctx-Meta-Blit;
+   const GLint dstX = MIN2(dstX0, dstX1);
+   const GLint dstY = MIN2(dstY0, dstY1);
+   const GLint dstW = abs(dstX1 - dstX0);
+   const GLint dstH = abs(dstY1 - dstY0);
+   const struct gl_texture_object *texObj;
+   GLuint srcLevel;
+   GLint baseLevelSave;
+   GLint maxLevelSave;
+   GLenum target;
+   GLuint sampler, samplerSave =
+  ctx-Texture.Unit[ctx-Texture.CurrentUnit].Sampler ?
+  ctx-Texture.Unit[ctx-Texture.CurrentUnit].Sampler-Name : 0;
+   int i;
+
+   if (readAtt  readAtt-Texture) {
+  srcLevel = readAtt-TextureLevel;
+  texObj = readAtt-Texture;
+   } else {
+  return false;
+   }
 
- /* Choose between glsl version and fixed function version of
-  * BlitFramebuffer function.
+   baseLevelSave = texObj-BaseLevel;
+   maxLevelSave = texObj-MaxLevel;
+   target = texObj-Target;
+
+   /* Iterate through all draw buffers */
+   for (i = 0; i  ctx-DrawBuffer-_NumColorDrawBuffers; i++) {
+  int idx = ctx-DrawBuffer-_ColorDrawBufferIndexes[i];
+  if (idx == -1)
+ continue;
+  drawAtt = drawFb-Attachment[idx];
+
+  if (drawAtt-Texture == readAtt-Texture) {
+ /* Can't use same texture as both the source and dest.  We need
+  * to handle overlapping blits and besides, some hw may not
+  * support this.
   */
- if (glsl_version) {
-setup_glsl_blit_framebuffer(ctx, blit, target);
-if (target

[Mesa-dev] [PATCH 01/11] meta: Move the meta structures to the meta header.

I'd like to split some of our code to separate files, since 4k lines and
growing is pretty unreasonable for all these separate operations.
---
 src/mesa/drivers/common/meta.c | 268 -
 src/mesa/drivers/common/meta.h | 268 +
 2 files changed, 268 insertions(+), 268 deletions(-)

diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index f12bcaa..71bd25d3 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -82,274 +82,6 @@
 /** Return offset in bytes of the field within a vertex struct */
 #define OFFSET(FIELD) ((void *) offsetof(struct vertex, FIELD))
 
-/**
- * State which we may save/restore across meta ops.
- * XXX this may be incomplete...
- */
-struct save_state
-{
-   GLbitfield SavedState;  /** bitmask of MESA_META_* flags */
-
-   /** MESA_META_CLEAR (and others?) */
-   struct gl_query_object *CurrentOcclusionObject;
-
-   /** MESA_META_ALPHA_TEST */
-   GLboolean AlphaEnabled;
-   GLenum AlphaFunc;
-   GLclampf AlphaRef;
-
-   /** MESA_META_BLEND */
-   GLbitfield BlendEnabled;
-   GLboolean ColorLogicOpEnabled;
-
-   /** MESA_META_COLOR_MASK */
-   GLubyte ColorMask[MAX_DRAW_BUFFERS][4];
-
-   /** MESA_META_DEPTH_TEST */
-   struct gl_depthbuffer_attrib Depth;
-
-   /** MESA_META_FOG */
-   GLboolean Fog;
-
-   /** MESA_META_PIXEL_STORE */
-   struct gl_pixelstore_attrib Pack, Unpack;
-
-   /** MESA_META_PIXEL_TRANSFER */
-   GLfloat RedBias, RedScale;
-   GLfloat GreenBias, GreenScale;
-   GLfloat BlueBias, BlueScale;
-   GLfloat AlphaBias, AlphaScale;
-   GLfloat DepthBias, DepthScale;
-   GLboolean MapColorFlag;
-
-   /** MESA_META_RASTERIZATION */
-   GLenum FrontPolygonMode, BackPolygonMode;
-   GLboolean PolygonOffset;
-   GLboolean PolygonSmooth;
-   GLboolean PolygonStipple;
-   GLboolean PolygonCull;
-
-   /** MESA_META_SCISSOR */
-   struct gl_scissor_attrib Scissor;
-
-   /** MESA_META_SHADER */
-   GLboolean VertexProgramEnabled;
-   struct gl_vertex_program *VertexProgram;
-   GLboolean FragmentProgramEnabled;
-   struct gl_fragment_program *FragmentProgram;
-   GLboolean ATIFragmentShaderEnabled;
-   struct gl_shader_program *Shader[MESA_SHADER_STAGES];
-   struct gl_shader_program *ActiveShader;
-
-   /** MESA_META_STENCIL_TEST */
-   struct gl_stencil_attrib Stencil;
-
-   /** MESA_META_TRANSFORM */
-   GLenum MatrixMode;
-   GLfloat ModelviewMatrix[16];
-   GLfloat ProjectionMatrix[16];
-   GLfloat TextureMatrix[16];
-
-   /** MESA_META_CLIP */
-   GLbitfield ClipPlanesEnabled;
-
-   /** 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 */
-   GLbitfield TexEnabled[MAX_TEXTURE_UNITS];
-   GLbitfield TexGenEnabled[MAX_TEXTURE_UNITS];
-   GLuint EnvMode;  /* unit[0] only */
-
-   /** MESA_META_VERTEX */
-   struct gl_vertex_array_object *VAO;
-   struct gl_buffer_object *ArrayBufferObj;
-
-   /** MESA_META_VIEWPORT */
-   GLfloat ViewportX, ViewportY, ViewportW, ViewportH;
-   GLclampd DepthNear, DepthFar;
-
-   /** MESA_META_CLAMP_FRAGMENT_COLOR */
-   GLenum ClampFragmentColor;
-
-   /** MESA_META_CLAMP_VERTEX_COLOR */
-   GLenum ClampVertexColor;
-
-   /** MESA_META_CONDITIONAL_RENDER */
-   struct gl_query_object *CondRenderQuery;
-   GLenum CondRenderMode;
-
-   /** MESA_META_SELECT_FEEDBACK */
-   GLenum RenderMode;
-   struct gl_selection Select;
-   struct gl_feedback Feedback;
-
-   /** MESA_META_MULTISAMPLE */
-   GLboolean MultisampleEnabled;
-
-   /** MESA_META_FRAMEBUFFER_SRGB */
-   GLboolean sRGBEnabled;
-
-   /** Miscellaneous (always disabled) */
-   GLboolean Lighting;
-   GLboolean RasterDiscard;
-   GLboolean TransformFeedbackNeedsResume;
-};
-
-/**
- * Temporary texture used for glBlitFramebuffer, glDrawPixels, etc.
- * This is currently shared by all the meta ops.  But we could create a
- * separate one for each of glDrawPixel, glBlitFramebuffer, glCopyPixels, etc.
- */
-struct temp_texture
-{
-   GLuint TexObj;
-   GLenum Target; /** GL_TEXTURE_2D or GL_TEXTURE_RECTANGLE */
-   GLsizei MinSize;   /** Min texture size to allocate */
-   GLsizei MaxSize;   /** Max possible texture size */
-   GLboolean NPOT;/** Non-power of two size OK? */
-   GLsizei Width, Height; /** Current texture size */
-   GLenum IntFormat;
-   GLfloat Sright, Ttop;  /** right, top texcoords */
-};
-
-
-/**
- * State for glBlitFramebufer()
- */
-struct blit_state
-{
-   GLuint VAO;
-   GLuint VBO;
-   GLuint DepthFP;
-   GLuint ShaderProg;
-   GLuint RectShaderProg;
-   struct temp_texture depthTex;
-};
-
-
-/**
- * State for glClear()
- */
-struct clear_state
-{
-   GLuint VAO;
-   GLuint VBO;
-   GLuint ShaderProg;
-   GLint ColorLocation;
-   GLint LayerLocation;
-
-   GLuint IntegerShaderProg;
-   GLint IntegerColorLocation;
-   GLint IntegerLayerLocation;
-};
-
-
-/**
- *

[Mesa-dev] [PATCH 07/11] i965: Add a driver hook for binding renderbuffers to textures.

This will let us use meta's acceleration from renderbuffers without having
to do a CopyTexImage first.

This is like what we do for TFP, but just taking an existing renderbuffer
and binding it to a texture with whatever its format was.  The
implementation won't work for stencil renderbuffers, and it only does
non-texture renderbuffers (but then, if you're using a texture
renderbuffer, you can just pull the texture object/level/slice out of the
renderbuffer, anyway).
---
 src/mesa/drivers/dri/i965/intel_tex_image.c | 34 +
 src/mesa/main/dd.h  |  7 ++
 2 files changed, 41 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/intel_tex_image.c 
b/src/mesa/drivers/dri/i965/intel_tex_image.c
index 02b3ba5..5a6a7ee 100644
--- a/src/mesa/drivers/dri/i965/intel_tex_image.c
+++ b/src/mesa/drivers/dri/i965/intel_tex_image.c
@@ -322,6 +322,39 @@ intelSetTexBuffer2(__DRIcontext *pDRICtx, GLint target,
_mesa_unlock_texture(brw-ctx, texObj);
 }
 
+static GLboolean
+intel_bind_renderbuffer_tex_image(struct gl_context *ctx,
+  struct gl_renderbuffer *rb,
+  struct gl_texture_image *image)
+{
+   struct intel_renderbuffer *irb = intel_renderbuffer(rb);
+   struct intel_texture_image *intel_image = intel_texture_image(image);
+   struct gl_texture_object *texobj = image-TexObject;
+   struct intel_texture_object *intel_texobj = intel_texture_object(texobj);
+
+   /* We can only handle RB allocated with AllocRenderbufferStorage, or
+* window-system renderbuffers.
+*/
+   assert(!rb-TexImage);
+
+   if (!irb-mt)
+  return false;
+
+   _mesa_lock_texture(ctx, texobj);
+   _mesa_init_teximage_fields(ctx, image,
+ rb-Width, rb-Height, 1,
+ 0, rb-InternalFormat, rb-Format);
+   intel_miptree_reference(intel_image-mt, irb-mt);
+
+   /* Immediately validate the image to the object. */
+   intel_miptree_reference(intel_texobj-mt, intel_image-mt);
+
+   intel_texobj-needs_validate = true;
+   _mesa_unlock_texture(ctx, texobj);
+
+   return true;
+}
+
 void
 intelSetTexBuffer(__DRIcontext *pDRICtx, GLint target, __DRIdrawable *dPriv)
 {
@@ -385,4 +418,5 @@ intelInitTextureImageFuncs(struct dd_function_table 
*functions)
 {
functions-TexImage = intelTexImage;
functions-EGLImageTargetTexture2D = intel_image_target_texture_2d;
+   functions-BindRenderbufferTexImage = intel_bind_renderbuffer_tex_image;
 }
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index ac317e3..ccd4494 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -399,6 +399,13 @@ struct dd_function_table {
void (*UnmapRenderbuffer)(struct gl_context *ctx,
 struct gl_renderbuffer *rb);
 
+   /**
+* Optional driver entrypoint that binds a non-texture renderbuffer's
+* contents to a texture image.
+*/
+   GLboolean (*BindRenderbufferTexImage)(struct gl_context *ctx,
+ struct gl_renderbuffer *rb,
+ struct gl_texture_image *texImage);
/*@}*/
 
 
-- 
1.9.rc1

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

Re: [Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

Am 06.02.2014 00:49, schrieb Jose Fonseca:
I hadn't looked at GL_ARB_buffer_storage. I need to read more closely, but at
a glance i looks like GL_MAP_PERSISTENT_BIT alone is okay (app needs to call
FlushMappedBufferRange must be called to guarantee coherence) but if
GL_MAP_COHERENCE_BIT is set we are indeed in face of the same issue... :-(

Even worse, being part of GL 4.4 and there being no way for the
implementation to fail GL_MAP_COHERENCE_BIT mappings, it means there is no
way to avoid supporting it...

Jose

Note to self: my time would be better spent on reviewing extensions before
they are ratified, than ranting after the fact...

I don't think that would work. The reason for this stuff to exist is
because new hw makes that possible on the hw level directly. Some apus
might even be able to share such buffers in LLC (I don't know if Haswell
can do that, and AMD APUs lack a common cache level but they can
actually do fully coherent memory access from the cpu and gpu side). Now
with discrete chips it's not that easy but everybody is doing unified
memory these days.
I don't know how to solve this for tracing, though, indeed seems
impossible...

Roland

- Original Message -
However, GL_ARB_buffer_storage (OpenGL 4.4) with GL_MAP_PERSISTENT_BIT
isn't much different. The only difference I see between
ARB_buffer_storage and AMD_pinned_memory is that AMD_pinned_memory
allows mapping CPU memory to the GPU address space permanently, while
ARB_buffer_storage allows mapping GPU memory to the CPU address
permanently. At the end of the day, both the GPU and the CPU can read
and modify the same buffer and all they need to use for
synchronization is fences.

Marek

On Wed, Feb 5, 2014 at 8:10 PM, Jose Fonseca jfons...@vmware.com wrote:

- Original Message -

- Original Message -
On 05.02.2014 18:08, Jose Fonseca wrote:
I honestly hope that GL_AMD_pinned_memory doesn't become popular. It
would
have been alright if it wasn't for this bit in
https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_memory.txtk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=pA%2FnK9X3xx0wAlMUZ24PfQ1mW6wAMdTUujz%2Bx7LRwCA%3D%0As=ebbe1f51deb46c81578b3c125b16e31b5f4b28c1d47e283bc9ef588e2707024d
which says:

2) Can the application still use the buffer using the CPU
address?

RESOLVED: YES. However, this access would be completely
non synchronized to the OpenGL pipeline, unless explicit
synchronization is being used (for example, through glFinish
or
by
using
sync objects).

And I'm imagining apps which are streaming vertex data doing precisely
just
that...

I don't understand your concern, this is exactly the same behavior
GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that
properly. How does apitrace handle it?

GL_AMD_pinned_memory it's nothing like GL_ARB_map_buffer_range's
GL_MAP_UNSYCHRONIZED_BIT:

- When an app touches memory returned by
glMapBufferRange(GL_MAP_UNSYCHRONIZED_BIT) it will communicate back to the
OpenGL driver which bytes it actually touched via the
glFlushMappedBufferRange (unless the apps doesn't care about performance
and
doesn't call glFlushMappedBufferRange at all, which is silly as it will
force the OpenGL driver to assumed the whole range changed)

In this case, the OpenGL driver (hence apitrace) should get all the
information it needs about which bytes were updated betwen
glMap/glUnmap.

- When an app touches memory bound via GL_AMD_pinned_memory outside
glMap/glUnmap, there are be _no_ hints whatsever. The OpenGL driver might
not care as the memory is shared between CPU and GPU, so all is good as
far
is it is concerned, but all the changes the app does are invisible at an
API
level, hence apitrace will not be able to catch them unless it does
onerous
heuristics.

So while both extensions allow unsynchronized access, but lack of
synchronization is not my concern. My concern is that GL_AMD_pinned_memory
allows *hidden* access to GPU memory.

Just for the record, the challenges GL_AMD_pinned_memory presents to
Apitrace are much similar to the old-fashioned OpenGL user array pointers:
an app is free to change the contents of memory pointed by user arrays
pointers at any point in time, except during a draw call. This means that
before every draw call, Apitrace needs to scavenge all the user memory
pointers and write their contents to the trace file, just in case the app
changed it..

In order to support GL_AMD_pinned_memory, for every draw call Apitrace
would also need to walk over bound GL_AMD_pinned_memory (and nowadays
there are loads of bound points!), and check if data changed, and
serialize in the trace file if it did...

I never care much about performance of Apitrace with user array pointers:
it is an old paradigm; only old

Re: [Mesa-dev] [PATCH] gallium: add geometry shader output limits

2014-02-05 Thread Michel Dänzer

On Mit, 2014-02-05 at 22:58 +0100, Grigori Goronzy wrote:
 
 diff --git a/src/gallium/drivers/radeonsi/si_pipe.c 
 b/src/gallium/drivers/radeonsi/si_pipe.c
 index 14dfd30..2f4098c 100644
 --- a/src/gallium/drivers/radeonsi/si_pipe.c
 +++ b/src/gallium/drivers/radeonsi/si_pipe.c
 @@ -299,6 +299,12 @@ static int si_get_param(struct pipe_screen* pscreen, 
 enum pipe_cap param)
   case PIPE_CAP_MAX_STREAM_OUTPUT_INTERLEAVED_COMPONENTS:
   return sscreen-b.has_streamout ? 32*4 : 0;
  
 + /* Geometry shader output. */
 + case PIPE_CAP_MAX_GEOMETRY_OUTPUT_VERTICES:
 + return 1024;
 + case PIPE_CAP_MAX_GEOMETRY_TOTAL_OUTPUT_COMPONENTS:
 + return 16384;

radeonsi currently can't handle more than 4095 total output components,
as the buffer resource for writing to the GSVS ring only has 14 bits for
the stride in bytes. This limit could be lifted in the future by falling
back to the pre-SI (supposedly slower) organization of the GSVS buffer
for larger numbers of total output components.


Also, might it make more sense for these to be shader caps than screen
caps?


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

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

[Mesa-dev] [PATCH 03.5/10?] meta/blit: Remove unnecessary #includes.

---
 src/mesa/drivers/common/meta_blit.c | 24 
 1 file changed, 24 deletions(-)

None of these seem to be necessary; the code compiles just fine without them.

diff --git a/src/mesa/drivers/common/meta_blit.c 
b/src/mesa/drivers/common/meta_blit.c
index 5f7cad7..e030f4d 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -28,46 +28,22 @@
 #include main/arbprogram.h
 #include main/arrayobj.h
 #include main/blend.h
-#include main/bufferobj.h
-#include main/buffers.h
-#include main/colortab.h
 #include main/condrender.h
 #include main/depth.h
 #include main/enable.h
 #include main/fbobject.h
-#include main/feedback.h
-#include main/formats.h
-#include main/glformats.h
-#include main/image.h
 #include main/macros.h
 #include main/matrix.h
-#include main/mipmap.h
-#include main/pixel.h
-#include main/pbo.h
-#include main/polygon.h
-#include main/queryobj.h
 #include main/readpix.h
-#include main/scissor.h
 #include main/shaderapi.h
-#include main/shaderobj.h
-#include main/state.h
-#include main/stencil.h
 #include main/texobj.h
 #include main/texenv.h
-#include main/texgetimage.h
 #include main/teximage.h
 #include main/texparam.h
-#include main/texstate.h
-#include main/transformfeedback.h
-#include main/uniforms.h
 #include main/varray.h
 #include main/viewport.h
-#include main/samplerobj.h
-#include program/program.h
 #include swrast/swrast.h
 #include drivers/common/meta.h
-#include main/enums.h
-#include main/glformats.h
 #include ../glsl/ralloc.h
 
 /** Return offset in bytes of the field within a vertex struct */
-- 
1.8.5.2

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

Re: [Mesa-dev] [PATCH 08/11] meta: Use BindRenderbufferTexture() for meta glBlitFramebuffer().

On 02/05/2014 05:20 PM, Eric Anholt wrote:
 This avoids a CopyTexImage() on Intel i965 hardware without blorp.
 ---
  src/mesa/drivers/common/meta_blit.c | 59 
 ++---
  1 file changed, 49 insertions(+), 10 deletions(-)
 
 diff --git a/src/mesa/drivers/common/meta_blit.c 
 b/src/mesa/drivers/common/meta_blit.c
 index 3c6998f..973ee1b 100644
 --- a/src/mesa/drivers/common/meta_blit.c
 +++ b/src/mesa/drivers/common/meta_blit.c
 @@ -264,9 +264,11 @@ setup_glsl_blit_framebuffer(struct gl_context *ctx,
  }
  
  /**
 - * Try to do a glBlitFramebuffer using no-copy texturing.
 - * We can do this when the src renderbuffer is actually a texture.
 - * But if the src buffer == dst buffer we cannot do this.
 + * Try to do a color-only glBlitFramebuffer using texturing.
 + *
 + * We can do this when the src renderbuffer is actually a texture, or when 
 the
 + * driver expposes BindRenderbufferTexImage().  But if the src buffer == dst
 + * buffer we cannot do this.
   */
  static bool
  blitframebuffer_texture(struct gl_context *ctx,
 @@ -285,7 +287,7 @@ blitframebuffer_texture(struct gl_context *ctx,
 const GLint dstY = MIN2(dstY0, dstY1);
 const GLint dstW = abs(dstX1 - dstX0);
 const GLint dstH = abs(dstY1 - dstY0);
 -   const struct gl_texture_object *texObj;
 +   struct gl_texture_object *texObj;
 GLuint srcLevel;
 GLint baseLevelSave;
 GLint maxLevelSave;
 @@ -294,17 +296,55 @@ blitframebuffer_texture(struct gl_context *ctx,
ctx-Texture.Unit[ctx-Texture.CurrentUnit].Sampler ?
ctx-Texture.Unit[ctx-Texture.CurrentUnit].Sampler-Name : 0;
 int i;
 +   GLuint tempTex = 0;
  
 if (readAtt  readAtt-Texture) {
 +  /* If there's a texture attached of a type we can handle, then just use
 +   * it directly.
 +   */
srcLevel = readAtt-TextureLevel;
texObj = readAtt-Texture;
 +  target = texObj-Target;
 +
 +  if (target != GL_TEXTURE_2D  target != GL_TEXTURE_RECTANGLE_ARB)

Could drop the _ARB suffix, but no big deal either way.

 + return false;
 +   } else if (ctx-Driver.BindRenderbufferTexImage) {
 +  /* Otherwise, we need the driver to be able to bind a renderbuffer as
 +   * a texture image.
 +   */
 +  struct gl_texture_image *texImage;
 +  struct gl_renderbuffer *rb = readAtt-Renderbuffer;
 +
 +  target = GL_TEXTURE_2D;
 +  _mesa_GenTextures(1, tempTex);
 +  _mesa_BindTexture(target, tempTex);
 +  srcLevel = 0;
 +  texObj = _mesa_lookup_texture(ctx, tempTex);
 +  texImage = _mesa_get_tex_image(ctx, texObj, target, srcLevel);
 +
 +  if (!ctx-Driver.BindRenderbufferTexImage(ctx, rb, texImage)) {
 + _mesa_DeleteTextures(1, tempTex);
 + return false;
 +  } else {

You already early return if the driver hook fails, so there's no need to
indent this code (below) in an else block.  Looks kind of weird.

 + if (ctx-Driver.FinishRenderTexture 
 + !rb-NeedsFinishRenderTexture) {
 +rb-NeedsFinishRenderTexture = true;
 +ctx-Driver.FinishRenderTexture(ctx, rb);
 + }
 +
 + if (_mesa_is_winsys_fbo(readFb)) {
 +GLint temp = srcY0;
 +srcY0 = rb-Height - srcY1;
 +srcY1 = rb-Height - temp;
 +flipY = -flipY;
 + }
 +  }

 } else {
return false;
 }
  
 baseLevelSave = texObj-BaseLevel;
 maxLevelSave = texObj-MaxLevel;
 -   target = texObj-Target;
  
 /* Iterate through all draw buffers */
 for (i = 0; i  ctx-DrawBuffer-_NumColorDrawBuffers; i++) {
 @@ -318,15 +358,12 @@ blitframebuffer_texture(struct gl_context *ctx,
* to handle overlapping blits and besides, some hw may not
* support this.
*/
 + if (tempTex)
 +_mesa_DeleteTextures(1, tempTex);
   return false;
}
 }
  
 -   if (target != GL_TEXTURE_2D  target != GL_TEXTURE_RECTANGLE_ARB) {
 -  /* Can't handle other texture types at this time */
 -  return false;
 -   }
 -
 /* Choose between glsl version and fixed function version of
  * BlitFramebuffer function.
  */
 @@ -440,6 +477,8 @@ blitframebuffer_texture(struct gl_context *ctx,
  
 _mesa_BindSampler(ctx-Texture.CurrentUnit, samplerSave);
 _mesa_DeleteSamplers(1, sampler);
 +   if (tempTex)
 +  _mesa_DeleteTextures(1, tempTex);
  
 return true;
  }
 

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

Re: [Mesa-dev] [Mesa-stable] [PATCH] configure: Use LLVM shared libraries by default

2014-02-05 Thread Aaron Watry

I've rebuilt my mesa/llvm stack with this patch instead of the
alternative patches for fdo bug 70410.  Everything seems satisfactory
after I rebuilt llvm with --enable-shared.  I haven't done full
before/after piglit runs, but the partial run that I did is showing
what looks like a proper amount of skipped/pass tests with very few
failures.  If you need, I can attempt full piglit runs to compare, but
I don't see why this change would require it (programs used to bomb
out immediately if the llvm linkage wasn't right).

This might make us a bit more vulnerable to issues due to changes in
the LLVM versions installed on the system (as opposed to a functioning
statically linked radeonsi and egl), but I'm not sure how big an issue
that really is in practice.

Tested-by: Aaron Watry awa...@gmail.com

[1] https://bugs.freedesktop.org/show_bug.cgi?id=70410

On Tue, Feb 4, 2014 at 1:24 PM, Tom Stellard t...@stellard.net wrote:
 From: Tom Stellard thomas.stell...@amd.com

 Linking with LLVM static libraries is easily broken by changes to
 the llvm-config program or when LLVM adds, removes, or changes library
 components.  Keeping up with these changes requires a lot of maintanence
 effort to keep the build working on the master and stable branches.

 Also, because of issues in the past LLVM static libraries, the release
 manager is currently configuring with --with-llvm-shared-libs when
 checking the build before release.  Enabling shared libraries by
 default would allow the release manager to run ./configure with
 no arguments, and be reasonably confident that the build would succeed.

 CC: 10.1 mesa-sta...@lists.freedesktop.org

 ---
  configure.ac | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 4da6c51..9568e7b 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1528,11 +1528,11 @@ AC_ARG_ENABLE([gallium-llvm],
  [enable_gallium_llvm=$enableval],
  [enable_gallium_llvm=auto])

 -AC_ARG_WITH([llvm-shared-libs],
 -[AS_HELP_STRING([--with-llvm-shared-libs],
 -[link with LLVM shared libraries @:@default=disabled@:@])],
 +AC_ARG_ENABLE([llvm-shared-libs],
 +[AS_HELP_STRING([--enable-llvm-shared-libs],
 +[link with LLVM shared libraries @:@default=enabled@:@])],
  [],
 -[with_llvm_shared_libs=no])
 +[with_llvm_shared_libs=yes])

  AC_ARG_WITH([llvm-prefix],
  [AS_HELP_STRING([--with-llvm-prefix],
 --
 1.8.1.4

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

[Mesa-dev] [PATCH 2/2] i965/fs: Implement scratch read/write support for Broadwell.

To make sure that both the Gen4 and Gen7 style messages work, I
initially disabled the SHADER_OPCODE_GEN7_SCRATCH_READ optimization,
ran Piglit, re-enabled it, and ran Piglit again.  Both worked fine.

Fixes 40 Piglit tests (most of the varying-packing category).

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 119 ++--
 1 file changed, 110 insertions(+), 9 deletions(-)

diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp 
b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
index 43eaa35..377834f 100644
--- a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
@@ -402,24 +402,125 @@ gen8_fs_generator::generate_ddy(fs_inst *inst,
 }
 
 void
-gen8_fs_generator::generate_scratch_write(fs_inst *inst, struct brw_reg dst)
+gen8_fs_generator::generate_scratch_write(fs_inst *ir, struct brw_reg src)
 {
-   assert(inst-mlen != 0);
-   assert(!TODO: Implement generate_scratch_write.);
+   MOV(retype(brw_message_reg(ir-base_mrf + 1), BRW_REGISTER_TYPE_UD),
+   retype(src, BRW_REGISTER_TYPE_UD));
+
+   struct brw_reg mrf =
+  retype(brw_message_reg(ir-base_mrf), BRW_REGISTER_TYPE_UD);
+
+   const int num_regs = dispatch_width / 8;
+
+   uint32_t msg_control;
+   if (num_regs == 1)
+  msg_control = BRW_DATAPORT_OWORD_BLOCK_2_OWORDS;
+   else
+  msg_control = BRW_DATAPORT_OWORD_BLOCK_4_OWORDS;
+
+   /* Set up the message header.  This is g0, with g0.2 filled with
+* the offset.  We don't want to leave our offset around in g0 or
+* it'll screw up texture samples, so set it up inside the message
+* reg.
+*/
+   unsigned save_exec_size = default_state.exec_size;
+   default_state.exec_size = BRW_EXECUTE_8;
+
+   MOV_RAW(mrf, retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
+   /* set message header global offset field (reg 0, element 2) */
+   MOV_RAW(get_element_ud(mrf, 2), brw_imm_ud(ir-offset / 16));
+
+   struct brw_reg dst;
+   if (dispatch_width == 16)
+  dst = retype(vec16(brw_null_reg()), BRW_REGISTER_TYPE_UW);
+   else
+  dst = retype(vec8(brw_null_reg()), BRW_REGISTER_TYPE_UW);
+
+   default_state.exec_size = BRW_EXECUTE_16;
+
+   gen8_instruction *send = next_inst(BRW_OPCODE_SEND);
+   gen8_set_dst(brw, send, dst);
+   gen8_set_src0(brw, send, mrf);
+   gen8_set_dp_message(brw, send, GEN7_SFID_DATAPORT_DATA_CACHE,
+   255, /* binding table index: stateless access */
+   GEN6_DATAPORT_WRITE_MESSAGE_OWORD_BLOCK_WRITE,
+   msg_control,
+   1 + num_regs, /* mlen */
+   0,/* rlen */
+   true, /* header present */
+   false);   /* EOT */
+
+   default_state.exec_size = save_exec_size;
 }
 
 void
-gen8_fs_generator::generate_scratch_read(fs_inst *inst, struct brw_reg dst)
+gen8_fs_generator::generate_scratch_read(fs_inst *ir, struct brw_reg dst)
 {
-   assert(inst-mlen != 0);
-   assert(!TODO: Implement generate_scratch_read.);
+   struct brw_reg mrf =
+  retype(brw_message_reg(ir-base_mrf), BRW_REGISTER_TYPE_UD);
+
+   const int num_regs = dispatch_width / 8;
+
+   uint32_t msg_control;
+   if (num_regs == 1)
+  msg_control = BRW_DATAPORT_OWORD_BLOCK_2_OWORDS;
+   else
+  msg_control = BRW_DATAPORT_OWORD_BLOCK_4_OWORDS;
+
+   unsigned save_exec_size = default_state.exec_size;
+   default_state.exec_size = BRW_EXECUTE_8;
+
+   MOV_RAW(mrf, retype(brw_vec8_grf(0, 0), BRW_REGISTER_TYPE_UD));
+   /* set message header global offset field (reg 0, element 2) */
+   MOV_RAW(get_element_ud(mrf, 2), brw_imm_ud(ir-offset / 16));
+
+   gen8_instruction *send = next_inst(BRW_OPCODE_SEND);
+   gen8_set_dst(brw, send, retype(dst, BRW_REGISTER_TYPE_UW));
+   gen8_set_src0(brw, send, mrf);
+   gen8_set_dp_message(brw, send, GEN7_SFID_DATAPORT_DATA_CACHE,
+   255, /* binding table index: stateless access */
+   BRW_DATAPORT_READ_MESSAGE_OWORD_BLOCK_READ,
+   msg_control,
+   1,/* mlen */
+   num_regs, /* rlen */
+   true, /* header present */
+   false);   /* EOT */
+
+   default_state.exec_size = save_exec_size;
 }
 
 void
-gen8_fs_generator::generate_scratch_read_gen7(fs_inst *inst, struct brw_reg 
dst)
+gen8_fs_generator::generate_scratch_read_gen7(fs_inst *ir, struct brw_reg dst)
 {
-   assert(inst-mlen != 0);
-   assert(!TODO: Implement generate_scratch_read_gen7.);
+   unsigned save_exec_size = default_state.exec_size;
+   gen8_instruction *send = next_inst(BRW_OPCODE_SEND);
+
+   int num_regs = dispatch_width / 8;
+   assert(num_regs == 1 || num_regs == 2 || num_regs == 4 || num_regs == 8);
+
+   /* According to the docs, offset is A 12-bit HWord offset into the memory
+* Immediate Memory buffer as specified by binding table

[Mesa-dev] [PATCH 1/2] i965: Add Gen8 assembly support for DP Scratch messages.

The new accessors will make it easy to do Gen7-style scratch messages.

Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
 src/mesa/drivers/dri/i965/gen8_instruction.c | 23 +++
 src/mesa/drivers/dri/i965/gen8_instruction.h | 23 +++
 2 files changed, 46 insertions(+)

diff --git a/src/mesa/drivers/dri/i965/gen8_instruction.c 
b/src/mesa/drivers/dri/i965/gen8_instruction.c
index 476b3a9..1a5d453 100644
--- a/src/mesa/drivers/dri/i965/gen8_instruction.c
+++ b/src/mesa/drivers/dri/i965/gen8_instruction.c
@@ -431,3 +431,26 @@ gen8_set_dp_message(const struct brw_context *brw,
gen8_set_dp_message_type(inst, msg_type);
gen8_set_dp_message_control(inst, msg_control);
 }
+
+void
+gen8_set_dp_scratch_message(const struct brw_context *brw,
+struct gen8_instruction *inst,
+bool write,
+bool dword,
+bool invalidate_after_read,
+unsigned num_regs,
+unsigned addr_offset,
+unsigned mlen,
+unsigned rlen,
+bool header_present,
+bool end_of_thread)
+{
+   gen8_set_message_descriptor(brw, inst, GEN7_SFID_DATAPORT_DATA_CACHE,
+   mlen, rlen, header_present, end_of_thread);
+   gen8_set_dp_category(inst, 1); /* Scratch Block Read/Write messages */
+   gen8_set_scratch_read_write(inst, write);
+   gen8_set_scratch_type(inst, dword);
+   gen8_set_scratch_invalidate_after_read(inst, invalidate_after_read);
+   gen8_set_scratch_block_size(inst, ffs(num_regs) - 1);
+   gen8_set_scratch_addr_offset(inst, addr_offset);
+}
diff --git a/src/mesa/drivers/dri/i965/gen8_instruction.h 
b/src/mesa/drivers/dri/i965/gen8_instruction.h
index 7d8b605..89f2364 100644
--- a/src/mesa/drivers/dri/i965/gen8_instruction.h
+++ b/src/mesa/drivers/dri/i965/gen8_instruction.h
@@ -204,6 +204,17 @@ MD(dp_message_control,  13,   8)
 /** @} */
 
 /**
+ * Scratch message bits:
+ *  @{
+ */
+MD(scratch_read_write,  17,  17) /* 0 = read,  1 = write */
+MD(scratch_type,16,  16) /* 0 = OWord, 1 = DWord */
+MD(scratch_invalidate_after_read, 15, 15)
+MD(scratch_block_size,  13,  12)
+MD(scratch_addr_offset, 11,   0)
+/** @} */
+
+/**
  * Render Target message function control bits:
  *  @{
  */
@@ -343,6 +354,18 @@ void gen8_set_dp_message(const struct brw_context *brw,
  bool header_present,
  bool end_of_thread);
 
+void gen8_set_dp_scratch_message(const struct brw_context *brw,
+ struct gen8_instruction *inst,
+ bool write,
+ bool dword,
+ bool invalidate_after_read,
+ unsigned num_regs,
+ unsigned addr_offset,
+ unsigned msg_length,
+ unsigned response_length,
+ bool header_present,
+ bool end_of_thread);
+
 /** Disassemble the instruction. */
 int gen8_disassemble(FILE *file, struct gen8_instruction *inst, int gen);
 
-- 
1.8.4.2

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

[Mesa-dev] [PATCH] glsl: Don't lose precision qualifiers when encountering centroid.