Re: [Mesa-dev] [PATCH] build/glsl: fix android build

[Tapani Pälli]

On 08/17/2012 01:05 AM, Matt Turner wrote:
> On Thu, Aug 16, 2012 at 2:13 AM, Tapani Pälli  wrote:
>> Commit 77a3efc6b907943903190b385fdf107c4acfcdca broke android
>> build that sets its own value for GLSL_SRCDIR. Patch sets the value
>> in Makefile.sources only if it is not defined previously.
>>
>> Signed-off-by: Tapani Pälli 
>> ---
>>  src/glsl/Makefile.sources | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
>> index aafb53e..1529b12 100644
>> --- a/src/glsl/Makefile.sources
>> +++ b/src/glsl/Makefile.sources
>> @@ -1,6 +1,6 @@
>>  # shared source lists for Makefile, SConscript, and Android.mk
>>
>> -GLSL_SRCDIR = $(top_srcdir)/src/glsl
>> +GLSL_SRCDIR ?= $(top_srcdir)/src/glsl
>>  GLSL_BUILDDIR = $(top_builddir)/src/glsl
>>
>>  # libglcpp
>> --
>> 1.7.11.4
> 
> This looks like it should work, but (at least on my machine) leaves
> GLSL_SRCDIR undefined and breaks the autotools build.

argh, it seems I'm trying to use a gnumake condition with automake here,
also ifeq type of conditional would not work. I'll try to come up with
an alternative.

> Sorry about the Android breakage. Chad asked if the patch you mention
> broke anything, but I never heard back.

no problem, we can fix it!


-- 

// Tapani




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

[Mesa-dev] X.Org Book Sprint 2012 (guide to writing graphics drivers)

[Matt Dew]

(Cross post. Yes, I know this is short notice and a short window to 
reply.   My apologies on that.)


X.Org Book Sprint 2012
Monday Sept 17 & Tuesday Sept 18.
Nürnberg (Nuremberg), Germany.

   The X.Org Consortium will hold a book sprint on the Monday and
Tuesday before the Developers Conference in Nürnberg Germany.
During these two days attendees will focus on a book for graphics
drivers development.  The book will be targeted towards new
contributors but will have enough details to be useful to all
levels of graphics driver development.  Anyone interested in
helping out and contributing to the book sprint is encouraged to
get involved.


From http://www.booksprints.net/about/

"A Book Sprint brings together a group to produce a book in 3-5 days.
There is no pre-production and the group is guided by a facilitator
from zero to published book. The books produced are high quality
content and are made available immediately at the end of the sprint
via print-on-demand services and e-book formats."

Our book sprint will be slightly different than that.  Our book sprint
is only two days and we are not starting from complete scratch. We are
starting with Marcheu's existing guide, located at:
http://people.freedesktop.org/~marcheu/linuxgraphicsdrivers.pdf

For more information or if you would like to participate in the book
sprint, please contact:
board at foundation.x.org
marcoz at osource.org

Please contact us on or before Mon Aug 20, 2012.

More information can be found at:
http://www.x.org/wiki/Events/BookSprint2012
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 53617] New: [llvmpipe] piglit fbo-depthtex regression

[bugzilla-daemon]

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

 Bug #: 53617
   Summary: [llvmpipe] piglit fbo-depthtex regression
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org
CC: bri...@vmware.com


mesa: 81ba2c53b698b3926e71dd37e7898719fd2deb3e (master)

Run piglit fbo-depthtex on llvmpipe.

$ ./bin/fbo-depthtex -auto
Probe at (64,240)
  Expected: 0.10 0.10 0.10
  Observed: 0.00 0.00 0.00
Probe at (192,240)
  Expected: 0.30 0.30 0.30
  Observed: 0.00 0.00 0.00
Probe at (320,240)
  Expected: 0.50 0.50 0.50
  Observed: 0.00 0.00 0.00
Probe at (448,240)
  Expected: 0.70 0.70 0.70
  Observed: 0.00 0.00 0.00
Probe at (576,240)
  Expected: 0.90 0.90 0.90
  Observed: 0.00 0.00 0.00
PIGLIT: {'result': 'fail' }


c969cb1447a0dc0da3cd8016f3e86dcfb381643f is the first bad commit
commit c969cb1447a0dc0da3cd8016f3e86dcfb381643f
Author: Brian Paul 
Date:   Thu Aug 9 20:59:44 2012 -0600

llvmpipe: add 'start' parameter to bind_sampler_states/views()

:04 04 a0e59eb6bfbbacd3f9e38b3056f236e7210c84c5
5852a901ed489daf14b8378b2b8b71d6142e0e56 Msrc
bisect run success

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 53616] New: [softpipe] sp_state_derived.c:308:update_polygon_stipple_enable: Assertion `unit >= softpipe->num_samplers[1]' failed.

[bugzilla-daemon]

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

 Bug #: 53616
   Summary: [softpipe]
sp_state_derived.c:308:update_polygon_stipple_enable:
Assertion `unit >= softpipe->num_samplers[1]' failed.
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Mesa core
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org
CC: bri...@vmware.com


mesa: 81ba2c53b698b3926e71dd37e7898719fd2deb3e (master)

Run glean paths on softpipe

