mesa3d-dev

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

[George S. <gsa...@gm...>]

On Mon, Mar 15, 2010 at 4:26 PM, Luca Barbieri <luc...@gm...> wrote:
> Why not softpipe_dri.so?
> It would also be nice to have llvmpipe_dri.so (and once it is mature,
> make this the default one instead of swrast, since it is much faster).
>

it will support both softpipe and llvmpipe, gallium allows
interchanging software renderers trivially, swrast_dri is the glue
with the DRI "window system".

Re: [Mesa3d-dev] [PATCHes] RFC: detect TLS during configuration

[tom f. <tf...@al...>]

Dan Nicholson <dbn...@gm...> writes:
> On Sun, Mar 14, 2010 at 5:38 PM, tom fogal <tf...@al...> wrote:
> > [I] volunteer[ed] to detect platform TLS support, + enable it in
> > Mesa / the X server if available.
> >
> > One thing I'm worried about is using an AC macro archive macro here;
> > it's GPL + an exception [. . .]
> 
> I don't think license of the build files affects the license of the
> code. We're already using lots of macros from autoconf that are almost
> certainly GPL.

Okay, great.

> > OTOH, the macro is dead simple.
> >
> > Comments?
> 
> I think I'd prefer if you added the macro directly to acinclude.m4
> instead of adding more macro files. If we're going to do that, I'd
> rather have an explicit m4 directory. I don't think mesa quite needs
> that, though.

Okay, I can integrate it directly.

> Changing TLS to autodetect might be a good thing down the road, but
> I think we need to at least have the xserver following the settings
> before we make this change. Otherwise, nearly everybody is suddenly
> going to get TLS enabled in the DRI drivers who don't know they need
> to start passing another option to the xserver.

Ahh, I see my memory was wrong; I figured a TLS driver could be used
regardless.  Digging up the old thread [1], it seems like it'd be
possible, but currently not implemented as such.

So, yes, I agree, autodetection shouldn't be applied until the X server
keys into it.

> So, I'd rather see these two patches broken up differently.
> 
> 1. Export glx_tls from gl.pc
> 2. Autodetect TLS usage

Will do.

-tom

[1] http://lists.x.org/archives/xorg-devel/2009-November/003411.html

Re: [Mesa3d-dev] Cast needed in program_lexer.l ???

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

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

Marcin Baczyński wrote:
> 2010/3/13 Karl Schultz <kar...@gm...>:
>> In some locales, a comma can be used as a decimal place.  That is, 5,2 is a
>> number between 5 and 6.  (I think I have that right)  I would guess that the
>> shader language, like C, wouldn't allow this form in code.  So, it makes
>> sense to force the C locale when parsing numbers from shader source code, as
>> the code does above.
>>
>> strtof doesn't show up until C99 and not all compilers support it, including
>> the MSFT Windows compilers.  Ian says that all usages of this function want
>> a float anyway, so we may end up with something like:
>>
>> float
>> _mesa_strtof( const char *s, char **end )
>> {
>> #ifdef _GNU_SOURCE
>>    static locale_t loc = NULL;
>>    if (!loc) {
>>       loc = newlocale(LC_CTYPE_MASK, "C", NULL);
>>    }
>>    return (float) strtod_l(s, end, loc);
>> #else
>>    return (float) strtod(s, end);
>> #endif
>> }
>>
>> And then change all _mesa_strtod to _mesa_strtof.
>>
>> If Ian doesn't care for the casts here, then I'm fine with silencing
>> warnings in the Studio with a compiler option.
> 
> Attached patch uses strtof when it is available.

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

iEYEARECAAYFAkueVj8ACgkQX1gOwKyEAw/aTQCfRrPt+MDFkh2g87pQKShWSpvR
m9gAnjcl8jsgxfJJJW9j7zCxxhv3LpN9
=mmpj
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [PATCH] dri: link DRI drivers with -Wl, --no-undefined -lGL

[Luca B. <lu...@lu...>]

You are right: I'll see if I can find a better solution that does not
cause libGL to be loaded.

Re: [Mesa3d-dev] xdemos build breakage...

[Jeff S. <why...@ya...>]

>> Except that AC_PATH_XTRA returns X_LIBS without '-lX11', while

>> PKG_CHECK_MODULES returns X_LIBS with it.  In the attached patch
>> I add '-lX11' to the former.  Of course, with '-lX11' as part of X_LIBS, the
>> explicit '-lX11' can be removed from the places that use X_LIBS.
>
>Jeff, it should get swapped back around to what you had in your patch
>and a s/X_\(CFLAGS\|LIBS\)/X11_\1/g across the rest of the files. I
>can put that together a little later if you don't have time to make
>another patch on master.
>
>--
>Dan

You can go ahead and do that yourself, if it's all the same to you.
I am busy elsewhere today.

 -- Jeff



      

Re: [Mesa3d-dev] [PATCH] dri: link DRI drivers with -Wl, --no-undefined -lGL

[Michel D. <mi...@da...>]

On Mon, 2010-03-15 at 15:00 +0100, Luca Barbieri wrote: 
> 
> Note that this introduces a dependency from the DRI drivers on libGL.so.1.
> However, the driver loader calls dlopen on libGL.so.1 with
> RTLD_GLOBAL | RTLD_NOW before loading any DRI driver, so the added
> dependency shouldn't cause changes in runtime behavior.
> 
> Please double-check the correctness of this assumption before pushing.

Have you tested that this works for AIGLX as well?


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

[Michel D. <mi...@da...>]

On Mon, 2010-03-15 at 14:30 +0100, Luca Barbieri wrote: 
> Adding both -Wl,--no-undefined and -lGL (in
> src/gallium/winsys/drm/Makefile.template) seems to work for me.
> 
> The driver loader is already loading libGL.so.1 with RTLD_NOW |
> RTLD_GLOBAL, so I think that the DRI driver depending on libGL.so.1
> shouldn't introduce any issue.

Keep in mind the AIGLX case. Loading libGL into the X server probably
isn't desirable.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

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

Why not softpipe_dri.so?
It would also be nice to have llvmpipe_dri.so (and once it is mature,
make this the default one instead of swrast, since it is much faster).

Re: [Mesa3d-dev] [RFC] gallium-sampler-view branch merge

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

