[Mesa-dev] [PATCH] mesa: Fix format matching checks for GL_INTENSITY* internalformats.

2014-03-23 Thread Chris Forbes 
GL_INTENSITY has never been valid as a pixel format -- to get the memcpy
pack/unpack paths, the app needs to specify GL_RED as the pixel format
(or GL_RED_INTEGER for the integer formats).

Signed-off-by: Chris Forbes 
---
 src/mesa/main/formats.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/src/mesa/main/formats.c b/src/mesa/main/formats.c
index c3e8049..e74625f 100644
--- a/src/mesa/main/formats.c
+++ b/src/mesa/main/formats.c
@@ -3124,9 +3124,9 @@ _mesa_format_matches_format_and_type(mesa_format 
mesa_format,
case MESA_FORMAT_L_UNORM16:
   return format == GL_LUMINANCE && type == GL_UNSIGNED_SHORT && !swapBytes;
case MESA_FORMAT_I_UNORM8:
-  return format == GL_INTENSITY && type == GL_UNSIGNED_BYTE;
+  return format == GL_RED && type == GL_UNSIGNED_BYTE;
case MESA_FORMAT_I_UNORM16:
-  return format == GL_INTENSITY && type == GL_UNSIGNED_SHORT && !swapBytes;
+  return format == GL_RED && type == GL_UNSIGNED_SHORT && !swapBytes;
 
case MESA_FORMAT_YCBCR:
   return format == GL_YCBCR_MESA &&
@@ -3218,9 +3218,9 @@ _mesa_format_matches_format_and_type(mesa_format 
mesa_format,
   return format == GL_LUMINANCE_ALPHA && type == GL_HALF_FLOAT && 
!swapBytes;
 
case MESA_FORMAT_I_FLOAT32:
-  return format == GL_INTENSITY && type == GL_FLOAT && !swapBytes;
+  return format == GL_RED && type == GL_FLOAT && !swapBytes;
case MESA_FORMAT_I_FLOAT16:
-  return format == GL_INTENSITY && type == GL_HALF_FLOAT && !swapBytes;
+  return format == GL_RED && type == GL_HALF_FLOAT && !swapBytes;
 
case MESA_FORMAT_R_FLOAT32:
   return format == GL_RED && type == GL_FLOAT && !swapBytes;
@@ -3248,13 +3248,17 @@ _mesa_format_matches_format_and_type(mesa_format 
mesa_format,
   return format == GL_ALPHA_INTEGER && type == GL_INT && !swapBytes;
 
case MESA_FORMAT_I_UINT8:
+  return format == GL_RED_INTEGER && type == GL_UNSIGNED_BYTE;
case MESA_FORMAT_I_UINT16:
+  return format == GL_RED_INTEGER && type == GL_UNSIGNED_SHORT && 
!swapBytes;
case MESA_FORMAT_I_UINT32:
+  return format == GL_RED_INTEGER && type == GL_UNSIGNED_INT && !swapBytes;
case MESA_FORMAT_I_SINT8:
+  return format == GL_RED_INTEGER && type == GL_BYTE;
case MESA_FORMAT_I_SINT16:
+  return format == GL_RED_INTEGER && type == GL_SHORT && !swapBytes;
case MESA_FORMAT_I_SINT32:
-  /* GL_INTENSITY_INTEGER_EXT doesn't exist. */
-  return GL_FALSE;
+  return format == GL_RED_INTEGER && type == GL_INT && !swapBytes;
 
case MESA_FORMAT_L_UINT8:
   return format == GL_LUMINANCE_INTEGER_EXT && type == GL_UNSIGNED_BYTE;
@@ -3421,7 +3425,7 @@ _mesa_format_matches_format_and_type(mesa_format 
mesa_format,
   return format == GL_LUMINANCE_ALPHA && type == GL_BYTE &&
  littleEndian && !swapBytes;
case MESA_FORMAT_I_SNORM8:
-  return format == GL_INTENSITY && type == GL_BYTE;
+  return format == GL_RED && type == GL_BYTE;
case MESA_FORMAT_A_SNORM16:
   return format == GL_ALPHA && type == GL_SHORT && !swapBytes;
case MESA_FORMAT_L_SNORM16:
@@ -3430,7 +3434,7 @@ _mesa_format_matches_format_and_type(mesa_format 
mesa_format,
   return format == GL_LUMINANCE_ALPHA && type == GL_SHORT &&
  littleEndian && !swapBytes;
case MESA_FORMAT_I_SNORM16:
-  return format == GL_INTENSITY && type == GL_SHORT && littleEndian &&
+  return format == GL_RED && type == GL_SHORT && littleEndian &&
  !swapBytes;
 
case MESA_FORMAT_B10G10R10A2_UINT:
-- 
1.9.1

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

[Mesa-dev] [PATCH] mesa: Generate FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT earlier

2014-03-23 Thread Chris Forbes 
The ARB_framebuffer_object spec lists this case before the
FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER and
FRAMEBUFFER_INCOMPLETE_READ_BUFFER cases.

Fixes two broken cases in piglit's fbo-incomplete test, if
ARB_ES2_compatibility is not advertised. (If it is, this is masked
because the FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER /
FRAMEBUFFER_INCOMPLETE_READ_BUFFER cases are removed by that extension)

Signed-off-by: Chris Forbes 
---
 src/mesa/main/fbobject.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index dfe2f1e..c408307 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1080,6 +1080,12 @@ _mesa_test_framebuffer_completeness(struct gl_context 
*ctx,
 
fb->MaxNumLayers = max_layer_count;
 
+   if (numImages == 0) {
+  fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT_EXT;
+  fbo_incomplete(ctx, "no attachments", -1);
+  return;
+   }
+
if (_mesa_is_desktop_gl(ctx) && !ctx->Extensions.ARB_ES2_compatibility) {
   /* Check that all DrawBuffers are present */
   for (j = 0; j < ctx->Const.MaxDrawBuffers; j++) {
@@ -1108,12 +1114,6 @@ _mesa_test_framebuffer_completeness(struct gl_context 
*ctx,
   }
}
 
-   if (numImages == 0) {
-  fb->_Status = GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT_EXT;
-  fbo_incomplete(ctx, "no attachments", -1);
-  return;
-   }
-
/* Provisionally set status = COMPLETE ... */
fb->_Status = GL_FRAMEBUFFER_COMPLETE_EXT;
 
-- 
1.9.1

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

Re: [Mesa-dev] RFC: Fixing XBMC crash with NV_vdpau_interop

2014-03-23 Thread Christian König 

Am 22.03.2014 23:33, schrieb Brian Paul:
On Sat, Mar 22, 2014 at 2:49 PM, Christian König 
mailto:deathsim...@vodafone.de>> wrote:


Hi guys,

recently some XBMC users complained about crashes with the
relatively new NV_vdpau_interop support.

That turned out to be a problem with how st_atom_texture.c caches
the sampler view for a texture. Since the texture in question is
shared between two GLX contexts the pipe object the sampler view
was originally created for doesn't necessary match the pipe object
it is used with.

Now my question is am I missing something or is this case really
not correctly supported? Where is the check if a texture is used
in more than one context? The attached patch fixes the issue, but
I'm not sure if it is the right approach.


I've run into this too.  I think the best thing to do (short of 
removing the sampler view from the st_texture_object) is to walk over 
all the textures in the share group at context-destroy time, looking 
for sampler views belonging to the context being destroyed, then free 
those sampler views.


Yeah, that's also a problem, but not what I'm currently dealing with.

My problem is that we pass a sampler view to a pipe context which 
doesn't belong to this context. Surprisingly the driver doesn't crash 
immediately, but instead works fine for at least some time.


Our radeonsi driver keeps an internal reference to all sample views 
bound to it, and so when some times later a new sampler view is bound we 
unreference the sampler view in question and crash because the context 
where this sampler view was created with no longer exists.


So it's reference inside the driver that crashes, not the one in the 
mesa state tracker. So there is probably nothing I can do except for 
what the attached patch does and try to never bind a sampler view to a 
context it doesn't belong to.



I could probably whip up a patch next week.


Would you mind if I try to fix that? Doesn't sounds so complicated to me.

Regards,
Christian.



-Brian



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

[Mesa-dev] [PATCH 3/3] st/mesa: Revert use pipe_sampler_view_release()

2014-03-23 Thread Christian König 
From: Christian König 

The original problem is fixed by now and unconditionally
destroying the sampler view, which is possible still
referenced elsewhere, is a really bad idea also.

This reverts commit 670be71bd801fea876f7512865ed5f54340da9be.

Signed-off-by: Christian König 
---
 src/mesa/state_tracker/st_atom_texture.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index 2826d12..eaa43d5 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -262,7 +262,7 @@ update_single_texture(struct st_context *st,
stObj->base.DepthMode) ||
  (view_format != stObj->sampler_view->format) ||
  stObj->base.BaseLevel != stObj->sampler_view->u.tex.first_level) {
-pipe_sampler_view_release(pipe, &stObj->sampler_view);
+pipe_sampler_view_reference(&stObj->sampler_view, NULL);
   }
}
 
-- 
1.9.1

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

[Mesa-dev] [PATCH 1/3] st/mesa: recreate sampler view on context change v2

2014-03-23 Thread Christian König 
From: Christian König 

With shared glx contexts it is possible that a texture is create and used
in one context and then used in another one resulting in incorrect
sampler view usage.

v2: avoid template copy

Signed-off-by: Christian König 
---
 src/mesa/state_tracker/st_atom_texture.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index 3557a3f..dc7f635 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -198,6 +198,13 @@ st_get_texture_sampler_view_from_stobj(struct 
st_texture_object *stObj,
if (!stObj->sampler_view) {
   stObj->sampler_view =
  st_create_texture_sampler_view_from_stobj(pipe, stObj, samp, format);
+
+   } else if (stObj->sampler_view->context != pipe) {
+  /* Recreate view in correct context, use existing view as template */
+  struct pipe_sampler_view *sv =
+ pipe->create_sampler_view(pipe, stObj->pt, stObj->sampler_view);
+  pipe_sampler_view_reference(&stObj->sampler_view, NULL);
+  stObj->sampler_view = sv;
}
 
return stObj->sampler_view;
-- 
1.9.1

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

[Mesa-dev] [PATCH 2/3] st/mesa: fix sampler view handling with shared textures

2014-03-23 Thread Christian König 
From: Christian König 

Release the references to the sampler views before destroying the pipe context.

TODO: Do we need to lock something?

Signed-off-by: Christian König 
---
 src/gallium/drivers/radeonsi/si_descriptors.c |  2 ++
 src/mesa/state_tracker/st_atom.h  |  2 ++
 src/mesa/state_tracker/st_atom_texture.c  |  8 
 src/mesa/state_tracker/st_context.c   | 10 ++
 4 files changed, 22 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c 
b/src/gallium/drivers/radeonsi/si_descriptors.c
index 0c58d5f..c2a8363 100644
--- a/src/gallium/drivers/radeonsi/si_descriptors.c
+++ b/src/gallium/drivers/radeonsi/si_descriptors.c
@@ -341,6 +341,8 @@ void si_set_sampler_view(struct si_context *sctx, unsigned 
shader,
 {
struct si_sampler_views *views = &sctx->samplers[shader].views;
 
+   assert(!view || view->context == &sctx->b.b);
+
if (views->views[slot] == view)
return;
 
diff --git a/src/mesa/state_tracker/st_atom.h b/src/mesa/state_tracker/st_atom.h
index 60d89d7..394c6ad 100644
--- a/src/mesa/state_tracker/st_atom.h
+++ b/src/mesa/state_tracker/st_atom.h
@@ -45,6 +45,8 @@ void st_destroy_atoms( struct st_context *st );
 
 void st_validate_state( struct st_context *st );
 
+void st_atom_texture_cleanup( struct st_context *st,
+  struct gl_texture_object *texObj );
 
 extern const struct st_tracked_state st_update_array;
 extern const struct st_tracked_state st_update_framebuffer;
diff --git a/src/mesa/state_tracker/st_atom_texture.c 
b/src/mesa/state_tracker/st_atom_texture.c
index dc7f635..2826d12 100644
--- a/src/mesa/state_tracker/st_atom_texture.c
+++ b/src/mesa/state_tracker/st_atom_texture.c
@@ -373,6 +373,14 @@ update_geometry_textures(struct st_context *st)
}
 }
 
+void st_atom_texture_cleanup(struct st_context *st,
+ struct gl_texture_object *texObj)
+{
+   struct st_texture_object *stObj = st_texture_object(texObj);
+
+   if (stObj->sampler_view && stObj->sampler_view->context == st->pipe)
+  pipe_sampler_view_reference(&stObj->sampler_view, NULL);
+}
 
 const struct st_tracked_state st_update_fragment_texture = {
"st_update_texture",/* name */
diff --git a/src/mesa/state_tracker/st_context.c 
b/src/mesa/state_tracker/st_context.c
index 0ffc762..816a095 100644
--- a/src/mesa/state_tracker/st_context.c
+++ b/src/mesa/state_tracker/st_context.c
@@ -33,6 +33,7 @@
 #include "main/shaderobj.h"
 #include "main/version.h"
 #include "main/vtxfmt.h"
+#include "main/hash.h"
 #include "program/prog_cache.h"
 #include "vbo/vbo.h"
 #include "glapi/glapi.h"
@@ -280,6 +281,13 @@ static void st_destroy_context_priv( struct st_context *st 
)
free( st );
 }
 
+static void st_destroy_tex_sampler( GLuint id, void *data, void *userData )
+{
+   struct gl_texture_object *texObj = (struct gl_texture_object *) data;
+   struct st_context *st = (struct st_context *) userData;
+
+   st_atom_texture_cleanup(st, texObj);
+}
  
 void st_destroy_context( struct st_context *st )
 {
@@ -288,6 +296,8 @@ void st_destroy_context( struct st_context *st )
struct gl_context *ctx = st->ctx;
GLuint i;
 
+   _mesa_HashWalk(ctx->Shared->TexObjects, st_destroy_tex_sampler, st);
+
/* need to unbind and destroy CSO objects before anything else */
cso_release_all(st->cso_context);
 
-- 
1.9.1

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

[Mesa-dev] [Bug 76489] Mesa git (011569b5b7) compilation issue: render2.c:49:4: error: implicit declaration of function '__glMap1d_size' [-Werror=implicit-function-declaration]

2014-03-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=76489

Emil Velikov  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=67740

--- Comment #1 from Emil Velikov  ---
Seems like I might need to eat my own words :-)

* Can you make sure that you do not have any local changes and/or danglin'
files - git reset --hard origin/master && git clean -fxd

* What platform/distribution are you using ?

* Can you complete the build if you explicitly define __GNU__ (see bug 67740) ?

-- 
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 67740] render2.c: In function '__indirect_glMap1d'

2014-03-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=67740

Emil Velikov  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=76489

-- 
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 76489] Mesa git (011569b5b7) compilation issue: render2.c:49:4: error: implicit declaration of function '__glMap1d_size' [-Werror=implicit-function-declaration]

2014-03-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=76489

--- Comment #2 from Dâniel Fraga  ---
(In reply to comment #1)
> Seems like I might need to eat my own words :-)
> 
> * Can you make sure that you do not have any local changes and/or danglin'
> files - git reset --hard origin/master && git clean -fxd
> 
> * What platform/distribution are you using ?
> 
> * Can you complete the build if you explicitly define __GNU__ (see bug
> 67740) ?

Hi Emil ;) I did the git reset and clean and it didn't work. I'm using Linux
(x86_64) with a installation similar to Linux from scratch. I compile
everything. Just Mesa is causing problems.

I tried the CFLAGS=-D__GNU__ and it solved the above errors, but now I got
another error:

make[3]: Entering directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
  CCLD libGL.la
./.libs/libglx.a(glxcmds.o): In function `glXGetProcAddressARB':
glxcmds.c:(.text+0x9b8): undefined reference to `__indirect_get_proc_address'
./.libs/libglx.a(indirect_init.o): In function `__glXNewIndirectAPI':
indirect_init.c:(.text+0x124): undefined reference to `__indirect_glAccum'
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-linux-gnu/bin/ld:
./.libs/libglx.a(indirect_init.o): relocation R_X86_64_PC32 against undefined
hidden symbol `__indirect_glAccum' can not be used when making a shared object
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-linux-gnu/bin/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit status
Makefile:692: recipe for target 'libGL.la' failed
make[3]: *** [libGL.la] Error 1
make[3]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
Makefile:779: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
Makefile:528: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src'
Makefile:579: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Any hints?

-- 
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] Questions regarding KHR_debug for OpenGL ES

2014-03-23 Thread Timothy Arceri 
On Mon, 2014-03-17 at 11:42 -0700, Felipe Tonello wrote:
> Hi all,
> 
> I'm working on the KHR_debug for OpenGL ES junior job. I recently
> submitted patches to allow the piglit tests to be enabled in GLES
> contexts as well.
> Now I want to work on the src/mapi/glapi/gen/es_EXT.xml file. Recently
> I saw a patch that moved the KHR_debug extension to a include type of
> file.
> 
> My question is: How can I reuse this file but change the functions
> definitions to add the KHR suffix?

Hi Felipe,

You need to use the alias attribute. Take a look at ARB_debug_output.xml
basically you will need to do the same thing in the es_EXT.xml file but
using the KHR suffix rather than ARB. I don't think there is anyway to
avoid the obvious duplications here (someone please correct me if I'm
wrong).

Tim

> 
> I will obviously have some other questions later on that I will
> address in this email.
> 
> Thanks for the time guys,
> 
> Felipe
> ___
> 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 76489] Mesa git (011569b5b7) compilation issue: render2.c:49:4: error: implicit declaration of function '__glMap1d_size' [-Werror=implicit-function-declaration]

2014-03-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=76489

--- Comment #3 from Emil Velikov  ---
(In reply to comment #2)
[...]
> Hi Emil ;) I did the git reset and clean and it didn't work. I'm using Linux
> (x86_64) with a installation similar to Linux from scratch. I compile
> everything. Just Mesa is causing problems.
> 
Hmmm, are you following the official instructions [1] ? The website indicates
zero problems with mesa 10.0 and 9.2. Would you consider this a regression in
mesa, or is it the first time you're doing such a build ?

> I tried the CFLAGS=-D__GNU__ and it solved the above errors, but now I got
> another error:
> 
I'm not sure if you applied to only for the specific folder or for the whole of
mesa. I'm suspecting that this is biting you below.

> make[3]: Entering directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
>   CCLD libGL.la
> ./.libs/libglx.a(glxcmds.o): In function `glXGetProcAddressARB':
> glxcmds.c:(.text+0x9b8): undefined reference to `__indirect_get_proc_address'
> ./.libs/libglx.a(indirect_init.o): In function `__glXNewIndirectAPI':
> indirect_init.c:(.text+0x124): undefined reference to `__indirect_glAccum'
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-
> linux-gnu/bin/ld: ./.libs/libglx.a(indirect_init.o): relocation
> R_X86_64_PC32 against undefined hidden symbol `__indirect_glAccum' can not
> be used when making a shared object
> /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-
> linux-gnu/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
> Makefile:692: recipe for target 'libGL.la' failed
> make[3]: *** [libGL.la] Error 1
> make[3]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
> Makefile:779: recipe for target 'all-recursive' failed
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
> Makefile:528: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/usr/local/src/git/modular/x/mesa/mesa/src'
> Makefile:579: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1
> 
> Any hints?

Ideally you can grab a upstream distro and compare the pre-processed source
with the one you're getting. Based on the differences we can stablish easier
where the problem is.

[1] www.linuxfromscratch.org

-- 
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 76530] New: account request

2014-03-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=76530

  Priority: medium
Bug ID: 76530
  Assignee: mesa-dev@lists.freedesktop.org
   Summary: account request
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: d...@lynxeye.de
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: Other
   Product: Mesa

Created attachment 96258
  --> https://bugs.freedesktop.org/attachment.cgi?id=96258&action=edit
SSH key

Hello,
I would like to request an account with push access to the MESA repo. I have
some small contributions in the project already and as I'm now working a
significant amount of my time on open-source graphics (llvmpipe on ARM, etnaviv
Vivante driver) I would like to be able to push patches after the ML review
myself.

real name: Lucas Stach
email: d...@lynxeye.de
preferred username: lynxeye

-- 
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 76530] account request

