[Mesa-dev] [PATCH] gallium/test/trivial: make it build

2011-06-22 Thread Alon Levy 
Signed-off-by: Alon Levy 
---
 src/gallium/tests/trivial/Makefile   |9 +++--
 src/gallium/tests/trivial/quad-tex.c |4 ++--
 src/gallium/tests/trivial/tri.c  |4 ++--
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/gallium/tests/trivial/Makefile 
b/src/gallium/tests/trivial/Makefile
index 2ed6341..e82 100644
--- a/src/gallium/tests/trivial/Makefile
+++ b/src/gallium/tests/trivial/Makefile
@@ -11,7 +11,12 @@ INCLUDES = \
-I$(TOP)/src/gallium/winsys \
$(PROG_INCLUDES)
 
-LINKS = \
+ifeq ($(MESA_LLVM),1)
+LINKS = $(TOP)/src/gallium/drivers/llvmpipe/libllvmpipe.a
+LDFLAGS += $(LLVM_LDFLAGS)
+endif
+
+LINKS += \
$(TOP)/src/gallium/drivers/rbug/librbug.a \
$(TOP)/src/gallium/drivers/trace/libtrace.a \
$(TOP)/src/gallium/drivers/galahad/libgalahad.a \
@@ -46,4 +51,4 @@ $(OBJECTS): %.o: %.c
$(CC) -c $(INCLUDES) $(CFLAGS) $(DEFINES) $(PROG_DEFINES) $< -o $@
 
 $(PROGS): %: %.o $(LINKS)
-   $(CC) $(LDFLAGS) $< $(LINKS) -lm -lpthread -ldl -o $@
+   $(CC) $(LDFLAGS) $< $(LINKS) $(LLVM_LIBS) -lm -lpthread -ldl -o $@
diff --git a/src/gallium/tests/trivial/quad-tex.c 
b/src/gallium/tests/trivial/quad-tex.c
index 3a64b1c..6c38b10 100644
--- a/src/gallium/tests/trivial/quad-tex.c
+++ b/src/gallium/tests/trivial/quad-tex.c
@@ -212,7 +212,7 @@ static void init_prog(struct program *p)
p->sampler.mag_img_filter = PIPE_TEX_MIPFILTER_LINEAR;
p->sampler.normalized_coords = 1;
 
-   surf_tmpl.format = templat.format;
+   surf_tmpl.format = PIPE_FORMAT_B8G8R8A8_UNORM; /* All drivers support 
this */
surf_tmpl.usage = PIPE_BIND_RENDER_TARGET;
surf_tmpl.u.tex.level = 0;
surf_tmpl.u.tex.first_layer = 0;
@@ -329,7 +329,7 @@ static void draw(struct program *p)
/* vertex element data */
cso_set_vertex_elements(p->cso, 2, p->velem);
 
