mesa3d-dev

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

[Chia-I Wu <ol...@gm...>]

On Fri, Apr 9, 2010 at 9:07 PM, Keith Whitwell <ke...@vm...> wrote:
> On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote:
>> On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote:
>> > 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.
>>
>> OK, if nobody chimes in, let's look at merging this to master in the
>> next day or so.
>>
>
> I've made a final merge of master into gallium-resources.  Please try it
> out and report/fix any issues.  This will be merged tomorrow.
Texturing in i915g seems to be broken.  You can find screenshots of drawpix and
teapot in the attachments.  Any idea?

-- 
ol...@Lu...

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

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

On Thu, Apr 8, 2010 at 4: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.

I've sent the subscriber list to Jesse and he's sent it to Tollef.  He
can preserve the digest vs. regular state with the new list....

-Brian

[Mesa3d-dev] [PATCH] Provide dri shared library building and SDK installation.

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

Patch cherry-picked from my dri-sdk-7.8 branch against current head 
(edb5253dfa). An earlier full build through of all drivers (except 
nouveau, i will play with its expansive libdrm dependencies later) 
showed it to be an exact match still.

This patch, while not harming or hampering anything or anyone, gives us 
the ability to maintain and build DRI drivers out of tree for those so 
inclined. Build system additions only. No adverse effects. Everybody 
wins.

I intend to provide changes as needed, I hope to at least manage to 
maintain released versions in the long term.

For those wanting a test run, please check out the 7.8 version of the 
SDK and the drivers in my cgit.freedesktop.org repos.

Luc Verhaegen.

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

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

2010/4/9 Ian Romanick <id...@fr...>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kristian Høgsberg wrote:
>> 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.
>
> Reviewed-by: Ian Romanick <ian...@in...>

Thanks.

> This should go into master, 7.8, and mesa_7_7_branch.

Done.

> Are there any
> specific bugs associated with this?  If so, those should be documented
> in the commit message.

Not that I know.  I just ran into it when trying to run glxpbdemo.

Kristian

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

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

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

Kristian Høgsberg wrote:
> 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.

Reviewed-by: Ian Romanick <ian...@in...>

This should go into master, 7.8, and mesa_7_7_branch.  Are there any
specific bugs associated with this?  If so, those should be documented
in the commit message.

> ---
>  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.

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

iEYEARECAAYFAku/d2QACgkQX1gOwKyEAw/6gACfcz1EfbxKymUy90FCCQjxyDp8
OyMAn0mFF4f8OOn+jPnwzKrHz5m0capG
=pndz
-----END PGP SIGNATURE-----

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

[Chia-I Wu <ol...@gm...>]

On Sat, Apr 10, 2010 at 12:15 AM, Roland Scheidegger <sr...@vm...> wrote:
> On 09.04.2010 17:29, STEVE555 wrote:
>> Hi all,
>>         I've git branched and got the latest commits from the
>> gallium-resources branch and also the latest commits from git master.
>>
>> I did a gmake -B realclean from a prevous compile on my copy of git
>> master,and did a  git checkout gallium-resources to switch to that
>> branch,and did a ./autogen.sh with the following options:
>>
>>  --prefix=/usr/local --enable-32-bit --enable-xcb --enable-gallium-nouveau
>> --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif
>> --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon
>> --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests
>> --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga
>> --with-max-width=4096 --with-max-height=4096 --enable-debug
>>
>> I then did a gmake to compile my copy of gallium-resources,but it ended with
>> error at the end:
> This should be fixed now.
Thanks for the quick fix.  My usual build with st/{egl,glx,dri,vega,es}
also compiles fine on this branch.

-- 
ol...@Lu...

Re: [Mesa3d-dev] Mesa (gallium-resources): gallium: fix comments for changed USAGE flags

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

