mesa3d-dev

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

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

Luca Barbieri wrote:
> I've looked into the issue, and found a workaround by looking at what
> st_renderbuffer_alloc_storage (which is called to create the depth
> buffer with ST_SURFACE_DEPTH != BUFFER_DEPTH) does.
> 
> Adding:
> if(ctx) ctx->NewState |= _NEW_BUFFERS;
> 
> at the end of st_set_framebuffer_surface seems to solve the warsow
> problem with no other regressions.
> 
> Brian, is this the right fix?

That's probably the right direction, but I think there's several other 
things to be fixed in st_set_framebuffer_surface().  I'll have a patch 
soon...

-Brian

[Mesa3d-dev] context transfers again

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

I've pushed a cleaned-up version of this branch to
gallium-context-transfers-2.  Despite its long history, this branch is a
fairly straightforward change, moving transfers to pipe_context.  

We've had to do quite a bit of work elsewhere to make this change
feasible, but having done that it's not too invasive.  I hope people can
take a look at it & I'll aim to merge in the next few days.

Keith

[Mesa3d-dev] extensions supported or not in gallium

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

Hi,

there are currently a couple of extensions enabled in the mesa state
tracker which probably shouldn't be. These were moved there by commit
a0ae2ca033ec2024da1e01d1c11c0437837c031b (that is with dri they were
already always enabled before).

Someone knows off-hand which one we can enable or not? I'm going to kill
off EXT_cull_vertex and  TDFX_texture_compression_FXT1, clearly we can't
handle them.
The others in question are
ARB_window_pos
APPLE_client_storage
MESA_pack_invert
NV_vertex_program
NV_vertex_program1_1

(the latter two IIRC the problem was that regs needed to be
zero-initialized)

Currently gallium dri drivers also have ARB_imaging enabled too (via
driInitExtensions()), I think that's not correct neither.

Roland

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

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

Karl Schultz wrote:
> Am getting these warnings in the Windows build:
> 
> 2>Compiling...
> 2>lex.yy.c
> 2>program_lexer.l(327) : warning C4244: '=' : conversion from 'double' 
> to 'float', possible loss of data
> 2>program_lexer.l(331) : warning C4244: '=' : conversion from 'double' 
> to 'float', possible loss of data
> 2>program_lexer.l(335) : warning C4244: '=' : conversion from 'double' 
> to 'float', possible loss of data
> 2>program_lexer.l(339) : warning C4244: '=' : conversion from 'double' 
> to 'float', possible loss of data
> 
> The corresponding lines in program_lexer.l are:
> 
> {num}?{frac}{exp}?        {
>    yylval->real = _mesa_strtod(yytext, NULL);
>    return REAL;
> }
> {num}"."/[^.]             {
>    yylval->real = _mesa_strtod(yytext, NULL);
>    return REAL;
> }
> {num}{exp}                {
>    yylval->real = _mesa_strtod(yytext, NULL);
>    return REAL;
> }
> {num}"."{exp}             {
>    yylval->real = _mesa_strtod(yytext, NULL);
>    return REAL;
> }
> 
> I think that we need to add a cast to these four places, e.g.:
> 
>    yylval->real = (float) _mesa_strtod(yytext, NULL);
> 
> Changing progam_lexer.l requires that lex.yy.c (and others) be 
> regenerated with flex/bison and the generated files committed as well, 
> right?  Is there a git trigger that does this, which would be really 
> cool?  Or does someone need to run flex/bison manually and commit all 
> the resulting files?
> 
> If the latter, I don't know the exact process and I'd guess that someone 
> routinely does this.
> 
> If it is not a huge hassle, can someone add these casts to 7.8 and 
> master?  The warnings are no big deal, but the casts do have some value 
> in documenting the implicit conversion.

I'll take care of it.  It's up to the developer to regenerate the 
files and commit them (to avoid everyone needing flex/bison).

-Brian

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

[Karl S. <kar...@gm...>]

Am getting these warnings in the Windows build:

2>Compiling...
2>lex.yy.c
2>program_lexer.l(327) : warning C4244: '=' : conversion from 'double' to
'float', possible loss of data
2>program_lexer.l(331) : warning C4244: '=' : conversion from 'double' to
'float', possible loss of data
2>program_lexer.l(335) : warning C4244: '=' : conversion from 'double' to
'float', possible loss of data
2>program_lexer.l(339) : warning C4244: '=' : conversion from 'double' to
'float', possible loss of data