-   util_draw_vertex_buffer(p->pipe,
+   util_draw_vertex_buffer(p->pipe, p->cso,
p->vbuf, 0,
PIPE_PRIM_QUADS,
4,  /* verts */
diff --git a/src/gallium/tests/trivial/tri.c b/src/gallium/tests/trivial/tri.c
index bfd2f3c..656e92e 100644
--- a/src/gallium/tests/trivial/tri.c
+++ b/src/gallium/tests/trivial/tri.c
@@ -153,7 +153,7 @@ static void init_prog(struct program *p)
p->rasterizer.cull_face = PIPE_FACE_NONE;
p->rasterizer.gl_rasterization_rules = 1;
 
-   surf_tmpl.format = templat.format;
+   surf_tmpl.format = PIPE_FORMAT_B8G8R8A8_UNORM;
surf_tmpl.usage = PIPE_BIND_RENDER_TARGET;
surf_tmpl.u.tex.level = 0;
surf_tmpl.u.tex.first_layer = 0;
@@ -258,7 +258,7 @@ static void draw(struct program *p)
/* vertex element data */
cso_set_vertex_elements(p->cso, 2, p->velem);
 
-   util_draw_vertex_buffer(p->pipe,
+   util_draw_vertex_buffer(p->pipe, p->cso,
p->vbuf, 0,
PIPE_PRIM_TRIANGLES,
3,  /* verts */
-- 
1.7.5.4

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

Re: [Mesa-dev] Status of the GLSL->TGSI translator

2011-06-22 Thread Bryan Cain 
On 06/16/2011 12:43 PM, Brian Paul wrote:
> On 06/16/2011 10:34 AM, Bryan Cain wrote:
>> On Thu, Jun 16, 2011 at 9:08 AM, Brian Paul > > wrote:
>>
>>
>> Looks like nice work, Bryan.
>>
>> Just a few minor questions/comments for now:
>>
>> 1. The st_fragment/vertex/geometry_program structs now have a
>> glsl_to_tgsi field.  I did a grep, but I couldn't find where that
>> field is assigned.  Can you clue me in?
>>
>> It's assigned at the end of the get_mesa_program function in
>> st_glsl_to_tgsi.cpp.
>
> Thanks.  I was using grep glsl_to_tgsi *.[ch]   Duh.
>
>
>> 2. The above mentioned program structs contains an old Mesa
>> instruction program AND/OR(?) a GLSL IR.  Do both types of
>> representations co-exist sometimes?  Perhaps you could update the
>> comments on those structs to explain that.
>>
>> They used to co-exist, because after my first commit, st_glsl_to_tgsi
>> still generated Mesa IR in addition to TGSI.  But I removed the Mesa
>> IR generation in "st/mesa: stop generating Mesa IR in
>> st_glsl_to_tgsi", so now it has either one or the other -
>> glsl_to_tgsi_visitor for GLSL shaders, Mesa IR programs for everything
>> else.
>
> OK, can you update the comments with this info?
>
>
>> 3. Kind of a follow-on: for glDrawPixels and glBitmap we take the
>> original program code (in Mesa form) and prepend extra
>> instructions for fetching the fragment color or doing the fragment
>> kill.  Do we always have the Mesa instructions for this?  It seems
>> we don't normally want to generate Mesa instructions all the time
>> but we still need them sometimes.
>>
>> No, I didn't realize Mesa did that, and we don't have the Mesa
>> instructions for GLSL programs anymore.  I'm not sure what the
>> right way to handle that is.
>
> How hard would it be to edit the IR to insert the extra operations?
>
> For glBitmaps it's basically sample a texture and then do a
> conditional fragment kill.  For glDrawPixels we need to sample the
> texture representing the image, then apply the pixel transfer ops
> (scale/bias, table lookup, etc).  We generate the code for that in
> st_atom_pixeltransfer.c.  That program is then concatenated with the
> current fragment program with _mesa_combine_program().
>
> If we ever propogate GLSL IR through the gallium interface there's
> lots of places where we'll need to do other kinds of IR editing.
>
> -Brian
>

I've been working on this for the last few days, but there are some
things I still haven't figured out yet.

I've written a function to generate the shader for
glDrawPixels/glCopyPixels in the form of glsl_to_tgsi_instructions, and
I doubt I'll have any problems writing the code to merge those
instructions with an existing shader.However, for the shader to work
correctly, I need to set stfp->glsl_to_tgsi in st_fragment_program, but
all of the fragment program variables in st_atom_pixeltransfer.c and
st_cb_drawpixels.c have the type gl_program or gl_fragment_program. 
When do these become st_fragment_program so they can be processed in
st_program.c?  Will I need to move the glsl_to_tgsi attribute into
gl_fragment program and give it a name not specific to the state tracker?

My other question is that if I don't have this part done before the
merge window closes, would it still be possible to merge the GLSL->TGSI
translator for 7.11 tomorrow or Friday, and for me to fix the
glBitmap/glDrawPixels/glCopyPixels issue in the stable branch before
Mesa 7.11 is released?  It's the only remaining issue I know of with the
GLSL->TGSI translator, and even it's something of a corner case.

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

Re: [Mesa-dev] [PATCH] linker: Reject shaders that use too many varyings

2011-06-22 Thread Alex Deucher 
On Wed, Jun 22, 2011 at 10:12 PM, Roland Scheidegger  wrote:
> Am 21.06.2011 20:59, schrieb Sven Arvidsson:
>> This change broke a whole lot of stuff on r600g, for example Unigine
>> Heaven:
>>
>>       shader uses too many varying components (36 > 32)
>
> It looks like the r600g driver claims to only support 10 varyings, which
> the state tracker reduces to 8 (as it subtracts the supposedly included
> color varyings).
> At first sight I can't quite see why it's limited to 10, all r600 chips
> should be able to handle 32 (dx10 requirement) but of course the driver
> might not (mesa itself is limited to 16 it seems). If it worked just
> fine before that suggests it indeed works just fine with more...
> Someone more familiar with the driver should be able to tell if it's
> safe to increase the limit to 32 (the state tracker will cap it to 16).

The hardware definitely supports 32.  I'm not sure why it's currently
set to 10; I don't see any limitations in the code off hand.

Alex

>
> Roland
> ___
> 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 0/8] GBM Graphics Buffer Manager

2011-06-22 Thread Chia-I Wu 
On Wed, Jun 22, 2011 at 10:30 PM, Benjamin Franzke
 wrote:
> Hi List,
>
> This series adds a graphics buffer management library which is
> targeted to be used as native (drm) platform for egl on kms or openwfd,
> and thus replaces the current mechanism of using a fd as EGLNativeDisplay
> and EGL_MESA_drm_image to create buffers.
> GBM uses the mesas internal dri interface or acts as a gallium state tracker.
>
> The mapping to EGL types is:
>
> gbm_device - EGLNativeDisplayType
> gbm_bo     - EGLNativePixmapType / EGL_NATIVE_PIXMAP_KHR
>
> This integrates better with the idea of EGL, which assumes there is
> some kind of native library thats responsible for allocating buffers.
>
> We wanted to use libkms, but since that's explicitly designed to no
> support hw renderable buffers we have to go a different route.
The idea looks good to me in general.  But would it make sense to
replace st/gbm and targets/gdm by another backend that uses st/xa,
which is supposed to have a stable ABI, instead (currently only on
xa_branch)?
>
> Benjamin Franzke (8):
>  dri: Add dupImage to DRIimageExtension
>  intel: Implement DRIimageExtension::dupImage
>  st/dri: Implement DRIimageExtension::dupImage
>  Add gbm (generic/graphics buffer manager)
>  gbm: Add dri backend
>  gbm: Add gallium (drm) backend
>  egl_dri2: Hookup gbm as drm platform
>  st/egl: Hookup gbm for drm backend
>
>  Makefile                                           |   11 +
>  configs/autoconf.in                                |   10 +-
>  configs/default                                    |   14 +-
>  configure.ac                                       |   70 
>  include/EGL/eglplatform.h                          |    6 +
>  include/GL/internal/dri_interface.h                |    2 +
>  src/egl/drivers/dri2/Makefile                      |    2 +
>  src/egl/drivers/dri2/egl_dri2.c                    |   76 +++--
>  src/egl/drivers/dri2/egl_dri2.h                    |   11 +
>  src/egl/drivers/dri2/platform_drm.c                |   99 --
>  src/egl/main/Makefile                              |    4 +
>  src/gallium/state_trackers/dri/drm/dri2.c          |   19 +
>  src/gallium/state_trackers/egl/Makefile            |    3 +-
>  src/gallium/state_trackers/egl/common/egl_g3d.c    |   18 +-
>  src/gallium/state_trackers/egl/common/native.h     |    3 +
>  src/gallium/state_trackers/egl/drm/modeset.c       |   36 ++
>  src/gallium/state_trackers/egl/drm/native_drm.c    |   77 ++---
>  src/gallium/state_trackers/egl/drm/native_drm.h    |    4 +
>  src/gallium/state_trackers/gbm/Makefile            |   46 +++
>  src/gallium/state_trackers/gbm/gbm_drm.c           |  225 
>  .../state_trackers/gbm/gbm_gallium_drmint.h        |   74 
>  src/gallium/targets/egl/Makefile                   |    2 +-
>  src/gallium/targets/gbm/Makefile                   |   32 ++
>  src/gallium/targets/gbm/gbm.c                      |   61 
>  src/gallium/targets/gbm/pipe_loader.c              |  192 ++
>  src/gallium/targets/gbm/pipe_loader.h              |   48 +++
>  src/gbm/Makefile                                   |   14 +
>  src/gbm/backends/Makefile                          |   14 +
>  src/gbm/backends/Makefile.template                 |   65 
>  src/gbm/backends/dri/Makefile                      |   22 ++
>  src/gbm/backends/dri/driver_name.c                 |   89 +
>  src/gbm/backends/dri/gbm_dri.c                     |  377 
> 
>  src/gbm/backends/dri/gbm_driint.h                  |   78 
>  src/gbm/main/Makefile                              |   90 +
>  src/gbm/main/backend.c                             |  128 +++
>  src/gbm/main/backend.h                             |   36 ++
>  src/gbm/main/common.c                              |   88 +
>  src/gbm/main/common.h                              |   42 +++
>  src/gbm/main/common_drm.h                          |   48 +++
>  src/gbm/main/gbm.c                                 |  189 ++
>  src/gbm/main/gbm.h                                 |   99 +
>  src/gbm/main/gbm.pc.in                             |   12 +
>  src/gbm/main/gbmint.h                              |   81 +
>  src/mesa/drivers/dri/intel/intel_screen.c          |   27 ++-
>  44 files changed, 2536 insertions(+), 108 deletions(-)
>  create mode 100644 src/gallium/state_trackers/gbm/Makefile
>  create mode 100644 src/gallium/state_trackers/gbm/gbm_drm.c
>  create mode 100644 src/gallium/state_trackers/gbm/gbm_gallium_drmint.h
>  create mode 100644 src/gallium/targets/gbm/Makefile
>  create mode 100644 src/gallium/targets/gbm/gbm.c
>  create mode 100644 src/gallium/targets/gbm/pipe_loader.c
>  create mode 100644 src/gallium/targets/gbm/pipe_loader.h
>  create mode 100644 src/gbm/Makefile
>  create mode 100644 src/gbm/backends/Makefile
>  create mode 100644 src/gbm/backends/Makefile.template
>  create mode 100644 src/gbm/backends/dri/Makefile
>  create mode 100644 src/gbm/backends/dr

Re: [Mesa-dev] [PATCH] linker: Reject shaders that use too many varyings

2011-06-22 Thread Roland Scheidegger 
Am 21.06.2011 20:59, schrieb Sven Arvidsson:
> This change broke a whole lot of stuff on r600g, for example Unigine
> Heaven:
> 
>   shader uses too many varying components (36 > 32)

It looks like the r600g driver claims to only support 10 varyings, which
the state tracker reduces to 8 (as it subtracts the supposedly included
color varyings).
At first sight I can't quite see why it's limited to 10, all r600 chips
should be able to handle 32 (dx10 requirement) but of course the driver
might not (mesa itself is limited to 16 it seems). If it worked just
fine before that suggests it indeed works just fine with more...
Someone more familiar with the driver should be able to tell if it's
safe to increase the limit to 32 (the state tracker will cap it to 16).

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

Re: [Mesa-dev] Error building on Windows with SCons

2011-06-22 Thread Campbell Barton 
Thanks Jose,
Mesa builds without trouble for me on Linux and windows (in a VM),

Would be good if this was mentioned in windows build instructions, or
mesa files updated to be a full GIT export, nevertheless its great to
have this working.

On Wed, Jun 22, 2011 at 2:15 PM, Jose Fonseca  wrote:
>
>
> - Original Message -
>> Jose, I don't understand your reply,
>> - Is there some way to add the def file or some way to generate them?
>> - Is building with scons on MingW with windows something that is
>> supposed to work?
>> - Is this issue going to be fixed or is this configuration
>> unsupported?
>> - Is there some way to build with MingW on windows with make? - You
>> reference makefiles however I don't think these are used for scons
>> builds.
>
> What I'm trying to say is, the official Mesa source tarballs are missing many 
> files necessary for windows builds.  Please try the git source code, or, if 
> you prefer, a tarball with all the source in git, e.g. 
> http://cgit.freedesktop.org/mesa/mesa/snapshot/mesa-7.10.3.zip
>
>> Or perhaps a better question is is it possible at the moment to build
>> mesa on windows?
>> What are known working configurations?
>
> Known working configurations (from git!) are:
> - mingw crosscompilation from linux (x86 only)
> - MSVC 2008 (requires cygwin flex & bison in the PATH), x86 or x64
> I have these continuously running on Jenkins (previously known as Hudson) 
> from git.
>
> I haven't tried Mingw on Windows. But it should work without problems with 
> MSYS.
>
>> I tried with scons because the docs suggest using scons on mesa's
>> page.
>
> Yep. There's no other way to build for windows besides scons.
>
>>
>> - Campbell
>
> Jose
>
>> On Mon, Jun 20, 2011 at 1:18 PM, Jose Fonseca 
>> wrote:
>> > Probably it's missing the .def files too...
>> >
>> > I think that instead of manually listing source files in
>> > mesa/Makefile we should invoke 'git ls-files' (and maybe manually
>> > list any exclusions).
>> >
>> > Splitting out Mesa GLUT from the source tree would make things much
>> > easier. Which is probably a sensible thing to do anyway, given
>> > that there are no glut dependencies in Mesa, and most people are
>> > using freeglut anyway.
>> >
>> > Would anybody see any problem with that?
>> >
>> > Jose
>> >
>> > - Original Message -
>> >> Hi There, Im trying to build Mesa so we can distribute it with
>> >> Blender3D on Windows (we already do this on Linux).
>> >>
>> >> But I have have been unsable to build mesa 7.10.3
>> >>  (Latest MingW XP, tested python 2.5, 2.7)
>> >>
>> >> Simply running 'm;\python25\Scripts\scons.bat'
>> >> I always get this error:
>> >> # --- snip
>> >> scons: Reading SConscript files ...
>> >>
>> >> scons: warning: Ignoring missing SConscript
>> >> 'build\windows-x86-debug\glut\glx\SConscript'
>> >> File "M:\Mesa-7.10.3\src\SConscript", line 13, in 
>> >> warning: LLVM disabled: not building llvmpipe
>> >> scons: done reading SConscript files.
>> >> scons: Building targets ...
>> >> scons: ***
>> >> [build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll]
>> >> Source `src\gallium\state_trackers\wgl\opengl32.def' not found,
>> >> needed
>> >> by target
>> >> `build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll'.
>> >> scons: building terminated because of errors.
>> >> # --- snip
>> >>
>> >> So I copied: src\mesa\drivers\windows\gldirect\opengl32.def
>> >>
>> >> But then I get this error:
>> >>
>> >> # --- snip
>> >> scons: Reading SConscript files ...
>> >> warning: LLVM disabled: not building llvmpipe
>> >> scons: done reading SConscript files.
>> >> scons: Building targets ...
>> >> link /nologo /fixed:no /incremental:no /dll
>> >> /out:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll
>> >> build\windows-x86-debug\gallium\state_trackers\wgl\wgl.lib
>> >> build\windows-x86-debug\gallium\winsys\sw\gdi\ws_gdi.lib
>> >> build\windows-x86-debug\mapi\glapi\glapi.lib
>> >> build\windows-x86-debug\mesa\mesa.lib
>> >> build\windows-x86-debug\gallium\drivers\softpipe\softpipe.lib
>> >> build\windows-x86-debug\gallium\drivers\trace\trace.lib
>> >> build\windows-x86-debug\gallium\drivers\rbug\rbug.lib
>> >> build\windows-x86-debug\gallium\auxiliary\gallium.lib
>> >> build\windows-x86-debug\glsl\glsl.lib gdi32.lib user32.lib
>> >> kernel32.lib ws2_32.lib
>> >> /PDB:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.pdb
>> >> /DEBUG
>> >> build\windows-x86-debug\gallium\targets\libgl-gdi\libgl_gdi.obj
>> >> /def:src\gallium\state_trackers\wgl\opengl32.def
>> >> src\gallium\state_trackers\wgl\opengl32.def(37) : warning LNK4017:
>> >> DESCRIPTION statement not supported for the target platform;
>> >> ignored
>> >> opengl32.def : error LNK2001: unresolved external symbol
>> >> glColorSubTableEXT
>> >> build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.lib :
>> >> fatal
>> >> error LNK1120: 1 unresolved externals
>> >> scons: building terminated because of errors.
>> >> # --- snip
>> >>
>> >>
>

Re: [Mesa-dev] multiple versions in version string

2011-06-22 Thread tom fogal 
Ian Romanick  writes:
> On 06/21/2011 10:58 AM, tom fogal wrote:
> > Michel D=C3=A4nzer  writes:
>  It should work fine with Xvfb or any other X server, using any
>  kind of display connection.
> >>>
> >>> This thread started because Xvfb isn't offering what I need: GL
> >>> 2.0.
> >>
> >> Because you're using indirect rendering.
> >
> > Yes.  That's the point, I /can't/ get direct rendering with Xvfb.
>
> What Michel means is you can build a software version of Mesa that
> just draws into a pixmap.  It's not indirect GLX, and it's not direct
> rendering either.  This is --with-driver=xlib, IIRC.

But that library still requires an X server, no?  And I can't get Xvfb
to use that library unless I custom compile Xvfb, right?

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

Re: [Mesa-dev] multiple versions in version string

2011-06-22 Thread Ian Romanick 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/21/2011 10:58 AM, tom fogal wrote:
> Michel Dänzer  writes:
>> On Die, 2011-06-21 at 10:34 -0600, tom fogal wrote:=20
>>> On 06/21/2011 10:23 AM, Michel D=C3=A4nzer wrote:
 On Die, 2011-06-21 at 10:10 -0600, tom fogal wrote:
> On 06/21/2011 01:06 AM, Michel D=C3=A4nzer wrote:
>> On Mon, 2011-06-20 at 13:46 -0600, tom fogal wrote:
>>> Nathan Kidd   writes:
 On 11-06-20 02:55 PM, tom fogal wrote:
> You are correct, rendering is indirect!

 Of course, for indirect rendering every glFoo() function call
 needs to be mapped to (GL)X protocol.  Protocol exists up to
 OpenGL 1.4.
>>>
>>> I can always fall back to OSMesa, I suppose :(
>>
>> Or a software rasterizer libGL / driver which uses direct
>> rendering. Preferably using llvmpipe for performance.
>
> It was hidden in another part of the thread, but I actually
> don't care (much) about performance, as this is for a regression
> testing system.

 Then you have free choice between llvmpipe or just softpipe (can
 be chosen at runtime), or even classic swrast.
>>>
>>> Yep.  I have used swrast with great effect in the past.
>>>
>>> Gallium and OSMesa currently don't mix, though Brian has mentioned
>>> once or twice that it wouldn't be /too/ hard to bring up.
>>
>> Does GLX indirect rendering 'mix' with OSMesa at all? If not, why are
>> you bringing this up? :)
> 
> No; OSMesa stands in place of GLX, of course.
> 
> I mentioned they don't mix because you implied I could try using
> llvmpipe or softpipe.  In reality, the only option for a standalone RTS
> that needs GL2.0 is swrast/OSMesa.
> 
 It should work fine with Xvfb or any other X server, using any
 kind of display connection.
>>>
>>> This thread started because Xvfb isn't offering what I need: GL
>>> 2.0.
>>
>> Because you're using indirect rendering.
> 
> Yes.  That's the point, I /can't/ get direct rendering with Xvfb.

What Michel means is you can build a software version of Mesa that just
draws into a pixmap.  It's not indirect GLX, and it's not direct
rendering either.  This is --with-driver=xlib, IIRC.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4CdAwACgkQX1gOwKyEAw+/DACfd278qm5plyLbPK9Hhn7QAJ1t
xnsAnRVoncK6GSz8LyTBVvrduvUSl+6I
=TTDp
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] explaining update_arrays

2011-06-22 Thread Brian Paul 

On 06/22/2011 02:36 PM, Dave Airlie wrote:



By the looks of it the 0/POS attrib + the overlapping/16-31 ones check
_Current
and the others all check _Enabled, to me it would make some sense at
least if 0
was consistent with the others, but maybe someone knows what is correct.


The confusion probably goes all the way back to the ARB's unfortunate
inability to reconcile NV's vs. ATI's different handling of generic
vertex arrays.  NV used aliasing while ATI didn't so the ARB extension
made it optional (a mess).  Plus, I think there was some minor
difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t.
generic vertex arrays.


In GLSL, only attribute 0 / glVertexArray alias.  The other non-generic
arrays can only be accessed via the named built-in variables (e.g.,
gl_Color).


Ah that makes sense, thanks guys,




Do you suspect a bug here?


No but this codepath is a real dog on profiles, and I'm guessing 90%
of it useless in 90% of profiles,
like in an app that doesn't use VBOs it pretty much could end up as
min = 2*1000*1000*1000; but
to figure that out it has a lot overhead. I'm guessing we should
probably push working out the array max
closer to the edges and not in this path if we can.


Agreed.  I'd like to get rid of that code.  If we can push the 
responsbility of not fetching vertex data from out of bounds down into 
the drivers, that would simplify core Mesa.


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

Re: [Mesa-dev] explaining update_arrays

2011-06-22 Thread Dave Airlie 
>>
>>> By the looks of it the 0/POS attrib + the overlapping/16-31 ones check
>>> _Current
>>> and the others all check _Enabled, to me it would make some sense at
>>> least if 0
>>> was consistent with the others, but maybe someone knows what is correct.
>>
>> The confusion probably goes all the way back to the ARB's unfortunate
>> inability to reconcile NV's vs. ATI's different handling of generic
>> vertex arrays.  NV used aliasing while ATI didn't so the ARB extension
>> made it optional (a mess).  Plus, I think there was some minor
>> difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t.
>> generic vertex arrays.
>
> In GLSL, only attribute 0 / glVertexArray alias.  The other non-generic
> arrays can only be accessed via the named built-in variables (e.g.,
> gl_Color).

Ah that makes sense, thanks guys,

>
>> Do you suspect a bug here?

No but this codepath is a real dog on profiles, and I'm guessing 90%
of it useless in 90% of profiles,
like in an app that doesn't use VBOs it pretty much could end up as
min = 2*1000*1000*1000; but
to figure that out it has a lot overhead. I'm guessing we should
probably push working out the array max
closer to the edges and not in this path if we can.

So I had to make sure I understood it before I try to change it.

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

Re: [Mesa-dev] [PATCH] configure.ac: Make --without-gallium-drivers work as expected

2011-06-22 Thread Ian Romanick 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/22/2011 12:55 PM, Dan Nicholson wrote:
> On Wed, Jun 22, 2011 at 11:38 AM, Ian Romanick  wrote:
>> From: Ian Romanick 
>>
>> ---
>>  configure.ac |6 ++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index c9dd8a7..76736c0 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -562,6 +562,12 @@ AC_ARG_WITH([gallium-drivers],
>> [with_gallium_drivers="$withval"],
>> [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
>>
>> +# Doing '--without-gallium-drivers' will set this variable to 'no'.  Clear 
>> it
>> +# here so that the script doesn't choke on an unknown driver name later.
>> +if test "x$with_gallium_drivers" = "xno"; then
>> +   with_gallium_drivers=''
>> +fi
> 
> Nitpicky, but the other thing that would be nice is if bare
> --with-gallium-drivers becomes $GALLIUM_DRIVERS_DEFAULT. Could be:
> 
> case "$with_gallium_drivers" in
> yes) with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT" ;;
> no) with_gallium_drivers='' ;;
> esac
> 
> Either way, good to catch this case.

I like that better.

> Reviewed-by: Dan Nicholson 

When I take your change, I'll make this S-o-b, okay?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4CT34ACgkQX1gOwKyEAw+YIgCcCx5q6ZQtxb9ZiDJqQlCG8BxT
ZJ4An1XQHar9yFL6kNk8NGdDbLYpN6wM
=TXc0
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] configure.ac: Make --without-gallium-drivers work as expected

2011-06-22 Thread Dan Nicholson 
On Wed, Jun 22, 2011 at 11:38 AM, Ian Romanick  wrote:
> From: Ian Romanick 
>
> ---
>  configure.ac |    6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index c9dd8a7..76736c0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -562,6 +562,12 @@ AC_ARG_WITH([gallium-drivers],
>     [with_gallium_drivers="$withval"],
>     [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
>
> +# Doing '--without-gallium-drivers' will set this variable to 'no'.  Clear it
> +# here so that the script doesn't choke on an unknown driver name later.
> +if test "x$with_gallium_drivers" = "xno"; then
> +   with_gallium_drivers=''
> +fi

Nitpicky, but the other thing that would be nice is if bare
--with-gallium-drivers becomes $GALLIUM_DRIVERS_DEFAULT. Could be:

case "$with_gallium_drivers" in
yes) with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT" ;;
no) with_gallium_drivers='' ;;
esac

Either way, good to catch this case.

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

Re: [Mesa-dev] [PATCH 3/4] i965: Don't bother telling swrast_setup about state updates until fallback.

2011-06-22 Thread Ian Romanick 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/22/2011 11:53 AM, Eric Anholt wrote:
> On Wed, 22 Jun 2011 10:59:37 -0700, Ian Romanick  wrote:
>>> diff --git a/src/mesa/drivers/dri/intel/intel_context.c 
>>> b/src/mesa/drivers/dri/intel/intel_context.c
>>> index 8b95444..70aee52 100644
>>> --- a/src/mesa/drivers/dri/intel/intel_context.c
>>> +++ b/src/mesa/drivers/dri/intel/intel_context.c
>>> @@ -504,7 +504,6 @@ intelInvalidateState(struct gl_context * ctx, GLuint 
>>> new_state)
>>>  struct intel_context *intel = intel_context(ctx);
>>>  
>>> _swrast_InvalidateState(ctx, new_state);
>>
>> Should this also get moved?  I guess I'm not sure what these two
>> functions do, so this may be a spurious comment.
> 
> swrast has some internal stuff to mitigate the statechange overhead (if
> you haven't swrasted in a while, it replaces its function pointer with a
> stub, and when you go to use it it notices that it's been stubbed out
> and assumes all state has changed).  Because of that,
> swrast_InvalidateState ended up being <.1% CPU usage.  It's tempting to
> move it out even still, but I think if we do then we'd need to
> _swrast_Wakeup anywhere that we call into swrast.

That makes sense.

For the series:

Reviewed-by: Ian Romanick 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4CO8gACgkQX1gOwKyEAw+ZOQCeLR7GTmwNB8JaSq8Tz0AgB3U7
gjgAn07vHoNq/Yc99brndnwSp+aa0BIj
=E2KO
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 3/4] i965: Don't bother telling swrast_setup about state updates until fallback.