On Mon, 2010-03-15 at 07:24 -0700, michal wrote:
> Keith Whitwell wrote on 2010-03-15 15:19:
> > On Mon, 2010-03-15 at 07:08 -0700, michal wrote:
> >   
> >> michal wrote on 2010-03-12 15:00:
> >>     
> >>> michal wrote on 2010-03-11 17:59:
> >>>   
> >>>       
> >>>> Keith Whitwell wrote on 2010-03-11 16:16:
> >>>>   
> >>>>     
> >>>>         
> >>>>> On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
> >>>>>   
> >>>>>     
> >>>>>       
> >>>>>           
> >>>>>> Keith Whitwell wrote on 2010-03-11 14:21:
> >>>>>>     
> >>>>>>       
> >>>>>>         
> >>>>>>             
> >>>>>>> On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> >>>>>>>   
> >>>>>>>       
> >>>>>>>         
> >>>>>>>           
> >>>>>>>               
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I would like to merge the branch in subject this week. This feature 
> >>>>>>>> branch allows state trackers to bind sampler views instead of textures 
> >>>>>>>> to shader stages.
> >>>>>>>>
> >>>>>>>> A sampler view object holds a reference to a texture and also overrides 
> >>>>>>>> internal texture format (resource casting) and specifies RGBA swizzle 
> >>>>>>>> (needed for GL_EXT_texture_swizzle extension).
> >>>>>>>>     
> >>>>>>>>         
> >>>>>>>>           
> >>>>>>>>             
> >>>>>>>>                 
> >>>>>>> Michal,
> >>>>>>>
> >>>>>>> I've got some issues with the way the sampler views are being generated
> >>>>>>> and used inside the CSO module.
> >>>>>>>
> >>>>>>> The point of a sampler view is that it gives the driver an opportunity
> >>>>>>> to do expensive operations required for special sampling modes (which
> >>>>>>> may include copying surface data if hardware is deficient in some way).
> >>>>>>>
> >>>>>>> This approach works if a sampler view is created once, then used
> >>>>>>> multiple times before being deleted.
> >>>>>>>
> >>>>>>> Unfortunately, it seems the changes to support this in the CSO module
> >>>>>>> provide only a single-shot usage model.  Sampler views are created in
> >>>>>>> cso_set_XXX_sampler_textures, bound to the context, and then
> >>>>>>> dereferenced/destroyed on the next bind.
> >>>>>>>
> >>>>>>>   
> >>>>>>>       
> >>>>>>>         
> >>>>>>>           
> >>>>>>>               
> >>>>>> The reason CSO code looks like this is because it was meant to be an 
> >>>>>> itermediate step towards migration to sampler view model. Fully 
> >>>>>> converting all existing state trackers is non-trivial and thus I chose 
> >>>>>> this conservative approach. State trackers that do not care about extra 
> >>>>>> features a sampler view provides will keep using this one-shot CSO 
> >>>>>> interface with the hope that creation of sampler objects is lighweight 
> >>>>>> (format matches texture format, swizzle matches native texel layout, 
> >>>>>> etc.). 
> >>>>>>     
> >>>>>>       
> >>>>>>         
> >>>>>>             
> >>>>> On the surface, this hope isn't likely to be fulfilled - lots of
> >>>>> hardware doesn't support non-zero first_level.  Most cases of drivers
> >>>>> implementing sampler views internally are to catch this issue.
> >>>>>
> >>>>> Of course, it seems like your branch so leaves the existing
> >>>>> driver-specific sampler view code in place, so that there are
> >>>>> potentially two implementations of sampler views in those drivers.  
> >>>>>
> >>>>> I guess this means that you can get away with the current implementation
> >>>>> for now, but it prevents drivers actually taking advantage of the fact
> >>>>> that these entities exist in the interface -- they will continue to have
> >>>>> to duplicate the concept internally until the state trackers and/or CSO
> >>>>> module start caching views.
> >>>>>
> >>>>>   
> >>>>>     
> >>>>>       
> >>>>>           
> >>>>>> Ideally, everybody moves on and we stop using CSO for sampler 
> >>>>>> views. I prefer putting my effort into incremental migration of state 
> >>>>>> trackers rather than caching something that by definition doesn't need 
> >>>>>> to be cached.
> >>>>>>     
> >>>>>>       
> >>>>>>         
> >>>>>>             
> >>>>> The CSO module exists to manage this type of caching on behalf of state
> >>>>> trackers.  I would have thought that this was a sensible extension of
> >>>>> the existing purpose of the CSO module.
> >>>>>
> >>>>> Won't all state-trackers implementing APIs which don't expose sampler
> >>>>> views to the application require essentially the same caching logic, as
> >>>>> is the case with regular state?  Wouldn't it be least effort to do that
> >>>>> caching once only in the CSO module?
> >>>>>   
> >>>>>     
> >>>>>       
> >>>>>           
> >>>> OK, I see your point. I will make the necessary changes and ping you 
> >>>> when that's done.
> >>>>
> >>>>   
> >>>>     
> >>>>         
> >>> Keith,
> >>>
> >>> I changed my mind, went ahead and implemented sampler view caching in 
> >>> mesa state tracker, rather than inside cso context.
> >>>
> >>> I strongly believe that doing caching on cso side would be slower and 
> >>> more complicated. A state tracker has a better understanding of the 
> >>> relationship between a texture and sampler view. In case of mesa, this 
> >>> is trivial 1-to-1 mapping. Later, when we'll need more sampler views per 
> >>> texture, we can have a per-texture cache for that, and yes, the code for 
> >>> that would be in cso.
> >>>
> >>> There are two other state trackers that need to be fixed: xorg and vega. 
> >>> The transition should be similar to mesa -- I can help with doing that, 
> >>> but I can't do it myself. Once that's done we can purge one-shot sampler 
> >>> view wrappers.
> >>>
> >>> What do you think?
> >>>
> >>>   
> >>>       
> >> Keith,
> >>
> >> I just finished transforming mesa and auxiliary modules to new sampler 
> >> view interfaces. The remaining bits are vega and xorg state trackers -- 
> >> I will need help with them, but they could be fixed after the merge, as 
> >> they are not broken, and just set sampler view in suboptimal fashion.
> >>
> >> Please review, thanks.
> >>     
> >
> >
> > Michal,
> >
> > Did you get a chance to look at the double-refcounting (views +
> > textures) in the cso module?
> >
> >
> >   
> They will go away once all the remaining consumers of 
> cso_set/save/restore_sampler_textures() switch to 
> cso_*_fragment_sampler_views().

I think they're not needed even now - if you look at the patch I sent
you, it seems like the only thing that happens to the texture pointers
is they get refcounted - but never used for anything...

Keith

Re: [Mesa3d-dev] [RFC] gallium-sampler-view branch merge

[michal <mi...@vm...>]

