mesa3d-dev

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

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

José Fonseca wrote on 2010-03-11 14:40:
> 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).
>>
>> Yesterday I had to merge master into gallium-sampler-view -- the nv50 
>> and r300 drivers had lots of conflicts. Could the maintainers of said 
>> drivers had a look at them and see if they are still functional, please?
>>
>> Thanks.
>>     
>
> Michal,
>
> Looks good overall. Minor comments below. Sorry if I rehash things that
> have been already discussed. Feel free to ignore them.
>
>
> diff --git a/src/gallium/include/pipe/p_state.h b/src/gallium/include/pipe/p_state.h
> index 3a97d88..3c7c0a5 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -300,6 +300,24 @@ struct pipe_surface
>  
>  
>  /**
> + * A view into a texture that can be bound to a shader stage.
> + */
> +struct pipe_sampler_view
> +{
> +   struct pipe_reference reference;
> +   enum pipe_format format;      /**< typed PIPE_FORMAT_x */
>
> I think it is worth to document that not all formats are valid here.
> pipe_sampler_view::format and pipe_texture::format must be compatible.
> The semantics of compatibility are a bit confusing though. Even DX10's.
>
> At very least format's util_format_block must match.
>
> RGB <=> SRGB variations should also be accepted. And sizzwle variations.
>
> The difficulty is whether formats like  A4R4G4B4 <=> A1G5R5B5 or
> R8G8B8A8 <=> R32 should be accepted. I think hardware should have no
> troubles with typecasting. So I'm inclined towards make this acceptible.
>
>   
How about all component sizes and order of components must match, and 
the only difference can be in value type, that is one can convert 
between SNORM, UNORM, SRGB, FLOAT, etc., as long as the base format is 
the same (e.g. PIPE_FORMAT_R8G8B8A8)?


> +   struct pipe_texture *texture; /**< texture into which this is a view  */
>
> +   struct pipe_context *context; /**< context this view belongs to */
>
> Is this for debugging? No other state object has a pointer to context so far.
>
>   
Had this object been created by pipe_screen, it would have a reference 
to a screen that created it. Sampler view is a first "resource" type 
that is created by pipe_context. We want to migrate other types to 
pipe_context as well. I suppose once pipe_texture has a reference to 
pipe_context, we could remove it from here, but in the meantime we will 
need it in e.g. pipe_sampler_view_reference().

> +   unsigned first_level:8;       /**< first mipmap level */
> +   unsigned num_levels:8;        /**< number of mipamp levels */
>
> I don't care much, but we've been using last_level instead of num_levels
> elsewhere. Is there a particular reason to use num_levels here? 
>
> s/mipamp/mipmap/ in comment.
>   
Makes sense, I will change it.

> +   unsigned swizzle_r:3;         /**< PIPE_SWIZZLE_x for red component */
> +   unsigned swizzle_g:3;         /**< PIPE_SWIZZLE_x for green component */
> +   unsigned swizzle_b:3;         /**< PIPE_SWIZZLE_x for blue component */
> +   unsigned swizzle_a:3;         /**< PIPE_SWIZZLE_x for alpha component */
> +};
> +
> +
> +/**
>   * Transfer object.  For data transfer to/from a texture.
>   */
>  struct pipe_transfer
>
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_state_sampler.c b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
> index b30a075..2df86a0 100644
> --- a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
> +++ b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
>
> [...]
>
>   
>> +struct pipe_sampler_view *
>> +llvmpipe_create_sampler_view(struct pipe_context *pipe,
>> +                            struct pipe_texture *texture,
>> +                            const struct pipe_sampler_view *templ)
>> +{
>> +   struct pipe_sampler_view *view = CALLOC_STRUCT(pipe_sampler_view);
>>     
>
> Need to handle out of memory here.
>
>   
Will fix it, thanks.

>> +   *view = *templ;
>> +   view->reference.count = 1;
>> +   view->texture = NULL;
>> +   pipe_texture_reference(&view->texture, texture);
>> +   view->context = pipe;
>> +
>> +   return view;
>> +}
>>     
>
> The rest looks great to me. It's a very useful gallium interface change.
> I particularly like how you eased migration with
> cso_set_sampler_textures().
>
> BTW, I noticed you commented out pipe video code. Everybody agreed on
> removing it from master and mature pipe video on a branch, but we never
> got around to do it. I'll remove this code in the next few days.
>
>   
Thanks for having a look.

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

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

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