$ ./bin/glean -r results -t paths --quick
sp_state_derived.c:308:update_polygon_stipple_enable: Assertion `unit >=
softpipe->num_samplers[1]' failed.

(gdb) bt
#0  _debug_assert_fail (expr=, file=,
line=, function=) at util/u_debug.c:281
#1  0x7fdcdf2ae1b0 in update_polygon_stipple_enable (prim=4,
softpipe=0x1e029c0) at sp_state_derived.c:308
#2  softpipe_update_derived (softpipe=0x1e029c0, prim=4) at
sp_state_derived.c:354
#3  0x7fdcdf2a2536 in softpipe_draw_vbo (pipe=0x1e029c0,
info=0x7fff611e8e50) at sp_draw_arrays.c:73
#4  0x7fdcdf3692b7 in st_draw_vbo (ctx=0x1f0f7c0, prims=0x1f8713c,
nr_prims=1, ib=0x0, index_bounds_valid=, min_index=0,
max_index=3, tfb_vertcount=0x0)
at ../../src/mesa/state_tracker/st_draw.c:265
#5  0x7fdcdf444885 in vbo_exec_vtx_flush (exec=0x1f868a8, keepUnmapped=1
'\001') at ../../src/mesa/vbo/vbo_exec_draw.c:409
#6  0x7fdcdf43846c in vbo_exec_FlushVertices_internal (exec=0x1f868a8,
unmap=) at ../../src/mesa/vbo/vbo_exec_api.c:539
#7  0x7fdcdf4419b8 in vbo_exec_FlushVertices (ctx=0x1f0f7c0,
flags=) at ../../src/mesa/vbo/vbo_exec_api.c:1296
#8  0x7fdcdf40d9c6 in _mesa_set_enable (ctx=0x1f0f7c0, cap=2882, state=0
'\000') at ../../src/mesa/main/enable.c:554
#9  0x004d186f in GLEAN::PathsTest::SetPathState (this=0x79f160,
path=GLEAN::PathsTest::STIPPLE, state=GLEAN::PathsTest::DISABLE)
at piglit/tests/glean/tpaths.cpp:161
#10 0x004d21f9 in GLEAN::PathsTest::runOne (this=0x79f160, r=...) at
piglit/tests/glean/tpaths.cpp:338
#11 0x0049a276 in GLEAN::BaseTest::run
(this=0x79f160, environment=...) at piglit/tests/glean/tbase.h:337
#12 0x0048f93c in main (argc=7, argv=0x7fff611ea4a8) at
piglit/tests/glean/main.cpp:141
(gdb) frame 1
#1  0x7fdcdf2ae1b0 in update_polygon_stipple_enable (prim=4,
softpipe=0x1e029c0) at sp_state_derived.c:308
308  assert(unit >= softpipe->num_samplers[PIPE_SHADER_FRAGMENT]);
(gdb) print unit
$1 = 0
(gdb) print softpipe->num_samplers
$2 = {0, 1, 0, 0}


The first bad commit could be any of:
25a42f39e362322dbac836c29b76b3104bbfe6f4
348ac08bfdc0741e8b2e14a747e2299c49771ece
c969cb1447a0dc0da3cd8016f3e86dcfb381643f
0ad95b923a2bfd91677872765946b6a2f8d11260
bd3733c0be174f947dd729e5fd987ea3a9566c27
f3c3aff6efed49b7740a144f767c713cb22561e2
f3cc4990a090ee076d8217c83aaf16e036e66686
6c8a13215813841703e7c2efa233e8d4cf517dfd
d4ab8bd0955f1b114acee80f17a2e82c7129cc1a
109e87dc6aed1ad42d36b3757accbb7e79401bce
cab2fed135bc1edf7b65ddca3236020638427061
10e552d056dd080c4e763a31df517c2d7684a9cf
a2c1df4c9a7375bc5306e8cfd07a9f7087759a96
bef196c7929606bb8c7e9c06fe83a90fc0d95f09
d663a557fd27d7c238248e19f22f2e6b05f03030
df87fb59136eb302d72eac4b58fd8ffb25989ed5
f6b7157550205a0633b4c2cb49a807d581176e21
0d308ef8feb081bedd12e01b270278e5f0de8e5a
We cannot bisect more!
bisect run cannot continue any more

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 53426] out-of-bounds access src/mesa/main/fbobject:222

[bugzilla-daemon]

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

--- Comment #2 from Brian Paul  2012-08-16 23:06:25 UTC 
---
Alternately, can you try this patch, Vinson?

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 792a92d..03094cc 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -215,8 +215,9 @@ _mesa_get_attachment(struct gl_context *ctx, struct
gl_frame
* hardware is used.
*/
   i = attachment - GL_COLOR_ATTACHMENT0_EXT;
-  if (i >= ctx->Const.MaxColorAttachments
- || (i > 0 && ctx->API == API_OPENGLES)) {
+  if (i >= ctx->Const.MaxColorAttachments ||
+  BUFFER_COLOR0 + i >= Elements(fb->Attachment) ||
+ (i > 0 && ctx->API == API_OPENGLES)) {
 return NULL;
   }
   return &fb->Attachment[BUFFER_COLOR0 + i];

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] R600 VDPAU 422 regression since r600g: make sure copying of all texture formats is accelerated

[Andy Furniss]

Marek Olšák wrote:

I have fixed this master. You were right - tiling on 422 was broken.


Ok, thanks, working now.

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

[Mesa-dev] [PATCH weston] compositor: add support for OES_EGL_image_external

[Rob Clark]

From: Rob Clark 

In cases where the GPU can natively handle certain YUV formats,
eglQueryWaylandBufferWL() can return the value EGL_TEXTURE_EXTERNAL_WL
and the compositor will treat the buffer as a single egl-image-external.

See:
http://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image_external.txt

v1: original
v2: rename EGL_TEXTURE_EXTERNAL_OES -> EGL_TEXTURE_EXTERNAL_WL and query
for the extension

Signed-off-by: Rob Clark 
---
 src/compositor.c |   47 +--
 src/compositor.h |2 ++
 src/weston-egl-ext.h |1 +
 3 files changed, 40 insertions(+), 10 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index b2a3ae9..5c6782e 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -719,14 +719,14 @@ ensure_textures(struct weston_surface *es, int 
num_textures)
 
for (i = es->num_textures; i < num_textures; i++) {
glGenTextures(1, &es->textures[i]);
-   glBindTexture(GL_TEXTURE_2D, es->textures[i]);
-   glTexParameteri(GL_TEXTURE_2D,
+   glBindTexture(es->target, es->textures[i]);
+   glTexParameteri(es->target,
GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
-   glTexParameteri(GL_TEXTURE_2D,
+   glTexParameteri(es->target,
GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
}
es->num_textures = num_textures;
-   glBindTexture(GL_TEXTURE_2D, 0);
+   glBindTexture(es->target, 0);
 }
 
 static void
@@ -771,6 +771,7 @@ weston_surface_attach(struct wl_surface *surface, struct 
wl_buffer *buffer)
if (wl_buffer_is_shm(buffer)) {
es->pitch = wl_shm_buffer_get_stride(buffer) / 4;
es->shader = &ec->texture_shader_rgba;
+   es->target = GL_TEXTURE_2D;
 
ensure_textures(es, 1);
glBindTexture(GL_TEXTURE_2D, es->textures[0]);
@@ -786,7 +787,7 @@ weston_surface_attach(struct wl_surface *surface, struct 
wl_buffer *buffer)
for (i = 0; i < es->num_images; i++)
ec->destroy_image(ec->egl_display, es->images[i]);
es->num_images = 0;
-
+   es->target = GL_TEXTURE_2D;
switch (format) {
case EGL_TEXTURE_RGB:
case EGL_TEXTURE_RGBA:
@@ -794,6 +795,11 @@ weston_surface_attach(struct wl_surface *surface, struct 
wl_buffer *buffer)
num_planes = 1;
es->shader = &ec->texture_shader_rgba;
break;
+   case EGL_TEXTURE_EXTERNAL_WL:
+   num_planes = 1;
+   es->target = GL_TEXTURE_EXTERNAL_OES;
+   es->shader = &ec->texture_shader_egl_external;
+   break;
case EGL_TEXTURE_Y_UV_WL:
num_planes = 2;
es->shader = &ec->texture_shader_y_uv;
@@ -824,8 +830,8 @@ weston_surface_attach(struct wl_surface *surface, struct 
wl_buffer *buffer)
es->num_images++;
 
glActiveTexture(GL_TEXTURE0 + i);
-   glBindTexture(GL_TEXTURE_2D, es->textures[i]);
-   ec->image_target_texture_2d(GL_TEXTURE_2D,
+   glBindTexture(es->target, es->textures[i]);
+   ec->image_target_texture_2d(es->target,
es->images[i]);
}
 
@@ -942,9 +948,9 @@ weston_surface_draw(struct weston_surface *es, struct 
weston_output *output,
for (i = 0; i < es->num_textures; i++) {
glUniform1i(es->shader->tex_uniforms[i], i);
glActiveTexture(GL_TEXTURE0 + i);
-   glBindTexture(GL_TEXTURE_2D, es->textures[i]);
-   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, filter);
-   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, filter);
+   glBindTexture(es->target, es->textures[i]);
+   glTexParameteri(es->target, GL_TEXTURE_MIN_FILTER, filter);
+   glTexParameteri(es->target, GL_TEXTURE_MAG_FILTER, filter);
}
 
v = ec->vertices.data;
@@ -2842,6 +2848,19 @@ static const char texture_fragment_shader_rgba[] =
FRAGMENT_SHADER_EXIT
"}\n";
 
+static const char texture_fragment_shader_egl_external[] =
+   "#extension GL_OES_EGL_image_external : require\n"
+   "precision mediump float;\n"
+   "varying vec2 v_texcoord;\n"
+   "uniform samplerExternalOES tex;\n"
+   FRAGMENT_SHADER_UNIFORMS
+   "void main()\n"
+   "{\n"
+   FRAGMENT_SHADER_INIT
+   "   gl_FragColor = texture2D(tex, v_texcoord)\n;"
+   FRAGMENT_SHADER_EXIT
+   "}\n";
+
 static const char texture_fragment_shader_y_uv[] =
"precision mediump float;\n"
"uniform sampler2D tex;\n"
@@ -3193,6 

[Mesa-dev] [PATCH mesa] add EGL_TEXTURE_EXTERNAL_WL to WL_bind_wayland_display spec

[Rob Clark]

From: Rob Clark 

Signed-off-by: Rob Clark 
---
 docs/WL_bind_wayland_display.spec |5 +
 include/EGL/eglmesaext.h  |1 +
 2 files changed, 6 insertions(+)

diff --git a/docs/WL_bind_wayland_display.spec 
b/docs/WL_bind_wayland_display.spec
index 02bd6ea..ce52e2d 100644
--- a/docs/WL_bind_wayland_display.spec
+++ b/docs/WL_bind_wayland_display.spec
@@ -75,6 +75,7 @@ New Tokens
 EGL_TEXTURE_Y_U_V_WL0x31D7
 EGL_TEXTURE_Y_UV_WL 0x31D8
 EGL_TEXTURE_Y_XUXV_WL   0x31D9
+EGL_TEXTURE_EXTERNAL_WL 0x31DA
 
 
 Additions to the EGL 1.4 Specification:
@@ -143,6 +144,10 @@ Additions to the EGL 1.4 Specification:
 Two planes, samples Y from the first plane to r in
 the shader, U and V from the second plane to g and a.
 
+EGL_TEXTURE_EXTERNAL_WL
+Treated as a single plane texture, but sampled with
+samplerExternalOES according to OES_EGL_image_external
+
 After querying the wl_buffer layout, create EGLImages for the
 planes by calling eglCreateImageKHR with wl_buffer as
 EGLClientBuffer, EGL_WAYLAND_BUFFER_WL as the target, NULL
diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h
index d476d18..2b91897 100644
--- a/include/EGL/eglmesaext.h
+++ b/include/EGL/eglmesaext.h
@@ -118,6 +118,7 @@ typedef EGLDisplay (EGLAPIENTRYP PFNEGLGETDRMDISPLAYMESA) 
(int fd);
 #define EGL_TEXTURE_Y_U_V_WL0x31D7
 #define EGL_TEXTURE_Y_UV_WL 0x31D8
 #define EGL_TEXTURE_Y_XUXV_WL   0x31D9
+#define EGL_TEXTURE_EXTERNAL_WL 0x31DA
 
 struct wl_display;
 struct wl_buffer;
-- 
1.7.9.5

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

Re: [Mesa-dev] [PATCH] build/glsl: fix android build

[Matt Turner]

On Thu, Aug 16, 2012 at 2:13 AM, Tapani Pälli  wrote:
> Commit 77a3efc6b907943903190b385fdf107c4acfcdca broke android
> build that sets its own value for GLSL_SRCDIR. Patch sets the value
> in Makefile.sources only if it is not defined previously.
>
> Signed-off-by: Tapani Pälli 
> ---
>  src/glsl/Makefile.sources | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
> index aafb53e..1529b12 100644
> --- a/src/glsl/Makefile.sources
> +++ b/src/glsl/Makefile.sources
> @@ -1,6 +1,6 @@
>  # shared source lists for Makefile, SConscript, and Android.mk
>
> -GLSL_SRCDIR = $(top_srcdir)/src/glsl
> +GLSL_SRCDIR ?= $(top_srcdir)/src/glsl
>  GLSL_BUILDDIR = $(top_builddir)/src/glsl
>
>  # libglcpp
> --
> 1.7.11.4

This looks like it should work, but (at least on my machine) leaves
GLSL_SRCDIR undefined and breaks the autotools build.

Sorry about the Android breakage. Chad asked if the patch you mention
broke anything, but I never heard back.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: do more teximage error checking for generic compressed formats

[Anuj Phogat]

On Thu, Aug 16, 2012 at 10:23 AM, Brian Paul  wrote:
> On 08/15/2012 02:31 PM, Anuj Phogat wrote:
>>
>> On Tue, May 1, 2012 at 2:07 PM, Brian Paul > > wrote:
>>
>> When glTexImage or glCopyTexImage is called with internalFormat
>> being a
>> generic compressed format (like GL_COMPRESSED_RGB) we need to do
>> the same
>> error checks as for specific compressed formats.  In particular,
>> check if
>> the texture target is compatible with the format.  None of the texture
>> compression formats we support so far work with GL_TEXTURE_1D, for
>> example.
>>
>> See also https://bugs.freedesktop.org/show_bug.cgi?id=49124
>>
>>
>> Brian, generic texture compression formats with GL_TEXTURE_1D seem to
>> work fine
>> on i965 drivers.
>
>
> Does that wind up using one of the DXT formats?
It uses RGTC for GL_COMPRESSED_RED & GL_COMPRESSED_RG
FXT for GL_COMPRESSED_RGB & GL_COMPRESSED_RGBA

>
>  I verified this by allowing generic texture
>>
>> compression formats for
>> GL_TEXTURE_1D in piglit copyteximage test case and reverting the
>> changes due to
>> this patch on mesa. Is this an issue only on swrast?
>
>
> That's what the bug reported, don't recall testing other drivers.
>
>
>
>> Returning
>> GL_INVALID_ENUM
>> error for generic texture compression formats in glTexImage1D() and
>> glCopyTexImage1D() doesn't seem to follow the OpenGL
>> specification. Spec does allow
>> GL_INVALID_ENUM error for a similar scenario in case
>> of glCompressedTexImage1D().
>> Please correct me if I'm missing something.
>
>
> I guess I'd like to check what either NVIDIA or AMD do in some of these
> cases.
>
> AFAIK, the various DXT, LATC, etc compressed formats are only spec'd to work
> with 2D textures, not 1D.  Since 1D textures are generally pretty small to
> start with, there's not a lot of value in compressed 1D textures.  Plus, if
> a compressed 1D texture uses 4 or 8 bytes to store a 4x1 block of texels,
> there's only 50% or 0% memory savings with compression.
>
> If you can post your patch for the piglit test I can run it with the NVIDIA
> driver and see what it does.
I'll send out a follow up patch for piglit test case which you can use
for testing.

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

Re: [Mesa-dev] [PATCH 1/3] i965: Move hiz resolve to after renderbuffer resizing

[Paul Berry]

On 14 August 2012 16:58, Chad Versace  wrote:

> Do all pre-draw hiz resolves *after* the renderbuffers are resized by
> intel_prepare_render. Otherwise, we may resolve buffers that are
> immediately discarded afterwards.
>
> Fixes the assertion failure below when resizing windows in KDE and under
> some unknown circumstance in Chrome OS:
> intel_resolve_map.c:46: intel_resolve_map_set: Assertion
> `(*tail)->need == need' failed.
>
> Also, remove the comment that "resolves must occur [...] before setting up
> any hardware state". That was true when resolves were implemented with
> meta-ops, but no longer with blorp.
>