Keith Whitwell wrote on 2010-03-15 15:19:
> On Mon, 2010-03-15 at 07:08 -0700, michal wrote:
>   
>> michal wrote on 2010-03-12 15:00:
>>     
>>> michal wrote on 2010-03-11 17:59:
>>>   
>>>       
>>>> Keith Whitwell wrote on 2010-03-11 16:16:
>>>>   
>>>>     
>>>>         
>>>>> On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
>>>>>   
>>>>>     
>>>>>       
>>>>>           
>>>>>> Keith Whitwell wrote on 2010-03-11 14:21:
>>>>>>     
>>>>>>       
>>>>>>         
>>>>>>             
>>>>>>> On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>         
>>>>>>>           
>>>>>>>               
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I would like to merge the branch in subject this week. This feature 
>>>>>>>> branch allows state trackers to bind sampler views instead of textures 
>>>>>>>> to shader stages.
>>>>>>>>
>>>>>>>> A sampler view object holds a reference to a texture and also overrides 
>>>>>>>> internal texture format (resource casting) and specifies RGBA swizzle 
>>>>>>>> (needed for GL_EXT_texture_swizzle extension).
>>>>>>>>     
>>>>>>>>         
>>>>>>>>           
>>>>>>>>             
>>>>>>>>                 
>>>>>>> Michal,
>>>>>>>
>>>>>>> I've got some issues with the way the sampler views are being generated
>>>>>>> and used inside the CSO module.
>>>>>>>
>>>>>>> The point of a sampler view is that it gives the driver an opportunity
>>>>>>> to do expensive operations required for special sampling modes (which
>>>>>>> may include copying surface data if hardware is deficient in some way).
>>>>>>>
>>>>>>> This approach works if a sampler view is created once, then used
>>>>>>> multiple times before being deleted.
>>>>>>>
>>>>>>> Unfortunately, it seems the changes to support this in the CSO module
>>>>>>> provide only a single-shot usage model.  Sampler views are created in
>>>>>>> cso_set_XXX_sampler_textures, bound to the context, and then
>>>>>>> dereferenced/destroyed on the next bind.
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>         
>>>>>>>           
>>>>>>>               
>>>>>> The reason CSO code looks like this is because it was meant to be an 
>>>>>> itermediate step towards migration to sampler view model. Fully 
>>>>>> converting all existing state trackers is non-trivial and thus I chose 
>>>>>> this conservative approach. State trackers that do not care about extra 
>>>>>> features a sampler view provides will keep using this one-shot CSO 
>>>>>> interface with the hope that creation of sampler objects is lighweight 
>>>>>> (format matches texture format, swizzle matches native texel layout, 
>>>>>> etc.). 
>>>>>>     
>>>>>>       
>>>>>>         
>>>>>>             
>>>>> On the surface, this hope isn't likely to be fulfilled - lots of
>>>>> hardware doesn't support non-zero first_level.  Most cases of drivers
>>>>> implementing sampler views internally are to catch this issue.
>>>>>
>>>>> Of course, it seems like your branch so leaves the existing
>>>>> driver-specific sampler view code in place, so that there are
>>>>> potentially two implementations of sampler views in those drivers.  
>>>>>
>>>>> I guess this means that you can get away with the current implementation
>>>>> for now, but it prevents drivers actually taking advantage of the fact
>>>>> that these entities exist in the interface -- they will continue to have
>>>>> to duplicate the concept internally until the state trackers and/or CSO
>>>>> module start caching views.
>>>>>
>>>>>   
>>>>>     
>>>>>       
>>>>>           
>>>>>> Ideally, everybody moves on and we stop using CSO for sampler 
>>>>>> views. I prefer putting my effort into incremental migration of state 
>>>>>> trackers rather than caching something that by definition doesn't need 
>>>>>> to be cached.
>>>>>>     
>>>>>>       
>>>>>>         
>>>>>>             
>>>>> The CSO module exists to manage this type of caching on behalf of state
>>>>> trackers.  I would have thought that this was a sensible extension of
>>>>> the existing purpose of the CSO module.
>>>>>
>>>>> Won't all state-trackers implementing APIs which don't expose sampler
>>>>> views to the application require essentially the same caching logic, as
>>>>> is the case with regular state?  Wouldn't it be least effort to do that
>>>>> caching once only in the CSO module?
>>>>>   
>>>>>     
>>>>>       
>>>>>           
>>>> OK, I see your point. I will make the necessary changes and ping you 
>>>> when that's done.
>>>>
>>>>   
>>>>     
>>>>         
>>> Keith,
>>>
>>> I changed my mind, went ahead and implemented sampler view caching in 
>>> mesa state tracker, rather than inside cso context.
>>>
>>> I strongly believe that doing caching on cso side would be slower and 
>>> more complicated. A state tracker has a better understanding of the 
>>> relationship between a texture and sampler view. In case of mesa, this 
>>> is trivial 1-to-1 mapping. Later, when we'll need more sampler views per 
>>> texture, we can have a per-texture cache for that, and yes, the code for 
>>> that would be in cso.
>>>
>>> There are two other state trackers that need to be fixed: xorg and vega. 
>>> The transition should be similar to mesa -- I can help with doing that, 
>>> but I can't do it myself. Once that's done we can purge one-shot sampler 
>>> view wrappers.
>>>
>>> What do you think?
>>>
>>>   
>>>       
>> Keith,
>>
>> I just finished transforming mesa and auxiliary modules to new sampler 
>> view interfaces. The remaining bits are vega and xorg state trackers -- 
>> I will need help with them, but they could be fixed after the merge, as 
>> they are not broken, and just set sampler view in suboptimal fashion.
>>
>> Please review, thanks.
>>     
>
>
> Michal,
>
> Did you get a chance to look at the double-refcounting (views +
> textures) in the cso module?
>
>
>   
They will go away once all the remaining consumers of 
cso_set/save/restore_sampler_textures() switch to 
cso_*_fragment_sampler_views().

Re: [Mesa3d-dev] [RFC] gallium-sampler-view branch merge

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

On Mon, 2010-03-15 at 07:08 -0700, michal wrote:
> michal wrote on 2010-03-12 15:00:
> > michal wrote on 2010-03-11 17:59:
> >   
> >> Keith Whitwell wrote on 2010-03-11 16:16:
> >>   
> >>     
> >>> On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
> >>>   
> >>>     
> >>>       
> >>>> Keith Whitwell wrote on 2010-03-11 14:21:
> >>>>     
> >>>>       
> >>>>         
> >>>>> On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
> >>>>>   
> >>>>>       
> >>>>>         
> >>>>>           
> >>>>>> Hi,
> >>>>>>
> >>>>>> I would like to merge the branch in subject this week. This feature 
> >>>>>> branch allows state trackers to bind sampler views instead of textures 
> >>>>>> to shader stages.
> >>>>>>
> >>>>>> A sampler view object holds a reference to a texture and also overrides 
> >>>>>> internal texture format (resource casting) and specifies RGBA swizzle 
> >>>>>> (needed for GL_EXT_texture_swizzle extension).
> >>>>>>     
> >>>>>>         
> >>>>>>           
> >>>>>>             
> >>>>> Michal,
> >>>>>
> >>>>> I've got some issues with the way the sampler views are being generated
> >>>>> and used inside the CSO module.
> >>>>>
> >>>>> The point of a sampler view is that it gives the driver an opportunity
> >>>>> to do expensive operations required for special sampling modes (which
> >>>>> may include copying surface data if hardware is deficient in some way).
> >>>>>
> >>>>> This approach works if a sampler view is created once, then used
> >>>>> multiple times before being deleted.
> >>>>>
> >>>>> Unfortunately, it seems the changes to support this in the CSO module
> >>>>> provide only a single-shot usage model.  Sampler views are created in
> >>>>> cso_set_XXX_sampler_textures, bound to the context, and then
> >>>>> dereferenced/destroyed on the next bind.
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>         
> >>>>>           
> >>>> The reason CSO code looks like this is because it was meant to be an 
> >>>> itermediate step towards migration to sampler view model. Fully 
> >>>> converting all existing state trackers is non-trivial and thus I chose 
> >>>> this conservative approach. State trackers that do not care about extra 
> >>>> features a sampler view provides will keep using this one-shot CSO 
> >>>> interface with the hope that creation of sampler objects is lighweight 
> >>>> (format matches texture format, swizzle matches native texel layout, 
> >>>> etc.). 
> >>>>     
> >>>>       
> >>>>         
> >>> On the surface, this hope isn't likely to be fulfilled - lots of
> >>> hardware doesn't support non-zero first_level.  Most cases of drivers
> >>> implementing sampler views internally are to catch this issue.
> >>>
> >>> Of course, it seems like your branch so leaves the existing
> >>> driver-specific sampler view code in place, so that there are
> >>> potentially two implementations of sampler views in those drivers.  
> >>>
> >>> I guess this means that you can get away with the current implementation
> >>> for now, but it prevents drivers actually taking advantage of the fact
> >>> that these entities exist in the interface -- they will continue to have
> >>> to duplicate the concept internally until the state trackers and/or CSO
> >>> module start caching views.
> >>>
> >>>   
> >>>     
> >>>       
> >>>> Ideally, everybody moves on and we stop using CSO for sampler 
> >>>> views. I prefer putting my effort into incremental migration of state 
> >>>> trackers rather than caching something that by definition doesn't need 
> >>>> to be cached.
> >>>>     
> >>>>       
> >>>>         
> >>> The CSO module exists to manage this type of caching on behalf of state
> >>> trackers.  I would have thought that this was a sensible extension of
> >>> the existing purpose of the CSO module.
> >>>
> >>> Won't all state-trackers implementing APIs which don't expose sampler
> >>> views to the application require essentially the same caching logic, as
> >>> is the case with regular state?  Wouldn't it be least effort to do that
> >>> caching once only in the CSO module?
> >>>   
> >>>     
> >>>       
> >> OK, I see your point. I will make the necessary changes and ping you 
> >> when that's done.
> >>
> >>   
> >>     
> > Keith,
> >
> > I changed my mind, went ahead and implemented sampler view caching in 
> > mesa state tracker, rather than inside cso context.
> >
> > I strongly believe that doing caching on cso side would be slower and 
> > more complicated. A state tracker has a better understanding of the 
> > relationship between a texture and sampler view. In case of mesa, this 
> > is trivial 1-to-1 mapping. Later, when we'll need more sampler views per 
> > texture, we can have a per-texture cache for that, and yes, the code for 
> > that would be in cso.
> >
> > There are two other state trackers that need to be fixed: xorg and vega. 
> > The transition should be similar to mesa -- I can help with doing that, 
> > but I can't do it myself. Once that's done we can purge one-shot sampler 
> > view wrappers.
> >
> > What do you think?
> >
> >   
> Keith,
> 
> I just finished transforming mesa and auxiliary modules to new sampler 
> view interfaces. The remaining bits are vega and xorg state trackers -- 
> I will need help with them, but they could be fixed after the merge, as 
> they are not broken, and just set sampler view in suboptimal fashion.
> 
> Please review, thanks.