2014-03-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=76530

--- Comment #1 from Lucas Stach  ---
Created attachment 96259
  --> https://bugs.freedesktop.org/attachment.cgi?id=96259&action=edit
GPG pubkey

-- 
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] intel, dma-buf import and egl image external

2014-03-23 Thread Dave Airlie 
On Sat, Mar 8, 2014 at 12:13 AM, Pohjolainen, Topi
 wrote:
> On Mon, Mar 03, 2014 at 01:19:48PM +1000, Dave Airlie wrote:
>> There is a comment and two checks in the i965 dma-buf importer,
>>
>> * Images originating via EGL_EXT_image_dma_buf_import can be used only
>> * with GL_OES_EGL_image_external only.
>>
>> however I can't find any reference to this in the spec txt, and
>> removing the checks make my test app run fine using TEXTURE_2D.
>
> You are correct that there is nothing in the spec about this, but it also 
> leaves
> it open for the driver to choose on which buffers it allows the external
> sampling.
> After quite a bit of debate on when/where it would be safe to use dma-buffers,
> it was decided that we simply allow dma-buffers for external sampling only -
> that extension already restricts the use for single-miplevel and read-only
> which is exactly what we wanted.
> The same time it wasn't clear what kind of sources we should allow for 
> external
> sampling (besides dma), and hence we simply kept things as they were before -
> none other. Note that before the introduction of dma-buffers the image 
> external
> extension wasn't enabled at all on i965.
>