Thanks for having a look.

> To make this change worthwhile, we'd want to somehow cache sampler views
> and reuse them on multiple draws.  Currently drivers that implement
> views internally hang them off the relevant texture.  
>
> The choices in this branch are to do it in the CSO module, or push it up
> to the state tracker.
>
>   

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

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

On Thu, 2010-03-11 at 05:21 -0800, Keith Whitwell wrote:
> 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.

Although I endorse cso_set_XXX_sampler_textures for migration, I agree
entirely with you.

Perhaps we could make this clear in the comments.

> To make this change worthwhile, we'd want to somehow cache sampler views
> and reuse them on multiple draws.  Currently drivers that implement
> views internally hang them off the relevant texture.  
> 
> The choices in this branch are to do it in the CSO module, or push it up
> to the state tracker.

Caching in the cso module is certainly feasible, but regardless where it
is done, care must be taken because the smapler view state includes
texture pointers. Worse, it holds on to a texture reference. So at the
very least the cso needs an entrypoint for flushing views for a given
texture that will be called when the st is done with the texture.

Jose

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

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

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).
> 
> Yesterday I had to merge master into gallium-sampler-view -- the nv50 
> and r300 drivers had lots of conflicts. Could the maintainers of said 
> drivers had a look at them and see if they are still functional, please?
> 
> Thanks.

Michal,

Looks good overall. Minor comments below. Sorry if I rehash things that
have been already discussed. Feel free to ignore them.


diff --git a/src/gallium/include/pipe/p_state.h b/src/gallium/include/pipe/p_state.h
index 3a97d88..3c7c0a5 100644
--- a/src/gallium/include/pipe/p_state.h
+++ b/src/gallium/include/pipe/p_state.h
@@ -300,6 +300,24 @@ struct pipe_surface
 
 
 /**
+ * A view into a texture that can be bound to a shader stage.
+ */
+struct pipe_sampler_view
+{
+   struct pipe_reference reference;
+   enum pipe_format format;      /**< typed PIPE_FORMAT_x */

I think it is worth to document that not all formats are valid here.
pipe_sampler_view::format and pipe_texture::format must be compatible.
The semantics of compatibility are a bit confusing though. Even DX10's.

At very least format's util_format_block must match.

RGB <=> SRGB variations should also be accepted. And sizzwle variations.

The difficulty is whether formats like  A4R4G4B4 <=> A1G5R5B5 or
R8G8B8A8 <=> R32 should be accepted. I think hardware should have no
troubles with typecasting. So I'm inclined towards make this acceptible.

+   struct pipe_texture *texture; /**< texture into which this is a view  */

+   struct pipe_context *context; /**< context this view belongs to */

Is this for debugging? No other state object has a pointer to context so far.

+   unsigned first_level:8;       /**< first mipmap level */
+   unsigned num_levels:8;        /**< number of mipamp levels */

I don't care much, but we've been using last_level instead of num_levels
elsewhere. Is there a particular reason to use num_levels here? 

s/mipamp/mipmap/ in comment.

+   unsigned swizzle_r:3;         /**< PIPE_SWIZZLE_x for red component */
+   unsigned swizzle_g:3;         /**< PIPE_SWIZZLE_x for green component */
+   unsigned swizzle_b:3;         /**< PIPE_SWIZZLE_x for blue component */
+   unsigned swizzle_a:3;         /**< PIPE_SWIZZLE_x for alpha component */
+};
+
+
+/**
  * Transfer object.  For data transfer to/from a texture.
  */
 struct pipe_transfer


diff --git a/src/gallium/drivers/llvmpipe/lp_state_sampler.c b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
index b30a075..2df86a0 100644
--- a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
+++ b/src/gallium/drivers/llvmpipe/lp_state_sampler.c

[...]

> +struct pipe_sampler_view *
> +llvmpipe_create_sampler_view(struct pipe_context *pipe,
> +                            struct pipe_texture *texture,
> +                            const struct pipe_sampler_view *templ)
> +{
> +   struct pipe_sampler_view *view = CALLOC_STRUCT(pipe_sampler_view);

Need to handle out of memory here.

> +   *view = *templ;
> +   view->reference.count = 1;
> +   view->texture = NULL;
> +   pipe_texture_reference(&view->texture, texture);
> +   view->context = pipe;
> +
> +   return view;
> +}