Michal,

Did you get a chance to look at the double-refcounting (views +
textures) in the cso module?

Keith

Re: [Mesa3d-dev] [PATCH] nv40: remove leftover nv40_transfer.c from unification into nvfx

[Younes M. <you...@gm...>]

On Mon, Mar 15, 2010 at 9:35 AM, Luca Barbieri <lu...@lu...> wrote:
> ---
>  src/gallium/drivers/nv40/nv40_transfer.c |  181 ------------------------------
>  1 files changed, 0 insertions(+), 181 deletions(-)
>  delete mode 100644 src/gallium/drivers/nv40/nv40_transfer.c
>
> diff --git a/src/gallium/drivers/nv40/nv40_transfer.c b/src/gallium/drivers/nv40/nv40_transfer.c
> deleted file mode 100644
> index 3d8c8e8..0000000
> --- a/src/gallium/drivers/nv40/nv40_transfer.c
> +++ /dev/null
> @@ -1,181 +0,0 @@
> -#include "pipe/p_state.h"
> -#include "pipe/p_defines.h"
> -#include "util/u_inlines.h"
> -#include "util/u_format.h"
> -#include "util/u_memory.h"
> -#include "util/u_math.h"
> -#include "nouveau/nouveau_winsys.h"
> -#include "nv40_context.h"
> -#include "nvfx_screen.h"
> -#include "nvfx_state.h"
> -
> -struct nv40_transfer {
> -       struct pipe_transfer base;
> -       struct pipe_surface *surface;
> -       boolean direct;
> -};
> -
> -static void
> -nv40_compatible_transfer_tex(struct pipe_texture *pt, unsigned width, unsigned height,
> -                             struct pipe_texture *template)
> -{
> -       memset(template, 0, sizeof(struct pipe_texture));
> -       template->target = pt->target;
> -       template->format = pt->format;
> -       template->width0 = width;
> -       template->height0 = height;
> -       template->depth0 = 1;
> -       template->last_level = 0;
> -       template->nr_samples = pt->nr_samples;
> -
> -       template->tex_usage = PIPE_TEXTURE_USAGE_DYNAMIC |
> -                             NOUVEAU_TEXTURE_USAGE_LINEAR;
> -}
> -
> -static struct pipe_transfer *
> -nv40_transfer_new(struct pipe_context *pcontext, struct pipe_texture *pt,
> -                 unsigned face, unsigned level, unsigned zslice,
> -                 enum pipe_transfer_usage usage,
> -                 unsigned x, unsigned y, unsigned w, unsigned h)
> -{
> -        struct pipe_screen *pscreen = pcontext->screen;
> -       struct nvfx_miptree *mt = (struct nvfx_miptree *)pt;
> -       struct nv40_transfer *tx;
> -       struct pipe_texture tx_tex_template, *tx_tex;
> -
> -       tx = CALLOC_STRUCT(nv40_transfer);
> -       if (!tx)
> -               return NULL;
> -
> -       pipe_texture_reference(&tx->base.texture, pt);
> -       tx->base.x = x;
> -       tx->base.y = y;
> -       tx->base.width = w;
> -       tx->base.height = h;
> -       tx->base.stride = mt->level[level].pitch;
> -       tx->base.usage = usage;
> -       tx->base.face = face;
> -       tx->base.level = level;
> -       tx->base.zslice = zslice;
> -
> -       /* Direct access to texture */
> -       if ((pt->tex_usage & PIPE_TEXTURE_USAGE_DYNAMIC ||
> -            debug_get_bool_option("NOUVEAU_NO_TRANSFER", TRUE/*XXX:FALSE*/)) &&
> -           pt->tex_usage & NOUVEAU_TEXTURE_USAGE_LINEAR)
> -       {
> -               tx->direct = true;
> -               tx->surface = pscreen->get_tex_surface(pscreen, pt,
> -                                                      face, level, zslice,
> -                                                      pipe_transfer_buffer_flags(&tx->base));
> -               return &tx->base;
> -       }
> -
> -       tx->direct = false;
> -
> -       nv40_compatible_transfer_tex(pt, w, h, &tx_tex_template);
> -
> -       tx_tex = pscreen->texture_create(pscreen, &tx_tex_template);
> -       if (!tx_tex)
> -       {
> -               FREE(tx);
> -               return NULL;
> -       }
> -
> -       tx->base.stride = ((struct nvfx_miptree*)tx_tex)->level[0].pitch;
> -
> -       tx->surface = pscreen->get_tex_surface(pscreen, tx_tex,
> -                                              0, 0, 0,
> -                                              pipe_transfer_buffer_flags(&tx->base));
> -
> -       pipe_texture_reference(&tx_tex, NULL);
> -
> -       if (!tx->surface)
> -       {
> -               pipe_surface_reference(&tx->surface, NULL);
> -               FREE(tx);
> -               return NULL;
> -       }
> -
> -       if (usage & PIPE_TRANSFER_READ) {
> -               struct nvfx_screen *nvscreen = nvfx_screen(pscreen);
> -               struct pipe_surface *src;
> -
> -               src = pscreen->get_tex_surface(pscreen, pt,
> -                                              face, level, zslice,
> -                                              PIPE_BUFFER_USAGE_GPU_READ);
> -
> -               /* TODO: Check if SIFM can deal with x,y,w,h when swizzling */
> -               /* TODO: Check if SIFM can un-swizzle */
> -               nvscreen->eng2d->copy(nvscreen->eng2d,
> -                                     tx->surface, 0, 0,
> -                                     src, x, y,
> -                                     w, h);
> -
> -               pipe_surface_reference(&src, NULL);
> -       }
> -
> -       return &tx->base;
> -}
> -
> -static void
> -nv40_transfer_del(struct pipe_context *pcontext, struct pipe_transfer *ptx)
> -{
> -       struct nv40_transfer *tx = (struct nv40_transfer *)ptx;
> -
> -       if (!tx->direct && (ptx->usage & PIPE_TRANSFER_WRITE)) {
> -               struct pipe_screen *pscreen = pcontext->screen;
> -               struct nvfx_screen *nvscreen = nvfx_screen(pscreen);
> -               struct pipe_surface *dst;
> -
> -               dst = pscreen->get_tex_surface(pscreen, ptx->texture,
> -                                              ptx->face, ptx->level, ptx->zslice,
> -                                              PIPE_BUFFER_USAGE_GPU_WRITE | NOUVEAU_BUFFER_USAGE_NO_RENDER);
> -
> -               /* TODO: Check if SIFM can deal with x,y,w,h when swizzling */
> -               nvscreen->eng2d->copy(nvscreen->eng2d,
> -                                     dst, tx->base.x, tx->base.y,
> -                                     tx->surface, 0, 0,
> -                                     tx->base.width, tx->base.height);
> -
> -               pipe_surface_reference(&dst, NULL);
> -       }
> -
> -       pipe_surface_reference(&tx->surface, NULL);
> -       pipe_texture_reference(&ptx->texture, NULL);
> -       FREE(ptx);
> -}
> -
> -static void *
> -nv40_transfer_map(struct pipe_context *pcontext, struct pipe_transfer *ptx)
> -{
> -        struct pipe_screen *pscreen = pcontext->screen;
> -       struct nv40_transfer *tx = (struct nv40_transfer *)ptx;
> -       struct nv04_surface *ns = (struct nv04_surface *)tx->surface;
> -       struct nvfx_miptree *mt = (struct nvfx_miptree *)tx->surface->texture;
> -       void *map = pipe_buffer_map(pscreen, mt->buffer,
> -                                   pipe_transfer_buffer_flags(ptx));
> -
> -       if(!tx->direct)
> -               return map + ns->base.offset;
> -       else
> -               return map + ns->base.offset + ptx->y * ns->pitch + ptx->x * util_format_get_blocksize(ptx->texture->format);
> -}
> -
> -static void
> -nv40_transfer_unmap(struct pipe_context *pcontext, struct pipe_transfer *ptx)
> -{
> -        struct pipe_screen *pscreen = pcontext->screen;
> -       struct nv40_transfer *tx = (struct nv40_transfer *)ptx;
> -       struct nvfx_miptree *mt = (struct nvfx_miptree *)tx->surface->texture;
> -
> -       pipe_buffer_unmap(pscreen, mt->buffer);
> -}
> -
> -void
> -nv40_init_transfer_functions(struct nvfx_context *nvfx)
> -{
> -       nvfx->pipe.get_tex_transfer = nv40_transfer_new;
> -       nvfx->pipe.tex_transfer_destroy = nv40_transfer_del;
> -       nvfx->pipe.transfer_map = nv40_transfer_map;
> -       nvfx->pipe.transfer_unmap = nv40_transfer_unmap;
> -}
> --
> 1.6.3.3
>
>