On Fri, 2010-04-09 at 09:57 -0700, Roland Scheidegger wrote:
> On 09.04.2010 18:22, José Fonseca wrote:
> > On Fri, 2010-04-09 at 09:02 -0700, Keith Whitwell wrote:
> >> On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote:
> >>> On 09.04.2010 17:49, Keith Whitwell wrote:
> >>>> On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote:
> >>>>> Module: Mesa
> >>>>> Branch: gallium-resources
> >>>>> Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf
> >>>>> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf
> >>>>>
> >>>>> Author: Roland Scheidegger <sr...@vm...>
> >>>>> Date:   Fri Apr  9 17:44:24 2010 +0200
> >>>>>
> >>>>> gallium: fix comments for changed USAGE flags
> >>>>>
> >>>>> ---
> >>>>>
> >>>>>  src/gallium/auxiliary/util/u_simple_screen.h  |    9 +++++----
> >>>>>  src/gallium/drivers/svga/svga_winsys.h        |   10 ++++------
> >>>>>  src/gallium/include/pipe/p_screen.h           |    2 +-
> >>>>>  src/gallium/include/state_tracker/sw_winsys.h |    2 +-
> >>>>>  4 files changed, 11 insertions(+), 12 deletions(-)
> >>>>>
> >>>>> diff --git a/src/gallium/auxiliary/util/u_simple_screen.h b/src/gallium/auxiliary/util/u_simple_screen.h
> >>>>> index 0042277..1ba59af 100644
> >>>>> --- a/src/gallium/auxiliary/util/u_simple_screen.h
> >>>>> +++ b/src/gallium/auxiliary/util/u_simple_screen.h
> >>>>> @@ -73,9 +73,10 @@ struct pipe_winsys
> >>>>>      * window systems must then implement that interface (rather than the
> >>>>>      * other way around...).
> >>>>>      *
> >>>>> -    * usage is a bitmask of PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This
> >>>>> -    * usage argument is only an optimization hint, not a guarantee, therefore
> >>>>> -    * proper behavior must be observed in all circumstances.
> >>>>> +    * usage is a bitmask of PIPE_BIND_*.
> >>>>> +    * XXX is this true?
> >>>>> +    * This usage argument is only an optimization hint, not a guarantee,
> >>>>> +    * therefore proper behavior must be observed in all circumstances.
> >>>> The new flags are no longer hints - they are supposed actually specify
> >>>> which operations are permitted on a resource.  
> >>>>
> >>>> Unfortunately I don't think this is very well enforced yet -- I intend
> >>>> to add a "debug" layer to sit between state-tracker and driver, based on
> >>>> the drivers/identity layer, which will check for violations of this &
> >>>> other rules.
> >>> Ok, I thought this to be the case, but wasn't sure. I'll fix the comment.
> >>> In the svga code, I actually couldn't figure out the usage flags when a
> >>> winsys buffer is created. It looks like usage is always 0, except for
> >>> queries it uses SVGA_BUFFER_USAGE_PINNED. Of course, that's not a
> >>> resource but a winsys buffer, but as far as I can tell this ends up in a
> >>> pb_buffer usage flag. Not sure if that's ok or supposed to be like that...
> >> Jose has looked at this more recently than I have...
> > 
> > pb_buffer sits between pipe driver and the winsys, and needs to pass
> > custom buffer flags unmodified from svga to the winsys.
> > 
> > SVGA_BUFFER_USAGE_PINNED is one of those usages.
> So the svga winsys buffer_create function takes only custom flags, none
> of the PB_USAGE ones? 

Yep. That's right. All SVGA winsys buffers are identical in nature apart
from the pinned vs unpinned. All winsys buffers allow for full CPU and
GPU access, so these are ignored.

> This is the idea I got from the code (plus the
> custom flags would clearly overlap with the generic ones), and hence
> what I updated the comment to (which clearly was wrong).
> I'm not sure though this really works with the pb code I thought it
> might do some checks on the usage flags there but if you say it works
> then I better believe it...

pb code does look into those flags. But I believe it pays more attention
to the same kind of flags that are passed when mapping and validation
time than the ones passed at buffer creation time.

Anwyay, this is just from skimming the code. I did not have time to test
gallium resources's svga pipe driver yet.


Jose

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

[STEVE555 <ste...@ho...>]

Dear Roland,
                   I like to thank you very much for the fixes.I have
compiled from commit 927cec79cedb457efa9e6f335727cfcb8e4908e2 on the
gallium-resources branch and that compiles fine now.
I also did a git merge of my copy of mesa master (from commit
75b8c4a8f869f63991c774caa7e1cec7e988c5ec) into my copy of gallium-resources
from commit 927cec79cedb457efa9e6f335727cfcb8e4908e2 .I'm glad to say that
the merge of my two copies and compile of gallium-resources all went fine.
Regards,
             STEVE555

Roland Scheidegger-4 wrote:
> 
> On 09.04.2010 17:29, STEVE555 wrote:
>> Hi all,
>>         I've git branched and got the latest commits from the
>> gallium-resources branch and also the latest commits from git master.
>> 
>> I did a gmake -B realclean from a prevous compile on my copy of git
>> master,and did a  git checkout gallium-resources to switch to that
>> branch,and did a ./autogen.sh with the following options:
>> 
>>  --prefix=/usr/local --enable-32-bit --enable-xcb
>> --enable-gallium-nouveau
>> --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif
>> --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon
>> --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests
>> --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga
>> --with-max-width=4096 --with-max-height=4096 --enable-debug
>> 
>> I then did a gmake to compile my copy of gallium-resources,but it ended
>> with
>> error at the end:
> This should be fixed now.
> 
> Roland
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/gallium-resources-branch-merge-tp28119468p28195020.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

[Mesa3d-dev] [PATCH] Fix build with --enable-32-bit.

[Török E. <edw...@gm...>]

CFLAGS needs to be passed, as you already know.
Commit 3e17a5b047124c46ee45dbd1848127c67e0d62f3 broke this by adding a new link
command without CFLAGS.

Signed-off-by: Török Edwin <edw...@gm...>
---
 src/gallium/targets/Makefile.dri       |    2 +-
 src/mesa/drivers/dri/Makefile.template |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/gallium/targets/Makefile.dri b/src/gallium/targets/Makefile.dri
index 6d9b81a..16477e3 100644
--- a/src/gallium/targets/Makefile.dri
+++ b/src/gallium/targets/Makefile.dri
@@ -69,7 +69,7 @@ $(LIBNAME): $(OBJECTS) $(MESA_MODULES) $(PIPE_DRIVERS) Makefile \
 		$(OBJECTS) $(PIPE_DRIVERS) \
                 -Wl,--start-group $(MESA_MODULES) -Wl,--end-group \
                  $(DRI_LIB_DEPS) $(DRIVER_EXTRAS)