The rest looks great to me. It's a very useful gallium interface change.
I particularly like how you eased migration with
cso_set_sampler_textures().

BTW, I noticed you commented out pipe video code. Everybody agreed on
removing it from master and mature pipe video on a branch, but we never
got around to do it. I'll remove this code in the next few days.

Jose

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

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

On Thu, 2010-03-11 at 05:21 -0800, Keith Whitwell wrote:
> 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.
> 
> To make this change worthwhile, we'd want to somehow cache sampler views
> and reuse them on multiple draws.  Currently drivers that implement
> views internally hang them off the relevant texture.  
> 
> The choices in this branch are to do it in the CSO module, or push it up
> to the state tracker.

Looking at it a little, I suspect that doing it in the CSO module will
be the least painful, though you'll need to be careful that caching
sampler views doesn't cause texture references to never go to zero.
Either way, it looks like there is a bit of work still to do on this
branch.

Keith

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

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

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.

To make this change worthwhile, we'd want to somehow cache sampler views
and reuse them on multiple draws.  Currently drivers that implement
views internally hang them off the relevant texture.  

The choices in this branch are to do it in the CSO module, or push it up
to the state tracker.

Keith

Re: [Mesa3d-dev] vmware gallium without X, on EGL

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

On Wed, 2010-03-10 at 13:37 +0100, Peter Hanzel wrote: 
> 
> I had to change this:
> src/gallium/state_trackers/egl/kms/native_kms.c
> in kms_surface_swap_buffers:
> 
>    if (ksurf->is_shown && kcrtc->crtc) {
>       //err = drmModeSetCrtc(kdpy->fd, kcrtc->crtc->crtc_id,
>       //      ksurf->back_fb.buffer_id, kcrtc->crtc->x, kcrtc->crtc->y,
>       //      kcrtc->connectors, kcrtc->num_connectors, &kcrtc->crtc->mode);
>       //if (err)
>       //   return FALSE;
>  drmModeDirtyFB(kdpy->fd, ksurf->back_fb.buffer_id, NULL, 0);
>    }
> 
> Because with drmModeSetCrtc i've got an kernel error:
> vmw_ldu_crtc_set_config: DRM_ERROR("Multiple framebuffers not supported\n");

There were bugs in the vmwgfx kernel module related to this which have
been fixed in the standalone vmwgfx kernel module repository. Are you
still getting these errors with that?


> I have also questuion to gallium.
> What is soft_pipe, llvm_pipe?

They're software rasterization drivers, all the work is done by the CPU.


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

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

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