Pushed. Thanks.

Re: [Mesa3d-dev] [RFC] gallium-sampler-view branch merge

[michal <mi...@vm...>]

michal wrote on 2010-03-12 15:00:
> michal wrote on 2010-03-11 17:59:
>   
>> Keith Whitwell wrote on 2010-03-11 16:16:
>>   
>>     
>>> On Thu, 2010-03-11 at 06:05 -0800, michal wrote:
>>>   
>>>     
>>>       
>>>> Keith Whitwell wrote on 2010-03-11 14:21:
>>>>     
>>>>       
>>>>         
>>>>> On Thu, 2010-03-11 at 03:16 -0800, michal wrote:
>>>>>   
>>>>>       
>>>>>         
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>> I would like to merge the branch in subject this week. This feature 
>>>>>> branch allows state trackers to bind sampler views instead of textures 
>>>>>> to shader stages.
>>>>>>
>>>>>> A sampler view object holds a reference to a texture and also overrides 
>>>>>> internal texture format (resource casting) and specifies RGBA swizzle 
>>>>>> (needed for GL_EXT_texture_swizzle extension).
>>>>>>     
>>>>>>         
>>>>>>           
>>>>>>             
>>>>> Michal,
>>>>>
>>>>> I've got some issues with the way the sampler views are being generated
>>>>> and used inside the CSO module.
>>>>>
>>>>> The point of a sampler view is that it gives the driver an opportunity
>>>>> to do expensive operations required for special sampling modes (which
>>>>> may include copying surface data if hardware is deficient in some way).
>>>>>
>>>>> This approach works if a sampler view is created once, then used
>>>>> multiple times before being deleted.
>>>>>
>>>>> Unfortunately, it seems the changes to support this in the CSO module
>>>>> provide only a single-shot usage model.  Sampler views are created in
>>>>> cso_set_XXX_sampler_textures, bound to the context, and then
>>>>> dereferenced/destroyed on the next bind.
>>>>>
>>>>>   
>>>>>       
>>>>>         
>>>>>           
>>>> The reason CSO code looks like this is because it was meant to be an 
>>>> itermediate step towards migration to sampler view model. Fully 
>>>> converting all existing state trackers is non-trivial and thus I chose 
>>>> this conservative approach. State trackers that do not care about extra 
>>>> features a sampler view provides will keep using this one-shot CSO 
>>>> interface with the hope that creation of sampler objects is lighweight 
>>>> (format matches texture format, swizzle matches native texel layout, 
>>>> etc.). 
>>>>     
>>>>       
>>>>         
>>> On the surface, this hope isn't likely to be fulfilled - lots of
>>> hardware doesn't support non-zero first_level.  Most cases of drivers
>>> implementing sampler views internally are to catch this issue.
>>>
>>> Of course, it seems like your branch so leaves the existing
>>> driver-specific sampler view code in place, so that there are
>>> potentially two implementations of sampler views in those drivers.  
>>>
>>> I guess this means that you can get away with the current implementation
>>> for now, but it prevents drivers actually taking advantage of the fact
>>> that these entities exist in the interface -- they will continue to have
>>> to duplicate the concept internally until the state trackers and/or CSO
>>> module start caching views.
>>>
>>>   
>>>     
>>>       
>>>> Ideally, everybody moves on and we stop using CSO for sampler 
>>>> views. I prefer putting my effort into incremental migration of state 
>>>> trackers rather than caching something that by definition doesn't need 
>>>> to be cached.
>>>>     
>>>>       
>>>>         
>>> The CSO module exists to manage this type of caching on behalf of state
>>> trackers.  I would have thought that this was a sensible extension of
>>> the existing purpose of the CSO module.
>>>
>>> Won't all state-trackers implementing APIs which don't expose sampler
>>> views to the application require essentially the same caching logic, as
>>> is the case with regular state?  Wouldn't it be least effort to do that
>>> caching once only in the CSO module?
>>>   
>>>     
>>>       
>> OK, I see your point. I will make the necessary changes and ping you 
>> when that's done.
>>
>>   
>>     
> Keith,
>
> I changed my mind, went ahead and implemented sampler view caching in 
> mesa state tracker, rather than inside cso context.
>
> I strongly believe that doing caching on cso side would be slower and 
> more complicated. A state tracker has a better understanding of the 
> relationship between a texture and sampler view. In case of mesa, this 
> is trivial 1-to-1 mapping. Later, when we'll need more sampler views per 
> texture, we can have a per-texture cache for that, and yes, the code for 
> that would be in cso.
>
> There are two other state trackers that need to be fixed: xorg and vega. 
> The transition should be similar to mesa -- I can help with doing that, 
> but I can't do it myself. Once that's done we can purge one-shot sampler 
> view wrappers.
>
> What do you think?
>
>   
Keith,

I just finished transforming mesa and auxiliary modules to new sampler 
view interfaces. The remaining bits are vega and xorg state trackers -- 
I will need help with them, but they could be fixed after the merge, as 
they are not broken, and just set sampler view in suboptimal fashion.

Please review, thanks.

[Mesa3d-dev] [PATCH] dri: link DRI drivers with -Wl, --no-undefined -lGL

[Luca B. <lu...@lu...>]