2011-06-22 Thread Eric Anholt 
On Wed, 22 Jun 2011 10:59:37 -0700, Ian Romanick  wrote:
> > diff --git a/src/mesa/drivers/dri/intel/intel_context.c 
> > b/src/mesa/drivers/dri/intel/intel_context.c
> > index 8b95444..70aee52 100644
> > --- a/src/mesa/drivers/dri/intel/intel_context.c
> > +++ b/src/mesa/drivers/dri/intel/intel_context.c
> > @@ -504,7 +504,6 @@ intelInvalidateState(struct gl_context * ctx, GLuint 
> > new_state)
> >  struct intel_context *intel = intel_context(ctx);
> >  
> > _swrast_InvalidateState(ctx, new_state);
> 
> Should this also get moved?  I guess I'm not sure what these two
> functions do, so this may be a spurious comment.

swrast has some internal stuff to mitigate the statechange overhead (if
you haven't swrasted in a while, it replaces its function pointer with a
stub, and when you go to use it it notices that it's been stubbed out
and assumes all state has changed).  Because of that,
swrast_InvalidateState ended up being <.1% CPU usage.  It's tempting to
move it out even still, but I think if we do then we'd need to
_swrast_Wakeup anywhere that we call into swrast.


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

[Mesa-dev] [PATCH] configure.ac: Make --without-gallium-drivers work as expected

2011-06-22 Thread Ian Romanick 
From: Ian Romanick 

---
 configure.ac |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index c9dd8a7..76736c0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -562,6 +562,12 @@ AC_ARG_WITH([gallium-drivers],
 [with_gallium_drivers="$withval"],
 [with_gallium_drivers="$GALLIUM_DRIVERS_DEFAULT"])
 
+# Doing '--without-gallium-drivers' will set this variable to 'no'.  Clear it
+# here so that the script doesn't choke on an unknown driver name later.
+if test "x$with_gallium_drivers" = "xno"; then
+   with_gallium_drivers=''
+fi
+
 if test "x$enable_opengl" = xno -a \
 "x$enable_gles1" = xno -a \
 "x$enable_gles2" = xno -a \
-- 
1.7.5.4

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

[Mesa-dev] [PATCH] glsl: Fix depth unbalancing problem in if-statement flattening

2011-06-22 Thread Ian Romanick 
From: Ian Romanick 