On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
> On Wed, 2010-03-10 at 20:15 -0800, Chia-I Wu wrote:
> > Hi all,
> > 
> > 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.
> > 
> > Feature-wise, st_api provides a more robust multiple client APIs
> > (OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of
> > various EGLImage extensions.  As st_api interface can coexist with
> > st_public interface, co state trackers should work as before unless they
> > are switched to use st_api.
> > 
> > The original plan to merge the work to master after the interface is
> > implemented by st/mesa and st/vega, and st/egl is converted to use it.
> > Further development and conversions of st/glx and st/dri will happen in
> > master.  While this is still the plan, the recent merge of
> > gallium-sw-api-2 motivates me to submit this WIP patch series for public
> > review.  I will cover only pipe_screen::update_buffer,
> > pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front
> > here as the other parts were discussed a while ago.  But any feedback to
> > the design is appreciated.
> > 
> > To summarize, there is *no* change to pipe_screen::update_buffer and
> > pipe_screen::flush_frontbuffer.  This guarantees the non-Khronos state
> > trackers are not affected, and the st_public path of st/mesa and st/vega
> > still work.  But when the st_api path is taken,
> > pipe_screen::update_buffer is no longer got called.  And the caller of
> > pipe_screen::flush_frontbuffer becomes co state trackers instead of
> > state trackers.
> > 
> > In st_api, the co state trackers are responsible for representing
> > windows/pixmaps/pbuffer as a set of pipe_textures (color buffers,
> > depth/stencil, ...) to the state trackers.  In DRI2, this is done
> > through DRI2GetBuffers and winsys_handle.  In software rasterizer (or
> > DRI1?), this is done by having co state trackers allocate a set of
> > private pipe_textures.  In both cases, the pipe_textures are created as
> > needed.  That is, if the state trackers draw only to the back buffer,
> > the front buffer will not be creatd.
> > 
> > At MakeCurrent, the state trackers (st/mesa and st/vega) are given an
> > st_framebuffer_iface.  The state trackers retrieve the pipe_textures of
> > a window/pixmap/pbuffer mentioned above through this interface.  Other
> > than retrieving the pipe_textures, to support front buffer rendering,
> > the state trackers should call st_framebuffer_iface::flush_front when it
> > has something to display.
> > 
> > The implementation of st_framebuffer_iface::flush_front again depends on
> > the window systems.  In X11 with DRI2, it is no-op if the front buffer
> > passed to the state trackers is real;  Otherwise, it calls
> > DRI2CopyRegion to copy the contents from the fake front buffer to the
> > real front one.
> > 
> > In X11 with software rasterizer, the co state tracker is responsible to
> > display its private pipe_texture to a X drawable.  With the merge of
> > gallium-sw-api-2, this is made really easy by calling
> > pipe_screen::flush_frontbuffer.
> > 
> > The last patch of the series converts st/glx to use st_api.  The diff is
> > cleaner than the diff to st/egl.  It is a quick conversion to help see
> > the design of st_api in work.  There should be bugs, but the simple
> > demos I tested all work.  The other patches are constrained to EGL and
> > any regression outside EGL is considered a bug.
> > 
> > If you read this long because of the mention of EGLImage in the subject,
> > you get to have some fun with progs/es1/xegl/texture_from_pixmap as a
> > thank-you gift :)
> > 
> 
> Chia-I,
> 
> This is all looking good to me.  The code doesn't seem to introduce any
> new layering issues or introduce dependencies on existing ones, which
> helps with ongoing cleanups.
> 
> I did some quick testing with the "linux-debug" target.  Gears works,
> with and without GALLIUM_WRAP=t.  However, demos/singlebuffer seems to
> get caught in infinite recursion and segfaults:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
> 185     {
> (gdb) bt
> #0  0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
> #1  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #2  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #3  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #4  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #5  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #6  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #7  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
> #8  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
>     statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189

Also, libgl-xlib / llvmpipe is getting some rendering errors with these
patches - seems like culling is messed up maybe.  This is with a scons
build after adding the missing xm_st.c file.

Does it make sense to push these patches to a public Mesa branch so some
bugfixing can get done?

Keith

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

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

On Wed, 2010-03-10 at 20:15 -0800, Chia-I Wu wrote:
> Hi all,
> 
> 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.
> 
> Feature-wise, st_api provides a more robust multiple client APIs
> (OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of
> various EGLImage extensions.  As st_api interface can coexist with
> st_public interface, co state trackers should work as before unless they
> are switched to use st_api.
> 
> The original plan to merge the work to master after the interface is
> implemented by st/mesa and st/vega, and st/egl is converted to use it.
> Further development and conversions of st/glx and st/dri will happen in
> master.  While this is still the plan, the recent merge of
> gallium-sw-api-2 motivates me to submit this WIP patch series for public
> review.  I will cover only pipe_screen::update_buffer,
> pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front
> here as the other parts were discussed a while ago.  But any feedback to
> the design is appreciated.
> 
> To summarize, there is *no* change to pipe_screen::update_buffer and
> pipe_screen::flush_frontbuffer.  This guarantees the non-Khronos state
> trackers are not affected, and the st_public path of st/mesa and st/vega
> still work.  But when the st_api path is taken,
> pipe_screen::update_buffer is no longer got called.  And the caller of
> pipe_screen::flush_frontbuffer becomes co state trackers instead of
> state trackers.
> 
> In st_api, the co state trackers are responsible for representing
> windows/pixmaps/pbuffer as a set of pipe_textures (color buffers,
> depth/stencil, ...) to the state trackers.  In DRI2, this is done
> through DRI2GetBuffers and winsys_handle.  In software rasterizer (or
> DRI1?), this is done by having co state trackers allocate a set of
> private pipe_textures.  In both cases, the pipe_textures are created as
> needed.  That is, if the state trackers draw only to the back buffer,
> the front buffer will not be creatd.
> 
> At MakeCurrent, the state trackers (st/mesa and st/vega) are given an
> st_framebuffer_iface.  The state trackers retrieve the pipe_textures of
> a window/pixmap/pbuffer mentioned above through this interface.  Other
> than retrieving the pipe_textures, to support front buffer rendering,
> the state trackers should call st_framebuffer_iface::flush_front when it
> has something to display.
> 
> The implementation of st_framebuffer_iface::flush_front again depends on
> the window systems.  In X11 with DRI2, it is no-op if the front buffer
> passed to the state trackers is real;  Otherwise, it calls
> DRI2CopyRegion to copy the contents from the fake front buffer to the
> real front one.
> 
> In X11 with software rasterizer, the co state tracker is responsible to
> display its private pipe_texture to a X drawable.  With the merge of
> gallium-sw-api-2, this is made really easy by calling
> pipe_screen::flush_frontbuffer.
> 
> The last patch of the series converts st/glx to use st_api.  The diff is
> cleaner than the diff to st/egl.  It is a quick conversion to help see
> the design of st_api in work.  There should be bugs, but the simple
> demos I tested all work.  The other patches are constrained to EGL and
> any regression outside EGL is considered a bug.
> 
> If you read this long because of the mention of EGLImage in the subject,
> you get to have some fun with progs/es1/xegl/texture_from_pixmap as a
> thank-you gift :)
> 

Chia-I,

This is all looking good to me.  The code doesn't seem to introduce any
new layering issues or introduce dependencies on existing ones, which
helps with ongoing cleanups.

I did some quick testing with the "linux-debug" target.  Gears works,
with and without GALLIUM_WRAP=t.  However, demos/singlebuffer seems to
get caught in infinite recursion and segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
185     {
(gdb) bt
#0  0x001ab7d5 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:185
#1  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#2  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#3  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#4  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#5  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#6  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#7  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189
#8  0x001ab800 in xmesa_st_framebuffer_flush_front (stfbi=0x80a7d08, 
    statt=ST_ATTACHMENT_FRONT_LEFT) at xm_st.c:189


Keith

[Mesa3d-dev] [Bug 27007] Lines disappear with GL_LINE_SMOOTH

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

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





--- Comment #2 from Michel Dänzer <mi...@da...>  2010-03-11 03:24:09 PST ---
Please attach the glxinfo output.


-- 
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] [RFC] gallium-sampler-view branch merge

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

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

