[Mesa-dev] [PATCH 0/3] Misc patches

2012-08-22 Thread Maxim Levitsky 
Hi, just sending few hacky patches I made while wrestling
with Unigine demos.

First patch, fixes long standing issue of using driconf GUI with
Gallium drivers. I stumbled upon it long ago.
Now I  fixed swrast to work with it too.

Second patch allows to use GLSL warning mode for shaders that dont
declare that they want modern GLSL features.
Unigine is major example of this, sadly.
I coldnt find a way to make Gallium use that option via driconf
because of abstraction between mesa state_tracker and dri state 
tracker that uses it.
Speaking of which I think that it would be good to move it out of mesa
main dir and put it to gallium state_tracker dir where it belongs.

Third patch which you probably wont accept piggybacks on that force
GLSL extension mode to also bump default GLSL version because otherwice
some GLSL extensions are not aviable even with this hack on to shaders that
dont ask for proper GLSL version (again Unigine of course...)

Best regards, 
Maxim Levitsky.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 3/3] mesa: glsl: force version too when force_glsl_extensions_warn is used

2012-08-22 Thread Maxim Levitsky 
Unfortunelly some buggy programs use extensions without asking ether for
proper GLSL version nor ask for particular extension.

Moreover the force_glsl_extensions_warn hack is only effective for some
extensions (GL_EXT_texture_array) but unfortunelly isnt effective for other
extensions (I suspect these that declare new built in functions)
Example of this is recently added ARB_shader_bit_encoding extension.
Forcing GLSL version to high value seems to fix this, not sure if this
is acceptable hack though.

This can be reproducted in Unigine Heaven with ambient occlusion on.
Note that even with this path shader compilatin fails, because code in Unigine
that gets activated when this extension gets enabled expects implicit 
conversions
between signed and unsigned immidiate constants. Whether GLSL shold allow this 
is open
for debate.

Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
 src/glsl/glsl_parser_extras.cpp |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 872fcda..754166b 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -105,8 +105,10 @@ _mesa_glsl_parse_state::_mesa_glsl_parse_state(struct 
gl_context *_ctx,
 
this-supported_version_string = supported;
 
-   if (ctx-Const.ForceGLSLExtensionsWarn)
+   if (ctx-Const.ForceGLSLExtensionsWarn) {
   _mesa_glsl_process_extension(all, NULL, warn, NULL, this);
+  this-language_version = 130;
+   }
 
this-default_uniform_qualifier = new(this) ast_type_qualifier();
this-default_uniform_qualifier-flags.q.shared = 1;
-- 
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 3/3] mesa: glsl: force version too when force_glsl_extensions_warn is used

2012-08-22 Thread Maxim Levitsky 
On Wed, 2012-08-22 at 08:48 -0600, Brian Paul wrote: 
 On 08/22/2012 02:23 AM, Maxim Levitsky wrote:
  Unfortunelly some buggy programs use extensions without asking ether for
  proper GLSL version nor ask for particular extension.
 
  Moreover the force_glsl_extensions_warn hack is only effective for some
  extensions (GL_EXT_texture_array) but unfortunelly isnt effective for other
  extensions (I suspect these that declare new built in functions)
  Example of this is recently added ARB_shader_bit_encoding extension.
  Forcing GLSL version to high value seems to fix this, not sure if this
  is acceptable hack though.
 
  This can be reproducted in Unigine Heaven with ambient occlusion on.
  Note that even with this path shader compilatin fails, because code in 
  Unigine
  that gets activated when this extension gets enabled expects implicit 
  conversions
  between signed and unsigned immidiate constants.
 
 Can you give a short example of the GLSL code that's causing the problem?
 
 
  Whether GLSL shold allow this is open
  for debate.
 
 
 In my opinion, it's better to bend the rules a bit to allow broken 
 apps to run than to just give up so I'm OK with this patch.  But let's 
 hear what Ian thinks.
 
 -Brian
Sure!

uniform uint foo;
void main() {
float x = float(foo  0xffu);
}

Best regards,
Maxim Levitsky

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

Re: [Mesa-dev] [PATCH 3/3] mesa: glsl: force version too when force_glsl_extensions_warn is used