Previously, if max_depth were 1, the following code would see the
first if-statement (correctly) not get flattened, but the second
if-statement would (incorrectly) get flattened:

void main()
{
if (a)
gl_Position = vec4(0);

if (b)
gl_Position = vec4(1);
}

This is because the visit_leave(ir_if*) method would not decrement the
depth before returning on the first if-statement.

NOTE: This is a candidate for the 7.10 branch.
---
 src/glsl/lower_if_to_cond_assign.cpp |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/src/glsl/lower_if_to_cond_assign.cpp 
b/src/glsl/lower_if_to_cond_assign.cpp
index e3a1065..b637eb4 100644
--- a/src/glsl/lower_if_to_cond_assign.cpp
+++ b/src/glsl/lower_if_to_cond_assign.cpp
@@ -149,11 +149,9 @@ ir_visitor_status
 ir_if_to_cond_assign_visitor::visit_leave(ir_if *ir)
 {
/* Only flatten when beyond the GPU's maximum supported nesting depth. */
-   if (this->depth <= this->max_depth)
+   if (this->depth-- <= this->max_depth)
   return visit_continue;
 
-   this->depth--;
-
bool found_control_flow = false;
ir_variable *cond_var;
ir_assignment *assign;
-- 
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 3/4] i965: Don't bother telling swrast_setup about state updates until fallback.

2011-06-22 Thread Ian Romanick 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/21/2011 06:34 PM, Eric Anholt wrote:
> ---
>  src/mesa/drivers/dri/i915/i830_vtbl.c  |2 ++
>  src/mesa/drivers/dri/i915/i915_vtbl.c  |2 ++
>  src/mesa/drivers/dri/intel/intel_context.c |1 -
>  3 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/src/mesa/drivers/dri/i915/i830_vtbl.c 
> b/src/mesa/drivers/dri/i915/i830_vtbl.c
> index 16c7aca..584df82 100644
> --- a/src/mesa/drivers/dri/i915/i830_vtbl.c
> +++ b/src/mesa/drivers/dri/i915/i830_vtbl.c
> @@ -34,6 +34,7 @@
>  #include "tnl/tnl.h"
>  #include "tnl/t_context.h"
>  #include "tnl/t_vertex.h"
> +#include "swrast_setup/swrast_setup.h"
>  
>  #define FILE_DEBUG_FLAG DEBUG_STATE
>  
> @@ -718,6 +719,7 @@ i830_invalidate_state(struct intel_context *intel, GLuint 
> new_state)
>  {
> struct gl_context *ctx = &intel->ctx;
>  
> +   _swsetup_InvalidateState(ctx, new_state);
> _tnl_InvalidateState(ctx, new_state);
> _tnl_invalidate_vertex_state(ctx, new_state);
>  
> diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c 
> b/src/mesa/drivers/dri/i915/i915_vtbl.c
> index 6383cda..9721a1c 100644
> --- a/src/mesa/drivers/dri/i915/i915_vtbl.c
> +++ b/src/mesa/drivers/dri/i915/i915_vtbl.c
> @@ -36,6 +36,7 @@
>  #include "tnl/tnl.h"
>  #include "tnl/t_context.h"
>  #include "tnl/t_vertex.h"
> +#include "swrast_setup/swrast_setup.h"
>  
>  #include "intel_batchbuffer.h"
>  #include "intel_regions.h"
> @@ -709,6 +710,7 @@ i915_invalidate_state(struct intel_context *intel, GLuint 
> new_state)
>  {
> struct gl_context *ctx = &intel->ctx;
>  
> +   _swsetup_InvalidateState(ctx, new_state);
> _tnl_InvalidateState(ctx, new_state);
> _tnl_invalidate_vertex_state(ctx, new_state);
>  }
> diff --git a/src/mesa/drivers/dri/intel/intel_context.c 
> b/src/mesa/drivers/dri/intel/intel_context.c
> index 8b95444..70aee52 100644
> --- a/src/mesa/drivers/dri/intel/intel_context.c
> +++ b/src/mesa/drivers/dri/intel/intel_context.c
> @@ -504,7 +504,6 @@ intelInvalidateState(struct gl_context * ctx, GLuint 
> new_state)
>  struct intel_context *intel = intel_context(ctx);
>  
> _swrast_InvalidateState(ctx, new_state);

Should this also get moved?  I guess I'm not sure what these two
functions do, so this may be a spurious comment.

> -   _swsetup_InvalidateState(ctx, new_state);
> _vbo_InvalidateState(ctx, new_state);
>  
> intel->NewGLState |= new_state;

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4CLYkACgkQX1gOwKyEAw+XfwCeOhS/nmOZPhtXcpR6jDiiZ55q
Xg0AniKKUb1T2ljv9dd+PE7P+BJp7k0X
=DOW0
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] explaining update_arrays

2011-06-22 Thread Ian Romanick 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/22/2011 07:11 AM, Brian Paul wrote:
> On 06/22/2011 04:18 AM, Dave Airlie wrote:
>> I don't suppose anyone could contribute a comment on why somethings
>> check ctx->VertexProgram._Current,
>> and others check ctx->VertexProgram._Enabled
> 
> The former may point to a GLSL shader/program, a
> GL_NV/ARB_vertex_program program or a shader derived from fixed-function
> state.
> 
> The later will only be true when a GL_NV/ARB_vertex_program program is
> enabled and valid (GL_VERTEX_PROGRAM_ARB is enabled and the user's
> program compiled successfully).
> 
> I haven't looked at all the places where _Enabled or _Current is used,
> but there is a difference in what they mean.
> 
> 
>> By the looks of it the 0/POS attrib + the overlapping/16-31 ones check
>> _Current
>> and the others all check _Enabled, to me it would make some sense at
>> least if 0
>> was consistent with the others, but maybe someone knows what is correct.
> 
> The confusion probably goes all the way back to the ARB's unfortunate
> inability to reconcile NV's vs. ATI's different handling of generic
> vertex arrays.  NV used aliasing while ATI didn't so the ARB extension
> made it optional (a mess).  Plus, I think there was some minor
> difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t.
> generic vertex arrays.

In GLSL, only attribute 0 / glVertexArray alias.  The other non-generic
arrays can only be accessed via the named built-in variables (e.g.,
gl_Color).

> Do you suspect a bug here?
> 
> I'd have to go back and re-read all the specs to remember the details.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4CLO8ACgkQX1gOwKyEAw+XiQCePgPOdtT6VC/M8wS7iy9zAdOG
mg0An3JeD0IMvXQEf456jx8CKNlx0bjF
=rXOl
-END PGP SIGNATURE-
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] explaining update_arrays

2011-06-22 Thread Brian Paul 

On 06/22/2011 08:20 AM, Roland Scheidegger wrote:

Am 22.06.2011 16:11, schrieb Brian Paul:

On 06/22/2011 04:18 AM, Dave Airlie wrote:

I don't suppose anyone could contribute a comment on why somethings
check ctx->VertexProgram._Current,
and others check ctx->VertexProgram._Enabled


The former may point to a GLSL shader/program, a
GL_NV/ARB_vertex_program program or a shader derived from fixed-function
state.

The later will only be true when a GL_NV/ARB_vertex_program program is
enabled and valid (GL_VERTEX_PROGRAM_ARB is enabled and the user's
program compiled successfully).

I haven't looked at all the places where _Enabled or _Current is used,
but there is a difference in what they mean.



By the looks of it the 0/POS attrib + the overlapping/16-31 ones check
_Current
and the others all check _Enabled, to me it would make some sense at
least if 0
was consistent with the others, but maybe someone knows what is correct.


The confusion probably goes all the way back to the ARB's unfortunate
inability to reconcile NV's vs. ATI's different handling of generic
vertex arrays.  NV used aliasing while ATI didn't so the ARB extension
made it optional (a mess).  Plus, I think there was some minor
difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t.
generic vertex arrays.


Wasn't the difference just that ARB_vertex_shader made it non-aliasing
instead of undefined aliasing, or was there more to it...


That's true, but then generic array[0] seems special.  It's not truly 
generic because it seems to override the legacy GL_VERTEX_ARRAY 
pointer.  But the spec seems to only indicate this in the 
ArrayElement() pseudo code.  The spec does explicitly say that 
glVertexAttrib(0,foo) is equivalent to glVertex(foo).


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

Re: [Mesa-dev] explaining update_arrays

2011-06-22 Thread Roland Scheidegger 
Am 22.06.2011 16:11, schrieb Brian Paul:
> On 06/22/2011 04:18 AM, Dave Airlie wrote:
>> I don't suppose anyone could contribute a comment on why somethings
>> check ctx->VertexProgram._Current,
>> and others check ctx->VertexProgram._Enabled
> 
> The former may point to a GLSL shader/program, a
> GL_NV/ARB_vertex_program program or a shader derived from fixed-function
> state.
> 
> The later will only be true when a GL_NV/ARB_vertex_program program is
> enabled and valid (GL_VERTEX_PROGRAM_ARB is enabled and the user's
> program compiled successfully).
> 
> I haven't looked at all the places where _Enabled or _Current is used,
> but there is a difference in what they mean.
> 
> 
>> By the looks of it the 0/POS attrib + the overlapping/16-31 ones check
>> _Current
>> and the others all check _Enabled, to me it would make some sense at
>> least if 0
>> was consistent with the others, but maybe someone knows what is correct.
> 
> The confusion probably goes all the way back to the ARB's unfortunate
> inability to reconcile NV's vs. ATI's different handling of generic
> vertex arrays.  NV used aliasing while ATI didn't so the ARB extension
> made it optional (a mess).  Plus, I think there was some minor
> difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t.
> generic vertex arrays.

Wasn't the difference just that ARB_vertex_shader made it non-aliasing
instead of undefined aliasing, or was there more to it...

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

Re: [Mesa-dev] Error building on Windows with SCons

2011-06-22 Thread Jose Fonseca 


- Original Message -
> Jose, I don't understand your reply,
> - Is there some way to add the def file or some way to generate them?
> - Is building with scons on MingW with windows something that is
> supposed to work?
> - Is this issue going to be fixed or is this configuration
> unsupported?
> - Is there some way to build with MingW on windows with make? - You
> reference makefiles however I don't think these are used for scons
> builds.

What I'm trying to say is, the official Mesa source tarballs are missing many 
files necessary for windows builds.  Please try the git source code, or, if you 
prefer, a tarball with all the source in git, e.g. 
http://cgit.freedesktop.org/mesa/mesa/snapshot/mesa-7.10.3.zip

> Or perhaps a better question is is it possible at the moment to build
> mesa on windows?
> What are known working configurations?

Known working configurations (from git!) are:
- mingw crosscompilation from linux (x86 only)
- MSVC 2008 (requires cygwin flex & bison in the PATH), x86 or x64
I have these continuously running on Jenkins (previously known as Hudson) from 
git.

I haven't tried Mingw on Windows. But it should work without problems with MSYS.

> I tried with scons because the docs suggest using scons on mesa's
> page.

Yep. There's no other way to build for windows besides scons.

> 
> - Campbell

Jose

