mesa3d-dev

Re: [Mesa3d-dev] [PATCH] dri/r700: Include shader/programopt.h instead of programopt.c.

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

Committed.  Thanks.

-Brian

On Fri, Mar 12, 2010 at 12:38 AM, Luc Verhaegen <li...@sk...> wrote:
> Luc Verhaegen.
>
> ------------------------------------------------------------------------------
> Download Intel&#174; 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
>
>

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

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

On Fri, Mar 12, 2010 at 6:48 AM, Jeff Smith <why...@ya...> wrote:
>> This change:
>>
>> commit d888bbc45a84946cafb4f4d2c89681a580cd89bc
>> Author: Brian Paul <br...@vm...>
>> Date:   Tue Nov 17 13:39:13 2009 -0700
>>
>>    progs/xdemos: added -lX11 -lpthread for GNU gold linker
>>
>> breaks the build if you are building under a specific path prefix
>> (say, /opt/XORG) and you have an existing X11 installation in the
>> usual location (/usr, etc.)
>
> I found the same problem and sent a patch to this list a few hours ago to address it:
>
> "[PATCH] Add -L$(libdir) for xdemos and egl so that the right libX11 is found"

That's not really the right thing, though. You're assuming that I have
libX11 in the same libdir as I'm installing to and I want to use it.
The fact is that configure uses pkg-config to check for x11 and other
libraries needed to link the demos. It certainly was working before
without requiring hardcoding things into the Makefiles.

--
Dan

Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.

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

On Fri, 2010-03-12 at 06:54 -0800, Luca Barbieri wrote:
> What if you have a non-integer min LOD?
> While the integer part may belong to the sampler view, the fractional
> part really seems to be a sampler property.
> Requiring min_lod < 1.0 also doesn't seem to make much sense, so
> shouldn't it be kept as it is now?
> Same thing for last_level / max_lod.

Hmm, I see your point.  Fractional values don't have a lot of meaning in
the views, but without a fraction from somewhere we don't capture all of
GL semantics.

I guess this is the underlying reason GL has such a wide variety of ways
of specifying the min/max level also.

And finally, it seems like DX10 has done the same thing - with both
integer min/max in views and float min/max in the sampler state.

It looks like we really do want to keep them both.

Keith

Re: [Mesa3d-dev] [PATCH] Change some int64_t's to uint64_t's, to match CARD64's signedness

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

I'd like one of the other DRI developers to double-check this patch
but the others look fine.  I'll commit them soon.

-Brian


On Thu, Mar 11, 2010 at 9:13 PM, Jeff Smith <why...@ya...> wrote:
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

Re: [Mesa3d-dev] util_format cleanup leftover: Gallium BGRA vertex swizzles

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

On Thu, 2010-03-11 at 17:50 -0800, Marek Olšák wrote:
> Please see this commit:
> http://cgit.freedesktop.org/~mareko/mesa/commit/?id=177a4432aa88fc68d83895ae71b7ad2c86a1e7e3
> 
> Subject: [PATCH] gallium: fix BGRA vertex color swizzles
> 
> The mapping for vertex_array_bgra:
> (gl -> st -> translate)
> GL_RGBA -> PIPE_FORMAT_R8G8B8A8 (RGBA) -> no swizzle (XYZW)
> GL_BGRA -> PIPE_FORMAT_A8R8G8B8 (ARGB) -> ZYXW (BGRA again??)
> 
> Iẗ́'s pretty clear that PIPE_FORMAT_A8R8G8B8 here is wrong. This
> commit
> fixes the pipe format and removes obvious workarounds in
> util/translate.
> 
> Tested with: softpipe, llvmpipe, r300g.
> 
> Please review.

Marek,

Well spotted.

These were cases where formats were being used inconsistently in respect
to their LSB->MSB vs MSB->LSB meanings and my automatic format rename
did no more than flipping the inconsistency the otherway around.

Looks good to me.

I've went ahead and commited since I needed to fix up other state
trackers.

Jose

Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.

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

What if you have a non-integer min LOD?
While the integer part may belong to the sampler view, the fractional
part really seems to be a sampler property.
Requiring min_lod < 1.0 also doesn't seem to make much sense, so
shouldn't it be kept as it is now?
Same thing for last_level / max_lod.

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

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

> This change:
> 
> commit d888bbc45a84946cafb4f4d2c89681a580cd89bc
> Author: Brian Paul <br...@vm...>
> Date:   Tue Nov 17 13:39:13 2009 -0700
> 
>    progs/xdemos: added -lX11 -lpthread for GNU gold linker
> 
> breaks the build if you are building under a specific path prefix
> (say, /opt/XORG) and you have an existing X11 installation in the
> usual location (/usr, etc.)

I found the same problem and sent a patch to this list a few hours ago to address it:

"[PATCH] Add -L$(libdir) for xdemos and egl so that the right libX11 is found"

 -- Jeff Smith



      

Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.

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

On Fri, 2010-03-12 at 06:19 -0800, Christoph Bumiller wrote:
> On 12.03.2010 15:08, michal wrote:
> > Keith Whitwell wrote on 2010-03-12 14:46:
> >   
> >> Michal,
> >>
> >> Is the intention to have >1 sampler view active in the Mesa state
> >> tracker, specifically in the cases where min_lod varies?
> >>
> >> In other words, you seem to have two ways of specifying the same state:
> >>
> >>   pipe_sampler_view::first_level
> >>
> >> and
> >>
> >>   pipe_sampler::min_lod
> >>
> >> Is there a case to keep both of these?  Or is one enough?
> >>
> >>   
> >>     
> > It looks like one has to go away, and that would be 
> > pipe_sampler::min_lod. And we want to have a per-texture cache of 
> > sampler views in mesa.
> >
> >   
> But there *is* a difference between
> GL_TEXTURE_MIN_LOD
> and
> GL_TEXTURE_BASE_LEVEL
> which those two seem to reflect.
> 
> How do you implement that if you just remove one ?

Note that we currently only have the one (sampler::min_lod), and the
other is a synonym for the same value that has been introduced by this
branch.