Yesterday I had to merge master into gallium-sampler-view -- the nv50 
and r300 drivers had lots of conflicts. Could the maintainers of said 
drivers had a look at them and see if they are still functional, please?

Thanks.

[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|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Michel Dänzer <mi...@da...>  2010-03-11 03:15:16 PST ---
Fixed in Git.


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

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

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

On Wed, 2010-03-10 at 22:48 +0100, Johannes Obermayr wrote: 
> XServer 1.7.5:
> 
> I think it is this commit:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=a56da1005d30da60701e33b75d5f4f37096df060
> 
> Thanks.
> Johannes
> 
> 
> 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  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71  xorg_driver.c -o xorg_driver.o
> xorg_crtc.c: In function 'crtc_load_cursor_argb':
> xorg_crtc.c:287: error: dereferencing pointer to incomplete type
> gmake[4]: *** [xorg_crtc.o] Error 1

Thanks for the report, and thanks Jakob for beating me to fixing it.


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

[Mesa3d-dev] [Bug 27012] New: mesa git shows a compilation error

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

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

           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:
---
xorg_crtc.c: In function ‘crtc_load_cursor_argb’:
xorg_crtc.c:287: error: dereferencing pointer to incomplete type
make[4]: *** [xorg_crtc.o] Error 1
make[4]: Leaving directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/state_trackers/xorg'
make[3]: *** [subdirs] Error 1
make[3]: Leaving directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/state_trackers'
make[2]: *** [default] Error 1
make[2]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src/gallium'
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.

Re: [Mesa3d-dev] Commit messages broken??

[Tollef F. H. <tf...@er...>]

]] Zack Rusin 

| On Wednesday 10 March 2010 14:59:42 Zack Rusin wrote:
| > Maybe /usr/bin/mail is broken, I'll double check it.
| 
| Yea, that's it. Someone installed a new mail daemon on the
| server. We're using "-a" to specify the Content-Type header in mails,
| but the heirloom mailx that has been installed uses the "-a" option to
| specify attachments and since filename "Content-Type: text/plain;" is
| not a valid filename it exits with an error. I'll try to fix it right
| now.