> On Mon, Jun 20, 2011 at 1:18 PM, Jose Fonseca 
> wrote:
> > Probably it's missing the .def files too...
> >
> > I think that instead of manually listing source files in
> > mesa/Makefile we should invoke 'git ls-files' (and maybe manually
> > list any exclusions).
> >
> > Splitting out Mesa GLUT from the source tree would make things much
> > easier. Which is probably a sensible thing to do anyway, given
> > that there are no glut dependencies in Mesa, and most people are
> > using freeglut anyway.
> >
> > Would anybody see any problem with that?
> >
> > Jose
> >
> > - Original Message -
> >> Hi There, Im trying to build Mesa so we can distribute it with
> >> Blender3D on Windows (we already do this on Linux).
> >>
> >> But I have have been unsable to build mesa 7.10.3
> >>  (Latest MingW XP, tested python 2.5, 2.7)
> >>
> >> Simply running 'm;\python25\Scripts\scons.bat'
> >> I always get this error:
> >> # --- snip
> >> scons: Reading SConscript files ...
> >>
> >> scons: warning: Ignoring missing SConscript
> >> 'build\windows-x86-debug\glut\glx\SConscript'
> >> File "M:\Mesa-7.10.3\src\SConscript", line 13, in 
> >> warning: LLVM disabled: not building llvmpipe
> >> scons: done reading SConscript files.
> >> scons: Building targets ...
> >> scons: ***
> >> [build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll]
> >> Source `src\gallium\state_trackers\wgl\opengl32.def' not found,
> >> needed
> >> by target
> >> `build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll'.
> >> scons: building terminated because of errors.
> >> # --- snip
> >>
> >> So I copied: src\mesa\drivers\windows\gldirect\opengl32.def
> >>
> >> But then I get this error:
> >>
> >> # --- snip
> >> scons: Reading SConscript files ...
> >> warning: LLVM disabled: not building llvmpipe
> >> scons: done reading SConscript files.
> >> scons: Building targets ...
> >> link /nologo /fixed:no /incremental:no /dll
> >> /out:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.dll
> >> build\windows-x86-debug\gallium\state_trackers\wgl\wgl.lib
> >> build\windows-x86-debug\gallium\winsys\sw\gdi\ws_gdi.lib
> >> build\windows-x86-debug\mapi\glapi\glapi.lib
> >> build\windows-x86-debug\mesa\mesa.lib
> >> build\windows-x86-debug\gallium\drivers\softpipe\softpipe.lib
> >> build\windows-x86-debug\gallium\drivers\trace\trace.lib
> >> build\windows-x86-debug\gallium\drivers\rbug\rbug.lib
> >> build\windows-x86-debug\gallium\auxiliary\gallium.lib
> >> build\windows-x86-debug\glsl\glsl.lib gdi32.lib user32.lib
> >> kernel32.lib ws2_32.lib
> >> /PDB:build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.pdb
> >> /DEBUG
> >> build\windows-x86-debug\gallium\targets\libgl-gdi\libgl_gdi.obj
> >> /def:src\gallium\state_trackers\wgl\opengl32.def
> >> src\gallium\state_trackers\wgl\opengl32.def(37) : warning LNK4017:
> >> DESCRIPTION statement not supported for the target platform;
> >> ignored
> >> opengl32.def : error LNK2001: unresolved external symbol
> >> glColorSubTableEXT
> >> build\windows-x86-debug\gallium\targets\libgl-gdi\opengl32.lib :
> >> fatal
> >> error LNK1120: 1 unresolved externals
> >> scons: building terminated because of errors.
> >> # --- snip
> >>
> >>
> >> Any hints on how to resolve these problems?
> >>
> >>
> >> --
> >> - Campbell
> >> ___
> >> 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] explaining update_arrays

2011-06-22 Thread Brian Paul 

On 06/22/2011 04:18 AM, Dave Airlie wrote:

I don't suppose anyone could contribute a comment on why somethings
check ctx->VertexProgram._Current,
and others check ctx->VertexProgram._Enabled


The former may point to a GLSL shader/program, a 
GL_NV/ARB_vertex_program program or a shader derived from 
fixed-function state.


The later will only be true when a GL_NV/ARB_vertex_program program is 
enabled and valid (GL_VERTEX_PROGRAM_ARB is enabled and the user's 
program compiled successfully).


I haven't looked at all the places where _Enabled or _Current is used, 
but there is a difference in what they mean.




By the looks of it the 0/POS attrib + the overlapping/16-31 ones check _Current
and the others all check _Enabled, to me it would make some sense at least if 0
was consistent with the others, but maybe someone knows what is correct.


The confusion probably goes all the way back to the ARB's unfortunate 
inability to reconcile NV's vs. ATI's different handling of generic 
vertex arrays.  NV used aliasing while ATI didn't so the ARB extension 
made it optional (a mess).  Plus, I think there was some minor 
difference in GL_ARB_vertex_program vs. GL_ARB_vertex_shaders w.r.t. 
generic vertex arrays.


Do you suspect a bug here?

I'd have to go back and re-read all the specs to remember the details.

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

[Mesa-dev] [PATCH 8/8] st/egl: Hookup gbm for drm backend

2011-06-22 Thread Benjamin Franzke 
---
 src/gallium/state_trackers/egl/Makefile |3 +-
 src/gallium/state_trackers/egl/common/egl_g3d.c |   18 +-
 src/gallium/state_trackers/egl/common/native.h  |3 +
 src/gallium/state_trackers/egl/drm/modeset.c|   36 +++
 src/gallium/state_trackers/egl/drm/native_drm.c |   77 +++
 src/gallium/state_trackers/egl/drm/native_drm.h |4 +
 src/gallium/targets/egl/Makefile|2 +-
 7 files changed, 99 insertions(+), 44 deletions(-)

diff --git a/src/gallium/state_trackers/egl/Makefile 
b/src/gallium/state_trackers/egl/Makefile
index 763e7b5..1c97022 100644
--- a/src/gallium/state_trackers/egl/Makefile
+++ b/src/gallium/state_trackers/egl/Makefile
@@ -33,7 +33,8 @@ wayland_INCLUDES = \
 wayland_SOURCES = $(wildcard wayland/*.c)
 wayland_OBJECTS = $(wayland_SOURCES:.c=.o)
 
-drm_INCLUDES = -I$(TOP)/src/gallium/winsys $(shell pkg-config --cflags-only-I 
libdrm)
+drm_INCLUDES = -I$(TOP)/src/gallium/winsys $(shell pkg-config --cflags-only-I 
libdrm) \
+  -I$(TOP)/src/gbm/main -I$(TOP)/src/gallium/state_trackers/gbm
 drm_SOURCES = $(wildcard drm/*.c)
 drm_OBJECTS = $(drm_SOURCES:.c=.o)
 
diff --git a/src/gallium/state_trackers/egl/common/egl_g3d.c 
b/src/gallium/state_trackers/egl/common/egl_g3d.c
index 29dbbef..6a40f4d 100644
--- a/src/gallium/state_trackers/egl/common/egl_g3d.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d.c
@@ -72,10 +72,26 @@ egl_g3d_new_sw_screen(struct native_display *ndpy, struct 
sw_winsys *ws)
return gdpy->loader->create_sw_screen(ws);
 }
 
+static struct pipe_resource *
+egl_g3d_lookup_egl_image(struct native_display *ndpy, void *egl_image)
+{
+   _EGLDisplay *dpy = (_EGLDisplay *) ndpy->user_data;
+   struct egl_g3d_display *gdpy = egl_g3d_display(dpy);
+   struct st_egl_image img;
+   struct pipe_resource *resource = NULL;
+
+   memset(&img, 0, sizeof(img));
+   if (gdpy->smapi->get_egl_image(gdpy->smapi, egl_image, &img))
+  resource = img.texture;
+
+   return resource;
+}
+
 static struct native_event_handler egl_g3d_native_event_handler = {
egl_g3d_invalid_surface,
egl_g3d_new_drm_screen,
-   egl_g3d_new_sw_screen
+   egl_g3d_new_sw_screen,
+   egl_g3d_lookup_egl_image
 };
 
 /**
diff --git a/src/gallium/state_trackers/egl/common/native.h 
b/src/gallium/state_trackers/egl/common/native.h
index 8646e52..cb26196 100644
--- a/src/gallium/state_trackers/egl/common/native.h
+++ b/src/gallium/state_trackers/egl/common/native.h
@@ -219,6 +219,9 @@ struct native_event_handler {
  const char *name, int fd);
struct pipe_screen *(*new_sw_screen)(struct native_display *ndpy,
 struct sw_winsys *ws);
+
+   struct pipe_resource *(*lookup_egl_image)(struct native_display *ndpy,
+ void *egl_image);
 };
 
 /**
diff --git a/src/gallium/state_trackers/egl/drm/modeset.c 
b/src/gallium/state_trackers/egl/drm/modeset.c
index 3fff954..73968d1 100644
--- a/src/gallium/state_trackers/egl/drm/modeset.c
+++ b/src/gallium/state_trackers/egl/drm/modeset.c
@@ -290,6 +290,42 @@ drm_display_create_surface(struct native_display *ndpy,
return drmsurf;
 }
 
+struct native_surface *
+drm_display_create_surface_from_resource(struct native_display *ndpy,
+ struct pipe_resource *resource)
+{
+   struct drm_display *drmdpy = drm_display(ndpy);
+   struct drm_surface *drmsurf;
+   enum native_attachment natt = NATIVE_ATTACHMENT_FRONT_LEFT;
+
+   drmsurf = CALLOC_STRUCT(drm_surface);
+   if (!drmsurf)
+  return NULL;
+
+   drmsurf->drmdpy = drmdpy;
+   drmsurf->color_format = resource->format;
+   drmsurf->width = resource->width0;
+   drmsurf->height = resource->height0;
+   drmsurf->have_pageflip = FALSE;
+
+   drmsurf->rsurf = resource_surface_create(drmdpy->base.screen,
+ drmsurf->color_format,
+ PIPE_BIND_RENDER_TARGET |
+ PIPE_BIND_SAMPLER_VIEW |
+ PIPE_BIND_DISPLAY_TARGET |
+ PIPE_BIND_SCANOUT);
+   
+   resource_surface_import_resource(drmsurf->rsurf, natt, resource);
+
+   drmsurf->base.destroy = drm_surface_destroy;
+   drmsurf->base.present = drm_surface_present;
+   drmsurf->base.validate = drm_surface_validate;
+   drmsurf->base.wait = drm_surface_wait;
+
+   return &drmsurf->base;
+}
+
+
 /**
  * Choose a CRTC that supports all given connectors.
  */
diff --git a/src/gallium/state_trackers/egl/drm/native_drm.c 
b/src/gallium/state_trackers/egl/drm/native_drm.c
index 725fe28..4814e8f 100644
--- a/src/gallium/state_trackers/egl/drm/native_drm.c
+++ b/src/gallium/state_trackers/egl/drm/native_drm.c
@@ -33,6 +33,8 @@
 
 #include "native_drm.h"
 
+#include "gbm_gallium_drmint.h"
+
 #ifdef HAVE_LIBUDEV
 #include 
 #endif
@@ -136,33 +138,6 @@ drm_display_destroy(struct native_display *ndpy)
FREE(drmdpy);
 }
 
