[Mesa-dev] [Bug 46502] Wine crashes with idnirect rendering

2012-03-02 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=46502

--- Comment #4 from Kusanagi Kouichi sl...@ac.auone-net.jp 2012-03-02 
03:05:30 PST ---
Wine crashes only if shared glapi is enabled.
Mesa version is irrelevant.

-- 
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] Mesa (master): vl/compositor: add per vertex color suport

2012-03-02 Thread Michel Dänzer

Hi Christian,


On Fre, 2012-03-02 at 04:42 -0800, Christian KXXnig wrote: 
 Module: Mesa
 Branch: master
 Commit: b90727bb241e4a04158d34aad078cb18e478fea7
 URL:
 http://cgit.freedesktop.org/mesa/mesa/commit/?id=b90727bb241e4a04158d34aad078cb18e478fea7
 
 Author: Christian König deathsim...@vodafone.de
 Date:   Mon Feb 27 16:07:51 2012 +0100
 
 vl/compositor: add per vertex color suport
 
 Used in subtitles, for example.
[...] 
 diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
 b/src/gallium/auxiliary/vl/vl_compositor.c
 index b030298..1e8d37f 100644
 --- a/src/gallium/auxiliary/vl/vl_compositor.c
 +++ b/src/gallium/auxiliary/vl/vl_compositor.c
 @@ -47,6 +47,7 @@ enum VS_OUTPUT
  {
 VS_O_VPOS,
 VS_O_VTEX,
 +   VS_O_COLOR,
 VS_O_VTOP,
 VS_O_VBOTTOM,
  };

This breaks r300g:

mplayer: r300_vs.c:62: r300_shader_read_vs_outputs: Assertion `index  2' 
failed.

Looking at the r300_shader_read_vs_outputs and ureg_DECL_output_masked
code, they interpret the indices per semantic, whereas the vl code seems
to use a single index namespace. The latter can only work as long as all
the indices happen to fit within the per-semantic limits supported by
the driver/hardware.


Possibly related: As of the vl/vdpau changes you pushed today, mplayer
-vo vdpau only displays a small band at the top of the screen anymore
here with r300g. It looks like the whole picture is compressed into the
height of a single line of the video. I don't have time to investigate
this more right now, but maybe it'll clear up anyway once the above is
resolved.


-- 
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 1/4] meta: Fix compilation without FEATURE_feedback

2012-03-02 Thread Chad Versace
On 02/29/2012 07:36 AM, Benjamin Franzke wrote:
 That is when building with --disable-opengl.
 Fix for commit c5f4024a793f1209b1693aed9a46be9374ba4741.
 
 CC: Chad Versace c...@chad-versace.us
 ---
  src/mesa/drivers/common/meta.c |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

For patches 1-2,
Reviewed-by: Chad Versace chad.vers...@linux.intel.com

I'm leaving patch 4 for someone who understands it better.

I've replied to patch 3 with a question.

-- 
Chad Versace
c...@chad-versace.us
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Mesa (master): vl/compositor: add per vertex color suport

2012-03-02 Thread Christian König

On 02.03.2012 15:00, Michel Dänzer wrote:

Hi Christian,


On Fre, 2012-03-02 at 04:42 -0800, Christian KXXnig wrote:

Module: Mesa
Branch: master
Commit: b90727bb241e4a04158d34aad078cb18e478fea7
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=b90727bb241e4a04158d34aad078cb18e478fea7

Author: Christian Königdeathsim...@vodafone.de
Date:   Mon Feb 27 16:07:51 2012 +0100

vl/compositor: add per vertex color suport

Used in subtitles, for example.

[...]

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
b/src/gallium/auxiliary/vl/vl_compositor.c
index b030298..1e8d37f 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -47,6 +47,7 @@ enum VS_OUTPUT
  {
 VS_O_VPOS,
 VS_O_VTEX,
+   VS_O_COLOR,
 VS_O_VTOP,
 VS_O_VBOTTOM,
  };

This breaks r300g:

mplayer: r300_vs.c:62: r300_shader_read_vs_outputs: Assertion `index  2' 
failed.