Ah, that would be it.  (And mail(1) is hardly a mail daemon :-)

| BTW, replacing a mail client on the server with something that's not 
| compatible is not very social.

Rather than assuming malice, you may assume that I was trying to fix
something when I made that change.  The old mailx mangled UTF-8
content.  The easiest way around this is to use /usr/bin/bsd-mailx
rather than just mail.  I believe it just does the right thing wrt
content-type now, so just dropping -a should fix it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

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

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

Hi all,

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.

Feature-wise, st_api provides a more robust multiple client APIs
(OpenGL/OpenGL ES/OpenVG) to EGL and enable the implementation of
various EGLImage extensions.  As st_api interface can coexist with
st_public interface, co state trackers should work as before unless they
are switched to use st_api.

The original plan to merge the work to master after the interface is
implemented by st/mesa and st/vega, and st/egl is converted to use it.
Further development and conversions of st/glx and st/dri will happen in
master.  While this is still the plan, the recent merge of
gallium-sw-api-2 motivates me to submit this WIP patch series for public
review.  I will cover only pipe_screen::update_buffer,
pipe_screen::flush_frontbuffer, and st_framebuffer_iface::flush_front
here as the other parts were discussed a while ago.  But any feedback to
the design is appreciated.

To summarize, there is *no* change to pipe_screen::update_buffer and
pipe_screen::flush_frontbuffer.  This guarantees the non-Khronos state
trackers are not affected, and the st_public path of st/mesa and st/vega
still work.  But when the st_api path is taken,
pipe_screen::update_buffer is no longer got called.  And the caller of
pipe_screen::flush_frontbuffer becomes co state trackers instead of
state trackers.

In st_api, the co state trackers are responsible for representing
windows/pixmaps/pbuffer as a set of pipe_textures (color buffers,
depth/stencil, ...) to the state trackers.  In DRI2, this is done
through DRI2GetBuffers and winsys_handle.  In software rasterizer (or
DRI1?), this is done by having co state trackers allocate a set of
private pipe_textures.  In both cases, the pipe_textures are created as
needed.  That is, if the state trackers draw only to the back buffer,
the front buffer will not be creatd.

At MakeCurrent, the state trackers (st/mesa and st/vega) are given an
st_framebuffer_iface.  The state trackers retrieve the pipe_textures of
a window/pixmap/pbuffer mentioned above through this interface.  Other
than retrieving the pipe_textures, to support front buffer rendering,
the state trackers should call st_framebuffer_iface::flush_front when it
has something to display.

The implementation of st_framebuffer_iface::flush_front again depends on
the window systems.  In X11 with DRI2, it is no-op if the front buffer
passed to the state trackers is real;  Otherwise, it calls
DRI2CopyRegion to copy the contents from the fake front buffer to the
real front one.

In X11 with software rasterizer, the co state tracker is responsible to
display its private pipe_texture to a X drawable.  With the merge of
gallium-sw-api-2, this is made really easy by calling
pipe_screen::flush_frontbuffer.

The last patch of the series converts st/glx to use st_api.  The diff is
cleaner than the diff to st/egl.  It is a quick conversion to help see
the design of st_api in work.  There should be bugs, but the simple
demos I tested all work.  The other patches are constrained to EGL and
any regression outside EGL is considered a bug.

If you read this long because of the mention of EGLImage in the subject,
you get to have some fun with progs/es1/xegl/texture_from_pixmap as a
thank-you gift :)

-- 
ol...@Lu...

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

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

Mesa/master is correct as is.  Changing ST_SURFACE_DEPTH to be !=
BUFFER_DEPTH is just hiding another problem elsewhere.

If ST_SURFACE_DEPTH==8 then calling st_set_framebuffer_surface(fb,
ST_SURFACE_DEPTH, surf) is effectively setting the fb's COLOR0
attachment to be a Z/stencil buffer (and leaves the fb's DEPTH
attachment undefined (or set to a default surface)).  I'm surprised
that doesn't cause tons of problems elsewhere.

To debug this, I'd start by looking for calls to
st_set_framebuffer_surface() with surfIndex==ST_SURFACE_DEPTH, then
no-op those calls.  That's roughly what would be happening if
ST_SURFACE_DEPTH==8.

-Brian