Right now undefined symbols in DRI drivers will still allow the
build to succeed.

As a result, people modifying drivers they cannot test risk creating
unloadable drivers with no easy way of automatically avoiding it.

For instance, the modifications to nv50 for context transfers caused
such an issue recently.

The fix is to build DRI drivers with -Wl,--no-undefined -lGL which
will cause make to fail in such cases.

Note that this introduces a dependency from the DRI drivers on libGL.so.1.
However, the driver loader calls dlopen on libGL.so.1 with
RTLD_GLOBAL | RTLD_NOW before loading any DRI driver, so the added
dependency shouldn't cause changes in runtime behavior.

Please double-check the correctness of this assumption before pushing.

All classic DRI drivers as well as all the Gallium drivers with configure
options compiled successfully with this change.

Thanks to Xavier Chantry <cha...@gm...> for helping with this.
---
 src/gallium/winsys/drm/Makefile.template |    4 ++--
 src/mesa/drivers/dri/Makefile.template   |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/winsys/drm/Makefile.template b/src/gallium/winsys/drm/Makefile.template
index f4cc0de..326cd59 100644
--- a/src/gallium/winsys/drm/Makefile.template
+++ b/src/gallium/winsys/drm/Makefile.template
@@ -66,9 +66,9 @@ default: depend symlinks $(TOP)/$(LIB_DIR)/gallium/$(LIBNAME)
 $(LIBNAME): $(OBJECTS) $(MESA_MODULES) $(PIPE_DRIVERS) Makefile \
 		$(TOP)/src/mesa/drivers/dri/Makefile.template
 	$(MKLIB) -o $@ -noprefix -linker '$(CC)' -ldflags '$(LDFLAGS)' \
-		$(OBJECTS) $(PIPE_DRIVERS) \
+		-Wl,--no-undefined $(OBJECTS) $(PIPE_DRIVERS) \
                 -Wl,--start-group $(MESA_MODULES) -Wl,--end-group \
-                 $(DRI_LIB_DEPS) $(DRIVER_EXTRAS)
+                 $(DRI_LIB_DEPS) $(DRIVER_EXTRAS) -L$(TOP)/lib -lGL
 
 $(TOP)/$(LIB_DIR)/gallium:
 	mkdir -p $@
diff --git a/src/mesa/drivers/dri/Makefile.template b/src/mesa/drivers/dri/Makefile.template
index a0c25d2..dcffa70 100644
--- a/src/mesa/drivers/dri/Makefile.template
+++ b/src/mesa/drivers/dri/Makefile.template
@@ -53,7 +53,7 @@ lib: symlinks subdirs depend
 $(LIBNAME): $(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) Makefile \
 		$(TOP)/src/mesa/drivers/dri/Makefile.template
 	$(MKLIB) -o $@ -noprefix -linker '$(CC)' -ldflags '$(LDFLAGS)' \
-		$(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) $(DRI_LIB_DEPS)
+		-Wl,--no-undefined $(OBJECTS) $(MESA_MODULES) $(EXTRA_MODULES) $(DRI_LIB_DEPS) -L$(TOP)/lib -lGL
 
 
 $(TOP)/$(LIB_DIR)/$(LIBNAME): $(LIBNAME)
-- 
1.6.3.3

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

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

On Mon, Mar 15, 2010 at 2:30 PM, Luca Barbieri <lu...@lu...> wrote:
> Adding both -Wl,--no-undefined and -lGL (in
> src/gallium/winsys/drm/Makefile.template) seems to work for me.
>

Oh great, that works for me too !

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

[Luca B. <lu...@lu...>]

Adding both -Wl,--no-undefined and -lGL (in
src/gallium/winsys/drm/Makefile.template) seems to work for me.

The driver loader is already loading libGL.so.1 with RTLD_NOW |
RTLD_GLOBAL, so I think that the DRI driver depending on libGL.so.1
shouldn't introduce any issue.

[Mesa3d-dev] [PATCH] nv40: remove leftover nv40_transfer.c from unification into nvfx

[Luca B. <lu...@lu...>]

---
 src/gallium/drivers/nv40/nv40_transfer.c |  181 ------------------------------
 1 files changed, 0 insertions(+), 181 deletions(-)
 delete mode 100644 src/gallium/drivers/nv40/nv40_transfer.c