Does "before setting up any hardware state" mean "before issuing any
commands to the batch buffer"?  If so then I think this is still necessary,
since blorp issues a bunch of commands to the batch buffer that change the
hardware state.

But it looks like this with this patch, we are still doing resolves before
setting up any hardware state, so I think we're ok.

Assuming the comment is fixed (or you can explain to me why I'm wrong),
this patch is:

Reviewed-by: Paul Berry 


>
> CC: Stephane Marchesin 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52252
> Reported-by: Lu Hua 
> Signed-off-by: Chad Versace 
> ---
>  src/mesa/drivers/dri/i965/brw_draw.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
> b/src/mesa/drivers/dri/i965/brw_draw.c
> index ccfc306..0b1a4e0 100644
> --- a/src/mesa/drivers/dri/i965/brw_draw.c
> +++ b/src/mesa/drivers/dri/i965/brw_draw.c
> @@ -433,11 +433,6 @@ static bool brw_try_draw_prims( struct gl_context
> *ctx,
>  */
> brw_validate_textures( brw );
>
> -   /* Resolves must occur after updating state and finalizing textures but
> -* before setting up any hardware state for this draw call.
> -*/
> -   brw_predraw_resolve_buffers(brw);
> -
> /* Bind all inputs, derive varying and size information:
>  */
> brw_merge_inputs( brw, arrays );
> @@ -458,6 +453,11 @@ static bool brw_try_draw_prims( struct gl_context
> *ctx,
>
> intel_prepare_render(intel);
>
> +   /* Resolves must occur after updating state, resizing renderbuffers,
> +* and finalizing textures.
> +*/
> +   brw_predraw_resolve_buffers(brw);
> +
> for (i = 0; i < nr_prims; i++) {
>int estimated_max_prim_size;
>
> --
> 1.7.11.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 51598] llvmpipe crashes with wine-1.5.7

[bugzilla-daemon]

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

--- Comment #4 from Vasily Khoruzhick  2012-08-16 20:51:40 
UTC ---
I'm using 32-bit system, so all apps are 32bit. Issue is reproducible only with
wine (and looks like only with DirectX-apps, have no issue with openarena which
is OpenGL I suppose).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] OSMesa and Shared GLAPI

[Kevin H. Hobbs]

With shared GLAPI can Mesa be built so that I link the same application
to GL and OSMesa and get onscreen rendering (or even accelerated
rendering) rendering when I have DISPLAY set and OSMesa rendering when I
don't?



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

Re: [Mesa-dev] R600 VDPAU 422 regression since r600g: make sure copying of all texture formats is accelerated

[Marek Olšák]

I have fixed this master. You were right - tiling on 422 was broken.

Marek

On Wed, Aug 8, 2012 at 1:04 AM, Andy Furniss  wrote:
> Marek Olšák wrote:
>>
>> Do you have any idea what could be wrong with the patch? Also could
>> please tell me how to setup VDPAU and where to download the tests, so
>> that I can test this.
>
>
> I don't know about the patch.
>
> One thing which may be a clue or a red herring is that when Christian first
> implemented 422 it was corrupt in the same way. He said he thought it was to
> do with tiling - and fixed it in (IIRC) ~deathsimple/mesa
>
> I run LFS so to get VDPAU I installed the lib from -
>
> git://people.freedesktop.org/~aplattner/libvdpau
>
> mplayer built from svn should find the lib and enable vdpau during
> configure.
>
> svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer
>
> I guess
>
> http://www.mplayerhq.hu/MPlayer/releases/MPlayer-1.1.tar.xz
>
> will also work if you don't want to do svn.
>
> For me -vo vdpau is the default output with mplayer - You may need to be
> explicit I guess if you already have some distro version with a config
> installed.
>
> This issue is just with -vo vdpau not decode (-vc ffmpeg12vdpau) as 422
> isn't implemented for decode anyway.
>
> When I autogen mesa I have --enable-gallium-g3dvl
>
> The sample I am using is from
>
> ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/
>
> The ones ending 400 are 422 the others are 420. The exact file is
>
> ftp://ftp.tek.com/tv/test/streams/Element/MPEG-Video/625/flwr_400.m2v
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 53426] out-of-bounds access src/mesa/main/fbobject:222

[bugzilla-daemon]

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

--- Comment #1 from Brian Paul  2012-08-16 19:02:18 UTC 
---
This warning is kind of bogus.

Jose suggested adding an assertion like this:

   assert(BUFFER_COLOR0 + ctx->Const.MaxColorAttachments <=
Elements(fb->Attachment));

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] mesa: silence coverity warning in _mesa_get_attachment()

[Brian Paul]

Actually, in this particular case, the assertion would have to be:

 assert(BUFFER_COLOR0 + ctx->Const.MaxColorAttachments <= 
Elements(fb->Attachment));


I'm not sure that Coverity will figure this out.

-Brian

On 08/16/2012 12:57 PM, Brian Paul wrote:

Yeah, this could happen a lot.

Vinson, can you try the assertion that Jose suggests below?

-Brian

On 08/16/2012 11:51 AM, Jose Fonseca wrote:

Given this sort of warning will pop-up all over the place, it would
be nice to educate coverity without introducing any behaviour change
or making logic statements unnecessarily more complex.

For example, I wonder if adding:

assert(ctx->Const.MaxColorAttachments<= Elements(fb->Attachment));

would be enough for coverity to realize this should never happen.
This is more self-documenting -- our assumptions are clearly stated
as such --, without changing behavior or making code more complex.

Jose

- Original Message -

The warning is kind of bogus since the i>=
ctx->Const.MaxColorAttachments
will prevent out of bounds array accesses, but it's easily silenced.