2012-08-22 Thread Maxim Levitsky 
On Wed, 2012-08-22 at 18:53 +0300, Maxim Levitsky wrote: 
 On Wed, 2012-08-22 at 08:48 -0600, Brian Paul wrote: 
  On 08/22/2012 02:23 AM, Maxim Levitsky wrote:
   Unfortunelly some buggy programs use extensions without asking ether for
   proper GLSL version nor ask for particular extension.
  
   Moreover the force_glsl_extensions_warn hack is only effective for some
   extensions (GL_EXT_texture_array) but unfortunelly isnt effective for 
   other
   extensions (I suspect these that declare new built in functions)
   Example of this is recently added ARB_shader_bit_encoding extension.
   Forcing GLSL version to high value seems to fix this, not sure if this
   is acceptable hack though.
  
   This can be reproducted in Unigine Heaven with ambient occlusion on.
   Note that even with this path shader compilatin fails, because code in 
   Unigine
   that gets activated when this extension gets enabled expects implicit 
   conversions
   between signed and unsigned immidiate constants.
  
  Can you give a short example of the GLSL code that's causing the problem?
  
  
   Whether GLSL shold allow this is open
   for debate.
  
  
  In my opinion, it's better to bend the rules a bit to allow broken 
  apps to run than to just give up so I'm OK with this patch.  But let's 
  hear what Ian thinks.
  
  -Brian
 Sure!
 
 uniform uint foo;
 void main() {
 float x = float(foo  0xffu);
 }
 
 Best regards,
 Maxim Levitsky
 
Oops, that is the fixed code.

This doesn't compile.

uniform uint normal;
void main() {
float x = float(normal  0xff);
}

Best regards,
Maxim Levitsky


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

Re: [Mesa-dev] [PATCH 2/3] state_tracker: allow to utilize GLSL workaround for broken apps in Gallium

2012-08-22 Thread Maxim Levitsky 
On Wed, 2012-08-22 at 19:54 +0400, Vadim Girlin wrote: 
 On Wed, 2012-08-22 at 11:31 -0400, Alex Deucher wrote:
  On Wed, Aug 22, 2012 at 11:24 AM, Vadim Girlin vadimgir...@gmail.com 
  wrote:
   On Wed, 2012-08-22 at 11:23 +0300, Maxim Levitsky wrote:
   Currently Gallium has no way to activate the
   'force_glsl_extensions_warn' workaround that allows
   buggy apps that use GLSL extensions without asking for them to work.
  
   Since gallium mesa state tracker is essentially split into two,
   (dri (src/gallium/state_trackers/dri) and mesa (src/mesa/state_tracker))
   and only former has access to driconf options while later knows nothing
   about dri, I added this support by reading an environment variable.
  
   export force_glsl_extensions_warn=true
  
  
   I just remembered that I sent some patches for passing the driconf
   options to the state tracker but then forgot about them completely.
  
   Feel free to reuse anything from that series if it might help:
  
   http://lists.freedesktop.org/archives/mesa-dev/2012-April/020729.html
  
  Series looks good to me.  Looks like Michel added his reviewed-by at
  the time as well.  
 
 Yes, it was reviewed, but then I found that it breaks swrast build due
 to missing driver descriptor, so I asked if it's OK to simply add the
 descriptor to swrast and it seems I'm still waiting for the answer... :)
 
  If it still applies, I'd say go ahead and commit it.
 
 I'll check if it still works and if it's enough to run Unigine apps
 correctly with current mesa. IIRC it doesn't contain GLSL version hacks
 as in Maxim's patch 3, so possibly it should be included too, and maybe
 something else.
Unless you enable 'ambient occlusion' in Heaven, just GLSL force
extension hack (which is included in this series), is enough.

With it, it starts using  ARB_shader_bit_encoding extension, and to make
it aviable you need my patch #3, but even that is not enough as demo
introduces unrelated compile error, when extension is enabled.
I have a local hack to override this, but its not worth looking at.
Just for reference I attach it.

Today I will test this patch series,
and thanks for telling about it, as I was about to stop being lazy and
implement the same thing.