-/**
- * Initialize KMS and pipe screen.
- */
-static boolean
-drm_display_init_screen

[Mesa-dev] [PATCH 7/8] egl_dri2: Hookup gbm as drm platform

2011-06-22 Thread Benjamin Franzke 
---
 configure.ac|3 +
 src/egl/drivers/dri2/Makefile   |2 +
 src/egl/drivers/dri2/egl_dri2.c |   76 +++
 src/egl/drivers/dri2/egl_dri2.h |   11 
 src/egl/drivers/dri2/platform_drm.c |   99 +--
 src/egl/main/Makefile   |4 ++
 6 files changed, 134 insertions(+), 61 deletions(-)

diff --git a/configure.ac b/configure.ac
index dbf8fe5..c94c5fa 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1653,6 +1653,9 @@ yes)
WAYLAND_EGL_LIB_DEPS="$WAYLAND_LIBS $LIBDRM_LIBS"
 GALLIUM_WINSYS_DIRS="$GALLIUM_WINSYS_DIRS sw/wayland"
fi
+if test "$plat" = "drm" && test "x$enable_gbm" = no; then
+AC_MSG_ERROR([EGL platform drm needs gbm])
+fi
 done
 EGL_PLATFORMS="$egl_platforms"
 ;;
diff --git a/src/egl/drivers/dri2/Makefile b/src/egl/drivers/dri2/Makefile
index f8ff82b..65d35b3 100644
--- a/src/egl/drivers/dri2/Makefile
+++ b/src/egl/drivers/dri2/Makefile
@@ -10,6 +10,8 @@ EGL_INCLUDES = \
-I$(TOP)/include \
-I$(TOP)/src/egl/main \
-I$(TOP)/src/mapi \
+   -I$(TOP)/src/gbm/main \
+   -I$(TOP)/src/gbm/backends/dri \
-DDEFAULT_DRIVER_DIR=\"$(DRI_DRIVER_SEARCH_DIR)\" \
$(LIBUDEV_CFLAGS) \
$(LIBDRM_CFLAGS)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index d430145..cad1737 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -244,7 +244,7 @@ dri2_add_config(_EGLDisplay *disp, const __DRIconfig 
*dri_config, int id,
return conf;
 }
 
-static __DRIimage *
+__DRIimage *
 dri2_lookup_egl_image(__DRIscreen *screen, void *image, void *data)
 {
_EGLDisplay *disp = data;
@@ -433,42 +433,12 @@ dri2_load_driver_swrast(_EGLDisplay *disp)
return EGL_TRUE;
 }
 
-EGLBoolean
-dri2_create_screen(_EGLDisplay *disp)
+void
+dri2_setup_screen(_EGLDisplay *disp)
 {
-   const __DRIextension **extensions;
-   struct dri2_egl_display *dri2_dpy;
+   struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
unsigned int api_mask;
 
-   dri2_dpy = disp->DriverData;
-
-   if (dri2_dpy->dri2) {
-  dri2_dpy->dri_screen =
- dri2_dpy->dri2->createNewScreen(0, dri2_dpy->fd, dri2_dpy->extensions,
-&dri2_dpy->driver_configs, disp);
-   } else {
-  assert(dri2_dpy->swrast);
-  dri2_dpy->dri_screen =
- dri2_dpy->swrast->createNewScreen(0, dri2_dpy->extensions,
-   &dri2_dpy->driver_configs, disp);
-   }
-
-   if (dri2_dpy->dri_screen == NULL) {
-  _eglLog(_EGL_WARNING, "DRI2: failed to create dri screen");
-  return EGL_FALSE;
-   }
-
-   extensions = dri2_dpy->core->getExtensions(dri2_dpy->dri_screen);
-   
-   if (dri2_dpy->dri2) {
-  if (!dri2_bind_extensions(dri2_dpy, dri2_core_extensions, extensions))
- goto cleanup_dri_screen;
-   } else {
-  assert(dri2_dpy->swrast);
-  if (!dri2_bind_extensions(dri2_dpy, swrast_core_extensions, extensions))
- goto cleanup_dri_screen;
-   }
-
if (dri2_dpy->dri2) {
   if (dri2_dpy->dri2->base.version >= 2)
  api_mask = dri2_dpy->dri2->getAPIMask(dri2_dpy->dri_screen);
@@ -510,6 +480,44 @@ dri2_create_screen(_EGLDisplay *disp)
   disp->Extensions.KHR_image_base = EGL_TRUE;
   disp->Extensions.KHR_gl_renderbuffer_image = EGL_TRUE;
}
+}
+
+EGLBoolean
+dri2_create_screen(_EGLDisplay *disp)
+{
+   const __DRIextension **extensions;
+   struct dri2_egl_display *dri2_dpy;
+
+   dri2_dpy = disp->DriverData;
+
+   if (dri2_dpy->dri2) {
+  dri2_dpy->dri_screen =
+ dri2_dpy->dri2->createNewScreen(0, dri2_dpy->fd, dri2_dpy->extensions,
+&dri2_dpy->driver_configs, disp);
+   } else {
+  assert(dri2_dpy->swrast);
+  dri2_dpy->dri_screen =
+ dri2_dpy->swrast->createNewScreen(0, dri2_dpy->extensions,
+   &dri2_dpy->driver_configs, disp);
+   }
+
+   if (dri2_dpy->dri_screen == NULL) {
+  _eglLog(_EGL_WARNING, "DRI2: failed to create dri screen");
+  return EGL_FALSE;
+   }
+
+   extensions = dri2_dpy->core->getExtensions(dri2_dpy->dri_screen);
+   
+   if (dri2_dpy->dri2) {
+  if (!dri2_bind_extensions(dri2_dpy, dri2_core_extensions, extensions))
+ goto cleanup_dri_screen;
+   } else {
+  assert(dri2_dpy->swrast);
+  if (!dri2_bind_extensions(dri2_dpy, swrast_core_extensions, extensions))
+ goto cleanup_dri_screen;
+   }
+
+   dri2_setup_screen(disp);
 
return EGL_TRUE;
 
diff --git a/src/egl/drivers/dri2/egl_dri2.h b/src/egl/drivers/dri2/egl_dri2.h
index 1844b6c..cd52d42 100644
--- a/src/egl/drivers/dri2/egl_dri2.h
+++ b/src/egl/drivers/dri2/egl_dri2.h
@@ -44,6 +44,8 @@
 #include 
 #include 
 
+#include 
+
 #include "eglconfig.h"
 #include "eglcontext.h"
 #include "egldisplay.h"
@@ -79,6 +8

[Mesa-dev] [PATCH 6/8] gbm: Add gallium (drm) backend

2011-06-22 Thread Benjamin Franzke 
---
 configure.ac   |   23 ++
 src/gallium/state_trackers/gbm/Makefile|   46 
 src/gallium/state_trackers/gbm/gbm_drm.c   |  225 
 .../state_trackers/gbm/gbm_gallium_drmint.h|   74 +++
 src/gallium/targets/gbm/Makefile   |   32 +++
 src/gallium/targets/gbm/gbm.c  |   61 ++
 src/gallium/targets/gbm/pipe_loader.c  |  192 +
 src/gallium/targets/gbm/pipe_loader.h  |   48 
 src/gbm/main/backend.c |1 +
 9 files changed, 702 insertions(+), 0 deletions(-)
 create mode 100644 src/gallium/state_trackers/gbm/Makefile
 create mode 100644 src/gallium/state_trackers/gbm/gbm_drm.c
 create mode 100644 src/gallium/state_trackers/gbm/gbm_gallium_drmint.h
 create mode 100644 src/gallium/targets/gbm/Makefile
 create mode 100644 src/gallium/targets/gbm/gbm.c
 create mode 100644 src/gallium/targets/gbm/pipe_loader.c
 create mode 100644 src/gallium/targets/gbm/pipe_loader.h

diff --git a/configure.ac b/configure.ac
index 249a689..dbf8fe5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -559,6 +559,13 @@ AC_ARG_ENABLE([gallium_egl],
  @<:@default=disable@:>@])],
 [enable_gallium_egl="$enableval"],
 [enable_gallium_egl=no])
+AC_ARG_ENABLE([gallium_gbm],
+[AS_HELP_STRING([--enable-gallium-gbm],
+[enable optional gbm state tracker (not required for
+ gbm support in Gallium)
+ @<:@default=disable@:>@])],
+[enable_gallium_gbm="$enableval"],
+[enable_gallium_gbm=no])
 
 # Option for Gallium drivers
 GALLIUM_DRIVERS_DEFAULT="r300,r600,swrast"
@@ -1305,6 +1312,22 @@ if test "x$enable_gallium_egl" = xyes; then
 fi
 
 dnl
+dnl gbm Gallium configuration
+dnl
+if test "x$enable_gallium_gbm" = xyes; then
+if test "x$with_gallium_drivers" = x; then
+AC_MSG_ERROR([cannot enable gbm_gallium without Gallium])
+fi
+if test "x$enable_gbm" = xno; then
+AC_MSG_ERROR([cannot enable gbm_gallium without gbm])
+fi
+
+GALLIUM_STATE_TRACKERS_DIRS="gbm $GALLIUM_STATE_TRACKERS_DIRS"
+GALLIUM_TARGET_DIRS="$GALLIUM_TARGET_DIRS gbm"
+HAVE_ST_GBM="yes"
+fi
+
+dnl
 dnl X.Org DDX configuration
 dnl
 if test "x$enable_xorg" = xyes; then
diff --git a/src/gallium/state_trackers/gbm/Makefile 
b/src/gallium/state_trackers/gbm/Makefile
new file mode 100644
index 000..1d96eb2
--- /dev/null
+++ b/src/gallium/state_trackers/gbm/Makefile
@@ -0,0 +1,46 @@
+TOP = ../../../..
+include $(TOP)/configs/current
+
+gbm_INCLUDES = \
+   -I. \
+   -I$(TOP)/src/gallium/include \
+   -I$(TOP)/src/gallium/auxiliary \
+   -I$(TOP)/src/gbm/main \
+   -I$(TOP)/include
+
+gbm_SOURCES = $(wildcard *.c)
+gbm_OBJECTS = $(gbm_SOURCES:.c=.o)
+
+ALL_INCLUDES = $(gbm_INCLUDES)
+ALL_SOURCES = $(gbm_SOURCES)
+
+GBM_OBJECTS = $(gbm_OBJECTS)
+GBM_CPPFLAGS = $(gbm_INCLUDES)
+
+# TARGETS #
+
+default: depend libgbm.a
+
+libgbm.a: $(GBM_OBJECTS) Makefile
+   $(MKLIB) -o gbm -static $(GBM_OBJECTS)
+
+depend: 
+   rm -f depend
+   touch depend
+   $(MKDEP) $(MKDEP_OPTIONS) $(ALL_INCLUDES) $(ALL_SOURCES) 2> /dev/null
+
+clean:
+   rm -f libgbm.a
+   rm -f $(GBM_OBJECTS)
+   rm -f depend depend.bak
+
+# Dummy target
+install:
+   @echo -n ""
+
+# RULES #
+
+$(gbm_OBJECTS): %.o: %.c
+   $(CC) -c $(GBM_CPPFLAGS) $(DEFINES) $(CFLAGS) $< -o $@
+
+sinclude depend
diff --git a/src/gallium/state_trackers/gbm/gbm_drm.c 
b/src/gallium/state_trackers/gbm/gbm_drm.c
new file mode 100644
index 000..39cea7a
--- /dev/null
+++ b/src/gallium/state_trackers/gbm/gbm_drm.c
@@ -0,0 +1,225 @@
+/*
+ * Copyright © 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Benjamin Franzke 
+ */
+
+#include "util/u_memory.h"
+#include "util/u_inlines.h"
+
+#