See http://bugs.freedesktop.org/show_bug.cgi?id=53426
---
src/mesa/main/fbobject.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index aa8ba18..556426c 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -215,8 +215,9 @@ _mesa_get_attachment(struct gl_context *ctx,
struct gl_framebuffer *fb,
* hardware is used.
*/
i = attachment - GL_COLOR_ATTACHMENT0_EXT;
- if (i>= ctx->Const.MaxColorAttachments
- || (i> 0&& ctx->API == API_OPENGLES)) {
+ if (i>= ctx->Const.MaxColorAttachments ||
+ i>= Elements(fb->Attachment) ||
+ (i> 0&& ctx->API == API_OPENGLES)) {
return NULL;
}
return&fb->Attachment[BUFFER_COLOR0 + i];
--
1.7.3.4

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






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

Re: [Mesa-dev] [PATCH] mesa: silence coverity warning in _mesa_get_attachment()

[Brian Paul]

Yeah, this could happen a lot.

Vinson, can you try the assertion that Jose suggests below?

-Brian

On 08/16/2012 11:51 AM, Jose Fonseca wrote:

Given this sort of warning will pop-up all over the place, it would be nice to 
educate coverity without introducing any behaviour change or making logic 
statements unnecessarily more complex.

For example, I wonder if adding:

   assert(ctx->Const.MaxColorAttachments<= Elements(fb->Attachment));

would be enough for coverity to realize this should never happen. This is more 
self-documenting -- our assumptions are clearly stated as such --, without 
changing behavior or making code more complex.

Jose

- Original Message -

The warning is kind of bogus since the i>=
ctx->Const.MaxColorAttachments
will prevent out of bounds array accesses, but it's easily silenced.

See http://bugs.freedesktop.org/show_bug.cgi?id=53426
---
  src/mesa/main/fbobject.c |5 +++--
  1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index aa8ba18..556426c 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -215,8 +215,9 @@ _mesa_get_attachment(struct gl_context *ctx,
struct gl_framebuffer *fb,
 * hardware is used.
 */
i = attachment - GL_COLOR_ATTACHMENT0_EXT;
-  if (i>= ctx->Const.MaxColorAttachments
- || (i>  0&&  ctx->API == API_OPENGLES)) {
+  if (i>= ctx->Const.MaxColorAttachments ||
+  i>= Elements(fb->Attachment) ||
+ (i>  0&&  ctx->API == API_OPENGLES)) {
 return NULL;
}
return&fb->Attachment[BUFFER_COLOR0 + i];
--
1.7.3.4

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



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

Re: [Mesa-dev] [PATCH] r600g-llvm: Crude fix for a race in initialization of the llvm backend

[Tom Stellard]

On Thu, Aug 16, 2012 at 02:39:48PM -0400, Tom Stellard wrote:
> On Thu, Aug 16, 2012 at 07:44:53PM +0200, Mathias Fröhlich wrote:
> > 
> > Hi,
> > 
> > > This is likely caused by the fact that the same LLVM Context is used
> > > for all threads.  Take a look at the comment starting at
> > > src/gallium/auxilary/gallivm/lp_bld_init.c:314
> > >
> > > You should be able to reproduce this error on llvmpipe as well.
> > > Creating a new LLVM Context for each thread should fix this.
> > 
> > I checked the suggestion, but: Are you sure?
> > I think we are using a new context for r* even per compile.
> > See radeon_setup_tgsi_llvm.c:1009.
> >
> 
> You're right.  I missed that.
> 
> > I have spent some time now to look into this a little closer:
> > The observation is that some pass manager stuff is crashing usually.
> > Its from the addPassesToEmitFile call while setting up 
> > AMDGPUTargetMachine but if you lock just this it crashes mostly in 
> > LLVMAddPromoteMemoryToRegisterPass called from radeon_llvm_finalize_module.
> > Locking both with the same mutex appears to work for a few short tests.
> >
> > Does this ring an other bell at the llvm guys?
> > 
> 

Actually, I just noticed that the LLVM docs say that only one thread can
access the target registry at a time:
http://llvm.org/docs/doxygen/html/structllvm_1_1TargetRegistry.html#a0b078b468553a84ec2b9fd70e93f7b43

Also, I think we should be doing the target registry once per
context rather than once per compile.

-Tom

> I'm not really sure about this one.  It might be worth while to see if
> you can reproduce the bug with the r600 backend built with LLVM rather
> than Mesa.  I have LLVM and Mesa branches that make this possible:
> 
> LLVM: http://cgit.freedesktop.org/~tstellar/llvm/ r600-master
> Mesa: cgit.freedesktop.org/~tstellar/mesa/ r600-external-llvm
> 
> I haven't tested it in a while, though, so it may not work.
> 
> -Tom
> 
> 
> 
> > Greetings
> > 
> > Mathias
> > 
> > 
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > 
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 

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

Re: [Mesa-dev] [PATCH] r600g-llvm: Crude fix for a race in initialization of the llvm backend

[Tom Stellard]

On Thu, Aug 16, 2012 at 07:44:53PM +0200, Mathias Fröhlich wrote:
> 
> Hi,
> 
> > This is likely caused by the fact that the same LLVM Context is used
> > for all threads.  Take a look at the comment starting at
> > src/gallium/auxilary/gallivm/lp_bld_init.c:314
> >
> > You should be able to reproduce this error on llvmpipe as well.
> > Creating a new LLVM Context for each thread should fix this.
> 
> I checked the suggestion, but: Are you sure?
> I think we are using a new context for r* even per compile.
> See radeon_setup_tgsi_llvm.c:1009.
>

You're right.  I missed that.

> I have spent some time now to look into this a little closer:
> The observation is that some pass manager stuff is crashing usually.
> Its from the addPassesToEmitFile call while setting up 
> AMDGPUTargetMachine but if you lock just this it crashes mostly in 
> LLVMAddPromoteMemoryToRegisterPass called from radeon_llvm_finalize_module.
> Locking both with the same mutex appears to work for a few short tests.
>
> Does this ring an other bell at the llvm guys?
> 

I'm not really sure about this one.  It might be worth while to see if
you can reproduce the bug with the r600 backend built with LLVM rather
than Mesa.  I have LLVM and Mesa branches that make this possible:

LLVM: http://cgit.freedesktop.org/~tstellar/llvm/ r600-master
Mesa: cgit.freedesktop.org/~tstellar/mesa/ r600-external-llvm

I haven't tested it in a while, though, so it may not work.

-Tom



> Greetings
> 
> Mathias
> 
> 
> ___
> 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 53608] New: lp_test_conv crashes on Sandy Bridge

[bugzilla-daemon]

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

 Bug #: 53608
   Summary: lp_test_conv crashes on Sandy Bridge
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
  Severity: critical
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org
CC: jfons...@vmware.com


mesa: 0efd564a09988a4a7f49cab70b778026459dff1b (master)

lp_test_conv crashes on Sandy Bridge with llvm-3.2svn, llvm-3.1, llvm-3.0, and
llvm-2.9.

(gdb) bt
#0  0x000100d13044 in ?? ()
#1  0x00011c43 in test_one (verbose=0, fp=0x0, src_type={floating = 1,
fixed = 0, sign = 1, norm = 1, width = 32, length = 8}, dst_type={floating = 0,
fixed = 0, sign = 1, norm = 1, width = 16, length = 8}) at
src/gallium/drivers/llvmpipe/lp_test_conv.c:243
#2  0x00012507 in test_some (verbose=0, fp=0x0, n=1000) at
src/gallium/drivers/llvmpipe/lp_test_conv.c:429
#3  0x00013701 in main (argc=1, argv=0x7fff5fbff5d0) at
src/gallium/drivers/llvmpipe/lp_test_main.c:406

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 51598] llvmpipe crashes with wine-1.5.7

[bugzilla-daemon]

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

--- Comment #3 from José Fonseca  2012-08-16 18:16:53 UTC 
---
I don't know why some many issues when running WINE. Unfortunately I don't have
the time to chace them.

I known that at one point the problem was not WINE per se, but the fact that
WINE is 32bits.

Could you try running a 32bits GL game (like Quake3 arena demo binaries)?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] mesa/dlopen: use HAVE_DLOPEN instead of _GNU_SOURCE

[Matt Turner]

On Thu, Aug 16, 2012 at 3:59 AM, Tapani Pälli  wrote:
> Patches changes mesa to use 'HAVE_DLOPEN' defined by configure and Android.mk
> instead of _GNU_SOURCE for detecting dlopen capability. This makes dlopen to
> work also on Android where _GNU_SOURCE is not defined.
>
> Signed-off-by: Tapani Pälli 
> ---
>  Android.common.mk  | 4 +++-
>  configure.ac   | 5 +++--
>  src/mesa/main/dlopen.c | 8 
>  3 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/Android.common.mk b/Android.common.mk
> index e8b9006..1e9f040 100644
> --- a/Android.common.mk
> +++ b/Android.common.mk
> @@ -47,7 +47,9 @@ LOCAL_CFLAGS += \
>  ifeq ($(strip $(MESA_ENABLE_ASM)),true)
>  ifeq ($(TARGET_ARCH),x86)
>  LOCAL_CFLAGS += \
> -   -DUSE_X86_ASM
> +   -DUSE_X86_ASM \
> +   -DHAVE_DLOPEN \
> +
>  endif
>  endif
>
> diff --git a/configure.ac b/configure.ac
> index 0329bad..5174280 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -503,8 +503,9 @@ MESA_PIC_FLAGS
>
>  dnl Check to see if dlopen is in default libraries (like Solaris, which
>  dnl has it in libc), or if libdl is needed to get it.
> -AC_CHECK_FUNC([dlopen], [],
> -[AC_CHECK_LIB([dl], [dlopen], [DLOPEN_LIBS="-ldl"])])
> +AC_CHECK_FUNC([dlopen], [DEFINES="$DEFINES -DHAVE_DLOPEN"],
> +[AC_CHECK_LIB([dl], [dlopen],
> +   [DEFINES="$DEFINES -DHAVE_DLOPEN"; DLOPEN_LIBS="-ldl"])])
>  AC_SUBST([DLOPEN_LIBS])
>
>  dnl See if posix_memalign is available
> diff --git a/src/mesa/main/dlopen.c b/src/mesa/main/dlopen.c
> index 57a3329..30fcd1d 100644
> --- a/src/mesa/main/dlopen.c
> +++ b/src/mesa/main/dlopen.c
> @@ -31,7 +31,7 @@
>  #include "compiler.h"
>  #include "dlopen.h"
>
> -#if defined(_GNU_SOURCE) && !defined(__MINGW32__) && !defined(__blrts)
> +#if defined(HAVE_DLOPEN) && !defined(__MINGW32__) && !defined(__blrts)