Those GL values are currently both consolidated down by the mesa
state-tracker (along with other stuff) into sampler::min_lod. 

Although Michal has chosen a different name for the new member, it has
the same meaning and the GL semantics can be implemented on top of it as
they currently are for sampler::min_lod.

Keith

Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.

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

On Fri, 2010-03-12 at 06:08 -0800, michal wrote:
> Keith Whitwell wrote on 2010-03-12 14:46:
> > Michal,
> >
> > Is the intention to have >1 sampler view active in the Mesa state
> > tracker, specifically in the cases where min_lod varies?
> >
> > In other words, you seem to have two ways of specifying the same state:
> >
> >   pipe_sampler_view::first_level
> >
> > and
> >
> >   pipe_sampler::min_lod
> >
> > Is there a case to keep both of these?  Or is one enough?
> >
> >   
> It looks like one has to go away, and that would be 
> pipe_sampler::min_lod. And we want to have a per-texture cache of 
> sampler views in mesa.

OK, I'm fine with this if you're ok to go ahead and implement the
caching.

It's worth noting that drivers can discard any vram backing sampler
views at any time (when they're not in use), so if we have a situation
where large numbers of views are gobbling up vram, the driver has the
option of running though all the views and discarding their cached
contents.

Keith

Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.

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

On Fri, 2010-03-12 at 06:08 -0800, michal wrote:
> Keith Whitwell wrote on 2010-03-12 14:46:
> > Michal,
> >
> > Is the intention to have >1 sampler view active in the Mesa state
> > tracker, specifically in the cases where min_lod varies?
> >
> > In other words, you seem to have two ways of specifying the same state:
> >
> >   pipe_sampler_view::first_level
> >
> > and
> >
> >   pipe_sampler::min_lod
> >
> > Is there a case to keep both of these?  Or is one enough?
> >
> >   
> It looks like one has to go away, and that would be 
> pipe_sampler::min_lod. And we want to have a per-texture cache of 
> sampler views in mesa.

Yeah. There is hardware out there that is modeled after DX9 that doesn't
support min_lod, which would be greatly simplified with this.

Jose

Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.

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

Keith Whitwell wrote on 2010-03-12 14:46:
> Michal,
>
> Is the intention to have >1 sampler view active in the Mesa state
> tracker, specifically in the cases where min_lod varies?
>
> In other words, you seem to have two ways of specifying the same state:
>
>   pipe_sampler_view::first_level
>
> and
>
>   pipe_sampler::min_lod
>
> Is there a case to keep both of these?  Or is one enough?
>
>   
It looks like one has to go away, and that would be 
pipe_sampler::min_lod. And we want to have a per-texture cache of 
sampler views in mesa.

Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

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

On Thu, 2010-03-11 at 21:12 -0800, Chia-I Wu wrote:
> On Fri, Mar 12, 2010 at 12:20 PM, Jakob Bornecrantz
> <wal...@gm...> wrote:
> > On Fri, Mar 12, 2010 at 3:00 AM, Chia-I Wu <ol...@gm...> wrote:
> >> On Thu, Mar 11, 2010 at 12:15 PM, Chia-I Wu <ol...@gm...> wrote:
> >>> This patch series adds st_api interface to st/mesa and st/vega, and
> >>> switch st/egl and st/glx from st_public interface to the new interface.
> >> I've pushed most of the this patch series to gallium-st-api.  I'd like to have
> >> this topic branch focus on the switch of st/egl and st/glx to use st_api.
> >> Further works, such as the switch of st/dri, EGLImage extensions will happen
> >> directly in master or some other topic branches, whichever suits better.
> >>
> >> The implementations of the new interfaces (st_api, st_framebuffer_iface) are
> >> isolated in new files in each state tracker.  The isolation makes it easier to
> >> locate the changes.  But more importantly, unlike the rest of a state tracker,
> >> the interfaces might be called from different threads.  I used whatever
> >> existing mechanisms available to protect those callbacks, but when there is no
> >> such mechanism, I ignored the issue mostly.
> >>
> >> I have one open question so far.  With st_api, co state trackers no longer have
> >> access to pipe_contexts.  The pipe_contexts are usually used to implement
> >>
> >> * glXCopySubBufferMESA: copy a region of the back buffer to the front
> >> * eglCopyBuffers: copy the render buffer of a surface to a pixmap
> >> * SwapBuffers and FlushFront in DRI1
> >>
> >> The copying is a framebuffer operation and it does not make sense to steal a
> >> random API context for the copying.  Remember that the co state trackers always
> >> own the pipe_textures of a drawable in st_api.  One way to solve the problem is
> >> to let the co state trackers own pipe_contexts of their own. A co state tracker
> >> may create its pipe_context (and probably a blitter context) on demand when
> >> glXCopySubBufferMESA or eglCopyBuffers is called and do the copying directly.
> >>
> >> But as all the 3 cases need to do a pipe_screen::flush_frontbuffer after the
> >> copying, a better approach might be to rename and enhance
> >> pipe_screen::flush_frontbuffer to support them directly, or a mix of both
> >> approaches.
> > Hmm maybe flush_frontbuffer should be made into a context function, or
> > take a pipe_context. But that would probably require
> > st_framebuffer_iface::flush_front to take a st_context as well. Not
> > that I have anything against that.
> > For eglCopyBuffers the manager probably need a pipe_context for
> > itself. If you don't want to randomly steal one that is currently
> > bound, even then it is not guarantied to be any context created, so as
> > a fallback you will probably always have a context around.
> I am thinking change pipe_screen::flush_frontbuffer to
> 
>   void
>   pipe_screen::display_texture(struct pipe_screen *,
>                                struct pipe_texture *,
>                                void *winsys_drawable_handle,
>                                unsigned x, unsigned y,
>                                unsigned width, unsigned height);
> 
> The pipe_texture must be created with DISPLAY_TARGET or SCANOUT.  The type of
> the opaque drawable handle is pipe_screen specific and is known to the co state
> tracker, or whoever, created the pipe_screen.

I'd support this. This is pretty much what I'd need for WGL too.

Regarding being pipe_screen vs pipe_context I don't have a strong
opinion about this, but I believe making it a context operation is
adequate. 

Presents are translated either to a series of blits or a fullscreen
flip. Certain hardware deos not have dedicate blit engines, so having a
context for doing the blits via 3d is very handy.

On Windows XP presents don't require context. On Vista and later
presents already require a rendering context (I typically use the last
one that rendered to a surface).

Furthermore, now it is very easy for any state tracker entity to create
a dummy context for if needed, via pipe_screen::context_create().

Jose

[Mesa3d-dev] some r6xx work for r600g

[Stephan S. <ste...@gm...>]

Hello,
attached is a patch against rev.
189abd58e83af98276b9e170413918c821592f0c of Jerome Glisse's mesa repo.
With this my RV610 runs rudimentarily (few card hangs instead of hangs
each time of loading r600g, some rendering). The changes against r7xx
cards are copied from the differences in r600demo.

The patch does not preserve compatibility with r7xx cards  (@ Jerome
Glisse: Is there a way to select codepaths depending on the used chip,
e.g. like if(rdev->chip <= RV670)... )
Also the renderung results are somewhat different from Jerome Glisse's
results.
tri-flat gives the following result:
-red background
-there is a completely green quad rendered. Its sides are parallel to
the window borders. Left bound is the left vertex of the desired
triangle,  right and lower bounds are the lower right vertex of the
triangle and upper bound is the middle of the window.
Regards
Stephan Schmid

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

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

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?

Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.

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

Resending to the right address.

Keith

On Fri, 2010-03-12 at 13:40 +0000, Keith Whitwell wrote:
> On Fri, 2010-03-12 at 02:54 -0800, Corbin Simpson wrote: 
> > Module: Mesa
> > Branch: master
> > Commit: 50876ddaaff72a324ac45e255985e0f84e108594
> > URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=50876ddaaff72a324ac45e255985e0f84e108594
> > 
> > Author: Corbin Simpson <Mos...@gm...>
> > Date:   Fri Mar 12 02:51:40 2010 -0800
> > 
> > st/mesa: Always recalculate invalid index bounds.
> > 
> > These should always be sanitized before heading towards the pipe driver,
> > and if the calling function explicitly marked them as invalid, we need
> > to regenerate them.
> > 
> > Allows r300g to properly pass a bit more of Wine's d3d9 testing without
> > dropping stuff on the floor.
> > 
> > ---
> > 
> >  src/mesa/state_tracker/st_draw.c |    6 +++---
> >  1 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
> > index 8b01272..d81b361 100644
> > --- a/src/mesa/state_tracker/st_draw.c
> > +++ b/src/mesa/state_tracker/st_draw.c
> > @@ -542,9 +542,9 @@ st_draw_vbo(GLcontext *ctx,
> >     assert(ctx->NewState == 0x0);
> >  
> >     /* Gallium probably doesn't want this in some cases. */
> > -   if (!index_bounds_valid)
> > -      if (!vbo_all_varyings_in_vbos(arrays))
> > -	 vbo_get_minmax_index(ctx, prims, ib, &min_index, &max_index);
> > +   if (index_bounds_valid != GL_TRUE) {
> > +      vbo_get_minmax_index(ctx, prims, ib, &min_index, &max_index);
> > +   }
> 
> 
> Corbin,
> 
> This isn't really desirable.  Ideally this range checking should be
> pushed into pipe driver, because it's an expensive operation that is not
> necessary on a lot of hardware.  #
> 
> Specifically, vertex fetch hardware can often be set up with the min/max
> permissible index bounds to avoid accessing vertex data outside of the
> bound VB's.  This can be achieved by examining the VBs, with min_index
> == 0, max_index = vb.size / vb.stride.
> 
> The case where we need to calculate them internally is if some data is
> not in a VB, meaning we can't guess what the legal min/max values are.
> Also note that we need that min/max information to be able to upload the
> data to a VB.
> 
> So, I think the code was probably correct in the original version -
> defer the minmax scan to the hardware driver, which may or may not need
> it.
> 
> But maybe there is a better way to let the driver know that we are not
> providing this information.
> 
> Keith
> 
>  

Re: [Mesa3d-dev] Mesa (gallium-sampler-view): st/mesa: Associate a sampler view with an st texture object.

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

Michal,

Is the intention to have >1 sampler view active in the Mesa state
tracker, specifically in the cases where min_lod varies?

In other words, you seem to have two ways of specifying the same state: 

  pipe_sampler_view::first_level

and

  pipe_sampler::min_lod

Is there a case to keep both of these?  Or is one enough?

Keith

On Fri, 2010-03-12 at 05:39 -0800, Micha?? Kr??l wrote:
> Module: Mesa
> Branch: gallium-sampler-view
> Commit: b8030c6561e019e079b5be2fe64ec804df4bfa03
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=b8030c6561e019e079b5be2fe64ec804df4bfa03
> 
> Author: Michal Krol <mi...@vm...>
> Date:   Fri Mar 12 14:37:36 2010 +0100
> 
> st/mesa: Associate a sampler view with an st texture object.
> 
> Lazily create a sampler view when the texture is being bound
> for the first time.
> 
> ---
> 
>  src/mesa/state_tracker/st_atom_pixeltransfer.c |    2 +
>  src/mesa/state_tracker/st_atom_texture.c       |   20 +++++-----
>  src/mesa/state_tracker/st_cb_bitmap.c          |   48 +++++++++++++++--------
>  src/mesa/state_tracker/st_cb_drawpixels.c      |   46 ++++++++++++++--------
>  src/mesa/state_tracker/st_cb_texture.c         |    4 ++
>  src/mesa/state_tracker/st_context.c            |    4 +-
>  src/mesa/state_tracker/st_context.h            |    3 +-
>  src/mesa/state_tracker/st_texture.h            |   39 +++++++++++++++++++
>  8 files changed, 119 insertions(+), 47 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_atom_pixeltransfer.c b/src/mesa/state_tracker/st_atom_pixeltransfer.c
> index 0b2e3f5..e766b3a 100644
> --- a/src/mesa/state_tracker/st_atom_pixeltransfer.c
> +++ b/src/mesa/state_tracker/st_atom_pixeltransfer.c
> @@ -257,6 +257,8 @@ get_pixel_transfer_program(GLcontext *ctx, const struct state_key *key)
>        /* create the colormap/texture now if not already done */
>        if (!st->pixel_xfer.pixelmap_texture) {
>           st->pixel_xfer.pixelmap_texture = create_color_map_texture(ctx);
> +         st->pixel_xfer.pixelmap_sampler_view = st_sampler_view_from_texture(ctx->st->pipe,
> +                                                                             st->pixel_xfer.pixelmap_texture);
>        }
> 
>        /* with a little effort, we can do four pixel map look-ups with
> diff --git a/src/mesa/state_tracker/st_atom_texture.c b/src/mesa/state_tracker/st_atom_texture.c
> index 57b71c1..241c001 100644
> --- a/src/mesa/state_tracker/st_atom_texture.c
> +++ b/src/mesa/state_tracker/st_atom_texture.c
> @@ -56,7 +56,7 @@ update_textures(struct st_context *st)
> 
>     /* loop over sampler units (aka tex image units) */
>     for (su = 0; su < st->ctx->Const.MaxTextureImageUnits; su++) {
> -      struct pipe_texture *pt = NULL;
> +      struct pipe_sampler_view *sampler_view = NULL;
> 
>        if (samplersUsed & (1 << su)) {
>           struct gl_texture_object *texObj;
> @@ -84,7 +84,7 @@ update_textures(struct st_context *st)
> 
>           st->state.num_textures = su + 1;
> 
> -         pt = st_get_stobj_texture(stObj);
> +         sampler_view = st_get_stobj_sampler_view(stObj);
>        }
> 
>        /*
> @@ -96,17 +96,17 @@ update_textures(struct st_context *st)
>        }
>        */
> 
> -      pipe_texture_reference(&st->state.sampler_texture[su], pt);
> +      pipe_sampler_view_reference(&st->state.sampler_views[su], sampler_view);
>     }
> 
> -   cso_set_sampler_textures(st->cso_context,
> -                            st->state.num_textures,
> -                            st->state.sampler_texture);
> +   cso_set_fragment_sampler_views(st->cso_context,
> +                                  st->state.num_textures,
> +                                  st->state.sampler_views);
>     if (st->ctx->Const.MaxVertexTextureImageUnits > 0) {
> -      cso_set_vertex_sampler_textures(st->cso_context,
> -                                      MIN2(st->state.num_textures,
> -                                           st->ctx->Const.MaxVertexTextureImageUnits),
> -                                      st->state.sampler_texture);
> +      cso_set_vertex_sampler_views(st->cso_context,
> +                                   MIN2(st->state.num_textures,
> +                                        st->ctx->Const.MaxVertexTextureImageUnits),
> +                                   st->state.sampler_views);
>     }
>  }
> 
> diff --git a/src/mesa/state_tracker/st_cb_bitmap.c b/src/mesa/state_tracker/st_cb_bitmap.c
> index f326601..25d33b9 100644
> --- a/src/mesa/state_tracker/st_cb_bitmap.c
> +++ b/src/mesa/state_tracker/st_cb_bitmap.c
> @@ -398,7 +398,7 @@ setup_bitmap_vertex_data(struct st_context *st,
>  static void
>  draw_bitmap_quad(GLcontext *ctx, GLint x, GLint y, GLfloat z,
>                   GLsizei width, GLsizei height,
> -                 struct pipe_texture *pt,
> +                 struct pipe_sampler_view *sv,
>                   const GLfloat *color)
>  {
>     struct st_context *st = ctx->st;
> @@ -436,7 +436,7 @@ draw_bitmap_quad(GLcontext *ctx, GLint x, GLint y, GLfloat z,
> 
>     cso_save_rasterizer(cso);
>     cso_save_samplers(cso);
> -   cso_save_sampler_textures(cso);
> +   cso_save_fragment_sampler_views(cso);
>     cso_save_viewport(cso);
>     cso_save_fragment_shader(cso);
>     cso_save_vertex_shader(cso);
> @@ -466,11 +466,11 @@ draw_bitmap_quad(GLcontext *ctx, GLint x, GLint y, GLfloat z,
> 
>     /* user textures, plus the bitmap texture */
>     {
> -      struct pipe_texture *textures[PIPE_MAX_SAMPLERS];
> +      struct pipe_sampler_view *sampler_views[PIPE_MAX_SAMPLERS];
>        uint num = MAX2(stfp->bitmap_sampler + 1, st->state.num_textures);
> -      memcpy(textures, st->state.sampler_texture, sizeof(textures));
> -      textures[stfp->bitmap_sampler] = pt;
> -      cso_set_sampler_textures(cso, num, textures);
> +      memcpy(sampler_views, st->state.sampler_views, sizeof(sampler_views));
> +      sampler_views[stfp->bitmap_sampler] = sv;
> +      cso_set_fragment_sampler_views(cso, num, sampler_views);
>     }
> 
>     /* viewport state: viewport matching window dims */
> @@ -508,7 +508,7 @@ draw_bitmap_quad(GLcontext *ctx, GLint x, GLint y, GLfloat z,
>     /* restore state */
>     cso_restore_rasterizer(cso);
>     cso_restore_samplers(cso);
> -   cso_restore_sampler_textures(cso);
> +   cso_restore_fragment_sampler_views(cso);
>     cso_restore_viewport(cso);
>     cso_restore_fragment_shader(cso);
>     cso_restore_vertex_shader(cso);
> @@ -602,6 +602,7 @@ st_flush_bitmap_cache(struct st_context *st)
>        if (st->ctx->DrawBuffer) {
>           struct pipe_context *pipe = st->pipe;
>           struct pipe_screen *screen = pipe->screen;
> +         struct pipe_sampler_view *sv;
> 
>           assert(cache->xmin <= cache->xmax);
> 
> @@ -624,13 +625,18 @@ st_flush_bitmap_cache(struct st_context *st)
>              cache->trans = NULL;
>           }
> 
> -         draw_bitmap_quad(st->ctx,
> -                          cache->xpos,
> -                          cache->ypos,
> -                          cache->zpos,
> -                          BITMAP_CACHE_WIDTH, BITMAP_CACHE_HEIGHT,
> -                          cache->texture,
> -                          cache->color);
> +         sv = st_sampler_view_from_texture(st->pipe, cache->texture);
> +         if (sv) {
> +            draw_bitmap_quad(st->ctx,
> +                             cache->xpos,
> +                             cache->ypos,
> +                             cache->zpos,
> +                             BITMAP_CACHE_WIDTH, BITMAP_CACHE_HEIGHT,
> +                             sv,
> +                             cache->color);
> +
> +            pipe_sampler_view_reference(&sv, NULL);
> +         }
>        }
> 
>        /* release/free the texture */
> @@ -753,10 +759,18 @@ st_Bitmap(GLcontext *ctx, GLint x, GLint y, GLsizei width, GLsizei height,
> 
>     pt = make_bitmap_texture(ctx, width, height, unpack, bitmap);
>     if (pt) {
> +      struct pipe_sampler_view *sv = st_sampler_view_from_texture(st->pipe, pt);
> +
>        assert(pt->target == PIPE_TEXTURE_2D);
> -      draw_bitmap_quad(ctx, x, y, ctx->Current.RasterPos[2],
> -                       width, height, pt,
> -                       st->ctx->Current.RasterColor);
> +
> +      if (sv) {
> +         draw_bitmap_quad(ctx, x, y, ctx->Current.RasterPos[2],
> +                          width, height, sv,
> +                          st->ctx->Current.RasterColor);
> +
> +         pipe_sampler_view_reference(&sv, NULL);
> +      }
> +
>        /* release/free the texture */
>        pipe_texture_reference(&pt, NULL);
>     }
> diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c b/src/mesa/state_tracker/st_cb_drawpixels.c
> index d542c99..236010c 100644
> --- a/src/mesa/state_tracker/st_cb_drawpixels.c
> +++ b/src/mesa/state_tracker/st_cb_drawpixels.c
> @@ -503,7 +503,7 @@ static void
>  draw_textured_quad(GLcontext *ctx, GLint x, GLint y, GLfloat z,
>                     GLsizei width, GLsizei height,
>                     GLfloat zoomX, GLfloat zoomY,
> -                   struct pipe_texture *pt,
> +                   struct pipe_sampler_view *sv,
>                     void *driver_vp,
>                     void *driver_fp,
>                     const GLfloat *color,
> @@ -526,7 +526,7 @@ draw_textured_quad(GLcontext *ctx, GLint x, GLint y, GLfloat z,
>     cso_save_rasterizer(cso);
>     cso_save_viewport(cso);
>     cso_save_samplers(cso);
> -   cso_save_sampler_textures(cso);
> +   cso_save_fragment_sampler_views(cso);
>     cso_save_fragment_shader(cso);
>     cso_save_vertex_shader(cso);
>     cso_save_vertex_elements(cso);
> @@ -586,13 +586,13 @@ draw_textured_quad(GLcontext *ctx, GLint x, GLint y, GLfloat z,
> 
>     /* texture state: */
>     if (st->pixel_xfer.pixelmap_enabled) {
> -      struct pipe_texture *textures[2];
> -      textures[0] = pt;
> -      textures[1] = st->pixel_xfer.pixelmap_texture;
> -      cso_set_sampler_textures(cso, 2, textures);
> +      struct pipe_sampler_view *sampler_views[2];
> +      sampler_views[0] = sv;
> +      sampler_views[1] = st->pixel_xfer.pixelmap_sampler_view;
> +      cso_set_fragment_sampler_views(cso, 2, sampler_views);
>     }
>     else {
> -      cso_set_sampler_textures(cso, 1, &pt);
> +      cso_set_fragment_sampler_views(cso, 1, &sv);
>     }
> 
>     /* Compute window coords (y=0=bottom) with pixel zoom.
> @@ -608,14 +608,14 @@ draw_textured_quad(GLcontext *ctx, GLint x, GLint y, GLfloat z,
>     z = z * 2.0 - 1.0;
> 
>     draw_quad(ctx, x0, y0, z, x1, y1, color, invertTex,
> -            (GLfloat) width / pt->width0,
> -            (GLfloat) height / pt->height0);
> +             (GLfloat) width / sv->texture->width0,
> +             (GLfloat) height / sv->texture->height0);
> 
>     /* restore state */
>     cso_restore_rasterizer(cso);
>     cso_restore_viewport(cso);
>     cso_restore_samplers(cso);
> -   cso_restore_sampler_textures(cso);
> +   cso_restore_fragment_sampler_views(cso);
>     cso_restore_fragment_shader(cso);
>     cso_restore_vertex_shader(cso);
>     cso_restore_vertex_elements(cso);
> @@ -809,12 +809,17 @@ st_DrawPixels(GLcontext *ctx, GLint x, GLint y, GLsizei width, GLsizei height,
>        struct pipe_texture *pt
>           = make_texture(st, width, height, format, type, unpack, pixels);
>        if (pt) {
> -         draw_textured_quad(ctx, x, y, ctx->Current.RasterPos[2],
> -                            width, height, ctx->Pixel.ZoomX, ctx->Pixel.ZoomY,
> -                            pt,
> -                            driver_vp,
> -                            driver_fp,
> -                            color, GL_FALSE);
> +         struct pipe_sampler_view *sv = st_sampler_view_from_texture(st->pipe, pt);
> +
> +         if (sv) {
> +            draw_textured_quad(ctx, x, y, ctx->Current.RasterPos[2],
> +                               width, height, ctx->Pixel.ZoomX, ctx->Pixel.ZoomY,
> +                               sv,
> +                               driver_vp,
> +                               driver_fp,
> +                               color, GL_FALSE);
> +            pipe_sampler_view_reference(&sv, NULL);
> +         }
>           pipe_texture_reference(&pt, NULL);
>        }
>     }
> @@ -933,6 +938,7 @@ st_CopyPixels(GLcontext *ctx, GLint srcx, GLint srcy,
>     struct st_renderbuffer *rbRead;
>     void *driver_vp, *driver_fp;
>     struct pipe_texture *pt;
> +   struct pipe_sampler_view *sv;
>     GLfloat *color;
>     enum pipe_format srcFormat, texFormat;
>     int ptw, pth;
> @@ -1050,6 +1056,11 @@ st_CopyPixels(GLcontext *ctx, GLint srcx, GLint srcy,
>     if (!pt)
>        return;
> 
> +   sv = st_sampler_view_from_texture(st->pipe, pt);
> +   if (!sv) {
> +      pipe_texture_reference(&pt, NULL);
> +      return;
> +   }
> 
>     if (srcFormat == texFormat) {
>        /* copy source framebuffer surface into mipmap/texture */
> @@ -1118,12 +1129,13 @@ st_CopyPixels(GLcontext *ctx, GLint srcx, GLint srcy,
>     /* draw textured quad */
>     draw_textured_quad(ctx, dstx, dsty, ctx->Current.RasterPos[2],
>                        width, height, ctx->Pixel.ZoomX, ctx->Pixel.ZoomY,
> -                      pt,
> +                      sv,
>                        driver_vp,
>                        driver_fp,
>                        color, GL_TRUE);
> 
>     pipe_texture_reference(&pt, NULL);
> +   pipe_sampler_view_reference(&sv, NULL);
>  }
> 
> 
> diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src/mesa/state_tracker/st_cb_texture.c
> index c849132..7684656 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -123,6 +123,8 @@ st_DeleteTextureObject(GLcontext *ctx,
>     struct st_texture_object *stObj = st_texture_object(texObj);
>     if (stObj->pt)
>        pipe_texture_reference(&stObj->pt, NULL);
> +   if (stObj->sampler_view)
> +      pipe_sampler_view_reference(&stObj->sampler_view, NULL);
> 
>     _mesa_delete_texture_object(ctx, texObj);
>  }
> @@ -312,6 +314,8 @@ guess_and_alloc_texture(struct st_context *st,
>                                   depth,
>                                   usage);
> 
> +   stObj->pipe = st->pipe;
> +
>     DBG("%s - success\n", __FUNCTION__);
>  }
> 
> diff --git a/src/mesa/state_tracker/st_context.c b/src/mesa/state_tracker/st_context.c
> index 09f891d..e978415 100644
> --- a/src/mesa/state_tracker/st_context.c
> +++ b/src/mesa/state_tracker/st_context.c
> @@ -215,8 +215,8 @@ static void st_destroy_context_priv( struct st_context *st )
>     st_destroy_drawtex(st);
>  #endif
> 
> -   for (i = 0; i < Elements(st->state.sampler_texture); i++) {
> -      pipe_texture_reference(&st->state.sampler_texture[i], NULL);
> +   for (i = 0; i < Elements(st->state.sampler_views); i++) {
> +      pipe_sampler_view_reference(&st->state.sampler_views[i], NULL);
>     }
> 
>     for (i = 0; i < Elements(st->state.constants); i++) {
> diff --git a/src/mesa/state_tracker/st_context.h b/src/mesa/state_tracker/st_context.h
> index 6622361..ae73817 100644
> --- a/src/mesa/state_tracker/st_context.h
> +++ b/src/mesa/state_tracker/st_context.h
> @@ -94,7 +94,7 @@ struct st_context
>        struct pipe_clip_state clip;
>        struct pipe_buffer *constants[2];
>        struct pipe_framebuffer_state framebuffer;
> -      struct pipe_texture *sampler_texture[PIPE_MAX_SAMPLERS];
> +      struct pipe_sampler_view *sampler_views[PIPE_MAX_SAMPLERS];
>        struct pipe_scissor_state scissor;
>        struct pipe_viewport_state viewport;
> 
> @@ -141,6 +141,7 @@ struct st_context
>        struct st_fragment_program *combined_prog;
>        GLuint combined_prog_sn;
>        struct pipe_texture *pixelmap_texture;
> +      struct pipe_sampler_view *pixelmap_sampler_view;
>        boolean pixelmap_enabled;  /**< use the pixelmap texture? */
>     } pixel_xfer;
> 
> diff --git a/src/mesa/state_tracker/st_texture.h b/src/mesa/state_tracker/st_texture.h
> index 60868ce..c62f7f2 100644
> --- a/src/mesa/state_tracker/st_texture.h
> +++ b/src/mesa/state_tracker/st_texture.h
> @@ -29,6 +29,9 @@
>  #define ST_TEXTURE_H
> 
> 
> +#include "pipe/p_context.h"
> +#include "util/u_sampler.h"
> +
>  #include "main/mtypes.h"
> 
>  struct pipe_context;
> @@ -68,6 +71,13 @@ struct st_texture_object
>      */
>     struct pipe_texture *pt;
> 
> +   /* Default sampler view attached to this texture object. Created lazily
> +    * on first binding.
> +    */
> +   struct pipe_sampler_view *sampler_view;
> +
> +   struct pipe_context *pipe;
> +
>     GLboolean teximage_realloc;
> 
>     /* True if there is/was a surface bound to this texture object.  It helps
> @@ -105,6 +115,35 @@ st_get_stobj_texture(struct st_texture_object *stObj)
>  }
> 
> 
> +static INLINE struct pipe_sampler_view *
> +st_sampler_view_from_texture(struct pipe_context *pipe,
> +                             struct pipe_texture *texture)
> +{
> +   struct pipe_sampler_view templ;
> +
> +   u_sampler_view_default_template(&templ,
> +                                   texture,
> +                                   texture->format);
> +
> +   return pipe->create_sampler_view(pipe, texture, &templ);
> +}
> +
> +
> +static INLINE struct pipe_sampler_view *
> +st_get_stobj_sampler_view(struct st_texture_object *stObj)
> +{
> +   if (!stObj || !stObj->pt) {
> +      return NULL;
> +   }
> +
> +   if (!stObj->sampler_view) {
> +      stObj->sampler_view = st_sampler_view_from_texture(stObj->pipe, stObj->pt);
> +   }
> +
> +   return stObj->sampler_view;
> +}
> +
> +
>  extern struct pipe_texture *
>  st_texture_create(struct st_context *st,
>                    enum pipe_texture_target target,
> 
> _______________________________________________
> mesa-commit mailing list
> mes...@li...
> http://lists.freedesktop.org/mailman/listinfo/mesa-commit

Re: [Mesa3d-dev] Mesa (master): st/mesa: Always recalculate invalid index bounds.

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

On Fri, 2010-03-12 at 02:54 -0800, Corbin Simpson wrote: 
> Module: Mesa
> Branch: master
> Commit: 50876ddaaff72a324ac45e255985e0f84e108594
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=50876ddaaff72a324ac45e255985e0f84e108594
> 
> Author: Corbin Simpson <Mos...@gm...>
> Date:   Fri Mar 12 02:51:40 2010 -0800
> 
> st/mesa: Always recalculate invalid index bounds.
> 
> These should always be sanitized before heading towards the pipe driver,
> and if the calling function explicitly marked them as invalid, we need
> to regenerate them.
> 
> Allows r300g to properly pass a bit more of Wine's d3d9 testing without
> dropping stuff on the floor.
> 
> ---
> 
>  src/mesa/state_tracker/st_draw.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
> index 8b01272..d81b361 100644
> --- a/src/mesa/state_tracker/st_draw.c
> +++ b/src/mesa/state_tracker/st_draw.c
> @@ -542,9 +542,9 @@ st_draw_vbo(GLcontext *ctx,
>     assert(ctx->NewState == 0x0);
>  
>     /* Gallium probably doesn't want this in some cases. */
> -   if (!index_bounds_valid)
> -      if (!vbo_all_varyings_in_vbos(arrays))
> -	 vbo_get_minmax_index(ctx, prims, ib, &min_index, &max_index);
> +   if (index_bounds_valid != GL_TRUE) {
> +      vbo_get_minmax_index(ctx, prims, ib, &min_index, &max_index);
> +   }


Corbin,

This isn't really desirable.  Ideally this range checking should be
pushed into pipe driver, because it's an expensive operation that is not
necessary on a lot of hardware.  #

Specifically, vertex fetch hardware can often be set up with the min/max
permissible index bounds to avoid accessing vertex data outside of the
bound VB's.  This can be achieved by examining the VBs, with min_index
== 0, max_index = vb.size / vb.stride.

The case where we need to calculate them internally is if some data is
not in a VB, meaning we can't guess what the legal min/max values are.
Also note that we need that min/max information to be able to upload the
data to a VB.

So, I think the code was probably correct in the original version -
defer the minmax scan to the hardware driver, which may or may not need
it.

But maybe there is a better way to let the driver know that we are not
providing this information.

Keith

 

Re: [Mesa3d-dev] New error in xorg_crtc.c

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

Steve,

Fixed, sorry for the screwup - it looks like a couple of directories
escaped conversion.

Keith

On Fri, 2010-03-12 at 03:59 -0800, STEVE555 wrote:
> Hi guys,
>            I've pulled in the latest commits for my local copy of Mesa git
> master.I ran gmake -B realclean,and used my usaul confiugre options:
> ./configure --prefix=/usr --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
> 
> Mesa stops compiling with this new error:
> 
> /usr/include/xorg/edid.h:623: warning: declaration does not declare anything
> gcc -c -I. -I../../../../src/gallium/include
> -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
> -DHAVE_CONFIG_H -DHAVE_XEXTPROTO_71 -DHAVE_LIBKMS -I/usr/include/libkms  
> -I/usr/include/pixman-1 -I/usr/include/xorg -I/usr/include/drm  
> -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
> -I../../../../include -I../../../../src/mesa
> -I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main -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  xorg_crtc.c -o
> xorg_crtc.o
> In file included from /usr/include/xorg/xf86Crtc.h:25,
>                  from xorg_crtc.c:41:
> /usr/include/xorg/edid.h:623: warning: declaration does not declare anything
> xorg_crtc.c: In function ‘crtc_load_cursor_argb_ga3d’:
> xorg_crtc.c:223: error: ‘struct pipe_screen’ has no member named
> ‘get_tex_transfer’
> xorg_crtc.c:227: error: ‘struct pipe_screen’ has no member named
> ‘transfer_map’
> xorg_crtc.c:231: error: ‘struct pipe_screen’ has no member named
> ‘transfer_unmap’
> xorg_crtc.c:232: error: ‘struct pipe_screen’ has no member named
> ‘tex_transfer_destroy’
> gmake[4]: *** [xorg_crtc.o] Error 1
> gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/xorg'
> gmake[3]: *** [subdirs] Error 1
> gmake[3]: Leaving directory `/opt/mesa/src/gallium/state_trackers'
> gmake[2]: *** [default] Error 1
> gmake[2]: Leaving directory `/opt/mesa/src/gallium'
> gmake[1]: *** [subdirs] Error 1
> gmake[1]: Leaving directory `/opt/mesa/src'
> gmake: *** [default] Error 1
> 
> I think it's to do with the gallium-context-tranfers merge,or some very
> recent commit,I'm not that sure.The error is similar to the one that has
> been posted earlier in the mailing list.
> Regards,
>             STEVE555

[Mesa3d-dev] New error in xorg_crtc.c

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

Hi guys,
           I've pulled in the latest commits for my local copy of Mesa git
master.I ran gmake -B realclean,and used my usaul confiugre options:
./configure --prefix=/usr --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

Mesa stops compiling with this new error:

/usr/include/xorg/edid.h:623: warning: declaration does not declare anything
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
-DHAVE_CONFIG_H -DHAVE_XEXTPROTO_71 -DHAVE_LIBKMS -I/usr/include/libkms  
-I/usr/include/pixman-1 -I/usr/include/xorg -I/usr/include/drm  
-I../../../../src/gallium/include -I../../../../src/gallium/auxiliary
-I../../../../include -I../../../../src/mesa
-I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa/main -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  xorg_crtc.c -o
xorg_crtc.o
In file included from /usr/include/xorg/xf86Crtc.h:25,
                 from xorg_crtc.c:41:
/usr/include/xorg/edid.h:623: warning: declaration does not declare anything
xorg_crtc.c: In function ‘crtc_load_cursor_argb_ga3d’:
xorg_crtc.c:223: error: ‘struct pipe_screen’ has no member named
‘get_tex_transfer’
xorg_crtc.c:227: error: ‘struct pipe_screen’ has no member named
‘transfer_map’
xorg_crtc.c:231: error: ‘struct pipe_screen’ has no member named
‘transfer_unmap’
xorg_crtc.c:232: error: ‘struct pipe_screen’ has no member named
‘tex_transfer_destroy’
gmake[4]: *** [xorg_crtc.o] Error 1
gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/xorg'
gmake[3]: *** [subdirs] Error 1
gmake[3]: Leaving directory `/opt/mesa/src/gallium/state_trackers'
gmake[2]: *** [default] Error 1
gmake[2]: Leaving directory `/opt/mesa/src/gallium'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/opt/mesa/src'
gmake: *** [default] Error 1

I think it's to do with the gallium-context-tranfers merge,or some very
recent commit,I'm not that sure.The error is similar to the one that has
been posted earlier in the mailing list.
Regards,
            STEVE555
-- 
View this message in context: http://old.nabble.com/New-error-in-xorg_crtc.c-tp27874502p27874502.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

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

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

On Fri, Mar 12, 2010 at 9:37 AM, David Miller <da...@da...> wrote:
> This change:
>
> commit d888bbc45a84946cafb4f4d2c89681a580cd89bc
> Author: Brian Paul <br...@vm...>
> Date:   Tue Nov 17 13:39:13 2009 -0700
>
>    progs/xdemos: added -lX11 -lpthread for GNU gold linker
>
> breaks the build if you are building under a specific path prefix
> (say, /opt/XORG) and you have an existing X11 installation in the
> usual location (/usr, etc.)
>
> Mesa gets configure with:
>
> PATH=/opt/XORG/bin:$PATH ./configure --prefix=/opt/XORG --libdir=/opt/XORG/lib
>
> And then we get, for example:
>
> make[2]: Entering directory `/home/davem/src/GIT/XORG/mesa/mesa/progs/xdemos'
> gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_SPARC_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  corender.o ipc.o -L../../lib -lGL  -lm -lX11 -lpthread -o corender
> /usr/bin/../lib/libxcb-xlib.so.0: undefined reference to `_xcb_lock_io'
> /usr/bin/../lib/libxcb-xlib.so.0: undefined reference to `_xcb_unlock_io'
> collect2: ld returned 1 exit status
>
> Reverting the commit, of course, makes the problem go away.
>
> One way to fix this would be to propagate the --libdir prefix
> down to these Makefiles.
>
> The same exact problem exists in progs/egl, but since libEGL doesn't
> link to libX11 any more, a simple revert of:
>
> commit 8d0bdfa4335ea07a747f53635a57414d15c234b7
> Author: Chia-I Wu <ol...@gm...>
> Date:   Wed Aug 26 12:44:02 2009 +0800
>
>    progs: EGL/X progs should link to libX11.
>
>    Since 5a459d58fca2b71cb77c39f98df8a81ce6298421, libEGL no longer links
>    to libX11.  Add the dependency to affected progs and cleanup
>    prog/egl/Makefile.
>
>    Signed-off-by: Chia-I Wu <ol...@gm...>
>
> doesn't fix the problem.
>
> Sigh... :-)
I think this is a configuration problem.  Does it help if you
configure mesa with

$ ./configure --prefix=/opt/XORG --libdir=/opt/XORG/lib
LDFLAGS="-L/opt/XORG/lib"

?

I haven't tried, but conventionally, LDFLAGS (and CFLAGS) are
available for user's use.

-- 
ol...@Lu...

[Mesa3d-dev] [Bug 27037] mesa git shows a compilation error

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

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


Michel Dänzer <mi...@da...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #1 from Michel Dänzer <mi...@da...>  2010-03-12 01:15:12 PST ---


*** This bug has been marked as a duplicate of bug 27010 ***


-- 
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] [Bug 27007] Lines disappear with GL_LINE_SMOOTH

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

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


Michel Dänzer <mi...@da...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|mesa3d-                     |er...@an...
                   |de...@li...   |
          Component|Drivers/X11                 |Drivers/DRI/i965




-- 
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] [Bug 27037] New: mesa git shows a compilation error

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

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

           Summary: mesa git shows a compilation error
           Product: Mesa
           Version: git
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: wo...@on...


make shows the following error:
---
make[5]: Entering directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm/radeon/egl'
gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -D_GNU_SOURCE
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o
make[5]: *** No rule to make target
`../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
`egl_x11_radeon.so'.  Stop.
make[5]: Leaving directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm/radeon/egl'
make[4]: *** [default] Error 1
make[4]: Leaving directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm/radeon'
make[3]: *** [default] Error 1
make[3]: Leaving directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm'
make[2]: *** [default] Error 1
make[2]: Leaving directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src'
make: *** [default] Error 1
---


-- 
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] [Bug 27012] mesa git shows a compilation error

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

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


Michel Dänzer <mi...@da...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Michel Dänzer <mi...@da...>  2010-03-12 00:32:50 PST ---
Different issue, file another bug for it if necessary.


-- 
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] [PATCH] dri/r700: Include shader/programopt.h instead of programopt.c.

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

Luc Verhaegen.