mesa3d-dev

Re: [Mesa3d-dev] piglit linking

[Xavier C. <cha...@gm...>]

On Fri, Apr 9, 2010 at 8:46 AM, Dave Airlie <ai...@gm...> wrote:
> So I don't understand cmake,
>
> but there is a lot of implicit linking going on in piglit, and in
> Fedora 13 our linker doesn't like that anymore.
>
> So for example the fp-rfl test uses sqrt which means it needs to link
> to libm not get libm via other links,
> glx-multithread needs to link to pthread etc.
>
> How do I add per-app linking clauses to the cmake files?
>

Here is a patch (split into two) I sent to Haehnle a few weeks ago but
he said he was busy traveling.

I only had a problem with glx-multithread and pthread though (fixed by
0001), not with fp-rfl and sqrt/libm .

[Mesa3d-dev] piglit linking

[Dave A. <ai...@gm...>]

So I don't understand cmake,

but there is a lot of implicit linking going on in piglit, and in
Fedora 13 our linker doesn't like that anymore.

So for example the fp-rfl test uses sqrt which means it needs to link
to libm not get libm via other links,
glx-multithread needs to link to pthread etc.

How do I add per-app linking clauses to the cmake files?

Dave.

Re: [Mesa3d-dev] u_half.? -> u_format_half.? rename

[Luca B. <luc...@gm...>]

I named it that way because it is datatype conversion functionality,
which is conceptually a lower layer than format conversion, which
operates on multi-component formats, and is also totally independent
of the existing format conversion functionality.

It is the only member of that layer because all other currently needed
datatype conversions can be performed with trivial C language
expressions: this could change as other unusual floating point
datatypes are needed (e.g. 6e5 and 5e5 for EXT_packed_float).

That said, feel free to rename it: it's just a cosmetic issue.
Alternatively, maybe it a new data conversion prefix could be
invented, like "u_convert_half.*" or something like that.

[Mesa3d-dev] [PATCH] glx: Fix config chooser logic for 'mask' matching

[Kristian H. <kr...@bi...>]

When matching attributes using the 'mask' matching criteria, the spec
says that

  "Only GLXFBConfigs for which the set bits of attribute include all
   the bits that are set in the requested value are
   considered. (Additional bits might be set in the attribute)."

The current test returns true if the two bit masks have bits in
common, specifically it matches even if the requested value has bits
set that are not set in the fbconfig attribute.  For example, an
application asking for

  GLX_DRAWABLE_TYPE, GLX_PIXMAP_BIT | GLX_PBUFFER_BIT,

as glxpbdemo does, will match fbconfigs that don't support pbuffer
rendering, as long as they support pixmap rendering.
---
 src/glx/glxcmds.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 7cdd42c..e256a07 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -1110,6 +1110,13 @@ init_fbconfig_for_chooser(__GLcontextModes * config,
     }                                           \
   } while ( 0 )
 