-	$(CC) -o $@.test $(TOP)/src/mesa/drivers/dri/common/dri_test.o $@.tmp $(DRI_LIB_DEPS)
+	$(CC) $(CFLAGS) -o $@.test $(TOP)/src/mesa/drivers/dri/common/dri_test.o $@.tmp $(DRI_LIB_DEPS)
 	@rm -f $@.test
 	mv -f $@.tmp $@
 
diff --git a/src/mesa/drivers/dri/Makefile.template b/src/mesa/drivers/dri/Makefile.template
index f19cc03..4cdd51e 100644
--- a/src/mesa/drivers/dri/Makefile.template
+++ b/src/mesa/drivers/dri/Makefile.template
@@ -54,7 +54,7 @@ $(LIBNAME): $(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) Makefile \
 		$(TOP)/src/mesa/drivers/dri/Makefile.template $(TOP)/src/mesa/drivers/dri/common/dri_test.o
 	$(MKLIB) -o $@.tmp -noprefix -linker '$(CC)' -ldflags '$(LDFLAGS)' \
 		$(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) $(DRI_LIB_DEPS)
-	$(CC) -o $@.test $(TOP)/src/mesa/drivers/dri/common/dri_test.o $@.tmp $(DRI_LIB_DEPS)
+	$(CC) $(CFLAGS) -o $@.test $(TOP)/src/mesa/drivers/dri/common/dri_test.o $@.tmp $(DRI_LIB_DEPS)
 	@rm -f $@.test
 	mv -f $@.tmp $@
 
-- 
1.7.0

Re: [Mesa3d-dev] Mesa (master): st/egl: Move probe interface to native_probe.h.

[Chia-I Wu <ol...@gm...>]