Looking at the r300_shader_read_vs_outputs and ureg_DECL_output_masked
code, they interpret the indices per semantic, whereas the vl code seems
to use a single index namespace. The latter can only work as long as all
the indices happen to fit within the per-semantic limits supported by
the driver/hardware.


Possibly related: As of the vl/vdpau changes you pushed today, mplayer
-vo vdpau only displays a small band at the top of the screen anymore
here with r300g. It looks like the whole picture is compressed into the
height of a single line of the video. I don't have time to investigate
this more right now, but maybe it'll clear up anyway once the above is
resolved.

Hi Michel,

Oh yeah, the assumption of a global index space indeed seems to be 
incorrect. I haven't noticed earlier since it doesn't matter for r600g.


Please give the attached patch a try with your r300, does it fix the 
problem?


If yes I should go over my code once more, since I probably made that 
wrong assumption a couple of times.


Thanks,
Christian.
From a9073e34863977f24ade27c0f332fe044495a09b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?= deathsim...@vodafone.de
Date: Fri, 2 Mar 2012 16:07:18 +0100
Subject: [PATCH] vl/compositor: fix shader in/out numbering
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Michel pointed out that my assumption of a global
index namespace is incorrect and breaks r300g.

Signed-off-by: Christian König deathsim...@vodafone.de
---
 src/gallium/auxiliary/vl/vl_compositor.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/gallium/auxiliary/vl/vl_compositor.c b/src/gallium/auxiliary/vl/vl_compositor.c
index 3595836..cc213b7 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -45,9 +45,9 @@
 
 enum VS_OUTPUT
 {
-   VS_O_VPOS,
-   VS_O_VTEX,
-   VS_O_COLOR,
+   VS_O_VPOS = 0,
+   VS_O_COLOR = 0,
+   VS_O_VTEX = 0,
VS_O_VTOP,
VS_O_VBOTTOM,
 };
@@ -70,8 +70,8 @@ create_vert_shader(struct vl_compositor *c)
color = ureg_DECL_vs_input(shader, 2);
tmp = ureg_DECL_temporary(shader);
o_vpos = ureg_DECL_output(shader, TGSI_SEMANTIC_POSITION, VS_O_VPOS);
-   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
o_color = ureg_DECL_output(shader, TGSI_SEMANTIC_COLOR, VS_O_COLOR);
+   o_vtex = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX);
o_vtop = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTOP);
o_vbottom = ureg_DECL_output(shader, TGSI_SEMANTIC_GENERIC, VS_O_VBOTTOM);
 
@@ -139,7 +139,7 @@ create_frag_shader_video_buffer(struct vl_compositor *c)
if (!shader)
   return false;
 
