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

Reply via email to