[Mesa-dev] [PATCH 5/8] gbm: Add dri backend

2011-06-22 Thread Benjamin Franzke 
---
 configure.ac   |7 +
 src/gbm/backends/dri/Makefile  |   22 ++
 src/gbm/backends/dri/driver_name.c |   89 +
 src/gbm/backends/dri/gbm_dri.c |  377 
 src/gbm/backends/dri/gbm_driint.h  |   78 
 src/gbm/main/Makefile  |5 +
 src/gbm/main/backend.c |3 +
 7 files changed, 581 insertions(+), 0 deletions(-)
 create mode 100644 src/gbm/backends/dri/Makefile
 create mode 100644 src/gbm/backends/dri/driver_name.c
 create mode 100644 src/gbm/backends/dri/gbm_dri.c
 create mode 100644 src/gbm/backends/dri/gbm_driint.h

diff --git a/configure.ac b/configure.ac
index b5dee9d..249a689 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1271,6 +1271,13 @@ if test "x$enable_gbm" = xyes; then
 PKG_CHECK_MODULES([LIBUDEV], [libudev], [],
   AC_MSG_ERROR([gbm needs udev]))
 GBM_LIB_DEPS="$DLOPEN_LIBS $LIBUDEV_LIBS"
+
+if test "$mesa_driver" = dri; then
+GBM_BACKEND_DIRS="$GBM_BACKEND_DIRS dri"
+if test "$SHARED_GLAPI" -eq 0; then
+AC_MSG_ERROR([gbm_dri requires --enable-shared-glapi])
+fi
+fi
 fi
 AC_SUBST([GBM_LIB_DEPS])
 AC_SUBST([GBM_BACKEND_DIRS])
diff --git a/src/gbm/backends/dri/Makefile b/src/gbm/backends/dri/Makefile
new file mode 100644
index 000..78fb329
--- /dev/null
+++ b/src/gbm/backends/dri/Makefile
@@ -0,0 +1,22 @@
+# src/gbm/backends/dri/Makefile
+
+TOP = ../../../..
+include $(TOP)/configs/current
+
+GBM_BACKEND = gbm_dri
+GBM_SOURCES = gbm_dri.c driver_name.c
+
+GBM_INCLUDES = \
+   -I$(TOP)/include \
+   -I$(TOP)/src/gbm/main \
+
+GBM_LIBS = $(LIBUDEV_LIBS) $(LIBDRM_LIB) -L$(TOP)/lib -lglapi 
+
+GBM_CFLAGS = \
+   -DDEFAULT_DRIVER_DIR=\"$(DRI_DRIVER_SEARCH_DIR)\" \
+   $(LIBUDEV_CFLAGS) \
+   $(LIBDRM_CFLAGS)
+
+GBM_BUILTIN=true
+
+include ../Makefile.template
diff --git a/src/gbm/backends/dri/driver_name.c 
b/src/gbm/backends/dri/driver_name.c
new file mode 100644
index 000..2ed209f
--- /dev/null
+++ b/src/gbm/backends/dri/driver_name.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright © 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Kristian Høgsberg 
+ *Benjamin Franzke 
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "gbm_driint.h"
+#define DRIVER_MAP_DRI2_ONLY
+#include "pci_ids/pci_id_driver_map.h"
+
+char *
+dri_fd_get_driver_name(int fd)
+{
+   struct udev *udev;
+   struct udev_device *device, *parent;
+   const char *pci_id;
+   char *driver = NULL;
+   int vendor_id, chip_id, i, j;
+
+   udev = udev_new();
+   device = _gbm_udev_device_new_from_fd(udev, fd);
+   if (device == NULL)
+  return NULL;
+
+   parent = udev_device_get_parent(device);
+   if (parent == NULL) {
+  fprintf(stderr, "gbm: could not get parent device");
+  goto out;
+   }
+
+   pci_id = udev_device_get_property_value(parent, "PCI_ID");
+   if (pci_id == NULL ||
+   sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
+  fprintf(stderr, "gbm: malformed or no PCI ID");
+  goto out;
+   }
+
+   for (i = 0; driver_map[i].driver; i++) {
+  if (vendor_id != driver_map[i].vendor_id)
+ continue;
+  if (driver_map[i].num_chips_ids == -1) {
+ driver = strdup(driver_map[i].driver);
+ _gbm_log("pci id for %d: %04x:%04x, driver %s",
+  fd, vendor_id, chip_id, driver);
+ goto out;
+  }
+
+  for (j = 0; j < driver_map[i].num_chips_ids; j++)
+ if (driver_map[i].chip_ids[j] == chip_id) {
+driver = strdup(driver_map[i].driver);
+_gbm_log("pci id for %d: %04x:%04x, driver %s",
+ fd, vendor_id, chip_id, driver);
+goto out;
+ }
+   }
+
+out:
+   udev_device_unref(device);
+   udev_unref(udev);
+
+   return driver;
+}
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm

[Mesa-dev] [PATCH 4/8] Add gbm (generic/graphics buffer manager)

2011-06-22 Thread Benjamin Franzke 
---
 Makefile   |   11 ++
 configs/autoconf.in|   10 ++-
 configs/default|   14 +++-
 configure.ac   |   37 +++
 include/EGL/eglplatform.h  |6 +
 src/gbm/Makefile   |   14 +++
 src/gbm/backends/Makefile  |   14 +++
 src/gbm/backends/Makefile.template |   65 
 src/gbm/main/Makefile  |   85 
 src/gbm/main/backend.c |  124 +++
 src/gbm/main/backend.h |   36 +++
 src/gbm/main/common.c  |   88 +
 src/gbm/main/common.h  |   42 
 src/gbm/main/common_drm.h  |   48 +
 src/gbm/main/gbm.c |  189 
 src/gbm/main/gbm.h |   99 +++
 src/gbm/main/gbm.pc.in |   12 +++
 src/gbm/main/gbmint.h  |   81 +++
 18 files changed, 973 insertions(+), 2 deletions(-)
 create mode 100644 src/gbm/Makefile
 create mode 100644 src/gbm/backends/Makefile
 create mode 100644 src/gbm/backends/Makefile.template
 create mode 100644 src/gbm/main/Makefile
 create mode 100644 src/gbm/main/backend.c
 create mode 100644 src/gbm/main/backend.h
 create mode 100644 src/gbm/main/common.c
 create mode 100644 src/gbm/main/common.h
 create mode 100644 src/gbm/main/common_drm.h
 create mode 100644 src/gbm/main/gbm.c
 create mode 100644 src/gbm/main/gbm.h
 create mode 100644 src/gbm/main/gbm.pc.in
 create mode 100644 src/gbm/main/gbmint.h