The corresponding lines in program_lexer.l are:

{num}?{frac}{exp}?        {
   yylval->real = _mesa_strtod(yytext, NULL);
   return REAL;
}
{num}"."/[^.]             {
   yylval->real = _mesa_strtod(yytext, NULL);
   return REAL;
}
{num}{exp}                {
   yylval->real = _mesa_strtod(yytext, NULL);
   return REAL;
}
{num}"."{exp}             {
   yylval->real = _mesa_strtod(yytext, NULL);
   return REAL;
}

I think that we need to add a cast to these four places, e.g.:

   yylval->real = (float) _mesa_strtod(yytext, NULL);

Changing progam_lexer.l requires that lex.yy.c (and others) be regenerated
with flex/bison and the generated files committed as well, right?  Is there
a git trigger that does this, which would be really cool?  Or does someone
need to run flex/bison manually and commit all the resulting files?

If the latter, I don't know the exact process and I'd guess that someone
routinely does this.

If it is not a huge hassle, can someone add these casts to 7.8 and master?
The warnings are no big deal, but the casts do have some value in
documenting the implicit conversion.

Thanks,
Karl

[Mesa3d-dev] [Bug 27017] New: swrast not working correctly - point-wide trivial

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

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

           Summary: swrast not working correctly - point-wide trivial
           Product: Mesa
           Version: git
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mes...@li...
        ReportedBy: ra...@ma...


Created an attachment (id=33954)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33954)
two colors  in four points are seen there

I have mesa up to commit a0ae2ca033ec2024da1e01d1c11c0437837c031b ( st/dri:
move extension initilization to st/mesa completely )

Unfortunately, bug with some small, and not so small trivial demos are still
here, it would be nice if someone fixed them, because working on hw drivers
without reference (correct) rasterizer unnecessary harder.

First bug about progs/trivial/point-wide, i'll attach picture


-- 
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] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

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

On Thu, 2010-03-11 at 07:43 -0800, Chia-I Wu wrote:
> On Thu, Mar 11, 2010 at 7:54 PM, Keith Whitwell <ke...@vm...> wrote:
> > On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
> >> 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?
> Thanks for testing the patches.  I will have a look at the segfault tomorrow.
> I haven't tried llvmpipe.  Does softpipe also get the rendering error?

No, purely llvmpipe.

> I will create a topic branch, gallium-st-api, tomorrow and continue the
> development/bugfixing there, unless there are major design defects that should
> be resolved first.

I don't see any major defects - it all looks pretty sensible to me.

Keith

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

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

On Thu, Mar 11, 2010 at 7:54 PM, Keith Whitwell <ke...@vm...> wrote:
> On Thu, 2010-03-11 at 03:25 -0800, Keith Whitwell wrote:
>> 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?
Thanks for testing the patches.  I will have a look at the segfault tomorrow.
I haven't tried llvmpipe.  Does softpipe also get the rendering error?

I will create a topic branch, gallium-st-api, tomorrow and continue the
development/bugfixing there, unless there are major design defects that should
be resolved first.

-- 
ol...@Lu...

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

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

I've looked into the issue, and found a workaround by looking at what
st_renderbuffer_alloc_storage (which is called to create the depth
buffer with ST_SURFACE_DEPTH != BUFFER_DEPTH) does.

Adding:
if(ctx) ctx->NewState |= _NEW_BUFFERS;

at the end of st_set_framebuffer_surface seems to solve the warsow
problem with no other regressions.

Brian, is this the right fix?
Marek, does it fix your r300g problems too?

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

[Daniel S. <da...@fo...>]

On Thu, Mar 11, 2010 at 10:02:46AM -0500, Zack Rusin wrote:
> On Thursday 11 March 2010 02:58:49 Tollef Fog Heen wrote:
> > ]] Zack Rusin 
> > | 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.  
> 
> I was assuming that whoever did it was trying to do something, but the 
> reasoning behind the change doesn't change the result at all - we were not 
> informed of it and the commit messages broke. So as far as we are concerned 
> there really wouldn't be any difference between someone just deleting 
> /usr/bin/mail and you trying to fix something by replacing mail with something 
> else. The bottom line is that there's quite a few projects hosted on fdo, with 
> a lot of people depending on that setup and making changes to it without 
> communicating it very clearly it is bound to break something.
> I don't want to make into a big deal, because it wasn't but a short email or 
> even an blog just saying "new /usr/bin/mail is coming in, make sure it doesn't 
> break your project" would avoid the whole problem.