I imagine that __MINGW32__ and __blrts (whatever that is) are
special-cased because they define _GNU_SOURCE, but don't have dlopen.
It'd probably be okay to simplify that to just #if
defined(HAVE_DLOPEN) and let configure.ac decide if dlopen is
available.

Otherwise, seems reasonable.

Acked-by: Matt Turner 

(send an updated patch and I'll commit it for you)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Bug 53572] scons: *** Two environments with different actions were specified for the same target: mesa/src/glsl/glcpp/pp.o

[bugzilla-daemon]

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

José Fonseca  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from José Fonseca  2012-08-16 18:13:30 UTC 
---
I think this was fixed with


commit 50dec637909cfe8fa53582f2f64ab261b123f092
Author: José Fonseca 
Date:   Wed Aug 15 19:24:58 2012 +0100

scons: Fix MinGW cross compilation.

Compensate for the recent changes and assumptions added to
Makefiles.sources

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 1/3] build: Require X11 pkg-config files

[Matt Turner]

On Wed, Aug 15, 2012 at 2:21 AM, Andreas Boll
 wrote:
>> @@ -975,38 +941,19 @@ xyesno)
>>  fi
>>
>>  # find the DRI deps for libGL
>> -if test "$x11_pkgconfig" = yes; then
>> -PKG_CHECK_MODULES([XCB],[x11-xcb xcb-glx >= 1.8.1])
>
> Don't we need to check against xcb-glx >= 1.8.1?

Yes, thank you. I'll fix that before I commit it.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] mesa: silence coverity warning in _mesa_get_attachment()

[Jose Fonseca]

Given this sort of warning will pop-up all over the place, it would be nice to 
educate coverity without introducing any behaviour change or making logic 
statements unnecessarily more complex.

For example, I wonder if adding:

  assert(ctx->Const.MaxColorAttachments <= Elements(fb->Attachment));

would be enough for coverity to realize this should never happen. This is more 
self-documenting -- our assumptions are clearly stated as such --, without 
changing behavior or making code more complex.

Jose