diff --git a/Makefile b/Makefile
index 07ec686..a9297ca 100644
--- a/Makefile
+++ b/Makefile
@@ -345,6 +345,16 @@ EGL_FILES = \
$(DIRECTORY)/src/egl/main/*.pc.in   \
$(DIRECTORY)/src/egl/main/*.def
 
+GBM_FILES = \
+   $(DIRECTORY)/src/gbm/Makefile   \
+   $(DIRECTORY)/src/gbm/main/*.pc.in   \
+   $(DIRECTORY)/src/gbm/main/*.[ch]\
+   $(DIRECTORY)/src/gbm/main/Makefile  \
+   $(DIRECTORY)/src/gbm/backends/Makefile  \
+   $(DIRECTORY)/src/gbm/backends/Makefile.template \
+   $(DIRECTORY)/src/gbm/backends/*/*.[ch]  \
+   $(DIRECTORY)/src/gbm/backends/*/Makefile\
+
 GALLIUM_FILES = \
$(DIRECTORY)/src/mesa/state_tracker/*[ch]   \
$(DIRECTORY)/src/gallium/Makefile   \
@@ -443,6 +453,7 @@ LIB_FILES = \
$(MAPI_FILES)   \
$(ES_FILES) \
$(EGL_FILES)\
+   $(GBM_FILES)\
$(GALLIUM_FILES)\
$(DRI_FILES)\
$(SGI_GLU_FILES)\
diff --git a/configs/autoconf.in b/configs/autoconf.in
index abc01b1..cac4bef 100644
--- a/configs/autoconf.in
+++ b/configs/autoconf.in
@@ -75,6 +75,7 @@ GLESv2_LIB = GLESv2
 VG_LIB = OpenVG
 GLAPI_LIB = glapi
 WAYLAND_EGL_LIB = wayland-egl
+GBM_LIB = gbm
 
 # Library names (actual file names)
 GL_LIB_NAME = @GL_LIB_NAME@
@@ -88,6 +89,7 @@ GLESv2_LIB_NAME = @GLESv2_LIB_NAME@
 VG_LIB_NAME = @VG_LIB_NAME@
 GLAPI_LIB_NAME = @GLAPI_LIB_NAME@
 WAYLAND_EGL_LIB_NAME = @WAYLAND_EGL_LIB_NAME@
+GBM_LIB_NAME = @GBM_LIB_NAME@
 
 # Globs used to install the lib and all symlinks
 GL_LIB_GLOB = @GL_LIB_GLOB@
@@ -101,6 +103,7 @@ GLESv2_LIB_GLOB = @GLESv2_LIB_GLOB@
 VG_LIB_GLOB = @VG_LIB_GLOB@
 GLAPI_LIB_GLOB = @GLAPI_LIB_GLOB@
 WAYLAND_EGL_LIB_GLOB = @WAYLAND_EGL_LIB_GLOB@
+GBM_LIB_GLOB = @GBM_LIB_GLOB@
 
 # Directories to build
 LIB_DIR = @LIB_DIR@
@@ -108,6 +111,7 @@ SRC_DIRS = @SRC_DIRS@
 GLU_DIRS = @GLU_DIRS@
 DRIVER_DIRS = @DRIVER_DIRS@
 EGL_DRIVERS_DIRS = @EGL_DRIVERS_DIRS@
+GBM_BACKEND_DIRS = @GBM_BACKEND_DIRS@
 GALLIUM_DIRS = @GALLIUM_DIRS@
 GALLIUM_DRIVERS_DIRS = @GALLIUM_DRIVERS_DIRS@
 GALLIUM_WINSYS_DIRS = @GALLIUM_WINSYS_DIRS@
@@ -147,7 +151,8 @@ GLESv1_CM_LIB_DEPS = $(EXTRA_LIB_PATH) @GLESv1_CM_LIB_DEPS@
 GLESv2_LIB_DEPS = $(EXTRA_LIB_PATH) @GLESv2_LIB_DEPS@
 VG_LIB_DEPS = $(EXTRA_LIB_PATH) @VG_LIB_DEPS@
 GLAPI_LIB_DEPS = $(EXTRA_LIB_PATH) @GLAPI_LIB_DEPS@
-WAYLAND_EGL_LIB_DEPS = $(EXTRA_LIBPATH) @WAYLAND_EGL_LIB_DEPS@
+WAYLAND_EGL_LIB_DEPS = $(EXTRA_LIB_PATH) @WAYLAND_EGL_LIB_DEPS@
+GBM_LIB_DEPS = $(EXTRA_LIB_PATH) @GBM_LIB_DEPS@
 
 # DRI dependencies
 MESA_MODULES = @MESA_MODULES@
@@ -206,6 +211,9 @@ EGL_PC_CFLAGS = @GL_PC_CFLAGS@
 WAYLAND_EGL_PC_REQ_PRIV = @WAYLAND_EGL_PC_REQ_PRIV@
 WAYLAND_EGL_PC_LIB_PRIV = @WAYLAND_EGL_PC_LIB_PRIV@
 WAYLAND_EGL_PC_CFLAGS = @WAYLAND_EGL_PC_CFLAGS@
+GBM_PC_REQ_PRIV = @GBM_PC_REQ_PRIV@
+GBM_PC_LIB_PRIV = @GBM_PC_LIB_PRIV@
+GBM_PC_CFLAGS = @GBM_PC_CFLAGS@
 
 XCB_DRI2_CFLAGS = @XCB_DRI2_CFLAGS@
 XCB_DRI2_LIBS = @XCB_DRI2_LIBS@
diff --git a/configs/default b/configs/default
index b7acfd2..e9f493a 100644
--- a/configs/default
+++ b/configs/defa

[Mesa-dev] [PATCH 3/8] st/dri: Implement DRIimageExtension::dupImage

2011-06-22 Thread Benjamin Franzke 
---
 src/gallium/state_trackers/dri/drm/dri2.c |   19 +++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/src/gallium/state_trackers/dri/drm/dri2.c 
b/src/gallium/state_trackers/dri/drm/dri2.c
index e471e8e..0296a78 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -564,6 +564,24 @@ dri2_query_image(__DRIimage *image, int attrib, int *value)
}
 }
 
+static __DRIimage *
+dri2_dup_image(__DRIimage *image, void *loaderPrivate)
+{
+   __DRIimage *img;
+
+   img = CALLOC_STRUCT(__DRIimageRec);
+   if (!img)
+  return NULL;
+
+   img->texture = NULL;
+   pipe_resource_reference(&img->texture, image->texture);
+   img->level = image->level;
+   img->layer = image->layer;
+   img->loader_private = loaderPrivate;
+
+   return img;
+}
+
 static void
 dri2_destroy_image(__DRIimage *img)
 {
@@ -578,6 +596,7 @@ static struct __DRIimageExtensionRec dri2ImageExtension = {
 dri2_destroy_image,
 dri2_create_image,
 dri2_query_image,
+dri2_dup_image,
 };
 
 /*
-- 
1.7.3.4

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

[Mesa-dev] [PATCH 2/8] intel: Implement DRIimageExtension::dupImage

2011-06-22 Thread Benjamin Franzke 
---
 src/mesa/drivers/dri/intel/intel_screen.c |   27 ++-
 1 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/intel/intel_screen.c 
b/src/mesa/drivers/dri/intel/intel_screen.c
index e915ca0..2a3a601 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -282,13 +282,38 @@ intel_query_image(__DRIimage *image, int attrib, int 
*value)
}
 }
 
+static __DRIimage *
+intel_dup_image(__DRIimage *orig_image, void *loaderPrivate)
+{
+   __DRIimage *image;
+
+   image = CALLOC(sizeof *image);
+   if (image == NULL)
+  return NULL;
+
+   image->region = NULL;
+   intel_region_reference(&image->region, orig_image->region);
+   if (image->region == NULL) {
+  FREE(image);
+  return NULL;
+   }
+
+   image->internal_format = orig_image->internal_format;
+   image->format  = orig_image->format;
+   image->data_type   = orig_image->data_type;
+   image->data= loaderPrivate;
+   
+   return image;
+}
+
 static struct __DRIimageExtensionRec intelImageExtension = {
 { __DRI_IMAGE, __DRI_IMAGE_VERSION },
 intel_create_image_from_name,
 intel_create_image_from_renderbuffer,
 intel_destroy_image,
 intel_create_image,
-intel_query_image
+intel_query_image,
+intel_dup_image
 };
 
 static const __DRIextension *intelScreenExtensions[] = {
-- 
1.7.3.4

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

[Mesa-dev] [PATCH 1/8] dri: Add dupImage to DRIimageExtension

2011-06-22 Thread Benjamin Franzke 
---
 include/GL/internal/dri_interface.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/GL/internal/dri_interface.h 
b/include/GL/internal/dri_interface.h
index f022b44..21b9af6 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -849,6 +849,8 @@ struct __DRIimageExtensionRec {
   void *loaderPrivate);
 
GLboolean (*queryImage)(__DRIimage *image, int attrib, int *value);
+
+   __DRIimage *(*dupImage)(__DRIimage *image, void *loaderPrivate);
 };
 
 
-- 
1.7.3.4

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

[Mesa-dev] [PATCH 0/8] GBM Graphics Buffer Manager

2011-06-22 Thread Benjamin Franzke 
Hi List,

This series adds a graphics buffer management library which is
targeted to be used as native (drm) platform for egl on kms or openwfd,
and thus replaces the current mechanism of using a fd as EGLNativeDisplay
and EGL_MESA_drm_image to create buffers.
GBM uses the mesas internal dri interface or acts as a gallium state tracker.

The mapping to EGL types is:

gbm_device - EGLNativeDisplayType
gbm_bo - EGLNativePixmapType / EGL_NATIVE_PIXMAP_KHR

This integrates better with the idea of EGL, which assumes there is
some kind of native library thats responsible for allocating buffers.

We wanted to use libkms, but since that's explicitly designed to no
support hw renderable buffers we have to go a different route.


Benjamin Franzke (8):
  dri: Add dupImage to DRIimageExtension
  intel: Implement DRIimageExtension::dupImage
  st/dri: Implement DRIimageExtension::dupImage
  Add gbm (generic/graphics buffer manager)
  gbm: Add dri backend
  gbm: Add gallium (drm) backend
  egl_dri2: Hookup gbm as drm platform
  st/egl: Hookup gbm for drm backend

 Makefile   |   11 +
 configs/autoconf.in|   10 +-
 configs/default|   14 +-
 configure.ac   |   70 
 include/EGL/eglplatform.h  |6 +
 include/GL/internal/dri_interface.h|2 +
 src/egl/drivers/dri2/Makefile  |2 +
 src/egl/drivers/dri2/egl_dri2.c|   76 +++--
 src/egl/drivers/dri2/egl_dri2.h|   11 +
 src/egl/drivers/dri2/platform_drm.c|   99 --
 src/egl/main/Makefile  |4 +
 src/gallium/state_trackers/dri/drm/dri2.c  |   19 +
 src/gallium/state_trackers/egl/Makefile|3 +-
 src/gallium/state_trackers/egl/common/egl_g3d.c|   18 +-
 src/gallium/state_trackers/egl/common/native.h |3 +
 src/gallium/state_trackers/egl/drm/modeset.c   |   36 ++
 src/gallium/state_trackers/egl/drm/native_drm.c|   77 ++---
 src/gallium/state_trackers/egl/drm/native_drm.h|4 +
 src/gallium/state_trackers/gbm/Makefile|   46 +++
 src/gallium/state_trackers/gbm/gbm_drm.c   |  225 
 .../state_trackers/gbm/gbm_gallium_drmint.h|   74 
 src/gallium/targets/egl/Makefile   |2 +-
 src/gallium/targets/gbm/Makefile   |   32 ++
 src/gallium/targets/gbm/gbm.c  |   61 
 src/gallium/targets/gbm/pipe_loader.c  |  192 ++
 src/gallium/targets/gbm/pipe_loader.h  |   48 +++
 src/gbm/Makefile   |   14 +
 src/gbm/backends/Makefile  |   14 +
 src/gbm/backends/Makefile.template |   65 
 src/gbm/backends/dri/Makefile  |   22 ++
 src/gbm/backends/dri/driver_name.c |   89 +
 src/gbm/backends/dri/gbm_dri.c |  377 
 src/gbm/backends/dri/gbm_driint.h  |   78 
 src/gbm/main/Makefile  |   90 +
 src/gbm/main/backend.c |  128 +++
 src/gbm/main/backend.h |   36 ++
 src/gbm/main/common.c  |   88 +
 src/gbm/main/common.h  |   42 +++
 src/gbm/main/common_drm.h  |   48 +++
 src/gbm/main/gbm.c |  189 ++
 src/gbm/main/gbm.h |   99 +
 src/gbm/main/gbm.pc.in |   12 +
 src/gbm/main/gbmint.h  |   81 +
 src/mesa/drivers/dri/intel/intel_screen.c  |   27 ++-
 44 files changed, 2536 insertions(+), 108 deletions(-)
 create mode 100644 src/gallium/state_trackers/gbm/Makefile
 create mode 100644 src/gallium/state_trackers/gbm/gbm_drm.c
 create mode 100644 src/gallium/state_trackers/gbm/gbm_gallium_drmint.h
 create mode 100644 src/gallium/targets/gbm/Makefile
 create mode 100644 src/gallium/targets/gbm/gbm.c
 create mode 100644 src/gallium/targets/gbm/pipe_loader.c
 create mode 100644 src/gallium/targets/gbm/pipe_loader.h
 create mode 100644 src/gbm/Makefile
 create mode 100644 src/gbm/backends/Makefile
 create mode 100644 src/gbm/backends/Makefile.template
 create mode 100644 src/gbm/backends/dri/Makefile
 create mode 100644 src/gbm/backends/dri/driver_name.c
 create mode 100644 src/gbm/backends/dri/gbm_dri.c
 create mode 100644 src/gbm/backends/dri/gbm_driint.h
 create mode 100644 src/gbm/main/Makefile
 create mode 100644 src/gbm/main/backend.c
 create mode 100644 src/gbm/main/backend.h
 create mode 100644 src/gbm/main/common.c
 create mode 100644 src/gbm/main/common.h
 create mode 100644 src/gbm/main/common_drm.h
 create mode 100644 src/gbm/main/gbm.c
 create mode

[Mesa-dev] explaining update_arrays

2011-06-22 Thread Dave Airlie 
I don't suppose anyone could contribute a comment on why somethings
check ctx->VertexProgram._Current,
and others check ctx->VertexProgram._Enabled

By the looks of it the 0/POS attrib + the overlapping/16-31 ones check _Current
and the others all check _Enabled, to me it would make some sense at least if 0
was consistent with the others, but maybe someone knows what is correct.

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