+/* Test that all bits from a are contained in b */
+#define MATCH_MASK(param)			\
+  do {						\
+    if ((a->param & ~b->param) != 0)		\
+      return False;				\
+  } while (0);
+
 /**
  * Determine if two GLXFBConfigs are compatible.
  *
@@ -1148,11 +1155,8 @@ fbconfigs_compatible(const __GLcontextModes * const a,
    MATCH_DONT_CARE(stereoMode);
    MATCH_EXACT(level);
 
-   if (((a->drawableType & b->drawableType) == 0)
-       || ((a->renderType & b->renderType) == 0)) {
-      return False;
-   }
-
+   MATCH_MASK(drawableType);
+   MATCH_MASK(renderType);
 
    /* There is a bug in a few of the XFree86 DDX drivers.  They contain
     * visuals with a "transparent type" of 0 when they really mean GLX_NONE.
-- 
1.7.0.1

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Stephane M. <ste...@gm...>]

On Thu, Apr 8, 2010 at 16:37, Jesse Barnes <jb...@vi...> wrote:
> On Thu, 8 Apr 2010 18:38:03 -0400
> Alex Deucher <ale...@gm...> wrote:
>
>> On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul <br...@vm...> wrote:
>> >
>> > Unless there's some objection I'm going to subscribe everyone to the
>> > new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list.
>> > Probably in the next 24 hours.
>> >
>> > Then, some of you may have to log into the mailman interface
>> > (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest
>> > mode, etc.
>> >
>> > -Brian
>>
>> Are there plans to move dri-devel as well?
>
> Yeah, I'm just getting the info for that now.  But I don't think we
> have subscriber lists, so everyone will have to re-subscribe to the new
> list.
>
> I'll send out a note to dri-devel when it's all set.
>

You can get the subscriber list at:
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Stephane

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Jesse B. <jb...@vi...>]

On Thu, 8 Apr 2010 18:38:03 -0400
Alex Deucher <ale...@gm...> wrote:

> On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul <br...@vm...> wrote:
> >
> > Unless there's some objection I'm going to subscribe everyone to the
> > new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list.
> > Probably in the next 24 hours.
> >
> > Then, some of you may have to log into the mailman interface
> > (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest
> > mode, etc.
> >
> > -Brian
> 
> Are there plans to move dri-devel as well?

Yeah, I'm just getting the info for that now.  But I don't think we
have subscriber lists, so everyone will have to re-subscribe to the new
list.

I'll send out a note to dri-devel when it's all set.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Alex D. <ale...@gm...>]

On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul <br...@vm...> wrote:
>
> Unless there's some objection I'm going to subscribe everyone to the
> new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list.
> Probably in the next 24 hours.
>
> Then, some of you may have to log into the mailman interface
> (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest
> mode, etc.
>
> -Brian

Are there plans to move dri-devel as well?

Alex

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Brian P. <br...@vm...>]

Unless there's some objection I'm going to subscribe everyone to the 
new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list. 
Probably in the next 24 hours.

Then, some of you may have to log into the mailman interface 
(http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest 
mode, etc.

-Brian

Re: [Mesa3d-dev] gallium-resources branch merge

[Marek O. <ma...@gm...>]

On Thu, Apr 8, 2010 at 3:54 PM, Keith Whitwell <ke...@vm...> wrote:

> OK, it seems like quite a few cases had migrated to the new
> buffer_map_range() behaviour.  I've looked at all I can find and moved
> them back to the old behaviour.
>
> glean is passing now on softpipe.
>

There's now an assertion failure in pipe_buffer_flush_mapped_range. Given a
mapped range, the current behavior in debug build doesn't allow to flush its
subrange if it doesn't touch the last byte of the range. The attached patch
fixes that and changes u_uploadmgr for the mapped and flushed ranges to
match. Please review.

Other than that, it's stable as master. Thank you very much.

-Marek

Re: [Mesa3d-dev] crossbar: read from back buffer, not front.

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This change isn't correct.  This causes the test to read from the back
buffer after the call to glutSwapBuffers.  The swap buffer call can,
especially on DRI2, cause the backbuffer to be filled with garbage.
This can cause the test to fail when nothing is wrong.

commit eb141ce29ef8d7f411f66afbb323f33e3eac4d80
Author: Dave Airlie <ai...@re...>
Date:   Sat Apr 3 14:53:01 2010 +1000

    crossbar: read from back buffer, not front.

    This test isn't a front buffer readback test so don't fail if front
buffer
    readback has issues.

    Signed-off-by: Dave Airlie <ai...@re...>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAku+JlQACgkQX1gOwKyEAw9NPwCfbJhWHiD6S037MQEO57W64jOP
U4IAn3HvXESdbll1PDWJP7zMM5U1ruNX
=MSC+
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] RFC: Add missing D3D9 color formats

[Keith W. <ke...@vm...>]

On Thu, 2010-04-08 at 09:33 -0700, José Fonseca wrote:
> The attached patch adds missing D3D9 color formats.
> 
> We've been going back and forward whether to add these or not, but the
> end conclusion seems there is no harm to add these formats, no matter
> how weird some are, as state tracker and pipe drivers are free to ignore
> them.
> 
> The util module should support all formats however, for everybody's
> convenience. I'll submit more code for these once this patches  go in.
> 
> If I'm not mistaken, the only missing D3D9 formats are some depth
> stencil plus some video formats (e.g. NV12). I did not bother to add
> these yet, given I have no pressing need.
> 
> Jose

This seems fine.  Some of these may actually exist in hardware.

Keith

[Mesa3d-dev] u_half.? -> u_format_half.? rename

[José F. <jfo...@vm...>]

Hi Luca,

Would you mind I rename u_half.? to u_format_half.?, so that all format
related sources group when sorted by name?

Jose

[Mesa3d-dev] RFC: Add missing D3D9 color formats

[José F. <jfo...@vm...>]

The attached patch adds missing D3D9 color formats.

We've been going back and forward whether to add these or not, but the
end conclusion seems there is no harm to add these formats, no matter
how weird some are, as state tracker and pipe drivers are free to ignore
them.

The util module should support all formats however, for everybody's
convenience. I'll submit more code for these once this patches  go in.

If I'm not mistaken, the only missing D3D9 formats are some depth
stencil plus some video formats (e.g. NV12). I did not bother to add
these yet, given I have no pressing need.

Jose

Re: [Mesa3d-dev] gallium-resources branch merge

[Keith W. <ke...@vm...>]

On Wed, 2010-04-07 at 18:58 -0700, Marek Olšák wrote:
> On Wed, Apr 7, 2010 at 7:01 PM, Keith Whitwell <ke...@vm...>
> wrote:
>         
>         On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote:
>         > On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote:
>         > > There's something fishy in u_upload_mgr, could you please
>         review the
>         > > first two patches here?
>         > >
>         http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources
>         > >
>         > > With this, r300g works again.
>         >
>         > Hmm, I think the second of the patches (flush range relative
>         to mapped
>         > range vs whole buffer) may be addressing a regression that
>         has creeped
>         > into the -resources branch regarding this behaviour - ie. I
>         think the
>         > code you modified was actually correct, but that
>         > pipe_flush_mapped_buffer_range() has changed to do the wrong
>         thing.
>         >
>         > I'll try and figure out what should be happening.
>         
>         
>         I've pushed a change which hopefully corrects the behaviour of
>         the
>         buffer_range inlines.  Can you give it a try?
> 
> Now glean/bufferObject fails on softpipe and r300g. I haven't tested
> other drivers.

OK, it seems like quite a few cases had migrated to the new
buffer_map_range() behaviour.  I've looked at all I can find and moved
them back to the old behaviour.

glean is passing now on softpipe.

Keith

Re: [Mesa3d-dev] ARB draw buffers + texenv program

[Dave A. <ai...@gm...>]

On Tue, Apr 6, 2010 at 10:47 PM, Keith Whitwell <ke...@vm...> wrote:
> On Fri, 2010-04-02 at 20:43 -0700, Dave Airlie wrote:
>> Just going down the r300g piglit failures and noticed fbo-drawbuffers
>> failed, I've no idea
>> if this passes on Intel hw, but it appears the texenvprogram really
>> needs to understand the
>> draw buffers. The attached patch fixes it here for me on r300g anyone
>> want to test this on Intel
>> with the piglit test before/after?
>>
>> Dave.
>
> This change makes sense & looks good to me.

Thanks pushed to 7.8.

Dave.

Re: [Mesa3d-dev] gallium-resources branch merge

[Marek O. <ma...@gm...>]

On Wed, Apr 7, 2010 at 7:01 PM, Keith Whitwell <ke...@vm...> wrote:

> On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote:
> > On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote:
> > > There's something fishy in u_upload_mgr, could you please review the
> > > first two patches here?
> > > http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources<http://cgit.freedesktop.org/%7Emareko/mesa/log/?h=gallium-resources>
> > >
> > > With this, r300g works again.
> >
> > Hmm, I think the second of the patches (flush range relative to mapped
> > range vs whole buffer) may be addressing a regression that has creeped
> > into the -resources branch regarding this behaviour - ie. I think the
> > code you modified was actually correct, but that
> > pipe_flush_mapped_buffer_range() has changed to do the wrong thing.
> >
> > I'll try and figure out what should be happening.
>
> I've pushed a change which hopefully corrects the behaviour of the
> buffer_range inlines.  Can you give it a try?
>

Now glean/bufferObject fails on softpipe and r300g. I haven't tested other
drivers.

-Marek

[Mesa3d-dev] gallium in 7.8.1 failing to build on SnowLeopard

[Jeremy H. <jer...@fr...>]

I have another build failure reported to me for gallium on OSX.

Any thoughts?

Here's the full log:
https://trac.macports.org/attachment/ticket/24393/mesa_7.8.1_SnowLepard.txt


/bin/sh ../../../../bin/mklib -o OpenVG -linker '/usr/bin/gcc-4.2 ' -ldflags '' \
		-major 1 \
		-minor 0 \
		-patch 0 \
		-install ../../../../lib \
		api_context.o api_filters.o api_images.o api_masks.o api_misc.o api_paint.o api_params.o api_path.o api_text.o api_transform.o vgu.o vg_context.o vg_state.o vg_tracker.o vg_translate.o polygon.o bezier.o path.o paint.o arc.o image.o renderer.o stroker.o mask.o shader.o shaders_cache.o ../../../../src/gallium/auxiliary/libgallium.a  -lm
mklib: Making Darwin shared library:  libOpenVG.1.0.dylib
Undefined symbols:
  "_util_format_read_4f", referenced from:
      _pipe_tile_raw_to_rgba in libgallium.a(u_tile.o)
  "_util_format_write_4f", referenced from:
      _pipe_put_tile_rgba in libgallium.a(u_tile.o)
  "_util_format_description", referenced from:
      _create_texture in vg_tracker.o
      _create_texture in vg_tracker.o
      __vega_unpack_float_span_rgba in vg_translate.o
      __vega_unpack_float_span_rgba in vg_translate.o
      __vega_unpack_float_span_rgba in vg_translate.o
      __vega_unpack_float_span_rgba in vg_translate.o
      _pipe_put_tile_raw in libgallium.a(u_tile.o)
      _pipe_put_tile_raw in libgallium.a(u_tile.o)
      _pipe_put_tile_raw in libgallium.a(u_tile.o)
      _pipe_get_tile_raw in libgallium.a(u_tile.o)
      _pipe_get_tile_raw in libgallium.a(u_tile.o)
      _pipe_get_tile_raw in libgallium.a(u_tile.o)
      _pipe_tile_raw_to_rgba in libgallium.a(u_tile.o)
      _pipe_tile_raw_to_rgba in libgallium.a(u_tile.o)
      _pipe_tile_raw_to_rgba in libgallium.a(u_tile.o)
      _pipe_get_tile_rgba in libgallium.a(u_tile.o)
      _pipe_get_tile_rgba in libgallium.a(u_tile.o)
      _pipe_get_tile_rgba in libgallium.a(u_tile.o)
      _pipe_get_tile_rgba in libgallium.a(u_tile.o)
      _pipe_get_tile_rgba in libgallium.a(u_tile.o)
      _pipe_put_tile_rgba in libgallium.a(u_tile.o)
      _pipe_put_tile_rgba in libgallium.a(u_tile.o)
      _pipe_put_tile_rgba in libgallium.a(u_tile.o)
      _pipe_put_tile_rgba in libgallium.a(u_tile.o)
      _pipe_put_tile_rgba in libgallium.a(u_tile.o)
      _pipe_put_tile_rgba in libgallium.a(u_tile.o)
      _pipe_put_tile_rgba in libgallium.a(u_tile.o)
      _pipe_put_tile_rgba in libgallium.a(u_tile.o)
      _util_copy_rect in libgallium.a(u_rect.o)
      _util_copy_rect in libgallium.a(u_rect.o)
      _util_copy_rect in libgallium.a(u_rect.o)
      _util_copy_rect in libgallium.a(u_rect.o)
      _util_copy_rect in libgallium.a(u_rect.o)
      _util_fill_rect in libgallium.a(u_rect.o)
      _util_fill_rect in libgallium.a(u_rect.o)
      _util_fill_rect in libgallium.a(u_rect.o)
      _util_fill_rect in libgallium.a(u_rect.o)
      _util_fill_rect in libgallium.a(u_rect.o)
      _util_surface_fill in libgallium.a(u_rect.o)
  "_util_format_write_4ub", referenced from:
      _util_pack_color_ub in vg_translate.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
mklib: Installing libOpenVG.1.0.dylib libOpenVG.1.dylib libOpenVG.dylib in ../../../../lib
mv: rename libOpenVG.1.0.dylib to ../../../../lib/libOpenVG.1.0.dylib: No such file or directory
make[4]: *** [../../../../lib/libOpenVG.so] Error 1
make[3]: *** [subdirs] Error 1
make[2]: *** [default] Error 1
make[1]: *** [subdirs] Error 1
make: *** [default] Error 1

Re: [Mesa3d-dev] gallium-resources branch merge

[Keith W. <ke...@vm...>]

On Tue, 2010-04-06 at 03:28 -0700, Keith Whitwell wrote:
> On Fri, 2010-04-02 at 23:23 -0700, Marek Olšák wrote:
> > There's something fishy in u_upload_mgr, could you please review the
> > first two patches here?
> > http://cgit.freedesktop.org/~mareko/mesa/log/?h=gallium-resources
> > 
> > With this, r300g works again.
> 
> Hmm, I think the second of the patches (flush range relative to mapped
> range vs whole buffer) may be addressing a regression that has creeped
> into the -resources branch regarding this behaviour - ie. I think the
> code you modified was actually correct, but that
> pipe_flush_mapped_buffer_range() has changed to do the wrong thing.
> 
> I'll try and figure out what should be happening.

I've pushed a change which hopefully corrects the behaviour of the
buffer_range inlines.  Can you give it a try?

Keith

[Mesa3d-dev] [Bug 27514] implementation error: Unsupported opcode 79 (TEX) in vertex shader

[<bug...@fr...>]

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

Roland Scheidegger <sr...@vm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Mesa core                   |Drivers/DRI/i965
         AssignedTo|mes...@li...urceforg |er...@an...
                   |e.net                       |

--- Comment #2 from Roland Scheidegger <sr...@vm...> 2010-04-07 07:12:09 PDT ---
This message is coming from the i965 dri driver, which does not implement
vertex texturing.
Unless I'm mistaken though the driver always said it didn't support vertex
texturing (what does glxinfo -l say about number of vertex texture units),
hence this would actually be an application bug if it still tries to use vertex
texturing.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27514] implementation error: Unsupported opcode 79 (TEX) in vertex shader

[<bug...@fr...>]

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

--- Comment #1 from Daniel Oertwig <mus...@go...> 2010-04-07 06:59:26 PDT ---
Mesa package version is 7.7-4ubuntu1

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27514] New: implementation error: Unsupported opcode 79 (TEX) in vertex shader

[<bug...@fr...>]

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

           Summary: implementation error: Unsupported opcode 79 (TEX) in
                    vertex shader
           Product: Mesa
           Version: unspecified
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: mus...@go...


Hi there :)

I just wanted to report a bug (if it is) to you.
It happens on my up to date Ubuntu Lucid 64bit which is running on my laptop
(which is a lenovo ibm thinkpad T500 with intel graphics module i915)

When using the openscenegraph sample application shipped with the distributions
package, i encounter the following error:

osgshaderterrain 
Creating terrain...done.
Mesa 7.7.1-DEVEL implementation error: Unsupported opcode 79 (TEX) in vertex
shader
Please report at bugzilla.freedesktop.org
Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,)
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.


The do_wait line appears with every sample.
The programm does not crash, it just shows the "terrain" which would normally
have shaders applied, but which is now black and with flickering black bars in
z direction (so called "up")

I don't know if that will help you any further, but if you need more
information, here i am ;)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] [PATCH] fix cell build

[Brian P. <bri...@gm...>]

On Tue, Apr 6, 2010 at 3:44 PM, Marc Dietrich <mar...@gm...> wrote:
> From: root <ro...@fb...>
>
> compile fix for cell driver.
> ---
>  src/gallium/drivers/cell/ppu/cell_screen.c  |    3 +++
>  src/gallium/drivers/cell/ppu/cell_texture.c |    2 +-
>  2 files changed, 4 insertions(+), 1 deletions(-)


Applied.  Thanks!

-Brian

Re: [Mesa3d-dev] Current tinderbox regression (swrast_dri)

[Brian P. <bri...@gm...>]

On Tue, Apr 6, 2010 at 8:00 PM, Chris Ball <cj...@la...> wrote:
> http://tinderbox.x.org/builds/2010-04-07-0001/logs/libGL/#build
>
> swrastg_dri.so.tmp: undefined reference to draw_pt_fetch_pipeline_or_emit_llvm
> collect2: ld returned 1 exit status
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae69f9fbf0a1aab7186e5b644085a5fe5aea99af

Should be fixed now.

-Brian

[Mesa3d-dev] Current tinderbox regression (swrast_dri)

[Chris B. <cj...@la...>]

http://tinderbox.x.org/builds/2010-04-07-0001/logs/libGL/#build

swrastg_dri.so.tmp: undefined reference to draw_pt_fetch_pipeline_or_emit_llvm
collect2: ld returned 1 exit status

http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae69f9fbf0a1aab7186e5b644085a5fe5aea99af

-- 
Chris Ball   <cj...@la...>
One Laptop Per Child

[Mesa3d-dev] Mesa 7.8 and 7.7.1 DRI SDK and modular drivers available.

[Luc V. <li...@sk...>]

Hi all,

After having spent a few pleasant hours on an ICE, I made updated DRI 
SDKs available at:

http://cgit.freedesktop.org/~libv/mesa-dri-sdk/

Updated modular dri drivers are available in my 
http://cgit.freedesktop.org/~libv/ repos too, namely at:

http://cgit.freedesktop.org/~libv/mesa-dri-i810
http://cgit.freedesktop.org/~libv/mesa-dri-i9xx
http://cgit.freedesktop.org/~libv/mesa-dri-mach64
http://cgit.freedesktop.org/~libv/mesa-dri-mga
http://cgit.freedesktop.org/~libv/mesa-dri-r128
http://cgit.freedesktop.org/~libv/mesa-dri-radeon
http://cgit.freedesktop.org/~libv/mesa-dri-savage
http://cgit.freedesktop.org/~libv/mesa-dri-sis
http://cgit.freedesktop.org/~libv/mesa-dri-tdfx
http://cgit.freedesktop.org/~libv/mesa-dri-unichrome

There were no changes to the drivers between 7.8 and 7.8.1, and the SDK 
can be just cherry picked it seems. Will spend 5 minutes now on doing 
so.

Luc Verhaegen.