diff --git a/src/gallium/drivers/nv40/nv40_transfer.c b/src/gallium/drivers/nv40/nv40_transfer.c
deleted file mode 100644
index 3d8c8e8..0000000
--- a/src/gallium/drivers/nv40/nv40_transfer.c
+++ /dev/null
@@ -1,181 +0,0 @@
-#include "pipe/p_state.h"
-#include "pipe/p_defines.h"
-#include "util/u_inlines.h"
-#include "util/u_format.h"
-#include "util/u_memory.h"
-#include "util/u_math.h"
-#include "nouveau/nouveau_winsys.h"
-#include "nv40_context.h"
-#include "nvfx_screen.h"
-#include "nvfx_state.h"
-
-struct nv40_transfer {
-	struct pipe_transfer base;
-	struct pipe_surface *surface;
-	boolean direct;
-};
-
-static void
-nv40_compatible_transfer_tex(struct pipe_texture *pt, unsigned width, unsigned height,
-                             struct pipe_texture *template)
-{
-	memset(template, 0, sizeof(struct pipe_texture));
-	template->target = pt->target;
-	template->format = pt->format;
-	template->width0 = width;
-	template->height0 = height;
-	template->depth0 = 1;
-	template->last_level = 0;
-	template->nr_samples = pt->nr_samples;
-
-	template->tex_usage = PIPE_TEXTURE_USAGE_DYNAMIC |
-	                      NOUVEAU_TEXTURE_USAGE_LINEAR;
-}
-
-static struct pipe_transfer *
-nv40_transfer_new(struct pipe_context *pcontext, struct pipe_texture *pt,
-		  unsigned face, unsigned level, unsigned zslice,
-		  enum pipe_transfer_usage usage,
-		  unsigned x, unsigned y, unsigned w, unsigned h)
-{
-        struct pipe_screen *pscreen = pcontext->screen;
-	struct nvfx_miptree *mt = (struct nvfx_miptree *)pt;
-	struct nv40_transfer *tx;
-	struct pipe_texture tx_tex_template, *tx_tex;
-
-	tx = CALLOC_STRUCT(nv40_transfer);
-	if (!tx)
-		return NULL;
-
-	pipe_texture_reference(&tx->base.texture, pt);
-	tx->base.x = x;
-	tx->base.y = y;
-	tx->base.width = w;
-	tx->base.height = h;
-	tx->base.stride = mt->level[level].pitch;
-	tx->base.usage = usage;
-	tx->base.face = face;
-	tx->base.level = level;
-	tx->base.zslice = zslice;
-
-	/* Direct access to texture */
-	if ((pt->tex_usage & PIPE_TEXTURE_USAGE_DYNAMIC ||
-	     debug_get_bool_option("NOUVEAU_NO_TRANSFER", TRUE/*XXX:FALSE*/)) &&
-	    pt->tex_usage & NOUVEAU_TEXTURE_USAGE_LINEAR)
-	{
-		tx->direct = true;
-		tx->surface = pscreen->get_tex_surface(pscreen, pt,
-	                                               face, level, zslice,
-	                                               pipe_transfer_buffer_flags(&tx->base));
-		return &tx->base;
-	}
-
-	tx->direct = false;
-
-	nv40_compatible_transfer_tex(pt, w, h, &tx_tex_template);
-
-	tx_tex = pscreen->texture_create(pscreen, &tx_tex_template);
-	if (!tx_tex)
-	{
-		FREE(tx);
-		return NULL;
-	}
-
-	tx->base.stride = ((struct nvfx_miptree*)tx_tex)->level[0].pitch;
-
-	tx->surface = pscreen->get_tex_surface(pscreen, tx_tex,
-	                                       0, 0, 0,
-	                                       pipe_transfer_buffer_flags(&tx->base));
-
-	pipe_texture_reference(&tx_tex, NULL);
-
-	if (!tx->surface)
-	{
-		pipe_surface_reference(&tx->surface, NULL);
-		FREE(tx);
-		return NULL;
-	}
-
-	if (usage & PIPE_TRANSFER_READ) {
-		struct nvfx_screen *nvscreen = nvfx_screen(pscreen);
-		struct pipe_surface *src;
-
-		src = pscreen->get_tex_surface(pscreen, pt,
-	                                       face, level, zslice,
-	                                       PIPE_BUFFER_USAGE_GPU_READ);
-
-		/* TODO: Check if SIFM can deal with x,y,w,h when swizzling */
-		/* TODO: Check if SIFM can un-swizzle */
-		nvscreen->eng2d->copy(nvscreen->eng2d,
-		                      tx->surface, 0, 0,
-		                      src, x, y,
-		                      w, h);
-
-		pipe_surface_reference(&src, NULL);
-	}
-
-	return &tx->base;
-}
-
-static void
-nv40_transfer_del(struct pipe_context *pcontext, struct pipe_transfer *ptx)
-{
-	struct nv40_transfer *tx = (struct nv40_transfer *)ptx;
-
-	if (!tx->direct && (ptx->usage & PIPE_TRANSFER_WRITE)) {
-		struct pipe_screen *pscreen = pcontext->screen;
-		struct nvfx_screen *nvscreen = nvfx_screen(pscreen);
-		struct pipe_surface *dst;
-
-		dst = pscreen->get_tex_surface(pscreen, ptx->texture,
-	                                       ptx->face, ptx->level, ptx->zslice,
-	                                       PIPE_BUFFER_USAGE_GPU_WRITE | NOUVEAU_BUFFER_USAGE_NO_RENDER);
-
-		/* TODO: Check if SIFM can deal with x,y,w,h when swizzling */
-		nvscreen->eng2d->copy(nvscreen->eng2d,
-		                      dst, tx->base.x, tx->base.y,
-		                      tx->surface, 0, 0,
-		                      tx->base.width, tx->base.height);
-
-		pipe_surface_reference(&dst, NULL);
-	}
-
-	pipe_surface_reference(&tx->surface, NULL);
-	pipe_texture_reference(&ptx->texture, NULL);
-	FREE(ptx);
-}
-
-static void *
-nv40_transfer_map(struct pipe_context *pcontext, struct pipe_transfer *ptx)
-{
-        struct pipe_screen *pscreen = pcontext->screen;
-	struct nv40_transfer *tx = (struct nv40_transfer *)ptx;
-	struct nv04_surface *ns = (struct nv04_surface *)tx->surface;
-	struct nvfx_miptree *mt = (struct nvfx_miptree *)tx->surface->texture;
-	void *map = pipe_buffer_map(pscreen, mt->buffer,
-	                            pipe_transfer_buffer_flags(ptx));
-
-	if(!tx->direct)
-		return map + ns->base.offset;
-	else
-		return map + ns->base.offset + ptx->y * ns->pitch + ptx->x * util_format_get_blocksize(ptx->texture->format);
-}
-
-static void
-nv40_transfer_unmap(struct pipe_context *pcontext, struct pipe_transfer *ptx)
-{
-        struct pipe_screen *pscreen = pcontext->screen;
-	struct nv40_transfer *tx = (struct nv40_transfer *)ptx;
-	struct nvfx_miptree *mt = (struct nvfx_miptree *)tx->surface->texture;
-
-	pipe_buffer_unmap(pscreen, mt->buffer);
-}
-
-void
-nv40_init_transfer_functions(struct nvfx_context *nvfx)
-{
-	nvfx->pipe.get_tex_transfer = nv40_transfer_new;
-	nvfx->pipe.tex_transfer_destroy = nv40_transfer_del;
-	nvfx->pipe.transfer_map = nv40_transfer_map;
-	nvfx->pipe.transfer_unmap = nv40_transfer_unmap;
-}
-- 
1.6.3.3

Re: [Mesa3d-dev] [PATCHes] RFC: detect TLS during configuration

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

On Sun, Mar 14, 2010 at 5:38 PM, tom fogal <tf...@al...> wrote:
> It was a long while back that I wondered && somehow ended up
> volunteering to detect platform TLS support, + enable it in Mesa / the
> X server if available.
>
> I got distracted before finishing the X parts, but rebased the Mesa
> parts, which are attached.
>
> One thing I'm worried about is using an AC macro archive macro here;
> it's GPL + an exception that "configure" (the output) is unrestricted.
> I'm not sure that'll be kosher for Mesa.

I don't think license of the build files affects the license of the
code. We're already using lots of macros from autoconf that are almost
certainly GPL.

> OTOH, the macro is dead simple.
>
> Comments?

I think I'd prefer if you added the macro directly to acinclude.m4
instead of adding more macro files. If we're going to do that, I'd
rather have an explicit m4 directory. I don't think mesa quite needs
that, though.

Changing TLS to autodetect might be a good thing down the road, but I
think we need to at least have the xserver following the settings
before we make this change. Otherwise, nearly everybody is suddenly
going to get TLS enabled in the DRI drivers who don't know they need
to start passing another option to the xserver.

So, I'd rather see these two patches broken up differently.

1. Export glx_tls from gl.pc
2. Autodetect TLS usage

Then we can hold off applying 2 until we have the xserver part landed
and we think it's safe to start defaulting (essentially) to using TLS.

--
Dan

Re: [Mesa3d-dev] xdemos build breakage...

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

On Mon, Mar 15, 2010 at 5:24 AM, Julien Cristau <jcr...@de...> wrote:
> On Sat, Mar 13, 2010 at 20:20:36 -0800, Jeff Smith wrote:
>> Except that AC_PATH_XTRA returns X_LIBS without '-lX11', while
>> PKG_CHECK_MODULES returns X_LIBS with it.  In the attached patch
>> I add '-lX11' to the former.  Of course, with '-lX11' as part of X_LIBS, the
>> explicit '-lX11' can be removed from the places that use X_LIBS.
>>
> If this wants -lX11, then it should use AC_PATH_X, not AC_PATH_XTRA,
> though?

AC_PATH_XTRA is just AC_PATH_X with some additional crap to make
compiling/linking X programs work on various platforms. I think Jeff
is right. I'd forgotten that AC_PATH_X* doesn't actually add the -lX11
to the X_LIBS variable.

Jeff, it should get swapped back around to what you had in your patch
and a s/X_\(CFLAGS\|LIBS\)/X11_\1/g across the rest of the files. I
can put that together a little later if you don't have time to make
another patch on master.

--
Dan

Re: [Mesa3d-dev] xdemos build breakage...

[Julien C. <jcr...@de...>]

On Sat, Mar 13, 2010 at 20:20:36 -0800, Jeff Smith wrote:
> Except that AC_PATH_XTRA returns X_LIBS without '-lX11', while
> PKG_CHECK_MODULES returns X_LIBS with it.  In the attached patch
> I add '-lX11' to the former.  Of course, with '-lX11' as part of X_LIBS, the
> explicit '-lX11' can be removed from the places that use X_LIBS.
> 
If this wants -lX11, then it should use AC_PATH_X, not AC_PATH_XTRA,
though?

Cheers,
Julien