Shit happens.  Ease up.

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

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

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?

Keith

[Mesa3d-dev] [Bug 27018] swrast not working correctly - samples/stencil

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

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





--- Comment #6 from Brian Paul <bri...@gm...>  2010-03-11 07:22:39 PST ---
Looks like the issue is related to single buffer rendering.

Some of the tests take a -db flag to turn on double buffering.  point-wide
looks OK with that flag.

Hopefully someone else can look into this.


-- 
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 27018] swrast not working correctly - samples/stencil

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

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





--- Comment #5 from Brian Paul <bri...@gm...>  2010-03-11 07:13:51 PST ---
This demo (and the others you've filed bugs against) work fine here with swrast
built with 'make linux'.  With this configuration, glxinfo reports:

OpenGL vendor string: Brian Paul
OpenGL renderer string: Mesa X11
OpenGL version string: 2.1 Mesa 7.9-devel


It looks like the issue/bugs are in the libGL GLX code or something about the
swrast_dri.so module.  I see the same thing here using a DRI build from a
couple months ago.  I tried updating my DRI stuff just now but ran into a bunch
of broken dependency issues.  I don't have right time to investigate any
further.

If you need a reference sw driver, I suggest 'make linux'.


-- 
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 27017] swrast not working correctly - point-wide trivial

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

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





--- Comment #1 from Andrew Randrianasulu <ra...@ma...>  2010-03-11 06:32:25 PST ---
Created an attachment (id=33955)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33955)
glxinfo -l


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

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

On Thursday 11 March 2010 02:58:49 Tollef Fog Heen wrote:
> ]] Zack Rusin 
> | 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.  

I was assuming that whoever did it was trying to do something, but the 
reasoning behind the change doesn't change the result at all - we were not 
informed of it and the commit messages broke. So as far as we are concerned 
there really wouldn't be any difference between someone just deleting 
/usr/bin/mail and you trying to fix something by replacing mail with something 
else. The bottom line is that there's quite a few projects hosted on fdo, with 
a lot of people depending on that setup and making changes to it without 
communicating it very clearly it is bound to break something.
I don't want to make into a big deal, because it wasn't but a short email or 
even an blog just saying "new /usr/bin/mail is coming in, make sure it doesn't 
break your project" would avoid the whole problem.

z

[Mesa3d-dev] [Bug 27017] swrast not working correctly - point-wide trivial

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

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


Andrew Randrianasulu <ra...@ma...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33956|application/octet-stream    |text/plain
          mime type|                            |




-- 
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 27018] swrast not working correctly - samples/stencil

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

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





--- Comment #4 from Andrew Randrianasulu <ra...@ma...>  2010-03-11 06:51:20 PST ---
Note - rendering directly to fb/vram is  currently way too slow on rv280/KMS

I can see for minute as demo draws itself. Composite manager speed it up .... 


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

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

On Thu, 2010-03-11 at 06:21 -0800, michal wrote:
> 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)?

Yes, looking again, this does seem consistent with DX10's
DXGI_FORMAT_xxxxxx_TYPELESS formats.

What about GL's PBOs? I don't know much about them, but I heard that is
possible to use surfaces with a different format from what was original
created. Do you or anybody know how pipe sampler view could be used in
that case?

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

If it makes life easier then sounds good.

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

Thanks!

Jose

[Mesa3d-dev] [Bug 27018] swrast not working correctly - samples/stencil

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

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





--- Comment #3 from Andrew Randrianasulu <ra...@ma...>  2010-03-11 06:47:45 PST ---
Created an attachment (id=33959)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33959)
same glxinfo -l as in bug #27017


-- 
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 27018] swrast not working correctly - samples/stencil

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

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





--- Comment #2 from Andrew Randrianasulu <ra...@ma...>  2010-03-11 06:46:30 PST ---
Created an attachment (id=33958)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33958)
wrong rendering from swrast


-- 
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 27018] swrast not working correctly - samples/stencil

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

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