-   tc = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, 1, TGSI_INTERPOLATE_LINEAR);
+   tc = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX, TGSI_INTERPOLATE_LINEAR);
for (i = 0; i  3; ++i) {
   csc[i] = ureg_DECL_constant(shader, i);
   sampler[i] = ureg_DECL_sampler(shader, i);
-- 
1.7.5.4

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


Re: [Mesa-dev] [PATCH 00/21] Another round of R600 improvements fixes

2012-03-02 Thread Alex Deucher
On Wed, Feb 29, 2012 at 11:52 AM, Marek Olšák mar...@gmail.com wrote:
 Hi everyone,

 here's another series of patches for r600g.

 These 5 patches are mostly about improving queries:
  r600g: move all query code into r600_query.c
  r600g: release query buffers in destroy_query
  r600g: don't suspend timer queries for u_blitter
  r600g: correctly handle queries which don't need begin_query
  r600g: remove obsolete todo comments

 These make changes to how we use the scissor registers and also fixing 
 GL_RASTERIZER_DISCARD.
  r600g: rework scissor for evergreen
  r600g: rework scissor for r600-r700
  r600g: make some scissor regs invariant on evergreen
  r600g: make some scissor regs invariant on r600-r700
  r600g: rework rasterizer discard for evergreen
  r600g: fix and improve rasterizer discard for r600-r700

 Next up are small improvements to texturing. The support for new colorbuffer 
 formats also means blitting is fully accelerated on those (previously it 
 wasn't).
  r600g: permit blitting between textures with STREAM and STAGING usage
  r600g: remove support for SCALED colorbuffer formats
  r600g: add support for missing texture formats

 These are mostly improvements to streamout. I am not sure whether 
 VS_GS_OUT_PRIM_TYPE should be initialized, I have done so just to be safe 
 because I am having some issues with streamout.
  r600g: if pixel shader is NULL, bind a dummy one
  r600g: initialize SX_SURFACE_SYNC
  r600g: initialize VS_GS_OUT_PRIM_TYPE
  r600g: initialize DB_DEPTH_CONTROL at beginning of CS
  winsys/radeon: add usage parameter to cs_is_buffer_referenced

 The last 2 patches are the most important, but not yet working very well, so 
 I am not going to push them.
  r600g: accelerate buffer copying
  r600g: implement wait-free buffer transfer for DISCARD flags

 The problem is streamout is not reliable yet. Although all tests for 
 glCopyBufferSubData and all but 2 GL2 transform feedback piglit tests pass, I 
 have seen data corruption and lockups with Wine (even on RV670 and Evergreen, 
 which we thought worked well). Or there might be some other bug that we just 
 uncovered.

 Efficient handling of the DISCARD transfer flags is crucial for performance. 
 If those flags are ignored, both the CPU and the GPU may idle in the middle 
 of rendering (because of the GEM_WAIT_IDLE ioctl), which makes every other 
 optimization less useful. I have seen the last patch improve framerate in 
 Wine.

 Please review.

Looks good to me.

Reviewed-by: Alex Deucher alexander.deuc...@amd.com


  src/gallium/drivers/r300/r300_transfer.c        |    2 +-
  src/gallium/drivers/r600/eg_sq.h                |    2 +-
  src/gallium/drivers/r600/evergreen_hw_context.c |   44 +--
  src/gallium/drivers/r600/evergreen_state.c      |  260 +++-
  src/gallium/drivers/r600/evergreend.h           |    9 +
  src/gallium/drivers/r600/r600.h                 |   12 -
  src/gallium/drivers/r600/r600_asm.c             |    2 +-
  src/gallium/drivers/r600/r600_blit.c            |   82 +++--
  src/gallium/drivers/r600/r600_buffer.c          |   65 +++-
  src/gallium/drivers/r600/r600_hw_context.c      |  451 +---
  src/gallium/drivers/r600/r600_pipe.c            |   32 +-
  src/gallium/drivers/r600/r600_pipe.h            |   43 ++-
  src/gallium/drivers/r600/r600_query.c           |  514 
 +--
  src/gallium/drivers/r600/r600_shader.c          |   10 +-
  src/gallium/drivers/r600/r600_state.c           |  210 ++
  src/gallium/drivers/r600/r600_state_common.c    |   74 +++-
  src/gallium/drivers/r600/r600_texture.c         |   17 +-
  src/gallium/drivers/r600/r600d.h                |    9 +
  src/gallium/winsys/radeon/drm/radeon_drm_cs.c   |   18 +-
  src/gallium/winsys/radeon/drm/radeon_winsys.h   |    3 +-
  20 files changed, 1096 insertions(+), 763 deletions(-)

 Marek
 ___
 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 12/21] r600g: permit blitting between textures with STREAM and STAGING usage

2012-03-02 Thread Christian König

On 01.03.2012 01:05, Marek Olšák wrote:

2012/2/29 Christian Königdeathsim...@vodafone.de:

On 29.02.2012 17:53, Marek Olšák wrote:

Why this wasn't allowed is beyond me.

Because that resulted in allot better performance.

It doesn't make much sense to let the driver blit the content of a texture
into a tilled version and make a single draw and then throw away that tilled
version before the next draw.

So either leave the test there or move it into r600_texture_create, but
don't remove it altogether.

Ah, so you want to disable tiling for staging and stream usage cases,
not blitting. That makes sense.

However blitting between non-tiled textures in our transfer path is
completely valid and recommended if the transfer is write-only and
mapping would require synchronization (flush + bo_wait). In such a
case, the blit will almost always be faster regardless of whether
tiling is enabled or not.


Correct, yeah. I also remember that there was a good reason that we put 
that check into that function instead of modifying the tilling 
attributes in the create function, but I can't remember it.


Anyway apart from that the patches looks good to me, so:

Reviewed-by: Christian Königchristian.koe...@amd.com


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


Re: [Mesa-dev] Mesa (master): vl/compositor: add per vertex color suport

2012-03-02 Thread Michel Dänzer
On Fre, 2012-03-02 at 16:14 +0100, Christian König wrote: 
 On 02.03.2012 15:00, Michel Dänzer wrote:
  Hi Christian,
 
 
  On Fre, 2012-03-02 at 04:42 -0800, Christian KXXnig wrote:
  Module: Mesa
  Branch: master
  Commit: b90727bb241e4a04158d34aad078cb18e478fea7
  URL:
  http://cgit.freedesktop.org/mesa/mesa/commit/?id=b90727bb241e4a04158d34aad078cb18e478fea7
 
  Author: Christian Königdeathsim...@vodafone.de
  Date:   Mon Feb 27 16:07:51 2012 +0100
 
  vl/compositor: add per vertex color suport
 
  Used in subtitles, for example.
  [...]
  diff --git a/src/gallium/auxiliary/vl/vl_compositor.c 
  b/src/gallium/auxiliary/vl/vl_compositor.c
  index b030298..1e8d37f 100644
  --- a/src/gallium/auxiliary/vl/vl_compositor.c
  +++ b/src/gallium/auxiliary/vl/vl_compositor.c
  @@ -47,6 +47,7 @@ enum VS_OUTPUT
{
   VS_O_VPOS,
   VS_O_VTEX,
  +   VS_O_COLOR,
   VS_O_VTOP,
   VS_O_VBOTTOM,
};
  This breaks r300g:
 
  mplayer: r300_vs.c:62: r300_shader_read_vs_outputs: Assertion `index  2' 
  failed.
 
  Looking at the r300_shader_read_vs_outputs and ureg_DECL_output_masked
  code, they interpret the indices per semantic, whereas the vl code seems
  to use a single index namespace. The latter can only work as long as all
  the indices happen to fit within the per-semantic limits supported by
  the driver/hardware.
 
 
  Possibly related: As of the vl/vdpau changes you pushed today, mplayer
  -vo vdpau only displays a small band at the top of the screen anymore
  here with r300g. It looks like the whole picture is compressed into the
  height of a single line of the video. I don't have time to investigate
  this more right now, but maybe it'll clear up anyway once the above is
  resolved.
 Hi Michel,
 
 Oh yeah, the assumption of a global index space indeed seems to be 
 incorrect. I haven't noticed earlier since it doesn't matter for r600g.
 
 Please give the attached patch a try with your r300, does it fix the 
 problem?

Yes, it does, thanks! (The squashed presentation problem is fixed as
well, maybe that was just a fluke or caused by my own attempt to fix
this)


 If yes I should go over my code once more, since I probably made that 
 wrong assumption a couple of times.

Good idea. :)


-- 
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 2/2] i915: fix wrong rendering of gl_PointSize on Pineview

2012-03-02 Thread Eric Anholt
On Fri, 2 Mar 2012 10:14:05 +0800, Yuanhan Liu yuanhan@linux.intel.com 
wrote:
 On Thu, Mar 01, 2012 at 09:54:46AM -0800, Eric Anholt wrote:
  On Thu, 23 Feb 2012 14:19:19 +0800, Yuanhan Liu 
  yuanhan@linux.intel.com wrote:

   +   /* Handle gl_PointSize builtin var here */
   +   if (ctx-Point._Attenuated || ctx-VertexProgram.PointSizeEnabled)
   +  EMIT_ATTR(_TNL_ATTRIB_POINTSIZE, EMIT_1F, S4_VFMT_POINT_WIDTH, 1);
  
  All the other EMIT_ATTRs specify the number of bytes as the last arg.
  It seems like this code shouldn't have worked.
 
 Actually, it does work ;)
 
 Well, if the last arg specify the size in _bytes_, then this patch was
 wrong. 
 
 And here is the updated one:

Reviewed-by: Eric Anholt e...@anholt.net


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


[Mesa-dev] [PATCH] i965: fixup W-tile offset computation to take swizzling into account

2012-03-02 Thread Daniel Vetter
There's even a comment in the code containing the right swizzling
computations!

Previously this has not been noticed because we need to manually
enabled swizzling on snb/ivb (kernel 3.4 will do that) and we
don't use the separate stencil on ilk (where the bios enables
swizzling). This fixes

piglit ./bin/fbo-stencil  readpixels GL_DEPTH32F_STENCIL8 -auto

on recent drm-intel-next kernels.

Also remove the comment about ivb, it's stale now.

Swizzling detection is done by allocating a temporary x-tiled
buffer object. Unfortunately kernels before v3.2 lie on snb/ivb
because they claim that swizzling is enable, but it isn't. The
kernel commit that fixes this for backport to pre-v3.2 is

commit acc83eb5a1e0ae7dbbf89ca2a1a943ade224bb84
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Mon Sep 12 20:49:16 2011 +0200

drm/i915: fix swizzling on gen6+

But if the kernel doesn't lie, this now works on swizzling and
not swizzling machines.

Note: This is a candidate for the 8.0 branch.
---
 src/mesa/drivers/dri/intel/intel_context.c |1 +
 src/mesa/drivers/dri/intel/intel_context.h |1 +
 src/mesa/drivers/dri/intel/intel_mipmap_tree.c |   12 ++---
 src/mesa/drivers/dri/intel/intel_screen.c  |   26 ++
 src/mesa/drivers/dri/intel/intel_screen.h  |1 +
 src/mesa/drivers/dri/intel/intel_span.c|   28 +--
 src/mesa/drivers/dri/intel/intel_span.h|2 +-
 7 files changed, 49 insertions(+), 22 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_context.c 
b/src/mesa/drivers/dri/intel/intel_context.c
index c876694..7b2bdad 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -629,6 +629,7 @@ intelInitContext(struct intel_context *intel,
intel-must_use_separate_stencil = 
intel-intelScreen-hw_must_use_separate_stencil;
intel-has_hiz = intel-intelScreen-hw_has_hiz;
intel-has_llc = intel-intelScreen-hw_has_llc;
+   intel-has_swizzling = intel-intelScreen-hw_has_swizzling;
 
memset(ctx-TextureFormatSupported,
  0, sizeof(ctx-TextureFormatSupported));
diff --git a/src/mesa/drivers/dri/intel/intel_context.h 
b/src/mesa/drivers/dri/intel/intel_context.h
index 150e55f..ef024b1 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -214,6 +214,7 @@ struct intel_context
bool must_use_separate_stencil;
bool has_hiz;
bool has_llc;
+   bool has_swizzling;
 
int urb_size;
 
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c 
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 5290da4..3601f5e 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -830,7 +830,8 @@ intel_miptree_map_s8(struct intel_context *intel,
 for (uint32_t x = 0; x  map-w; x++) {
ptrdiff_t offset = intel_offset_S8(mt-region-pitch,
   x + image_x + map-x,
-  y + image_y + map-y);
+  y + image_y + map-y,
+  intel-has_swizzling);
untiled_s8_map[y * map-w + x] = tiled_s8_map[offset];
 }
   }
@@ -865,7 +866,8 @@ intel_miptree_unmap_s8(struct intel_context *intel,
 for (uint32_t x = 0; x  map-w; x++) {
ptrdiff_t offset = intel_offset_S8(mt-region-pitch,
   x + map-x,
-  y + map-y);
+  y + map-y,
+  intel-has_swizzling);
tiled_s8_map[offset] = untiled_s8_map[y * map-w + x];
 }
   }
@@ -925,7 +927,8 @@ intel_miptree_map_depthstencil(struct intel_context *intel,
int map_x = map-x + x, map_y = map-y + y;
ptrdiff_t s_offset = intel_offset_S8(s_mt-region-pitch,
 map_x + s_image_x,
-map_y + s_image_y);
+map_y + s_image_y,
+intel-has_swizzling);
ptrdiff_t z_offset = ((map_y + z_image_y) * z_mt-region-pitch +
  (map_x + z_image_x));
uint8_t s = s_map[s_offset];
@@ -983,7 +986,8 @@ intel_miptree_unmap_depthstencil(struct intel_context 
*intel,
 for (uint32_t x = 0; x  map-w; x++) {
ptrdiff_t s_offset = intel_offset_S8(s_mt-region-pitch,
 x + s_image_x + map-x,
-y + s_image_y + map-y);
+y + s_image_y + map-y,
+intel-has_swizzling);
ptrdiff_t 

Re: [Mesa-dev] Mesa (master): glx: Convert to automake.

2012-03-02 Thread Ian Romanick

On 02/29/2012 11:56 AM, Eric Anholt wrote:

Module: Mesa
Branch: master
Commit: 8ffb098234fbc3d2e3c8b3db6912dec9ea7a65eb
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=8ffb098234fbc3d2e3c8b3db6912dec9ea7a65eb

Author: Eric Anholte...@anholt.net
Date:   Sun Feb  5 06:10:56 2012 +0100

glx: Convert to automake.

Reviewed-by: Kenneth Graunkekenn...@whitecape.org


I'm going to take a wild guess that this commit broke 'make check'.

gmake[3]: *** No rule to make target `../../src/glx/libglx.a', needed by 
`glx_unittest'.  Stop.




---

  configure.ac|4 ++
  src/glx/.gitignore  |5 ++
  src/glx/Makefile|  119 -
  src/glx/Makefile.am |  122 +++
  src/mesa/Makefile   |2 -
  5 files changed, 131 insertions(+), 121 deletions(-)

diff --git a/configure.ac b/configure.ac
index 0caa1b1..ac06e80 100644
--- a/configure.ac
+++ b/configure.ac
@@ -379,6 +379,7 @@ fi
  AC_SUBST([GL_LIB])
  AC_SUBST([GLU_LIB])
  AC_SUBST([OSMESA_LIB])
+AM_CONDITIONAL(HAVE_MANGLED_GL, test $GL_LIB = MangledGL)

  dnl
  dnl potentially-infringing-but-nobody-knows-for-sure stuff
@@ -703,6 +704,7 @@ if test x$enable_shared_glapi = xyes; then
  DEFINES=$DEFINES -DIN_DRI_DRIVER
  fi
  AC_SUBST([SHARED_GLAPI])
+AM_CONDITIONAL(HAVE_SHARED_GLAPI, test $SHARED_GLAPI = 1)

  dnl
  dnl Driver configuration. Options are xlib, dri and osmesa right now.
@@ -1040,6 +1042,7 @@ esac
  # builds.
  AM_CONDITIONAL(HAVE_XCB_GLX_CREATE_CONTEXT,
  test x$HAVE_XCB_GLX_CREATE_CONTEXT = xyes)
+AM_CONDITIONAL(HAVE_XF86VIDMODE, test x$HAVE_XF86VIDMODE = xyes)

  GLESv1_CM_LIB_DEPS=$LIBDRM_LIBS -lm -lpthread $DLOPEN_LIBS
  GLESv1_CM_PC_LIB_PRIV=-lm -lpthread $DLOPEN_LIBS
@@ -1939,6 +1942,7 @@ AC_CONFIG_FILES([configs/autoconf
src/egl/wayland/wayland-egl/Makefile
src/egl/wayland/wayland-egl/wayland-egl.pc
src/egl/wayland/wayland-drm/Makefile
+   src/glx/Makefile
src/mesa/drivers/dri/dri.pc
src/mesa/drivers/dri/Makefile
src/mesa/drivers/dri/common/Makefile
diff --git a/src/glx/.gitignore b/src/glx/.gitignore
new file mode 100644
index 000..ea7b611
--- /dev/null
+++ b/src/glx/.gitignore
@@ -0,0 +1,5 @@
+.deps
+.libs
+Makefile
+Makefile.in
+libGL.la
diff --git a/src/glx/Makefile b/src/glx/Makefile
deleted file mode 100644
index f702f95..000
--- a/src/glx/Makefile
+++ /dev/null
@@ -1,119 +0,0 @@
-TOP = ../..
-include $(TOP)/configs/current
-
-ifeq ($(HAVE_XF86VIDMODE),yes)
-EXTRA_DEFINES_XF86VIDMODE = -DXF86VIDMODE
-endif
-
-EXTRA_DEFINES = $(EXTRA_DEFINES_XF86VIDMODE) -D_REENTRANT \
--DDEFAULT_DRIVER_DIR=\$(DRI_DRIVER_SEARCH_DIR)\
-
-SOURCES = \
- clientattrib.c \
- clientinfo.c \
- compsize.c \
- create_context.c \
- eval.c \
- glxconfig.c \
- glxcmds.c \
- glxcurrent.c \
- glx_error.c \
- glxext.c \
- glxextensions.c \
- indirect_glx.c \
- indirect.c \
- indirect_init.c \
- indirect_size.c \
- indirect_window_pos.c \
- indirect_texture_compression.c \
- indirect_transpose_matrix.c \
- indirect_vertex_array.c \
- indirect_vertex_program.c \
- pixel.c \
- pixelstore.c \
- render2.c \
- renderpix.c \
- single2.c \
- singlepix.c \
- vertarr.c \
- xfont.c \
- glx_pbuffer.c \
- glx_query.c \
- drisw_glx.c \
- dri_common.c \
- dri_glx.c \
- XF86dri.c \
- glxhash.c \
- dri2_glx.c \
- dri2.c \
- applegl_glx.c
-
-
-ifeq ($(SHARED_GLAPI),1)
-GL_LIB_DEPS := -L$(TOP)/$(LIB_DIR) -l$(GLAPI_LIB) $(GL_LIB_DEPS)
-EXTRA_DEFINES += -DGLX_SHARED_GLAPI
-endif
-
-# override GLAPI_LIB
-GLAPI_LIB = $(TOP)/src/mapi/glapi/libglapi.a
-
-OBJECTS = $(SOURCES:.c=.o)
-
-INCLUDES = -I. \
-   -I$(TOP)/include \
-   -I$(TOP)/include/GL/internal \
-   -I$(TOP)/src/mesa \
-   -I$(TOP)/src/mapi \
-   -I$(TOP)/src/mapi/glapi \
-   $(LIBDRM_CFLAGS) \
-   $(DRI2PROTO_CFLAGS) \
-   $(GLPROTO_CFLAGS) \
-   $(X11_INCLUDES)
-
-
-# RULES #
-
-.c.o:
-   $(CC) -c $(INCLUDES) $(CFLAGS) $(EXTRA_DEFINES) $  -o $@
-
-.S.o:
-   $(CC) -c $(INCLUDES) $(CFLAGS) $(EXTRA_DEFINES)  $  -o $@
-
-# TARGETS #
-
-default: depend $(TOP)/$(LIB_DIR)/$(GL_LIB_NAME)
-
-libglx.a: $(OBJECTS)
-   $(MKLIB) -cplusplus -o glx -static $(OBJECTS)
-
-# Make libGL
-$(TOP)/$(LIB_DIR)/$(GL_LIB_NAME): libglx.a $(OBJECTS) $(GLAPI_LIB) Makefile
-   $(MKLIB) -o $(GL_LIB) -linker '$(CXX)' -ldflags '$(LDFLAGS)' \
-   -major 1 -minor 2 \
-   -cplusplus $(MKLIB_OPTIONS) \
-   -install $(TOP)/$(LIB_DIR) -id 
$(INSTALL_LIB_DIR)/lib$(GL_LIB).1.dylib \
-   $(GL_LIB_DEPS) $(OBJECTS) 

[Mesa-dev] [PATCH] mesa: Fix valid texture target test in _mesa_GetTexLevelParameteriv()

2012-03-02 Thread Anuj Phogat
_mesa_max_texture_levels() is also used to test valid texture target
in _mesa_GetTexLevelParameteriv(). GL_TEXTURE_CUBE_MAP is not allowed
as texture target in glGetTexLevelParameter(). So, this should throw
GL_INVALID_ENUM error.

Few other functions which use _mesa_max_texture_levels() like
getcompressedteximage_error_check() and getteximage_error_check()
also don't accept GL_TEXTURE_CUBE_MAP.

Above fix makes piglit fbo-cubemap test to fail. This is because of
incorrect texture target passed to _mesa_max_texture_levels() in
framebuffer_texture(). Fixing that as well

Note: This is a candidate for the stable branches

Signed-off-by: Anuj Phogat anuj.pho...@gmail.com

---
 src/mesa/main/fbobject.c |2 +-
 src/mesa/main/teximage.c |1 -
 2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 6ee062d..281b1ca 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1994,7 +1994,7 @@ framebuffer_texture(struct gl_context *ctx, const char 
*caller, GLenum target,
   }
 
   if ((level  0) ||
-  (level = _mesa_max_texture_levels(ctx, texObj-Target))) {
+  (level = _mesa_max_texture_levels(ctx, textarget))) {
  _mesa_error(ctx, GL_INVALID_VALUE,
  glFramebufferTexture%sEXT(level), caller);
  return;
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 4fb81e6..c0e5b9b 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -915,7 +915,6 @@ _mesa_max_texture_levels(struct gl_context *ctx, GLenum 
target)
case GL_TEXTURE_CUBE_MAP_NEGATIVE_Y_ARB:
case GL_TEXTURE_CUBE_MAP_POSITIVE_Z_ARB:
case GL_TEXTURE_CUBE_MAP_NEGATIVE_Z_ARB:
-   case GL_TEXTURE_CUBE_MAP_ARB:
case GL_PROXY_TEXTURE_CUBE_MAP_ARB:
   return ctx-Extensions.ARB_texture_cube_map
  ? ctx-Const.MaxCubeTextureLevels : 0;
-- 
1.7.7.6

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


Re: [Mesa-dev] Mesa (master): glx: Convert to automake.

2012-03-02 Thread Eric Anholt
On Fri, 02 Mar 2012 14:38:37 -0800, Ian Romanick i...@freedesktop.org wrote:
 On 02/29/2012 11:56 AM, Eric Anholt wrote:
  Module: Mesa
  Branch: master
  Commit: 8ffb098234fbc3d2e3c8b3db6912dec9ea7a65eb
  URL:
  http://cgit.freedesktop.org/mesa/mesa/commit/?id=8ffb098234fbc3d2e3c8b3db6912dec9ea7a65eb
 
  Author: Eric Anholte...@anholt.net
  Date:   Sun Feb  5 06:10:56 2012 +0100
 
  glx: Convert to automake.
 
  Reviewed-by: Kenneth Graunkekenn...@whitecape.org
 
 I'm going to take a wild guess that this commit broke 'make check'.
 
 gmake[3]: *** No rule to make target `../../src/glx/libglx.a', needed by 
 `glx_unittest'.  Stop.

make check passes for me, but I didn't have the external dependency
installed, and even with libgtest-dev installed I don't have a
gtest-config so it doesn't end up building the test suite.


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