This is a really bad idea, since it means you can't use dma-buf
imported things with standard shader programs, if I want to import a
dma-buf I shouldn't have to write specific shader programs or use
special bindings, unless the spec says so.

Either the spec should be more restrictive, or the implementation
shouldn't have arbitrary differences from what other implementations
could do.

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

[Mesa-dev] [Bug 76489] Mesa git (011569b5b7) compilation issue: render2.c:49:4: error: implicit declaration of function '__glMap1d_size' [-Werror=implicit-function-declaration]

2014-03-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=76489

--- Comment #4 from Dâniel Fraga  ---
(In reply to comment #3)

> Hmmm, are you following the official instructions [1] ? The website
> indicates zero problems with mesa 10.0 and 9.2. Would you consider this a
> regression in mesa, or is it the first time you're doing such a build ?

No, because it's not Linux from scratch. It's like LFS, but not exactly like
they do. Anyway, I compile all software I use. Mesa seems the most problematic.
I compiled Mesa up to 8.0.5. Starting with vesion 9 I get all these problems,
so yes, it is a regression (first detect in Mesa 9).

> I'm not sure if you applied to only for the specific folder or for the whole
> of mesa. I'm suspecting that this is biting you below.

I get the same result in both cases.

> > make[3]: Entering directory '/usr/local/src/git/modular/x/mesa/mesa/src/glx'
> >   CCLD libGL.la
> > ./.libs/libglx.a(glxcmds.o): In function `glXGetProcAddressARB':
> > glxcmds.c:(.text+0x9b8): undefined reference to 
> > `__indirect_get_proc_address'

> Ideally you can grab a upstream distro and compare the pre-processed source
> with the one you're getting. Based on the differences we can stablish easier
> where the problem is.

Ok, how exactly I do that? Can you please describe with more details? 

Thank you.

-- 
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 76489] Mesa git (011569b5b7) compilation issue: render2.c:49:4: error: implicit declaration of function '__glMap1d_size' [-Werror=implicit-function-declaration]

2014-03-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=76489

--- Comment #5 from Emil Velikov  ---
(In reply to comment #4)
[...]
> No, because it's not Linux from scratch. It's like LFS, but not exactly like
> they do. Anyway, I compile all software I use. Mesa seems the most
Great you feel like going through all the mayhem with zero assistance, good
luck :P

> problematic. I compiled Mesa up to 8.0.5. Starting with vesion 9 I get all
> these problems,
> so yes, it is a regression (first detect in Mesa 9).
> 
[...]

> I get the same result in both cases.
Not cool.

[...]
> Ok, how exactly I do that? Can you please describe with more details? 
> 
gcc -E will help you out. Note that I'm not passionate at looking through and
comparing the mile long preprocessed sources so I'd leave that pleasure to you
:)

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