Best regards,
Maxim Levitsky
From 729e4f56bc56b909976fc2375b584b4b37b624ce Mon Sep 17 00:00:00 2001
From: Maxim Levitsky maximlevit...@gmail.com
Date: Sun, 19 Aug 2012 13:30:47 +0300
Subject: [PATCH 4/7] glsl: hack int/uint conversions

---
 src/glsl/ast_to_hir.cpp  |2 ++
 src/glsl/ir_validate.cpp |4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 02fe66b..b00a845 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -415,11 +415,13 @@ bit_logic_result_type(const struct glsl_type *type_a,
 /* The fundamental types of the operands (signed or unsigned) must
  * match,
  */
+#if 0
 if (type_a-base_type != type_b-base_type) {
_mesa_glsl_error(loc, state, operands of `%s' must have the same 
 base type, ast_expression::operator_string(op));
return glsl_type::error_type;
 }
+#endif
 
 /* The operands cannot be vectors of differing size. */
 if (type_a-is_vector() 
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index af0b576..5754330 100644
--- a/src/glsl/ir_validate.cpp
+++ b/src/glsl/ir_validate.cpp
@@ -398,8 +398,8 @@ ir_validate::visit_leave(ir_expression *ir)
case ir_binop_bit_and:
case ir_binop_bit_xor:
case ir_binop_bit_or:
-   assert(ir-operands[0]-type-base_type ==
-  ir-operands[1]-type-base_type);
+//   assert(ir-operands[0]-type-base_type ==
+//  ir-operands[1]-type-base_type);
assert(ir-type-is_integer());
if (ir-operands[0]-type-is_vector() 
ir-operands[1]-type-is_vector()) {
-- 
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] gallium/st: Use driver name to access driconf

2012-08-15 Thread Maxim Levitsky 
On Wed, 2012-08-15 at 10:48 +0200, Michel Dänzer wrote: 
 On Mit, 2012-08-15 at 03:45 +0300, Maxim Levitsky wrote: 
  This fixes fetching driconf options from the gallium drivers.
  
  Patch written by, Carl-Philip Haensch
  (http://lists.freedesktop.org/archives/mesa-dev/2011-May/007743.html)
 
 This should be reflected in the Git authorship directly.
Don't know how to do this. 
 
 
  @@ -103,8 +104,8 @@ dri_create_context(gl_api api, const struct gl_config * 
  visual,
  ctx-cPriv = cPriv;
  ctx-sPriv = sPriv;
   
  -   driParseConfigFiles(ctx-optionCache,
  -  screen-optionCache, sPriv-myNum, dri);
  +   driParseConfigFiles(ctx-optionCache, screen-optionCache,
  +sPriv-myNum, driver_descriptor.name);
 
 Unfortunately, this breaks the src/gallium/targets/dri-swrast build:
And stupid me tried to compile swrast today, and I wonder why it didn't
compile..
I see what I could do.

Best regards,
Maxim Levitsky

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

Re: [Mesa-dev] [PATCH] gallium/st: Use driver name to access driconf

2012-08-15 Thread Maxim Levitsky 
On Wed, 2012-08-15 at 11:32 +0200, Michel Dänzer wrote: 
 On Mit, 2012-08-15 at 12:29 +0300, Maxim Levitsky wrote: 
  On Wed, 2012-08-15 at 10:48 +0200, Michel Dänzer wrote: 
   On Mit, 2012-08-15 at 03:45 +0300, Maxim Levitsky wrote: 
This fixes fetching driconf options from the gallium drivers.

Patch written by, Carl-Philip Haensch
(http://lists.freedesktop.org/archives/mesa-dev/2011-May/007743.html)
   
   This should be reflected in the Git authorship directly.
  Don't know how to do this. 
 
 git commit --author

Ah, thanks!

-- 
Best regards,
Maxim Levitsky


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

[Mesa-dev] (no subject)

2012-08-14 Thread Maxim Levitsky 

Hi, I have this backported patch here for more that an year, and forgot all 
about it.
It just makes gallium drivers use driver name instread of 'dri' in driconf
parser, thus making it compatable with 'driconf' GUI.

Can you merge it?

Best regards,
Maxim Levitsky
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [QUESTION] If shared dricode/glapi is enabled by default, why it isn't used by gallium

2012-08-14 Thread Maxim Levitsky 

I noticed that recently in addition to nouveau_dri.so, I also get
installed libdricore.so and libglsl.so.
But two later files aren't linked to anything and can be deleted.
Obviously nouveau_dri.so statically links its code.

Quick glance over Makefiles makes me thing that same issue exists
in other Gallium drivers.

Any ideas?


Any while at it, why not to move mesa state tracker
(src/mesa/state_tracker) to gallium for consistency, as anyway
the (src/gallium/state_trackers) long ago isn't just
'This directory is a placeholder for incubating state-trackers.'

In fact wrapper for all DRI gallium drivers, lives there.
Its just confusing this way in my opinion.

Best regards,
Maxim Levitsky

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

Re: [Mesa-dev] Removing GLw from the main Mesa repository

2011-08-05 Thread Maxim Levitsky 
On Fri, 2011-08-05 at 07:45 -0600, Brian Paul wrote:
 On Thu, Aug 4, 2011 at 4:26 PM, Kenneth Graunke kenn...@whitecape.org wrote:
  Hey,
 
  I'd like to remove libGLw from the main Mesa repository.  It never
  changes, and almost noone uses it...because GL and Motif is awesome, right?
 
  Since Debian still packages it, I pulled it into its own git repository,
  preserving history, and then autotooled it.
 
  You can get it here:
  git://people.freedesktop.org/~kwg/glw
 
 Sounds good to me.  Please scan through the Mesa docs for any mention
 of libGLw and update/remove as needed.  There should at least be a
 pointer to the new home of libGLw too.

While at it, why not to remove libGLU from mesa as well?

Best regards,
Maxim Levitsky


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

Re: [Mesa-dev] [PATCH] glproto: add a new GLXBufferSwapComplete struct that matches the spec

2011-05-19 Thread Maxim Levitsky 
On Thu, 2011-05-19 at 13:28 -0700, Jesse Barnes wrote: 
 On Tue, 10 May 2011 17:57:52 -0700
 Eric Anholt e...@anholt.net wrote:
 
  On Tue, 10 May 2011 12:32:24 -0700, Jesse Barnes jbar...@virtuousgeek.org 
  wrote:
   On Tue, 10 May 2011 11:59:56 -0700
   Eric Anholt e...@anholt.net wrote:
   
On Thu, 5 May 2011 12:39:57 -0700, Jesse Barnes 
jbar...@virtuousgeek.org wrote:
 Just add a new struct to remain compatible with existing code.
 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 
 diff --git a/configure.ac b/configure.ac
 index a3047e4..a6c301c 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1,5 +1,5 @@
  AC_PREREQ([2.60])
 -AC_INIT([GLProto], [1.4.13], 
 [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
 +AC_INIT([GLProto], [1.4.14], 
 [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
  AM_INIT_AUTOMAKE([foreign dist-bzip2])
  AM_MAINTAINER_MODE
  
 diff --git a/glxproto.h b/glxproto.h
 index dfa0647..3f9e837 100644
 --- a/glxproto.h
 +++ b/glxproto.h
 @@ -1375,6 +1375,20 @@ typedef struct {
  BYTE pad;
  CARD16 sequenceNumber B16;
  CARD16 event_type B16;

While this is the compat structure, I'd still like to see the padding
explicit so I don't worry about it when reading the code ever again.
   
   Ok, wanna push your existing patch for that or should I push it with
   this stuff?
  
  Meh, just push it with your stuff.
 
 Ok, I've just pushed the dri2proto and glproto changes.  I'd appreciate
 some testing besides myself before pushing the mesa bits though (which
 work with both old and new X servers, so the delay in getting the X
 bits merged should be fine).
 
 There's a glx-swap-event test in piglit I've been using.  The -v option
 will give you counts, and you can edit the server to start at a high
 swap count to test the wrapping.


To be honest, I already use the whole patchset for a week from now.
I applied in in small hope it would fix really bad flickering in games
if compiz is running on nouveau stack. It didn't fix it, but nether seem
to break anything. 

-- 
Best regards,
Maxim Levitsky


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

Re: [Mesa-dev] [PATCH] Anisotropic filtering extension for swrast

2011-05-18 Thread Maxim Levitsky 
On Wed, 2011-05-18 at 08:06 -0600, Brian Paul wrote: 
 On 05/17/2011 05:08 AM, Andreas Faenger wrote:
  Hi,
 
  this patch makes it possible to have high quality texture filtering
  with the pure software renderer. The main purpose is to use it with
  osmesa. The anisotropic filtering is based on Elliptical Weighted Avarage 
  (EWA).
 
  The patch was designed to make as little changes to the existing codebase 
  as possible. Therefore, the existing texture_sample_func
  signature has not been adjusted although this was required; a hack
  was used instead to pass the required arguments.
 
  I provide this patch as other people might be interessted in
  using anisotropic filtering for osmesa, especially when rendering
  images in a headless environment.
 
 Thanks.  I'm about to commit your patch (with some formatting fixes).
 
 Would you be interested in implementing this feature in the Gallium 
 softpipe driver too?

Offtopic: @phoronix: please don't write an excitement article about how
mesa now supports anisotropic filtering (with writing in very small text
that is only for software renderer...) :-)

Best regards,
Maxim Levitsly

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

[Mesa-dev] [PATCH v2] nv50: add support for user clip planes.

2011-05-18 Thread Maxim Levitsky 
Clip distance is calculated each time vertex position is written
which is suboptiomal is some cases but very safe.
User clip planes are an obsolete feature anyway.

Every time number of clip planes increases, the vertex program is recompiled.
That ensures no overhead in normal case (no user clip planes)
and reasonable overhead otherwice.

Fixes 3D windows in compiz, and reflection effect in neverball.
Also fixes  compiz expo plugin when windows were dragged and each window shown 
3 times.

Thanks to Christoph Bumiller for writing the shader compiler, and for helping me
learn it enough to fix that little issue.
Also, this is based on old patch by him, that added this support to older 
version of the shader compiler.

V2: * revalidate shader linkage only when vertex program is rebuilt as 
suggested by Christoph Bumiller
* little consmetic fixes

Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
---
 src/gallium/drivers/nv50/nv50_program.c|3 ++
 src/gallium/drivers/nv50/nv50_shader_state.c   |8 ++-
 src/gallium/drivers/nv50/nv50_state_validate.c |4 +++
 src/gallium/drivers/nv50/nv50_tgsi_to_nc.c |   28 
 4 files changed, 42 insertions(+), 1 deletions(-)

diff --git a/src/gallium/drivers/nv50/nv50_program.c 
b/src/gallium/drivers/nv50/nv50_program.c
index 41d3e14..4def93d 100644
--- a/src/gallium/drivers/nv50/nv50_program.c
+++ b/src/gallium/drivers/nv50/nv50_program.c
@@ -395,6 +395,9 @@ nv50_vertprog_prepare(struct nv50_translation_info *ti)
   }
}
 
+   p-vp.clpd = p-max_out;
+   p-max_out += p-vp.clpd_nr;
+
for (i = 0; i  TGSI_SEMANTIC_COUNT; ++i) {
   switch (ti-sysval_map[i]) {
   case 2:
diff --git a/src/gallium/drivers/nv50/nv50_shader_state.c 
b/src/gallium/drivers/nv50/nv50_shader_state.c
index 82c346c..065a9e7 100644
--- a/src/gallium/drivers/nv50/nv50_shader_state.c
+++ b/src/gallium/drivers/nv50/nv50_shader_state.c
@@ -170,6 +170,12 @@ nv50_vertprog_validate(struct nv50_context *nv50)
struct nouveau_channel *chan = nv50-screen-base.channel;
struct nv50_program *vp = nv50-vertprog;
 
+   if (nv50-clip.nr  vp-vp.clpd_nr) {
+  if (vp-translated)
+nv50_program_destroy(nv50, vp);
+  vp-vp.clpd_nr = nv50-clip.nr;
+   }
+
if (!nv50_program_validate(nv50, vp))
  return;
 
@@ -369,7 +375,7 @@ nv50_fp_linkage_validate(struct nv50_context *nv50)
m = nv50_vec4_map(map, 0, lin, dummy, vp-out[0]);
 
for (c = 0; c  vp-vp.clpd_nr; ++c)
-  map[m++] |= vp-vp.clpd + c;
+  map[m++] = vp-vp.clpd + c;
 
colors |= m  8; /* adjust BFC0 id */
 
diff --git a/src/gallium/drivers/nv50/nv50_state_validate.c 
b/src/gallium/drivers/nv50/nv50_state_validate.c
index cdf1a98..c8a0d50 100644
--- a/src/gallium/drivers/nv50/nv50_state_validate.c
+++ b/src/gallium/drivers/nv50/nv50_state_validate.c
@@ -225,6 +225,10 @@ nv50_validate_clip(struct nv50_context *nv50)
 
BEGIN_RING(chan, RING_3D(VP_CLIP_DISTANCE_ENABLE), 1);
OUT_RING  (chan, (1  nv50-clip.nr) - 1);
+
+   if (nv50-vertprog  nv50-vertprog-translated 
+ nv50-clip.nr  nv50-vertprog-vp.clpd_nr)
+ nv50-dirty |= NV50_NEW_VERTPROG;
 }
 
 static void
diff --git a/src/gallium/drivers/nv50/nv50_tgsi_to_nc.c 
b/src/gallium/drivers/nv50/nv50_tgsi_to_nc.c
index 25dcaae..5efa99c 100644
--- a/src/gallium/drivers/nv50/nv50_tgsi_to_nc.c
+++ b/src/gallium/drivers/nv50/nv50_tgsi_to_nc.c
@@ -1990,6 +1990,34 @@ bld_instruction(struct bld_context *bld,
 
FOR_EACH_DST0_ENABLED_CHANNEL(c, insn)
   emit_store(bld, insn, c, dst0[c]);
+
+
+   const struct tgsi_full_dst_register *dreg = insn-Dst[0];
+   struct nv50_program *prog = bld-ti-p;
+
+   if (prog-vp.clpd_nr  prog-type == PIPE_SHADER_VERTEX 
+  dreg-Register.File == TGSI_FILE_OUTPUT 
+  prog-out[dreg-Register.Index].sn == TGSI_SEMANTIC_POSITION) {
+
+  for (int p = 0 ; p  prog-vp.clpd_nr ; p++) {
+ struct nv_value *clipd = NULL;
+
+ for (int c = 0 ; c  4 ; c++) {
+temp = new_value(bld-pc, NV_FILE_MEM_C(15), NV_TYPE_F32);
+temp-reg.id = p * 4 + c;
+temp = bld_insn_1(bld, NV_OP_LDA, temp);
+
+clipd = clipd ?
+bld_insn_3(bld, NV_OP_MAD, dst0[c], temp, clipd) :
+bld_insn_2(bld, NV_OP_MUL, dst0[c], temp);
+ }
+
+ temp = bld_insn_1(bld, NV_OP_MOV, clipd);
+ temp-reg.file = NV_FILE_OUT;
+ temp-reg.id = bld-ti-p-vp.clpd + p;
+ temp-insn-fixed = 1;
+  }
+   }
 }
 
 static INLINE void
-- 
1.7.4.1

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

Re: [Mesa-dev] [Mesa3d-dev] mesa doesn't work with compiz (i965 + tips of all branches)

2010-07-05 Thread Maxim Levitsky 
2010/7/5 Michel Dänzer mic...@daenzer.net:
 On Don, 2010-07-01 at 10:32 -0700, Ian Romanick wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Note: I'm sending this reply to mesa-dev@lists.freedesktop.org instead
 of the old mailing list.

 Maxim Levitsky wrote:
  On Tue, 2010-06-29 at 15:49 -0700, Ian Romanick wrote:
  Corbin Simpson wrote:
  Curious. Admittedly I can't look at the content of that commit, but they
  can't be too useless if compiz selects them. IIRC the point was to limit
  the runtime of Intel internal tests; can't those tests be amended
  instead? The number of configs will only grow; r300g has over 200 now
  thanks to multisampling.
  The configs are useless.  Applications can only ask for bits = X.
  There are still 24-bit depth / 8-bit stencil configs, and, last time I
  checked, 8 = 0.  There is no way to ask for a 24/0 config that wouldn't
  instead give a 24/8 config.
 
  Posting from a mobile, pardon my terseness. ~ C.
 
  On Jun 29, 2010 1:28 PM, Maxim Levitsky maximlevit...@gmail.com
  mailto:maximlevit...@gmail.com wrote:
 
  On Tue, 2010-06-29 at 20:34 +0300, Maxim Levitsky wrote:
  On Sun, 2010-06-27 at 19:07 +0300, Maxim ...
  Bisected this to
 
  73e24cd5a7a0760726a681dda5b88805ddcf1555 is first bad commit
  commit 73e24cd5a7a0760726a681dda5b88805ddcf1555
  Author: Ian Romanick ian.d.roman...@intel.com
  mailto:ian.d.roman...@intel.com
  Date:   Mon Feb 8 10:34:52 2010 -0800
 
     intel: Stop exposing useless 24 depth/0 stencil configs
  I need two pieces of information:
 
    - A diff of the output of glxinfo immediately before and immediately
      after this commit.
 
    - A list of what config attributes compiz is requesting.  It should
      be easy enough to instrument choose_visual in glxcmds.c to dump out
      attribList.
 
  It should be pretty easy to root-cause this problem with that data.

 [snip]

  What is interesting is this:
 
  -0x62 32 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None

 Yup.  That has to be it.  The fix will have two parts.  First, make the
 3D driver a this specific visual.

 -ENOPARSE :)

 That will make new 3D drivers work with old 2D drivers.  Second,
 make the 2D driver mark this visual has having stencil.

 The X driver is no longer involved in GLX visuals. (However, the Mesa
 driver loaded by the X server is involved. Maxim, did the X server load
 your self-built i965_dri.so for each test?)
No. I just compile the mesa (and of course includes i965_dri.so) with
or without commit
change is instant.

However. both good and bad behavior is persistent over X restarts,
when it does load new  i965_dri.so


Wait a minute

(II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so
(II) GLX: Initialized DRISWRAST GL provider for screen 0


I disabled AIGLX in x server long time ago, because it makes me
recompile the server each time mesa changes, and otherwise is useless.

So I try with AIGLX next.


 I think at least part of the problem could be that the X server code was
 changed to make the depth 32 GLX visual take the place of one of the
 depth 24 ones. It should probably become separate again.


 --
 Earthling Michel Dänzer           |                http://www.vmware.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] [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures

2010-05-03 Thread Maxim Levitsky 
On Mon, 2010-05-03 at 13:11 -0600, Brian Paul wrote: 
 Xavier Chantry wrote:
  On Sun, May 2, 2010 at 3:16 PM, Marek Olšák mar...@gmail.com wrote:
  On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky maximlevit...@gmail.com
  wrote:
  This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
  Compiz shows dark screen.
  (Using nouveau drivers)
 
  Without this commit compiz works almost perfectly.
 
  The error messages from compiz:
 
 
  debug_get_bool_option: NV50_ALWAYS_PUSH = FALSE
  debug_get_bool_option: DRAW_FSE = FALSE
  debug_get_bool_option: DRAW_NO_FSE = FALSE
  debug_get_bool_option: GALLIUM_DUMP_VS = FALSE
  Mesa: Mesa 7.9-devel DEBUG build May  1 2010 19:02:06
  Mesa warning: software DXTn compression/decompression available
  debug_get_bool_option: MESA_MVP_DP4 = FALSE
  debug_get_flags_option: ST_DEBUG = 0x0
  Mesa: User error: GL_OUT_OF_MEMORY in glTexImage
  compiz (cube) - Warn: Failed to load
  slide: /usr/share/gdm/themes/Human/ubuntu.png
  ^CMesa: User error: GL_OUT_OF_MEMORY in glTexImage
  The commit also causes surface_copy to be called with S3TC textures,
  breaking loading of such textures in r300g. I am working on a fix for r300g
  but I haven't expected to get such weird formats in surface_copy.
 
  FYI Maxim, please use mesa-dev@lists.freedesktop.org instead.
 
  -Marek
 
  
  This commit also causes piglit fbo-3d test to fail with both llvmpipe
  and nv50 gallium.
  http://img163.imageshack.us/img163/535/fbo3d.png
 
 Can you retest now?
Nope, still same error.

Best regards,
Maxim Levitsky



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

Re: [Mesa-dev] [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures

2010-05-03 Thread Maxim Levitsky 
On Mon, 2010-05-03 at 15:18 -0600, Brian Paul wrote: 
 Maxim Levitsky wrote:
  On Mon, 2010-05-03 at 13:11 -0600, Brian Paul wrote: 
  Xavier Chantry wrote:
  On Sun, May 2, 2010 at 3:16 PM, Marek Olšák mar...@gmail.com wrote:
  On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky maximlevit...@gmail.com
  wrote:
  This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
  Compiz shows dark screen.
  (Using nouveau drivers)
 
  Without this commit compiz works almost perfectly.
 
  The error messages from compiz:
 
 
  debug_get_bool_option: NV50_ALWAYS_PUSH = FALSE
  debug_get_bool_option: DRAW_FSE = FALSE
  debug_get_bool_option: DRAW_NO_FSE = FALSE
  debug_get_bool_option: GALLIUM_DUMP_VS = FALSE
  Mesa: Mesa 7.9-devel DEBUG build May  1 2010 19:02:06
  Mesa warning: software DXTn compression/decompression available
  debug_get_bool_option: MESA_MVP_DP4 = FALSE
  debug_get_flags_option: ST_DEBUG = 0x0
  Mesa: User error: GL_OUT_OF_MEMORY in glTexImage
  compiz (cube) - Warn: Failed to load
  slide: /usr/share/gdm/themes/Human/ubuntu.png
  ^CMesa: User error: GL_OUT_OF_MEMORY in glTexImage
  The commit also causes surface_copy to be called with S3TC textures,
  breaking loading of such textures in r300g. I am working on a fix for 
  r300g
  but I haven't expected to get such weird formats in surface_copy.
 
  FYI Maxim, please use mesa-dev@lists.freedesktop.org instead.
 
  -Marek
 
  This commit also causes piglit fbo-3d test to fail with both llvmpipe
  and nv50 gallium.
  http://img163.imageshack.us/img163/535/fbo3d.png
  Can you retest now?
  Nope, still same error.
 
 Both compiz and fbo-3d?

Didn't test fbo-3d, but compiz fails:

Breakpoint 1, _mesa_error (ctx=0x949690, error=1285, fmtString=0x734d8341 
glTexImage) at main/imports.c:1005
1005{
(gdb) bt
#0  _mesa_error (ctx=0x949690, error=1285, fmtString=0x734d8341 
glTexImage) at main/imports.c:1005
#1  0x73417504 in st_finalize_texture (ctx=0x949690, pipe=value 
optimized out, tObj=0xcb1a80, 
needFlush=value optimized out) at state_tracker/st_cb_texture.c:1920
#2  0x7340830a in finalize_textures (st=0x991f80) at 
state_tracker/st_atom_texture.c:145
#3  0x734045d9 in st_validate_state (st=0x991f80) at 
state_tracker/st_atom.c:167
#4  0x733d5b2a in st_draw_vbo (ctx=value optimized out, 
arrays=0x9956c8, prims=value optimized out, 
nr_prims=value optimized out, ib=0xcc49b0, index_bounds_valid=0 '\000', 
min_index=0, max_index=15)
at state_tracker/st_draw.c:577
#5  0x733fcf84 in vbo_exec_DrawArrays (mode=7, start=0, count=value 
optimized out)
at vbo/vbo_exec_array.c:525
#6  0x00427c9e in ?? ()
#7  0x00427afb in drawWindowTexture ()
#8  0x00427013 in drawWindow ()
#9  0x7fffef6bbd4f in ?? () from /usr/lib/compiz/libdecoration.so
#10 0x00426ef9 in paintWindow ()
#11 0x7fffefcd0988 in ?? () from /usr/lib/compiz/libmove.so
#12 0x7fffefacaa80 in ?? () from /usr/lib/compiz/libresize.so
#13 0x00428c3d in ?? ()
#14 0x004299b5 in paintOutput ()
#15 0x7fffefacaee0 in ?? () from /usr/lib/compiz/libresize.so
#16 0x00410b67 in paintScreen ()
#17 0x00412a35 in eventLoop ()
#18 0x0040d8e9 in main ()
(gdb) q
A debugging session is active.

Best regards,
Maxim Levitsky

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