--- Comment #1 from Andrew Randrianasulu <ra...@ma...>  2010-03-11 06:45:33 PST ---
Created an attachment (id=33957)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33957)
correct rendering from rv280


-- 
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 27018] New: swrast not working correctly - samples/stencil

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

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

           Summary: swrast not working correctly - samples/stencil
           Product: Mesa
           Version: git
          Platform: x86 (IA32)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mes...@li...
        ReportedBy: ra...@ma...


Using mesa's swrast i have incorrect rendering in progs/samples/stencil, see
picture

I have mesa master up to commit a0ae2ca033ec2024da1e01d1c11c0437837c031b (
st/dri: move extension initilization to st/mesa completely )


-- 
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] sw-api-2 branch

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

Steve,

Does the attached patch help for you?

Keith

On Wed, 2010-03-10 at 05:34 -0800, STEVE555 wrote:
> Hi Keith,
>             I use these configure 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 --ernable-debug
> 
> I sometimes use --with-max-width= and --with-max-height= but the rest of
> them generally stay the same.
> 
> Regards,
>              STEVE555
> 
> 
> Keith Whitwell-3 wrote:
> > 
> > Steve,
> > 
> > What configure options are those?
> > 
> > Keith
> > 
> > On Wed, 2010-03-10 at 04:41 -0800, STEVE555 wrote:
> >> Dear Keith,
> >>                 I checked out your branch using git checkout -b.and used
> >> git
> >> pull to get the differences between your branch and master.I did a gmake
> >> -B
> >> realclean and used my ./configure options I use for master.
> >> Unfortunately,it has stopped compiling with this error:
> >> 
> >> /usr/bin/install -c vmwgfx_dri.so ../../../../../../lib/gallium
> >> gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/dri'
> >> 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
> >> -DHAVE_XEXTPROTO_71 -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
> >> -DHAVE_XEXTPROTO_71 -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
> >> 
> >> Regards,
> >>              STEVE555
> >> 
> >> 
> >> Keith Whitwell-3 wrote:
> >> > 
> >> > This has reached a point where I could think about merging it.  There
> >> is
> >> > plenty more cleanup to do, but the branch makes some big strides and
> >> > introduces a couple of concepts that I've wanted for a long time. 
> >> > 
> >> > In particular the idea of a designated "targets" subtree which has code
> >> > for explicitly constructing driver stacks. 
> >> > 
> >> > Secondly the ability to inject layers into (at least) the software
> >> > stacks has been greatly improved, and I'd like to see us build on that
> >> > for hardware drivers as well.
> >> > 
> >> > There is probably still some bugfix to come, but if you're interested
> >> in
> >> > the software rasterizers, please check out this branch and let me know
> >> > how much I've broken things...
> >> > 
> >> > Keith
> >> > 
> >> > 
> >> >
> >> ------------------------------------------------------------------------------
> >> > 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
> >> > 
> >> > 
> >> 
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > 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
> > 
> > 
> 

[Mesa3d-dev] [Bug 27017] swrast not working correctly - point-wide trivial

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

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





--- Comment #3 from Andrew Randrianasulu <ra...@ma...>  2010-03-11 06:37:35 PST ---
as i can seen in point-wide code, there sould be FOUR different colors:

static void Draw(void)
{
   glClear(GL_COLOR_BUFFER_BIT);.
   glDisable(GL_DEPTH_TEST);

   glPointSize(8.0);

   glBegin(GL_POINTS);
   glColor3f(1,0,0);.
   glVertex3f( 0.9, -0.9, -30.0);
   glColor3f(1,1,0);.
   glVertex3f( 0.9,  0.9, -30.0);
   glColor3f(1,0,1);.
   glVertex3f(-0.9,  0.9, -30.0);
   glColor3f(0,1,1);.
   glVertex3f(-0.9,  -0.9, -30.0);
   glEnd();

   glFlush();

.....


-- 
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 27017] swrast not working correctly - point-wide trivial

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

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


Andrew Randrianasulu <ra...@ma...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33955|0                           |1
        is obsolete|                            |




--- Comment #2 from Andrew Randrianasulu <ra...@ma...>  2010-03-11 06:34:05 PST ---
Created an attachment (id=33956)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33956)
glxinfo -l

Oops, wrong glxinfo


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