On Wed, Mar 10, 2010 at 6:33 PM, Marek Olšák <ma...@gm...> wrote:
> I second that. The commit breaks 6 glean tests (api2, clipFlat, fragProg1,
> occluQry, pointAtten, texCombine4) with r300g.
>
> -Marek
>
> On Wed, Mar 10, 2010 at 10:50 PM, Luca Barbieri <lu...@lu...>
> wrote:
>>
>> In mesa_7_7_branch, 52d83efdbc4735d721e6fc9b44f29bdd432d4d73 reverts
>> commit 9d17ad2891b58de9e33e943ff918a678c6a3c2bd.
>>
>> How about cherry-picking that commit into master, until a fix for the
>> bugs the revert commit introduces are found?
>>
>> The reverted commit currently breaks the Warsow main menu for me,
>> making it show garbage.
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
> ------------------------------------------------------------------------------
> 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
>
>

[Mesa3d-dev] [Bug 27007] Lines disappear with GL_LINE_SMOOTH

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

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





--- Comment #1 from Søren Hauberg <so...@ha...>  2010-03-10 18:39:55 PST ---
Created an attachment (id=33931)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33931)
Image that shows the result of running the demonstration program


-- 
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] New: Lines disappear with GL_LINE_SMOOTH

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

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

           Summary: Lines disappear with GL_LINE_SMOOTH
           Product: Mesa
           Version: 7.6
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/X11
        AssignedTo: mes...@li...
        ReportedBy: so...@ha...


Created an attachment (id=33930)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33930)
A program that demonstrates the bug

In GNU Octave we use OpenGL to plot data. From time to time I see lines that
simply disappear in short places. I have been able to reproduce the problem
with a simple test case, which I attach. On my machine, this program generates
an image which I also attach.

I have an Intel GM45 graphics card and I am using Ubuntu 9.10.


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

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

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

I second that. The commit breaks 6 glean tests (api2, clipFlat, fragProg1,
occluQry, pointAtten, texCombine4) with r300g.

-Marek

On Wed, Mar 10, 2010 at 10:50 PM, Luca Barbieri <lu...@lu...>wrote:

> In mesa_7_7_branch, 52d83efdbc4735d721e6fc9b44f29bdd432d4d73 reverts
> commit 9d17ad2891b58de9e33e943ff918a678c6a3c2bd.
>
> How about cherry-picking that commit into master, until a fix for the
> bugs the revert commit introduces are found?
>
> The reverted commit currently breaks the Warsow main menu for me,
> making it show garbage.
>
>
> ------------------------------------------------------------------------------
> 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] Compile error in xorg_crtc.c

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

I'm experiencing a similar compile error,I currently use the latest packages
for xorg from Fedora 13.The configure options I use are the same from my
last post on nabble (galliun-sw-api-2).The compile error I get is this one:

gmake[4]: Entering directory `/opt/mesa/src/gallium/state_trackers/xorg'
rm -f depend
touch depend
/usr/bin/makedepend -fdepend -I/usr/lib/gcc/i686-redhat-linux/4.4.3/include
-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 ./xorg_composite.c ./xorg_crtc.c ./xorg_dri2.c
./xorg_driver.c ./xorg_exa.c ./xorg_exa_tgsi.c ./xorg_output.c
./xorg_renderer.c ./xorg_xv.c    2> /dev/null
gmake[4]: Leaving directory `/opt/mesa/src/gallium/state_trackers/xorg'
gmake[4]: Entering directory `/opt/mesa/src/gallium/state_trackers/xorg'
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_composite.c -o
xorg_composite.o
In file included from /usr/include/xorg/xf86Crtc.h:25,
                 from xorg_tracker.h:42,
                 from xorg_exa.h:4,
                 from xorg_composite.h:4,
                 from xorg_composite.c:1:
/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’:
xorg_crtc.c:287: error: dereferencing pointer to incomplete type
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

If I leave out the xorg state tracker,it goes past fine until it comes up
with this error I posted earlier:

gmake[5]: Entering directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
gcc -c  -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
-DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 -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
-DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dummy.c -o dummy.o
gmake[5]: *** No rule to make target
`../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
`egl_x11_vmwgfx.so'.  Stop.
gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
gmake[4]: *** [default] Error 1
gmake[4]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/opt/mesa/src/gallium/winsys/drm'
gmake[2]: *** [default] Error 1
gmake[2]: Leaving directory `/opt/mesa/src/gallium/winsys'
gmake[1]: *** [subdirs] Error 1
gmake[1]: Leaving directory `/opt/mesa/src'
gmake: *** [default] Error 1

I'll try and wait if the latest packages get updated for xorg,but I might be
tempted to bit the bullet and upgrade to Rawhide.

Regards,
            STEVE555


Bugzilla from joh...@gm... wrote:
> 
> XServer 1.7.5:
> 
> I think it is this commit:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=a56da1005d30da60701e33b75d5f4f37096df060
> 
> Thanks.
> Johannes
> 
> 
> 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  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM
> -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN
> -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
> -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71  xorg_driver.c
> -o xorg_driver.o
> xorg_crtc.c: In function 'crtc_load_cursor_argb':
> xorg_crtc.c:287: error: dereferencing pointer to incomplete type
> gmake[4]: *** [xorg_crtc.o] Error 1
> gmake[4]: *** Waiting for unfinished jobs....
> gmake[4]: Leaving directory
> `/usr/src/packages/BUILD/Mesa/src/gallium/state_trackers/xorg'
> gmake[3]: *** [subdirs] Error 1
> gmake[3]: Leaving directory
> `/usr/src/packages/BUILD/Mesa/src/gallium/state_trackers'
> gmake[2]: *** [default] Error 1
> gmake[2]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/gallium'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/usr/src/packages/BUILD/Mesa/src'
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/Compile-error-in-xorg_crtc.c-tp27856291p27857116.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

[Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

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

In mesa_7_7_branch, 52d83efdbc4735d721e6fc9b44f29bdd432d4d73 reverts
commit 9d17ad2891b58de9e33e943ff918a678c6a3c2bd.

How about cherry-picking that commit into master, until a fix for the
bugs the revert commit introduces are found?

The reverted commit currently breaks the Warsow main menu for me,
making it show garbage.

[Mesa3d-dev] Compile error in xorg_crtc.c

[Johannes O. <joh...@gm...>]

XServer 1.7.5:

I think it is this commit:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=a56da1005d30da60701e33b75d5f4f37096df060

Thanks.
Johannes


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  -fPIC  -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71  xorg_driver.c -o xorg_driver.o
xorg_crtc.c: In function 'crtc_load_cursor_argb':
xorg_crtc.c:287: error: dereferencing pointer to incomplete type
gmake[4]: *** [xorg_crtc.o] Error 1
gmake[4]: *** Waiting for unfinished jobs....
gmake[4]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/gallium/state_trackers/xorg'
gmake[3]: *** [subdirs] Error 1
gmake[3]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/gallium/state_trackers'
gmake[2]: *** [default] Error 1
gmake[2]: Leaving directory `/usr/src/packages/BUILD/Mesa/src/gallium'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/Mesa/src'

Re: [Mesa3d-dev] Commit messages broken??

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

Zack Rusin wrote:
> On Wednesday 10 March 2010 15:18:03 Zack Rusin wrote:
>> On Wednesday 10 March 2010 14:59:42 Zack Rusin wrote:
>>> Maybe /usr/bin/mail is broken, I'll double check it.
>> Yea, that's it. Someone installed a new mail daemon on the server. We're
>>  using "-a" to specify the Content-Type header in mails, but the heirloom
>>  mailx that has been installed uses the "-a" option to specify attachments
>>  and since filename "Content-Type: text/plain;" is not a valid filename it
>>  exits with an error. I'll try to fix it right now.
> 
> k, it should be working now. I switched it to use sendmail directly so that 
> future changes to /usr/bin/mail don't affect it.

Thanks, Zack!!

-Brian

Re: [Mesa3d-dev] Commit messages broken??

[Zack R. <za...@vm...>]

On Wednesday 10 March 2010 15:18:03 Zack Rusin wrote:
> On Wednesday 10 March 2010 14:59:42 Zack Rusin wrote:
> > Maybe /usr/bin/mail is broken, I'll double check it.
> 
> Yea, that's it. Someone installed a new mail daemon on the server. We're
>  using "-a" to specify the Content-Type header in mails, but the heirloom
>  mailx that has been installed uses the "-a" option to specify attachments
>  and since filename "Content-Type: text/plain;" is not a valid filename it
>  exits with an error. I'll try to fix it right now.

k, it should be working now. I switched it to use sendmail directly so that 
future changes to /usr/bin/mail don't affect it.

z