On Fri, Apr 9, 2010 at 9:36 PM, Brian Paul <br...@vm...> wrote:
> One thing below...
>
> diff --git a/src/gallium/state_trackers/egl/common/native_probe.h b/src/gallium/state_trackers/egl/common/native_probe.h
> new file mode 100644
> index 0000000..4ed37a5
> --- /dev/null
> +++ b/src/gallium/state_trackers/egl/common/native_probe.h
> @@ -0,0 +1,67 @@
> +/*
> + * Mesa 3-D graphics library
> + * Version:  7.8
> + *
> + * Copyright (C) 2009-2010 Chia-I Wu <ol...@0x...>
> + *
> + * 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 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
> + * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
> When  copying/pasting the license info into new files, check who's named in the license blurb.
> You can either replace "BRIAN PAUL" with your name or "THE AUTHORS AND COPYRIGHT HOLDERS".
Ouch, sorry.  I overlooked that part.  I will audit all files with my name and
update the license notice accordingly.

-- 
ol...@Lu...

Re: [Mesa3d-dev] Mesa (gallium-resources): gallium: fix comments for changed USAGE flags

[Roland S. <sr...@vm...>]

On 09.04.2010 18:22, José Fonseca wrote:
> On Fri, 2010-04-09 at 09:02 -0700, Keith Whitwell wrote:
>> On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote:
>>> On 09.04.2010 17:49, Keith Whitwell wrote:
>>>> On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote:
>>>>> Module: Mesa
>>>>> Branch: gallium-resources
>>>>> Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf
>>>>> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf
>>>>>
>>>>> Author: Roland Scheidegger <sr...@vm...>
>>>>> Date:   Fri Apr  9 17:44:24 2010 +0200
>>>>>
>>>>> gallium: fix comments for changed USAGE flags
>>>>>
>>>>> ---
>>>>>
>>>>>  src/gallium/auxiliary/util/u_simple_screen.h  |    9 +++++----
>>>>>  src/gallium/drivers/svga/svga_winsys.h        |   10 ++++------
>>>>>  src/gallium/include/pipe/p_screen.h           |    2 +-
>>>>>  src/gallium/include/state_tracker/sw_winsys.h |    2 +-
>>>>>  4 files changed, 11 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/src/gallium/auxiliary/util/u_simple_screen.h b/src/gallium/auxiliary/util/u_simple_screen.h
>>>>> index 0042277..1ba59af 100644
>>>>> --- a/src/gallium/auxiliary/util/u_simple_screen.h
>>>>> +++ b/src/gallium/auxiliary/util/u_simple_screen.h
>>>>> @@ -73,9 +73,10 @@ struct pipe_winsys
>>>>>      * window systems must then implement that interface (rather than the
>>>>>      * other way around...).
>>>>>      *
>>>>> -    * usage is a bitmask of PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This
>>>>> -    * usage argument is only an optimization hint, not a guarantee, therefore
>>>>> -    * proper behavior must be observed in all circumstances.
>>>>> +    * usage is a bitmask of PIPE_BIND_*.
>>>>> +    * XXX is this true?
>>>>> +    * This usage argument is only an optimization hint, not a guarantee,
>>>>> +    * therefore proper behavior must be observed in all circumstances.
>>>> The new flags are no longer hints - they are supposed actually specify
>>>> which operations are permitted on a resource.  
>>>>
>>>> Unfortunately I don't think this is very well enforced yet -- I intend
>>>> to add a "debug" layer to sit between state-tracker and driver, based on
>>>> the drivers/identity layer, which will check for violations of this &
>>>> other rules.
>>> Ok, I thought this to be the case, but wasn't sure. I'll fix the comment.
>>> In the svga code, I actually couldn't figure out the usage flags when a
>>> winsys buffer is created. It looks like usage is always 0, except for
>>> queries it uses SVGA_BUFFER_USAGE_PINNED. Of course, that's not a
>>> resource but a winsys buffer, but as far as I can tell this ends up in a
>>> pb_buffer usage flag. Not sure if that's ok or supposed to be like that...
>> Jose has looked at this more recently than I have...
> 
> pb_buffer sits between pipe driver and the winsys, and needs to pass
> custom buffer flags unmodified from svga to the winsys.
> 
> SVGA_BUFFER_USAGE_PINNED is one of those usages.
So the svga winsys buffer_create function takes only custom flags, none
of the PB_USAGE ones? This is the idea I got from the code (plus the
custom flags would clearly overlap with the generic ones), and hence
what I updated the comment to (which clearly was wrong).
I'm not sure though this really works with the pb code I thought it
might do some checks on the usage flags there but if you say it works
then I better believe it...

Roland

Re: [Mesa3d-dev] Mesa (gallium-resources): gallium: fix comments for changed USAGE flags

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

On Fri, 2010-04-09 at 09:22 -0700, José Fonseca wrote:
> On Fri, 2010-04-09 at 09:02 -0700, Keith Whitwell wrote:
> > On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote:
> > > On 09.04.2010 17:49, Keith Whitwell wrote:
> > > > On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote:
> > > >> Module: Mesa
> > > >> Branch: gallium-resources
> > > >> Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf
> > > >> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf
> > > >>
> > > >> Author: Roland Scheidegger <sr...@vm...>
> > > >> Date:   Fri Apr  9 17:44:24 2010 +0200
> > > >>
> > > >> gallium: fix comments for changed USAGE flags
> > > >>
> > > >> ---
> > > >>
> > > >>  src/gallium/auxiliary/util/u_simple_screen.h  |    9 +++++----
> > > >>  src/gallium/drivers/svga/svga_winsys.h        |   10 ++++------
> > > >>  src/gallium/include/pipe/p_screen.h           |    2 +-
> > > >>  src/gallium/include/state_tracker/sw_winsys.h |    2 +-
> > > >>  4 files changed, 11 insertions(+), 12 deletions(-)
> > > >>
> > > >> diff --git a/src/gallium/auxiliary/util/u_simple_screen.h b/src/gallium/auxiliary/util/u_simple_screen.h
> > > >> index 0042277..1ba59af 100644
> > > >> --- a/src/gallium/auxiliary/util/u_simple_screen.h
> > > >> +++ b/src/gallium/auxiliary/util/u_simple_screen.h
> > > >> @@ -73,9 +73,10 @@ struct pipe_winsys
> > > >>      * window systems must then implement that interface (rather than the
> > > >>      * other way around...).
> > > >>      *
> > > >> -    * usage is a bitmask of PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This
> > > >> -    * usage argument is only an optimization hint, not a guarantee, therefore
> > > >> -    * proper behavior must be observed in all circumstances.
> > > >> +    * usage is a bitmask of PIPE_BIND_*.
> > > >> +    * XXX is this true?
> > > >> +    * This usage argument is only an optimization hint, not a guarantee,
> > > >> +    * therefore proper behavior must be observed in all circumstances.
> > > > 
> > > > The new flags are no longer hints - they are supposed actually specify
> > > > which operations are permitted on a resource.  
> > > > 
> > > > Unfortunately I don't think this is very well enforced yet -- I intend
> > > > to add a "debug" layer to sit between state-tracker and driver, based on
> > > > the drivers/identity layer, which will check for violations of this &
> > > > other rules.
> > > 
> > > Ok, I thought this to be the case, but wasn't sure. I'll fix the comment.
> > > In the svga code, I actually couldn't figure out the usage flags when a
> > > winsys buffer is created. It looks like usage is always 0, except for
> > > queries it uses SVGA_BUFFER_USAGE_PINNED. Of course, that's not a
> > > resource but a winsys buffer, but as far as I can tell this ends up in a
> > > pb_buffer usage flag. Not sure if that's ok or supposed to be like that...
> > 
> > Jose has looked at this more recently than I have...
> 
> pb_buffer sits between pipe driver and the winsys, and needs to pass
> custom buffer flags unmodified from svga to the winsys.
> 
> SVGA_BUFFER_USAGE_PINNED is one of those usages.
> 
> PIPE_BIND_* don't matter at this level. What matters at the pipebuffer
> level is CPU/GPU READ/WRITE flags. Perhaps it might make sense to modify
> pipebuffer and its users to use pipebuffer specifc PB_BUFFER_*** flags
> instead of the gallium ones.

It's already done. Nevermind.

Jose

Re: [Mesa3d-dev] Mesa (gallium-resources): gallium: fix comments for changed USAGE flags

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

On Fri, 2010-04-09 at 09:02 -0700, Keith Whitwell wrote:
> On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote:
> > On 09.04.2010 17:49, Keith Whitwell wrote:
> > > On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote:
> > >> Module: Mesa
> > >> Branch: gallium-resources
> > >> Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf
> > >> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf
> > >>
> > >> Author: Roland Scheidegger <sr...@vm...>
> > >> Date:   Fri Apr  9 17:44:24 2010 +0200
> > >>
> > >> gallium: fix comments for changed USAGE flags
> > >>
> > >> ---
> > >>
> > >>  src/gallium/auxiliary/util/u_simple_screen.h  |    9 +++++----
> > >>  src/gallium/drivers/svga/svga_winsys.h        |   10 ++++------
> > >>  src/gallium/include/pipe/p_screen.h           |    2 +-
> > >>  src/gallium/include/state_tracker/sw_winsys.h |    2 +-
> > >>  4 files changed, 11 insertions(+), 12 deletions(-)
> > >>
> > >> diff --git a/src/gallium/auxiliary/util/u_simple_screen.h b/src/gallium/auxiliary/util/u_simple_screen.h
> > >> index 0042277..1ba59af 100644
> > >> --- a/src/gallium/auxiliary/util/u_simple_screen.h
> > >> +++ b/src/gallium/auxiliary/util/u_simple_screen.h
> > >> @@ -73,9 +73,10 @@ struct pipe_winsys
> > >>      * window systems must then implement that interface (rather than the
> > >>      * other way around...).
> > >>      *
> > >> -    * usage is a bitmask of PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This
> > >> -    * usage argument is only an optimization hint, not a guarantee, therefore
> > >> -    * proper behavior must be observed in all circumstances.
> > >> +    * usage is a bitmask of PIPE_BIND_*.
> > >> +    * XXX is this true?
> > >> +    * This usage argument is only an optimization hint, not a guarantee,
> > >> +    * therefore proper behavior must be observed in all circumstances.
> > > 
> > > The new flags are no longer hints - they are supposed actually specify
> > > which operations are permitted on a resource.  
> > > 
> > > Unfortunately I don't think this is very well enforced yet -- I intend
> > > to add a "debug" layer to sit between state-tracker and driver, based on
> > > the drivers/identity layer, which will check for violations of this &
> > > other rules.
> > 
> > Ok, I thought this to be the case, but wasn't sure. I'll fix the comment.
> > In the svga code, I actually couldn't figure out the usage flags when a
> > winsys buffer is created. It looks like usage is always 0, except for
> > queries it uses SVGA_BUFFER_USAGE_PINNED. Of course, that's not a
> > resource but a winsys buffer, but as far as I can tell this ends up in a
> > pb_buffer usage flag. Not sure if that's ok or supposed to be like that...
> 
> Jose has looked at this more recently than I have...

pb_buffer sits between pipe driver and the winsys, and needs to pass
custom buffer flags unmodified from svga to the winsys.

SVGA_BUFFER_USAGE_PINNED is one of those usages.

PIPE_BIND_* don't matter at this level. What matters at the pipebuffer
level is CPU/GPU READ/WRITE flags. Perhaps it might make sense to modify
pipebuffer and its users to use pipebuffer specifc PB_BUFFER_*** flags
instead of the gallium ones.

Jose

Re: [Mesa3d-dev] [PATCH] Fix build with --enable-32-bit. again.

[Török E. <edw...@gm...>]

2010/4/9 Dan Nicholson <dbn...@gm...>:
>
> Good catch, although it really affects anyone that stores flags
> necessary to the linker in CFLAGS. Could you also fix the one in
> src/gallium/winsys/drm/Makefile.template from the same commit and
> repost the patch? Thanks.

Will do that a bit later.

--Edwin

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

[Roland S. <sr...@vm...>]

On 09.04.2010 17:29, STEVE555 wrote:
> Hi all,
>         I've git branched and got the latest commits from the
> gallium-resources branch and also the latest commits from git master.
> 
> I did a gmake -B realclean from a prevous compile on my copy of git
> master,and did a  git checkout gallium-resources to switch to that
> branch,and did a ./autogen.sh with the following options:
> 
>  --prefix=/usr/local --enable-32-bit --enable-xcb --enable-gallium-nouveau
> --with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif
> --enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon
> --with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests
> --with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga
> --with-max-width=4096 --with-max-height=4096 --enable-debug
> 
> I then did a gmake to compile my copy of gallium-resources,but it ended with
> error at the end:
This should be fixed now.

Roland

Re: [Mesa3d-dev] Mesa (gallium-resources): gallium: fix comments for changed USAGE flags

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

On Fri, 2010-04-09 at 08:59 -0700, Roland Scheidegger wrote:
> On 09.04.2010 17:49, Keith Whitwell wrote:
> > On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote:
> >> Module: Mesa
> >> Branch: gallium-resources
> >> Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf
> >> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf
> >>
> >> Author: Roland Scheidegger <sr...@vm...>
> >> Date:   Fri Apr  9 17:44:24 2010 +0200
> >>
> >> gallium: fix comments for changed USAGE flags
> >>
> >> ---
> >>
> >>  src/gallium/auxiliary/util/u_simple_screen.h  |    9 +++++----
> >>  src/gallium/drivers/svga/svga_winsys.h        |   10 ++++------
> >>  src/gallium/include/pipe/p_screen.h           |    2 +-
> >>  src/gallium/include/state_tracker/sw_winsys.h |    2 +-
> >>  4 files changed, 11 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/src/gallium/auxiliary/util/u_simple_screen.h b/src/gallium/auxiliary/util/u_simple_screen.h
> >> index 0042277..1ba59af 100644
> >> --- a/src/gallium/auxiliary/util/u_simple_screen.h
> >> +++ b/src/gallium/auxiliary/util/u_simple_screen.h
> >> @@ -73,9 +73,10 @@ struct pipe_winsys
> >>      * window systems must then implement that interface (rather than the
> >>      * other way around...).
> >>      *
> >> -    * usage is a bitmask of PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This
> >> -    * usage argument is only an optimization hint, not a guarantee, therefore
> >> -    * proper behavior must be observed in all circumstances.
> >> +    * usage is a bitmask of PIPE_BIND_*.
> >> +    * XXX is this true?
> >> +    * This usage argument is only an optimization hint, not a guarantee,
> >> +    * therefore proper behavior must be observed in all circumstances.
> > 
> > The new flags are no longer hints - they are supposed actually specify
> > which operations are permitted on a resource.  
> > 
> > Unfortunately I don't think this is very well enforced yet -- I intend
> > to add a "debug" layer to sit between state-tracker and driver, based on
> > the drivers/identity layer, which will check for violations of this &
> > other rules.
> 
> Ok, I thought this to be the case, but wasn't sure. I'll fix the comment.
> In the svga code, I actually couldn't figure out the usage flags when a
> winsys buffer is created. It looks like usage is always 0, except for
> queries it uses SVGA_BUFFER_USAGE_PINNED. Of course, that's not a
> resource but a winsys buffer, but as far as I can tell this ends up in a
> pb_buffer usage flag. Not sure if that's ok or supposed to be like that...

Jose has looked at this more recently than I have...

Keith

Re: [Mesa3d-dev] Mesa (gallium-resources): gallium: fix comments for changed USAGE flags

[Roland S. <sr...@vm...>]

On 09.04.2010 17:49, Keith Whitwell wrote:
> On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote:
>> Module: Mesa
>> Branch: gallium-resources
>> Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf
>> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf
>>
>> Author: Roland Scheidegger <sr...@vm...>
>> Date:   Fri Apr  9 17:44:24 2010 +0200
>>
>> gallium: fix comments for changed USAGE flags
>>
>> ---
>>
>>  src/gallium/auxiliary/util/u_simple_screen.h  |    9 +++++----
>>  src/gallium/drivers/svga/svga_winsys.h        |   10 ++++------
>>  src/gallium/include/pipe/p_screen.h           |    2 +-
>>  src/gallium/include/state_tracker/sw_winsys.h |    2 +-
>>  4 files changed, 11 insertions(+), 12 deletions(-)
>>
>> diff --git a/src/gallium/auxiliary/util/u_simple_screen.h b/src/gallium/auxiliary/util/u_simple_screen.h
>> index 0042277..1ba59af 100644
>> --- a/src/gallium/auxiliary/util/u_simple_screen.h
>> +++ b/src/gallium/auxiliary/util/u_simple_screen.h
>> @@ -73,9 +73,10 @@ struct pipe_winsys
>>      * window systems must then implement that interface (rather than the
>>      * other way around...).
>>      *
>> -    * usage is a bitmask of PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This
>> -    * usage argument is only an optimization hint, not a guarantee, therefore
>> -    * proper behavior must be observed in all circumstances.
>> +    * usage is a bitmask of PIPE_BIND_*.
>> +    * XXX is this true?
>> +    * This usage argument is only an optimization hint, not a guarantee,
>> +    * therefore proper behavior must be observed in all circumstances.
> 
> The new flags are no longer hints - they are supposed actually specify
> which operations are permitted on a resource.  
> 
> Unfortunately I don't think this is very well enforced yet -- I intend
> to add a "debug" layer to sit between state-tracker and driver, based on
> the drivers/identity layer, which will check for violations of this &
> other rules.

Ok, I thought this to be the case, but wasn't sure. I'll fix the comment.
In the svga code, I actually couldn't figure out the usage flags when a
winsys buffer is created. It looks like usage is always 0, except for
queries it uses SVGA_BUFFER_USAGE_PINNED. Of course, that's not a
resource but a winsys buffer, but as far as I can tell this ends up in a
pb_buffer usage flag. Not sure if that's ok or supposed to be like that...

Roland

Re: [Mesa3d-dev] Mesa (gallium-resources): gallium: fix comments for changed USAGE flags

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

On Fri, 2010-04-09 at 08:45 -0700, Roland Scheidegger wrote:
> Module: Mesa
> Branch: gallium-resources
> Commit: faf53328d1154c51d8a59513f2bfcae62272b0bf
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=faf53328d1154c51d8a59513f2bfcae62272b0bf
> 
> Author: Roland Scheidegger <sr...@vm...>
> Date:   Fri Apr  9 17:44:24 2010 +0200
> 
> gallium: fix comments for changed USAGE flags
> 
> ---
> 
>  src/gallium/auxiliary/util/u_simple_screen.h  |    9 +++++----
>  src/gallium/drivers/svga/svga_winsys.h        |   10 ++++------
>  src/gallium/include/pipe/p_screen.h           |    2 +-
>  src/gallium/include/state_tracker/sw_winsys.h |    2 +-
>  4 files changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/util/u_simple_screen.h b/src/gallium/auxiliary/util/u_simple_screen.h
> index 0042277..1ba59af 100644
> --- a/src/gallium/auxiliary/util/u_simple_screen.h
> +++ b/src/gallium/auxiliary/util/u_simple_screen.h
> @@ -73,9 +73,10 @@ struct pipe_winsys
>      * window systems must then implement that interface (rather than the
>      * other way around...).
>      *
> -    * usage is a bitmask of PIPE_BUFFER_USAGE_PIXEL/VERTEX/INDEX/CONSTANT. This
> -    * usage argument is only an optimization hint, not a guarantee, therefore
> -    * proper behavior must be observed in all circumstances.
> +    * usage is a bitmask of PIPE_BIND_*.
> +    * XXX is this true?
> +    * This usage argument is only an optimization hint, not a guarantee,
> +    * therefore proper behavior must be observed in all circumstances.

The new flags are no longer hints - they are supposed actually specify
which operations are permitted on a resource.  

Unfortunately I don't think this is very well enforced yet -- I intend
to add a "debug" layer to sit between state-tracker and driver, based on
the drivers/identity layer, which will check for violations of this &
other rules.

Keith

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

[STEVE555 <ste...@ho...>]

Hi all,
        I've git branched and got the latest commits from the
gallium-resources branch and also the latest commits from git master.

I did a gmake -B realclean from a prevous compile on my copy of git
master,and did a  git checkout gallium-resources to switch to that
branch,and did a ./autogen.sh with the following options:

 --prefix=/usr/local --enable-32-bit --enable-xcb --enable-gallium-nouveau
--with-state-trackers=dri,egl,xorg,glx,vega,es --enable-motif
--enable-gl-osmesa --disable-gallium-intel --disable-gallium-radeon
--with-expat=/usr/lib --with-demos=xdemos,demos,trivial,tests
--with-dri-drivers=swrast --enable-gallium-swrast --enable-gallium-svga
--with-max-width=4096 --with-max-height=4096 --enable-debug

I then did a gmake to compile my copy of gallium-resources,but it ended with
error at the end:

dri_st_api.c: In function ‘dri_st_manager_get_egl_image’:
dri_st_api.c:244: warning: implicit declaration of function
‘pipe_texture_reference’
gcc -c -I. -I../../../../../src/gallium/include
-I../../../../../src/gallium/auxiliary -I../../../../../src/gallium/drivers
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/gallium/state_trackers/dri/common
-I../../../../../src/mesa/drivers/dri/common -I../../../../../src/mesa/main
-I/usr/include/drm -I/usr/include/libdrm   -g -O2 -Wall -Wmissing-prototypes
-std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC
-m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  dri1_helper.c -o
dri1_helper.o
gcc -c -I. -I../../../../../src/gallium/include
-I../../../../../src/gallium/auxiliary -I../../../../../src/gallium/drivers
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/gallium/state_trackers/dri/common
-I../../../../../src/mesa/drivers/dri/common -I../../../../../src/mesa/main
-I/usr/include/drm -I/usr/include/libdrm   -g -O2 -Wall -Wmissing-prototypes
-std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC
-m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  dri1.c -o dri1.o
gcc -c -I. -I../../../../../src/gallium/include
-I../../../../../src/gallium/auxiliary -I../../../../../src/gallium/drivers
-I../../../../../include -I../../../../../src/mesa
-I../../../../../src/gallium/state_trackers/dri/common
-I../../../../../src/mesa/drivers/dri/common -I../../../../../src/mesa/main
-I/usr/include/drm -I/usr/include/libdrm   -g -O2 -Wall -Wmissing-prototypes
-std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC
-m32 -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE
-DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1
-DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096 -DMAX_HEIGHT=4096  dri2.c -o dri2.o
dri2.c: In function ‘dri2_create_image_from_name’:
dri2.c:393: error: storage size of ‘templ’ isn’t known
dri2.c:398: error: ‘PIPE_TEXTURE_USAGE_RENDER_TARGET’ undeclared (first use
in this function)
dri2.c:398: error: (Each undeclared identifier is reported only once
dri2.c:398: error: for each function it appears in.)
dri2.c:398: error: ‘PIPE_TEXTURE_USAGE_SAMPLER’ undeclared (first use in
this function)
dri2.c:434: error: ‘struct pipe_screen’ has no member named
‘texture_from_handle’
dri2.c:393: warning: unused variable ‘templ’
dri2.c: In function ‘dri2_destroy_image’:
dri2.c:465: warning: implicit declaration of function
‘pipe_texture_reference’
gmake[5]: *** [dri2.o] Error 1

Regards,
             STEVE555
-- 
View this message in context: http://old.nabble.com/gallium-resources-branch-merge-tp28119468p28191257.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] [PATCH] Fix build with --enable-32-bit. again.

[Dan N. <dbn...@gm...>]

2010/4/9 Török Edwin <edw...@gm...>:
> CFLAGS needs to be passed, as you already know.
> Commit 3e17a5b047124c46ee45dbd1848127c67e0d62f3 broke this by adding a new link
> command without CFLAGS.
>
> Signed-off-by: Török Edwin <edw...@gm...>
> ---
>  src/mesa/drivers/dri/Makefile.template |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/Makefile.template b/src/mesa/drivers/dri/Makefile.template
> index f19cc03..4cdd51e 100644
> --- a/src/mesa/drivers/dri/Makefile.template
> +++ b/src/mesa/drivers/dri/Makefile.template
> @@ -54,7 +54,7 @@ $(LIBNAME): $(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) Makefile \
>                $(TOP)/src/mesa/drivers/dri/Makefile.template $(TOP)/src/mesa/drivers/dri/common/dri_test.o
>        $(MKLIB) -o $@.tmp -noprefix -linker '$(CC)' -ldflags '$(LDFLAGS)' \
>                $(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) $(DRI_LIB_DEPS)
> -       $(CC) -o $@.test $(TOP)/src/mesa/drivers/dri/common/dri_test.o $@.tmp $(DRI_LIB_DEPS)
> +       $(CC) $(CFLAGS) -o $@.test $(TOP)/src/mesa/drivers/dri/common/dri_test.o $@.tmp $(DRI_LIB_DEPS)
>        @rm -f $@.test
>        mv -f $@.tmp $@
>
> --

Good catch, although it really affects anyone that stores flags
necessary to the linker in CFLAGS. Could you also fix the one in
src/gallium/winsys/drm/Makefile.template from the same commit and
repost the patch? Thanks.

--
Dan

[Mesa3d-dev] [PATCH] Fix build with --enable-32-bit. again.

[Török E. <edw...@gm...>]

CFLAGS needs to be passed, as you already know.
Commit 3e17a5b047124c46ee45dbd1848127c67e0d62f3 broke this by adding a new link
command without CFLAGS.

Signed-off-by: Török Edwin <edw...@gm...>
---
 src/mesa/drivers/dri/Makefile.template |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/mesa/drivers/dri/Makefile.template b/src/mesa/drivers/dri/Makefile.template
index f19cc03..4cdd51e 100644
--- a/src/mesa/drivers/dri/Makefile.template
+++ b/src/mesa/drivers/dri/Makefile.template
@@ -54,7 +54,7 @@ $(LIBNAME): $(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) Makefile \
 		$(TOP)/src/mesa/drivers/dri/Makefile.template $(TOP)/src/mesa/drivers/dri/common/dri_test.o
 	$(MKLIB) -o $@.tmp -noprefix -linker '$(CC)' -ldflags '$(LDFLAGS)' \
 		$(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) $(DRI_LIB_DEPS)
-	$(CC) -o $@.test $(TOP)/src/mesa/drivers/dri/common/dri_test.o $@.tmp $(DRI_LIB_DEPS)
+	$(CC) $(CFLAGS) -o $@.test $(TOP)/src/mesa/drivers/dri/common/dri_test.o $@.tmp $(DRI_LIB_DEPS)
 	@rm -f $@.test
 	mv -f $@.tmp $@
 
-- 
1.7.0

Re: [Mesa3d-dev] Mesa (master): st/egl: Move probe interface to native_probe.h.

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

One thing below...

diff --git a/src/gallium/state_trackers/egl/common/native_probe.h b/src/gallium/state_trackers/egl/common/native_probe.h
new file mode 100644
index 0000000..4ed37a5
--- /dev/null
+++ b/src/gallium/state_trackers/egl/common/native_probe.h
@@ -0,0 +1,67 @@
+/*
+ * Mesa 3-D graphics library
+ * Version:  7.8
+ *
+ * Copyright (C) 2009-2010 Chia-I Wu <ol...@0x...>
+ *
+ * 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 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
+ * BRIAN PAUL BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN

When  copying/pasting the license info into new files, check who's named in the license blurb.

You can either replace "BRIAN PAUL" with your name or "THE AUTHORS AND COPYRIGHT HOLDERS".

Thanks.

Re: [Mesa3d-dev] Mesa (master): st/xorg: Fix bad paramf.

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

> 
> Author: Corbin Simpson <Mos...@gm...>
> Date:   Fri Apr  9 03:38:23 2010 -0700
> 
> st/xorg: Fix bad paramf.
> 
> Should be an integer param, according to docs.
> 
> ---
> 
>  src/gallium/state_trackers/xorg/xorg_driver.c |    4 +---
>  1 files changed, 1 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/state_trackers/xorg/xorg_driver.c b/src/gallium/state_trackers/xorg/xorg_driver.c
> index 8ac5179..d5dd0d7 100644
> --- a/src/gallium/state_trackers/xorg/xorg_driver.c
> +++ b/src/gallium/state_trackers/xorg/xorg_driver.c
> @@ -676,10 +676,8 @@ drv_screen_init(int scrnIndex, ScreenPtr pScreen, int argc, char **argv)
>      }
> 
>      if (ms->screen) {
> -       float maxf;
>         int max;
> -       maxf = ms->screen->get_paramf(ms->screen, PIPE_CAP_MAX_TEXTURE_2D_LEVELS);
> -       max = (1 << (int)(maxf - 1.0f));
> +       max = ms->screen->get_param(ms->screen, PIPE_CAP_MAX_TEXTURE_2D_LEVELS);
>         max_width = max < max_width ? max : max_width;
>         max_height = max < max_height ? max : max_height;
>      }
> 

This doesn't look right.  The shift line is missing.  PIPE_CAP_MAX_TEXTURE_2D_LEVELS is not a width/height value.  To compute the max width and height from max_levels:

max_width = 1 << (max_levels - 1)

-Brian

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

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

On Fri, 2010-04-09 at 03:43 -0700, Keith Whitwell wrote:
> On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote:
> > 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.
> 
> OK, if nobody chimes in, let's look at merging this to master in the
> next day or so.
> 

I've made a final merge of master into gallium-resources.  Please try it
out and report/fix any issues.  This will be merged tomorrow.

Keith

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

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

On Thu, 2010-04-08 at 15:20 -0700, Marek Olšák wrote:
> 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.

OK, if nobody chimes in, let's look at merging this to master in the
next day or so.

Keith