Re: [Mesa3d-dev] undefined symbols and silent fallback to swrast

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

2010/3/15 Michel Dänzer <mi...@da...>:
>
> One problem is that drivers can be loaded from several paths; if the HW
> driver fails to load from the first path but succeeds from the next one,
> any error messages from the first attempt would be confusing.
>

If it fails to load because it does not exist ? Or because it exists
but has undefined symbols or other problems ?
It makes sense to not display the first case, but what about the second ?

And what if the driver cannot be found in any places ?

Here are two examples :

1) If swrast can be found

With current mesa master :
libGL error: dlopen /home/xavier/app/mesa/lib/gallium/nouveau_dri.so
failed (/home/xavier/app/mesa/lib/gallium/nouveau_dri.so: undefined
symbol: nv50_transfer_init_screen_functions)
libGL error: dlopen /home/xavier/app/mesa/lib/nouveau_dri.so failed
(/home/xavier/app/mesa/lib/nouveau_dri.so: cannot open shared object
file: No such file or directory)
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: dlopen /home/xavier/app/mesa/lib/gallium/swrast_dri.so
failed (/home/xavier/app/mesa/lib/gallium/swrast_dri.so: cannot open
shared object file: No such file or directory)
Mesa: Mesa 7.9-devel DEBUG build Mar 15 2010 01:44:03
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
2623 frames in 5.0 seconds = 524.588 FPS

The first swrast_dri.so error is indeed misleading as it was loaded
fine afterwards. Well we don't need to display that.
libGL error: dlopen /home/xavier/app/mesa/lib/gallium/nouveau_dri.so
failed (/home/xavier/app/mesa/lib/gallium/nouveau_dri.so: undefined
symbol: nv50_transfer_init_screen_functions)
libGL error: unable to load driver: nouveau_dri.so
libGL error: reverting to software direct rendering
Mesa: Mesa 7.9-devel DEBUG build Mar 15 2010 01:44:03
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
2708 frames in 5.0 seconds = 541.526 FPS

2) If swrast cannot be found

libGL error: dlopen /home/xavier/app/mesa/lib/gallium/nouveau_dri.so
failed (/home/xavier/app/mesa/lib/gallium/nouveau_dri.so: undefined
symbol: nv50_transfer_init_screen_functions)
libGL error: dlopen /home/xavier/app/mesa/lib/gallium2/nouveau_dri.so
failed (/home/xavier/app/mesa/lib/gallium2/nouveau_dri.so: cannot open
shared object file: No such file or directory)
libGL error: unable to load driver: nouveau_dri.so
libGL error: driver pointer missing
libGL error: dlopen /home/xavier/app/mesa/lib/gallium/swrast_dri.so
failed (/home/xavier/app/mesa/lib/gallium/swrast_dri.so: cannot open
shared object file: No such file or directory)
libGL error: dlopen /home/xavier/app/mesa/lib/gallium2/swrast_dri.so
failed (/home/xavier/app/mesa/lib/gallium2/swrast_dri.so: cannot open
shared object file: No such file or directory)
libGL error: unable to load driver: swrast_dri.so
libGL error: reverting to indirect rendering
3299 frames in 5.0 seconds = 658.631 FPS

could be changed to :
libGL error: dlopen /home/xavier/app/mesa/lib/gallium/nouveau_dri.so
failed (/home/xavier/app/mesa/lib/gallium/nouveau_dri.so: undefined
symbol: nv50_transfer_init_screen_functions)
libGL error: unable to load driver: nouveau_dri.so
libGL error: reverting to software direct rendering
libGL error: swrast_dri.so not found in
/home/xavier/app/mesa/lib/gallium:/home/xavier/app/mesa/lib/gallium2
libGL error: unable to load driver: swrast_dri.so
libGL error: reverting to indirect rendering
2981 frames in 5.1 seconds = 590.078 FPS


In these two examples I only compared the different behavior with
swrast which is a valid driver, but can either be found or not.
nouveau_dri is invalid however with undefined symbols, any reason for
not displaying that all the time ?

Re: [Mesa3d-dev] Merging gallium-st-api

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

On Mon, 2010-03-15 at 04:27 -0700, Chia-I Wu wrote:
> Hi list,
> 
> gallium-st-api has come to the point that st/glx passes as many piglit
> quick tests as st/glx in master does.  I'd like to merge it to master
> some time this week.
> 
> gallium-st-api implements a new interface, st_api.h, that aims to be a
> replacement for st_public.h.  The new interface paves the way to
> implement various EGL specific features.  Meanwhile, it is hopefully
> st_public.h done right.  pipe_screen::flush_frontbuffer, which needs a
> pipe_screen-specific winsys drawable handle, is no longer called
> directly by st/mesa.  pipe_screen::update_buffer is no longer needed,
> and the validation of drawables is done only when the drawable has
> changed (resized or buffers swapped).
> 
> st_api.h can coexist with st_public.h.  It has been implemented by both
> st/mesa and st/vega.  Co state trackers, however, can only choose to use
> one of the interfaces.  st/glx and st/egl have been converted to use
> st_api.h.  The plan is to convert st/dri and st/wgl to st_api.h after
> the merge, and then drop st_public.h support.  Work on EGLImage
> extensions will start also after the merge.
> 
> Let me know if there is any concern.
> 

I'm very happy to see it merged - it's a nice cleanup of the
state-tracker behaviours.

Keith

[Mesa3d-dev] [Bug 27065] build failure: No rule to make target `../../../../src/gallium/drivers/softpipe/sp_winsys.h', needed by `x11/native_ximage.o'.

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

http://bugs.freedesktop.org/show_bug.cgi?id=27065


Chia-I Wu <ol...@gm...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |NOTABUG




--- Comment #3 from Chia-I Wu <ol...@gm...>  2010-03-15 04:31:17 PST ---
make clean should remove the mentioned files.  It's probably that egl is not in
your GALLIUM_STATE_TRACKERS_DIRS.  I am closing the bug.  Feel free to reopen
if the issue recurs.


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

[Mesa3d-dev] Merging gallium-st-api

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

Hi list,

gallium-st-api has come to the point that st/glx passes as many piglit
quick tests as st/glx in master does.  I'd like to merge it to master
some time this week.

gallium-st-api implements a new interface, st_api.h, that aims to be a
replacement for st_public.h.  The new interface paves the way to
implement various EGL specific features.  Meanwhile, it is hopefully
st_public.h done right.  pipe_screen::flush_frontbuffer, which needs a
pipe_screen-specific winsys drawable handle, is no longer called
directly by st/mesa.  pipe_screen::update_buffer is no longer needed,
and the validation of drawables is done only when the drawable has
changed (resized or buffers swapped).

st_api.h can coexist with st_public.h.  It has been implemented by both
st/mesa and st/vega.  Co state trackers, however, can only choose to use
one of the interfaces.  st/glx and st/egl have been converted to use
st_api.h.  The plan is to convert st/dri and st/wgl to st_api.h after
the merge, and then drop st_public.h support.  Work on EGLImage
extensions will start also after the merge.

Let me know if there is any concern.

-- 
ol...@Lu...

Re: [Mesa3d-dev] plumbing for gallium swrast_dri.so

[George S. <gsa...@gm...>]

On Mon, Mar 15, 2010 at 3:11 AM, Ian Romanick <id...@fr...> wrote:
>
> If you're going to do this, please make a separate driver.  Call it
> swrastg or something.  I use swrast for testing new core Mesa features
> that I implement, and I don't want to be forced to muck about with
> Gallium to do that.
>
sure, it will be called swrastg_dri.so and selected with
LIBGL_GALLIUM_SOFTWARE or something with lowest priority.