- Original Message -
> The warning is kind of bogus since the i >=
> ctx->Const.MaxColorAttachments
> will prevent out of bounds array accesses, but it's easily silenced.
> 
> See http://bugs.freedesktop.org/show_bug.cgi?id=53426
> ---
>  src/mesa/main/fbobject.c |5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
> index aa8ba18..556426c 100644
> --- a/src/mesa/main/fbobject.c
> +++ b/src/mesa/main/fbobject.c
> @@ -215,8 +215,9 @@ _mesa_get_attachment(struct gl_context *ctx,
> struct gl_framebuffer *fb,
> * hardware is used.
> */
>i = attachment - GL_COLOR_ATTACHMENT0_EXT;
> -  if (i >= ctx->Const.MaxColorAttachments
> -   || (i > 0 && ctx->API == API_OPENGLES)) {
> +  if (i >= ctx->Const.MaxColorAttachments ||
> +  i >= Elements(fb->Attachment) ||
> +   (i > 0 && ctx->API == API_OPENGLES)) {
>return NULL;
>}
>return &fb->Attachment[BUFFER_COLOR0 + i];
> --
> 1.7.3.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] r600g-llvm: Crude fix for a race in initialization of the llvm backend

[Mathias Fröhlich]

Hi,

> This is likely caused by the fact that the same LLVM Context is used
> for all threads.  Take a look at the comment starting at
> src/gallium/auxilary/gallivm/lp_bld_init.c:314
>
> You should be able to reproduce this error on llvmpipe as well.
> Creating a new LLVM Context for each thread should fix this.

I checked the suggestion, but: Are you sure?
I think we are using a new context for r* even per compile.
See radeon_setup_tgsi_llvm.c:1009.

I have spent some time now to look into this a little closer:
The observation is that some pass manager stuff is crashing usually.
Its from the addPassesToEmitFile call while setting up 
AMDGPUTargetMachine but if you lock just this it crashes mostly in 
LLVMAddPromoteMemoryToRegisterPass called from radeon_llvm_finalize_module.
Locking both with the same mutex appears to work for a few short tests.

Does this ring an other bell at the llvm guys?

Greetings

Mathias


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

Re: [Mesa-dev] [PATCH] glsl: Fix array overflow.

[Brian Paul]

On 08/14/2012 07:40 PM, Stéphane Marchesin wrote:

Otherwise we run past the end of the array and crash.

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Stéphane Marchesin
---
  src/glsl/link_uniforms.cpp |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index 25dc1d7..eef9025 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -313,7 +313,7 @@ private:
 const gl_texture_index target = base_type->sampler_index();
 const unsigned shadow = base_type->sampler_shadow;
 for (unsigned i = this->uniforms[id].sampler
-; i<  this->next_sampler
+; i<  MIN2(this->next_sampler, MAX_SAMPLERS)
 ; i++) {
this->targets[i] = target;
this->shader_samplers_used |= 1U<<  i;


Hi Stéphane,

I wonder if we should be checking earlier if the number of samplers 
exceeds the GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS limit.  Ian, Eric?


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

Re: [Mesa-dev] [PATCH] mesa: do more teximage error checking for generic compressed formats

[Brian Paul]

On 08/15/2012 02:31 PM, Anuj Phogat wrote:

On Tue, May 1, 2012 at 2:07 PM, Brian Paul mailto:bri...@vmware.com>> wrote:

When glTexImage or glCopyTexImage is called with internalFormat
being a
generic compressed format (like GL_COMPRESSED_RGB) we need to do
the same
error checks as for specific compressed formats.  In particular,
check if
the texture target is compatible with the format.  None of the texture
compression formats we support so far work with GL_TEXTURE_1D, for
example.

See also https://bugs.freedesktop.org/show_bug.cgi?id=49124


Brian, generic texture compression formats with GL_TEXTURE_1D seem to
work fine
on i965 drivers.


Does that wind up using one of the DXT formats?


 I verified this by allowing generic texture

compression formats for
GL_TEXTURE_1D in piglit copyteximage test case and reverting the
changes due to
this patch on mesa. Is this an issue only on swrast?


That's what the bug reported, don't recall testing other drivers.



Returning
GL_INVALID_ENUM
error for generic texture compression formats in glTexImage1D() and
glCopyTexImage1D() doesn't seem to follow the OpenGL
specification. Spec does allow
GL_INVALID_ENUM error for a similar scenario in case
of glCompressedTexImage1D().
Please correct me if I'm missing something.


I guess I'd like to check what either NVIDIA or AMD do in some of 
these cases.


AFAIK, the various DXT, LATC, etc compressed formats are only spec'd 
to work with 2D textures, not 1D.  Since 1D textures are generally 
pretty small to start with, there's not a lot of value in compressed 
1D textures.  Plus, if a compressed 1D texture uses 4 or 8 bytes to 
store a 4x1 block of texels, there's only 50% or 0% memory savings 
with compression.


If you can post your patch for the piglit test I can run it with the 
NVIDIA driver and see what it does.


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

Re: [Mesa-dev] [PATCH] wayland-drm: close fd after the display is uninitialized

[Kristian Høgsberg]

On Wed, Aug 15, 2012 at 06:14:44PM +0200, Philipp Brüschweiler wrote:
> This fixes a "kernel rejected pushbuf: Bad file descriptor" error on
> wl_drm display destruction.

Thanks, that looks good, applied.

Kristian

> ---
>  src/gallium/state_trackers/egl/wayland/native_drm.c | 5 +++--
>  1 Datei geändert, 3 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)
> 
> diff --git a/src/gallium/state_trackers/egl/wayland/native_drm.c 
> b/src/gallium/state_trackers/egl/wayland/native_drm.c
> index 006b3d5..c6f6197 100644
> --- a/src/gallium/state_trackers/egl/wayland/native_drm.c
> +++ b/src/gallium/state_trackers/egl/wayland/native_drm.c
> @@ -71,8 +71,6 @@ wayland_drm_display_destroy(struct native_display *ndpy)
>  {
> struct wayland_drm_display *drmdpy = wayland_drm_display(ndpy);
>  
> -   if (drmdpy->fd)
> -  close(drmdpy->fd);
> if (drmdpy->wl_drm)
>wl_drm_destroy(drmdpy->wl_drm);
> if (drmdpy->device_name)
> @@ -84,6 +82,9 @@ wayland_drm_display_destroy(struct native_display *ndpy)
>  
> ndpy_uninit(ndpy);
>  
> +   if (drmdpy->fd)
> +  close(drmdpy->fd);
> +
> FREE(drmdpy);
>  }
>  
> -- 
> 1.7.11.4
> 
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/fs: Don't try 16-wide if 8-wide uses more than half the registers.

[Paul Berry]

On 15 August 2012 16:37, Kenneth Graunke  wrote:

> 16-wide programs use roughly twice as many registers as 8-wide, and we
> don't support spilling in 16-wide.  So if an 8-wide program uses more
> than half the available GRFs, the 16-wide one almost certainly will fail
> to compile during register allocation.
>
> Not only that, but attempting to compiling such shaders is expensive:
> programs that use a lot of registers tend to be quite complex, meaning
> that we spend more time than usual generating and optimizing code.  If
> we fail at register allocation, we've failed at the last step, after
> needlessly burning through a lot of CPU time.
>
> To make things worse, such shader compilation typically happens at the
> first draw call using the shader, so it can cause the GPU to stall.
>
> With all that in mind, it makes sense to short-circuit the 16-wide
> attempt if the 8-wide program uses too many registers.  I've chosen 75
> to be conservative---if we /can/ compile a SIMD16 program, we want to.
>
> Reduces the number of GPU stalls due to fragment shader recompiles
> in Left 4 Dead 2 by about 20%, and reduces the duration of many of the
> remaining stalls by about half.
>
> Signed-off-by: Kenneth Graunke 
> ---
>  src/mesa/drivers/dri/i965/brw_fs.cpp | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index e2dafdc..a113105 100644
> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> @@ -2100,7 +2100,10 @@ brw_wm_fs_emit(struct brw_context *brw, struct
> brw_wm_compile *c,
>return false;
> }
>
> -   if (intel->gen >= 5 && c->prog_data.nr_pull_params == 0) {
> +   if (v.grf_used >= 75) {
> +  perf_debug("Too many registers to attempt compiling a 16-wide
> shader; "
> + "falling back to 8-wide at a 10-20%% performance
> cost.\n");
> +   } else if (intel->gen >= 5 && c->prog_data.nr_pull_params == 0) {
>

It looks like this code will give the perf warning even for situations
where we couldn't do 16-wide anyhow (intel->gen == 4 ||
c->prog_data.nr_pull_params != 0).  To avoid confusing people, we should
probably only give the perf warning if register count is the *only* reason
we can't do 16-wide.


>c->dispatch_width = 16;
>fs_visitor v2(c, prog, shader);
>v2.import_uniforms(&v);
> --
> 1.7.11.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] mesa: silence coverity warning in _mesa_get_attachment()

[Brian Paul]

The warning is kind of bogus since the i >= ctx->Const.MaxColorAttachments
will prevent out of bounds array accesses, but it's easily silenced.

See http://bugs.freedesktop.org/show_bug.cgi?id=53426
---
 src/mesa/main/fbobject.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index aa8ba18..556426c 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -215,8 +215,9 @@ _mesa_get_attachment(struct gl_context *ctx, struct 
gl_framebuffer *fb,
* hardware is used.
*/
   i = attachment - GL_COLOR_ATTACHMENT0_EXT;
-  if (i >= ctx->Const.MaxColorAttachments
- || (i > 0 && ctx->API == API_OPENGLES)) {
+  if (i >= ctx->Const.MaxColorAttachments ||
+  i >= Elements(fb->Attachment) ||
+ (i > 0 && ctx->API == API_OPENGLES)) {
 return NULL;
   }
   return &fb->Attachment[BUFFER_COLOR0 + i];
-- 
1.7.3.4

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

Re: [Mesa-dev] [PATCH] st/mesa: index can be negative in the PROGRAM_CONSTANT case

[Brian Paul]

On 08/12/2012 10:35 AM, Niels Ole Salscheider wrote:

---
  src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp 
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index 39717b6..9f58312 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4028,7 +4028,7 @@ dst_register(struct st_translate *t,
  static struct ureg_src
  src_register(struct st_translate *t,
   gl_register_file file,
- GLuint index)
+ GLint index)
  {
 switch(file) {
 case PROGRAM_UNDEFINED:


Reviewed-by: Brian Paul 

Thanks.  I'll commit this soon.

-Brian

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

Re: [Mesa-dev] [PATCH] Remove 3D registers from compute command stream

[Tom Stellard]

On Wed, Aug 15, 2012 at 12:30:38PM -0400, Matt Harvey wrote:
> Hey, I'd be interested in testing this to make sure it works, but I have a
> HD4200 running r600g, and I don't think that card has opencl support at the
> moment. Do you know if that would still be useful for testing, and what I
> would use for testing? Also, I was having trouble getting the proper
> libraries installed for building from source last weekend, so it might take
> me until after next weekend to get anything tested.
> Does the mailing list think that would be useful?
>

Unfortunately, there is no compute support yet for HD4200, so there is not much
to test for this patch.  However, it is always useful to have people do piglit
runs on various cards to identify regressions.  If you need help setting up
piglit, or mesa, the best thing to do is to stop by #radeon on irc.freenode.net
and ask for questions.

-Tom
 
> Matt
> 
> On Mon, Aug 13, 2012 at 4:05 PM, archibald  wrote:
> 
> > Hi list,
> >
> > Here is my attempt at solving the task "Remove 3D registers from compute
> > command stream" on 
> > http://dri.freedesktop.org/**wiki/R600ToDo.
> > It's my
> > first attempt at a patch for mesa, so I'd appreciate any comments or
> > advice that people might have.
> >
> > I don't have a Cayman card, so I'm not able to test on that, so that part
> > is officially untested.
> >
> > I ran the opencl-example programs to test the opencl aspect and there was
> > no difference in the number of passed and failed tests (67:4) before and
> > after the patch. OpenArena and my desktop session ran fine afterwards, but
> > I'm having `fun' trying to get piglit to behave so I couldn't do a
> > full regression test.
> >
> > Thanks,
> > Archibald
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >
> >

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

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

Re: [Mesa-dev] [PATCH] Remove 3D registers from compute command stream

[Tom Stellard]

Hi,

In the future, could you use git format-patch to send patches.

Overall, I think this looks OK, I just need to test it out a little bit.

-Tom

On Mon, Aug 13, 2012 at 09:05:29PM +0100, archibald wrote:
> diff --git a/src/gallium/drivers/r600/evergreen_compute.c 
> b/src/gallium/drivers/r600/evergreen_compute.c
> index 0d6eb4e..acf91ba 100644
> --- a/src/gallium/drivers/r600/evergreen_compute.c
> +++ b/src/gallium/drivers/r600/evergreen_compute.c
> @@ -325,20 +325,10 @@ static void compute_emit_cs(struct r600_context *ctx, 
> const uint *block_layout,
>   struct evergreen_compute_resource *resources =
>   ctx->cs_shader_state.shader->resources;
>  
> - /* Initialize all the registers common to both 3D and compute.  Some
> -  * 3D only register will be initialized by this atom as well, but
> -  * this is OK for now.
> -  *
> -  * See evergreen_init_atom_start_cs() or cayman_init_atom_start_cs() in
> -  * evergreen_state.c for the list of registers that are intialized by
> -  * the start_cs_cmd atom.
> -  */
> - r600_emit_atom(ctx, &ctx->start_cs_cmd.atom);
> -
> - /* Initialize all the compute specific registers.
> + /* Initialize all the compute-related registers.
>*
>* See evergreen_init_atom_start_compute_cs() in this file for the list
> -  * of registers initialized by the start_compuet_cs_cmd atom.
> +  * of registers initialized by the start_compute_cs_cmd atom.
>*/
>   r600_emit_atom(ctx, &ctx->start_compute_cs_cmd.atom);
>  
> @@ -590,11 +580,10 @@ void evergreen_init_atom_start_compute_cs(struct 
> r600_context *ctx)
>   int num_threads;
>   int num_stack_entries;
>  
> - /* We aren't passing the EMIT_EARLY flag as the third argument
> -  * because we will be emitting this atom manually in order to
> -  * ensure it gets emitted after the start_cs_cmd atom.
> + /* since all required registers are initialised in the
> +  * start_compute_cs_cmd atom, we can EMIT_EARLY here.
>*/
> - r600_init_command_buffer(cb, 256, 0);
> + r600_init_command_buffer(cb, 256, EMIT_EARLY);
>   cb->pkt_flags = RADEON_CP_PACKET3_COMPUTE_MODE;
>  
>   switch (ctx->family) {
> @@ -643,6 +632,8 @@ void evergreen_init_atom_start_compute_cs(struct 
> r600_context *ctx)
>   }
>  
>   /* Config Registers */
> + evergreen_init_common_regs(cb, ctx->chip_class
> + , ctx->family, ctx->screen->info.drm_minor);
>  
>   /* The primitive type always needs to be POINTLIST for compute. */
>   r600_store_config_reg(cb, R_008958_VGT_PRIMITIVE_TYPE,
> diff --git a/src/gallium/drivers/r600/evergreen_state.c 
> b/src/gallium/drivers/r600/evergreen_state.c
> index 67ae7d3..addc36a 100644
> --- a/src/gallium/drivers/r600/evergreen_state.c
> +++ b/src/gallium/drivers/r600/evergreen_state.c
> @@ -1901,19 +1901,13 @@ static void cayman_init_atom_start_cs(struct 
> r600_context *rctx)
>   r600_store_value(cb, 0x8000);
>   r600_store_value(cb, 0x8000);
>  
> + cayman_init_common_regs(cb);
> +
>   r600_store_config_reg_seq(cb, R_008C00_SQ_CONFIG, 2);
>   r600_store_value(cb, S_008C00_EXPORT_SRC_C(1)); /* R_008C00_SQ_CONFIG */
>   /* always set the temp clauses */
>   r600_store_value(cb, S_008C04_NUM_CLAUSE_TEMP_GPRS(4)); /* 
> R_008C04_SQ_GPR_RESOURCE_MGMT_1 */
>  
> - r600_store_config_reg_seq(cb, R_008C10_SQ_GLOBAL_GPR_RESOURCE_MGMT_1, 
> 2);
> - r600_store_value(cb, 0); /* R_008C10_SQ_GLOBAL_GPR_RESOURCE_MGMT_1 */
> - r600_store_value(cb, 0); /* R_008C14_SQ_GLOBAL_GPR_RESOURCE_MGMT_2 */
> -
> - r600_store_config_reg(cb, R_008D8C_SQ_DYN_GPR_CNTL_PS_FLUSH_REQ, (1 << 
> 8));
> -
> - r600_store_context_reg(cb, R_028A4C_PA_SC_MODE_CNTL_1, 0);
> -
>   r600_store_context_reg_seq(cb, R_028A10_VGT_OUTPUT_PATH_CNTL, 13);
>   r600_store_value(cb, 0); /* R_028A10_VGT_OUTPUT_PATH_CNTL */
>   r600_store_value(cb, 0); /* R_028A14_VGT_HOS_CNTL */
> @@ -1929,16 +1923,77 @@ static void cayman_init_atom_start_cs(struct 
> r600_context *rctx)
>   r600_store_value(cb, 0); /* R_028A3C_VGT_GROUP_VECT_1_FMT_CNTL */
>   r600_store_value(cb, 0); /* R_028A40_VGT_GS_MODE */
>  
> - r600_store_context_reg_seq(cb, R_028B94_VGT_STRMOUT_CONFIG, 2);
> - r600_store_value(cb, 0); /* R_028B94_VGT_STRMOUT_CONFIG */
> - r600_store_value(cb, 0); /* R_028B98_VGT_STRMOUT_BUFFER_CONFIG */
> -
>   r600_store_context_reg_seq(cb, R_028AB4_VGT_REUSE_OFF, 2);
>   r600_store_value(cb, 0); /* R_028AB4_VGT_REUSE_OFF */
>   r600_store_value(cb, 0); /* R_028AB8_VGT_VTX_CNT_EN */
>  
>   r600_store_config_reg(cb, R_008A14_PA_CL_ENHANCE, (3 << 1) | 1);
>  
> + r600_store_ctl_const(cb, R_03CFF0_SQ_VTX_BASE_VTX_LOC, 0);
> +
> + r600_store_context_reg_seq(cb, R_028028_DB_STENCIL_CLEAR, 2);
> + r600_store_value(cb, 0); /* R_028028_DB_STENCIL_CLEAR */
> + r600_store_value(cb, 

Re: [Mesa-dev] [PATCH] radeonsi: Fix symbol conflicts with r600g.

[Michel Dänzer]

On Don, 2012-08-16 at 09:26 -0400, Alex Deucher wrote: 
> On Thu, Aug 16, 2012 at 6:04 AM, Michel Dänzer  wrote:
> > From: Michel Dänzer 
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50389
> >
> > Signed-off-by: Michel Dänzer 
> 
> Reviewed-by: Alex Deucher 

Thanks, Alex.


> BTW, any reason not to rename the files at this point?

No particular reason.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] radeonsi: Fix symbol conflicts with r600g.

[Alex Deucher]

On Thu, Aug 16, 2012 at 6:04 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50389
>
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 

BTW, any reason not to rename the files at this point?

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

[Mesa-dev] [PATCH] mesa/dlopen: use HAVE_DLOPEN instead of _GNU_SOURCE

[Tapani Pälli]

Patches changes mesa to use 'HAVE_DLOPEN' defined by configure and Android.mk
instead of _GNU_SOURCE for detecting dlopen capability. This makes dlopen to
work also on Android where _GNU_SOURCE is not defined.

Signed-off-by: Tapani Pälli 
---
 Android.common.mk  | 4 +++-
 configure.ac   | 5 +++--
 src/mesa/main/dlopen.c | 8 
 3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/Android.common.mk b/Android.common.mk
index e8b9006..1e9f040 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -47,7 +47,9 @@ LOCAL_CFLAGS += \
 ifeq ($(strip $(MESA_ENABLE_ASM)),true)
 ifeq ($(TARGET_ARCH),x86)
 LOCAL_CFLAGS += \
-   -DUSE_X86_ASM
+   -DUSE_X86_ASM \
+   -DHAVE_DLOPEN \
+
 endif
 endif
 
diff --git a/configure.ac b/configure.ac
index 0329bad..5174280 100644
--- a/configure.ac
+++ b/configure.ac
@@ -503,8 +503,9 @@ MESA_PIC_FLAGS
 
 dnl Check to see if dlopen is in default libraries (like Solaris, which
 dnl has it in libc), or if libdl is needed to get it.
-AC_CHECK_FUNC([dlopen], [],
-[AC_CHECK_LIB([dl], [dlopen], [DLOPEN_LIBS="-ldl"])])
+AC_CHECK_FUNC([dlopen], [DEFINES="$DEFINES -DHAVE_DLOPEN"],
+[AC_CHECK_LIB([dl], [dlopen],
+   [DEFINES="$DEFINES -DHAVE_DLOPEN"; DLOPEN_LIBS="-ldl"])])
 AC_SUBST([DLOPEN_LIBS])
 
 dnl See if posix_memalign is available
diff --git a/src/mesa/main/dlopen.c b/src/mesa/main/dlopen.c
index 57a3329..30fcd1d 100644
--- a/src/mesa/main/dlopen.c
+++ b/src/mesa/main/dlopen.c
@@ -31,7 +31,7 @@
 #include "compiler.h"
 #include "dlopen.h"
 
-#if defined(_GNU_SOURCE) && !defined(__MINGW32__) && !defined(__blrts)
+#if defined(HAVE_DLOPEN) && !defined(__MINGW32__) && !defined(__blrts)
 #include 
 #endif
 #if defined(_WIN32)
@@ -48,7 +48,7 @@ _mesa_dlopen(const char *libname, int flags)
 {
 #if defined(__blrts)
return NULL;
-#elif defined(_GNU_SOURCE)
+#elif defined(HAVE_DLOPEN)
flags = RTLD_LAZY | RTLD_GLOBAL; /* Overriding flags at this time */
return dlopen(libname, flags);
 #elif defined(__MINGW32__)
@@ -80,7 +80,7 @@ _mesa_dlsym(void *handle, const char *fname)
strncpy(fname2 + 1, fname, 998);
fname2[999] = 0;
u.v = dlsym(handle, fname2);
-#elif defined(_GNU_SOURCE)
+#elif defined(HAVE_DLOPEN)
u.v = dlsym(handle, fname);
 #elif defined(__MINGW32__)
u.v = (void *) GetProcAddress(handle, fname);
@@ -99,7 +99,7 @@ _mesa_dlclose(void *handle)
 {
 #if defined(__blrts)
(void) handle;
-#elif defined(_GNU_SOURCE)
+#elif defined(HAVE_DLOPEN)
dlclose(handle);
 #elif defined(__MINGW32__)
FreeLibrary(handle);
-- 
1.7.11.4

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

[Mesa-dev] [Bug 51598] llvmpipe crashes with wine-1.5.7

[bugzilla-daemon]

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

--- Comment #2 from Vasily Khoruzhick  2012-08-16 10:40:28 
UTC ---
Just rebuilt mesa against llvm-3.0 and it works

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 51598] llvmpipe crashes with wine-1.5.7

[bugzilla-daemon]

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

--- Comment #1 from Vasily Khoruzhick  2012-08-16 10:17:55 
UTC ---
Anyone can take a look? It crashes on any d3d app startup, both on git master
and on 8.0.4

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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] radeonsi: Fix symbol conflicts with r600g.

[Michel Dänzer]

From: Michel Dänzer 

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

Signed-off-by: Michel Dänzer 
---
 src/gallium/drivers/radeonsi/r600.h|   10 +-
 src/gallium/drivers/radeonsi/r600_blit.c   |   10 +-
 src/gallium/drivers/radeonsi/r600_buffer.c |8 +-
 src/gallium/drivers/radeonsi/r600_hw_context.c |   18 +-
 src/gallium/drivers/radeonsi/r600_resource.c   |6 +-
 src/gallium/drivers/radeonsi/r600_resource.h   |   20 +-
 src/gallium/drivers/radeonsi/r600_texture.c|  414 
 src/gallium/drivers/radeonsi/radeonsi_pipe.c   |   10 +-
 src/gallium/drivers/radeonsi/radeonsi_pipe.h   |   22 +-
 src/gallium/drivers/radeonsi/si_state_draw.c   |4 +-
 10 files changed, 254 insertions(+), 268 deletions(-)

diff --git a/src/gallium/drivers/radeonsi/r600.h 
b/src/gallium/drivers/radeonsi/r600.h
index df9e7a0..c2c22c4 100644
--- a/src/gallium/drivers/radeonsi/r600.h
+++ b/src/gallium/drivers/radeonsi/r600.h
@@ -98,8 +98,8 @@ struct r600_so_target {
 struct r600_context;
 struct r600_screen;
 
-void r600_get_backend_mask(struct r600_context *ctx);
-void r600_context_flush(struct r600_context *ctx, unsigned flags);
+void si_get_backend_mask(struct r600_context *ctx);
+void si_context_flush(struct r600_context *ctx, unsigned flags);
 
 struct r600_query *r600_context_query_create(struct r600_context *ctx, 
unsigned query_type);
 void r600_context_query_destroy(struct r600_context *ctx, struct r600_query 
*query);
@@ -112,11 +112,11 @@ void r600_context_queries_suspend(struct r600_context 
*ctx);
 void r600_context_queries_resume(struct r600_context *ctx);
 void r600_query_predication(struct r600_context *ctx, struct r600_query 
*query, int operation,
int flag_wait);
-void r600_context_emit_fence(struct r600_context *ctx, struct si_resource 
*fence,
- unsigned offset, unsigned value);
+void si_context_emit_fence(struct r600_context *ctx, struct si_resource *fence,
+   unsigned offset, unsigned value);
 
 void r600_context_draw_opaque_count(struct r600_context *ctx, struct 
r600_so_target *t);
-void r600_need_cs_space(struct r600_context *ctx, unsigned num_dw, boolean 
count_draw_in);
+void si_need_cs_space(struct r600_context *ctx, unsigned num_dw, boolean 
count_draw_in);
 
 int si_context_init(struct r600_context *ctx);
 
diff --git a/src/gallium/drivers/radeonsi/r600_blit.c 
b/src/gallium/drivers/radeonsi/r600_blit.c
index 9a0cd80..4406204 100644
--- a/src/gallium/drivers/radeonsi/r600_blit.c
+++ b/src/gallium/drivers/radeonsi/r600_blit.c
@@ -113,7 +113,7 @@ static unsigned u_num_layers(struct pipe_resource *r, 
unsigned level)
}
 }
 
-void r600_blit_uncompress_depth(struct pipe_context *ctx, struct 
r600_resource_texture *texture)
+void si_blit_uncompress_depth(struct pipe_context *ctx, struct 
r600_resource_texture *texture)
 {
struct r600_context *rctx = (struct r600_context *)ctx;
unsigned layer, level;
@@ -153,7 +153,7 @@ void r600_blit_uncompress_depth(struct pipe_context *ctx, 
struct r600_resource_t
texture->dirty_db = FALSE;
 }
 
-void r600_flush_depth_textures(struct r600_context *rctx)
+void si_flush_depth_textures(struct r600_context *rctx)
 {
unsigned int i;
 
@@ -173,7 +173,7 @@ void r600_flush_depth_textures(struct r600_context *rctx)
if (tex->is_flushing_texture)
continue;
 
-   r600_blit_uncompress_depth(&rctx->context, tex);
+   si_blit_uncompress_depth(&rctx->context, tex);
}
 
/* also check CB here */
@@ -187,7 +187,7 @@ void r600_flush_depth_textures(struct r600_context *rctx)
if (tex->is_flushing_texture)
continue;
 
-   r600_blit_uncompress_depth(&rctx->context, tex);
+   si_blit_uncompress_depth(&rctx->context, tex);
}
 }
 
@@ -374,7 +374,7 @@ static void r600_resource_copy_region(struct pipe_context 
*ctx,
r600_reset_blittable_to_compressed(dst, dst_level, 
&orig_info[1]);
 }
 
-void r600_init_blit_functions(struct r600_context *rctx)
+void si_init_blit_functions(struct r600_context *rctx)
 {
rctx->context.clear = r600_clear;
rctx->context.clear_render_target = r600_clear_render_target;
diff --git a/src/gallium/drivers/radeonsi/r600_buffer.c 
b/src/gallium/drivers/radeonsi/r600_buffer.c
index 76de941..ec9d87e 100644
--- a/src/gallium/drivers/radeonsi/r600_buffer.c
+++ b/src/gallium/drivers/radeonsi/r600_buffer.c
@@ -114,7 +114,7 @@ static const struct u_resource_vtbl r600_buffer_vtbl =
NULL/* transfer_inline_write */
 };
 
-bool r600_init_resource(struct r600_screen *rscreen,
+bool si_init_resource(struct r600_screen *rscreen,
struct si_resource *res,
unsigned size, unsigned alignment,
unsigned bind, unsigned usage)
@@ -156,8 +156,8 @@ bool r600_

[Mesa-dev] [PATCH] build/glsl: fix android build

[Tapani Pälli]

Commit 77a3efc6b907943903190b385fdf107c4acfcdca broke android
build that sets its own value for GLSL_SRCDIR. Patch sets the value
in Makefile.sources only if it is not defined previously.

Signed-off-by: Tapani Pälli 
---
 src/glsl/Makefile.sources | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/glsl/Makefile.sources b/src/glsl/Makefile.sources
index aafb53e..1529b12 100644
--- a/src/glsl/Makefile.sources
+++ b/src/glsl/Makefile.sources
@@ -1,6 +1,6 @@
 # shared source lists for Makefile, SConscript, and Android.mk
 
-GLSL_SRCDIR = $(top_srcdir)/src/glsl
+GLSL_SRCDIR ?= $(top_srcdir)/src/glsl
 GLSL_BUILDDIR = $(top_builddir)/src/glsl
 
 # libglcpp
-- 
1.7.11.4

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

[Mesa-dev] [Bug 53572] New: scons: *** Two environments with different actions were specified for the same target: mesa/src/glsl/glcpp/pp.o

[bugzilla-daemon]

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

 Bug #: 53572
   Summary: scons: *** Two environments with different actions
were specified for the same target:
mesa/src/glsl/glcpp/pp.o
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Other
AssignedTo: mesa-dev@lists.freedesktop.org
ReportedBy: v...@freedesktop.org
CC: chalserog...@gmail.com


$ scons platform=windows toolchain=crossmingw
scons: Reading SConscript files ...
Mkdir("build/windows-x86-debug")
Checking for X11 (x11 xext xdamage xfixes)... no
Checking for XCB (x11-xcb xcb-glx >= 1.8.1)... no
Checking for XF86VIDMODE (xxf86vm)... no
Checking for DRM (libdrm >= 2.4.24)... no
Checking for DRM_INTEL (libdrm_intel >= 2.4.30)... no
Checking for DRM_RADEON (libdrm_radeon >= 2.4.31)... no
Checking for XORG (xorg-server >= 1.6.0)... no
Checking for KMS (libkms >= 2.4.24)... no
Checking for UDEV (libudev > 150)... no
Mkdir("build/linux-x86_64-debug")
Checking for X11 (x11 xext xdamage xfixes)... yes
Checking for XCB (x11-xcb xcb-glx >= 1.8.1)... yes
Checking for XF86VIDMODE (xxf86vm)... yes
Checking for DRM (libdrm >= 2.4.24)... yes
Checking for DRM_INTEL (libdrm_intel >= 2.4.30)... yes
Checking for DRM_RADEON (libdrm_radeon >= 2.4.31)... yes
Checking for XORG (xorg-server >= 1.6.0)... yes
Checking for KMS (libkms >= 2.4.24)... no
Checking for UDEV (libudev > 150)... yes

scons: *** Two environments with different actions were specified for the same
target: mesa/src/glsl/glcpp/pp.o
File "mesa/src/glsl/SConscript", line 102, in 


77a3efc6b907943903190b385fdf107c4acfcdca is the first bad commit
commit 77a3efc6b907943903190b385fdf107c4acfcdca
Author: Christopher James Halse Rogers 
Date:   Thu Jul 19 12:30:10 2012 +1000

build/glsl: fix location of generated files.

Like in src/mesa, use GLSL_BUILDDIR/GLSL_SRCDIR to unambiguously
distinguish between in-tree and generated files.

Reviewed-by: Eric Anholt 
Signed-off-by: Christopher James Halse Rogers


:04 04 adb4f21cb3a3a8eda9e2ea0cedbcf9df5475da38
517c2ddd643e88aa526df665df49d2f19ae5c994 Msrc
bisect run success

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- 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 1/2] r600g: set CB_COLOR_INFO to INVALID for disabled colorbuffers on r600-r700

[Michel Dänzer]

On Mit, 2012-08-15 at 19:48 +0200, Marek Olšák wrote: 
> ---
>  src/gallium/drivers/r600/r600_state.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/src/gallium/drivers/r600/r600_state.c 
> b/src/gallium/drivers/r600/r600_state.c
> index d2ef68e..e024907 100644
> --- a/src/gallium/drivers/r600/r600_state.c
> +++ b/src/gallium/drivers/r600/r600_state.c
> @@ -1438,6 +1438,9 @@ static void r600_set_framebuffer_state(struct 
> pipe_context *ctx,
>  surf->cb_color_info, res, 
> RADEON_USAGE_READWRITE);
>   i++;
>   }
> + for (; i < 8 ; i++) {
> + r600_pipe_state_add_reg(rstate, R_0280A0_CB_COLOR0_INFO + i * 
> 4, 0);
> + }

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev