mesa3d-dev

Re: [Mesa3d-dev] Remove support for GCC version < 3.3.x

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

On Mon, Mar 1, 2010 at 4:19 PM, Ian Romanick <id...@fr...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> There are a few places in Mesa where we check the GCC version and have
> alternate code paths.  It looks like almost all of the checks go away if
> we require GCC version of at least 3.3.0.  The last 3.2 (or earlier)
> release was in April of 2003.  It seems safe to remove support for a 7
> year old version.  Opinions?

Sounds OK.  It could always be reverted if necessary.

-Brian

[Mesa3d-dev] [PATCH] Fix for multitextured secondary color?

[<ran...@gm...>]

Not tested, but pervious version was from my erroneous testing, clearly wrong 
value and offset.

[Mesa3d-dev] [PATCH] Nouveau add GL_EXT_secondary_color for nv05

[<ran...@gm...>]

Tested with progs/demos/spectex and progs/tests/seccol

[Mesa3d-dev] Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?)

[Stephan R. <mai...@op...>]

Hi all,

i have problems running an Application that depends on Mesa. It seems 
there is an loop after starting this App and before the GUI loads. I use

- xorg-server-1.8 git from 28.02.2010
- Mesa-7.8 git from 28.02.2010
- xf86-video-intel-2.10.901
- linux-2.6.33
- libdrm git from 28.02.2010

glxgears, an windowmanager and mrxvt as terminal works. can anyone see 
where is my problem?

GDB output:

Thread 1 (Thread 0xb5cc7720 (LWP 587)):
#0  0xb7806424 in __kernel_vsyscall ()
#1  0xb5e47fb6 in *__GI___poll (fds=0xb5ec7ff4, nfds=1, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:87
#2  0xb5d5d268 in _xcb_conn_wait (c=0x9571ca0, cond=0xbf9dbbe0, 
vector=0x0, count=0x0) at xcb_conn.c:306
#3  0xb5d5ee09 in xcb_wait_for_reply (c=0x9571ca0, request=30, 
e=0xbf9dbc6c) at xcb_in.c:390
#4  0xb6283b06 in _XReply (dpy=0x9571358, rep=0xbf9dbcdc, extra=0, 
discard=0) at xcb_io.c:461
#5  0xb6c27edf in DRI2GetBuffersWithFormat (dpy=0x9571358, 
drawable=2097167, width=0x9c2b0b4, height=0x9c2b0b8, 
attachments=0xbf9dbdfc, count=2,
     outCount=0xbf9dbe28) at dri2.c:428
#6  0xb6c25ae3 in dri2GetBuffersWithFormat (driDrawable=0x9c2b090, 
width=0x9c2b0b4, height=0x9c2b0b8, attachments=0xbf9dbdfc, count=2, 
out_count=0xbf9dbe28,
     loaderPrivate=0x9c2aff0) at dri2_glx.c:435
#7  0xb592db79 in intel_update_renderbuffers (context=0x95cc468, 
drawable=0x9c2b090) at intel_context.c:253
#8  0xb592e1a6 in intel_prepare_render (intel=0x98e6640) at 
intel_context.c:395
#9  0xb5929451 in intelClearWithBlit (ctx=0x98e6640, mask=<value 
optimized out>) at intel_blit.c:253
#10 0xb592bc92 in intelClear (ctx=0x98e6640, mask=2) at intel_clear.c:169
#11 0xb59cc999 in _mesa_Clear (mask=0) at main/clear.c:183
#12 0xb6c3accb in glClear (mask=16384) at 
../../src/mesa/glapi/glapitemp.h:1102
#13 0x085de6f4 in CRenderSystemGL::ClearBuffers (this=0x8c09b1c, r=0, 
g=0, b=0, a=0) at RenderSystemGL.cpp:196
#14 0x086714f4 in CGraphicContext::Clear (this=0x8c0a340) at 
GraphicContext.cpp:515
#15 0x0831c58c in CApplication::RenderNoPresent (this=0x8c070a0) at 
Application.cpp:2007
#16 0x0830ef80 in CApplication::Render (this=0x8c070a0) at 
Application.cpp:2202
#17 0x0869f704 in CGUIDialog::DoModal_Internal (this=0xb2e6aa80, 
iWindowID=9999, param=...) at GUIDialog.cpp:171
#18 0x0855d38e in CApplicationMessenger::ProcessMessage (this=0x8c07cc4, 
pMsg=0xbf9dc6fc) at ApplicationMessenger.cpp:512
#19 0x0855e46f in CApplicationMessenger::SendMessage (this=0x8c07cc4, 
message=..., wait=true) at ApplicationMessenger.cpp:98
#20 0x0855e95c in CApplicationMessenger::DoModal (this=0x8c07cc4, 
pDialog=0xb2e6aa80, iWindowID=9999, param=...) at 
ApplicationMessenger.cpp:818
#21 0x0869f28f in CGUIDialog::DoModal (this=0xb2e6aa80, iWindowID=9999, 
param=...) at GUIDialog.cpp:219
#22 0x0855ceee in CApplicationMessenger::ProcessMessage (this=0x8c07cc4, 
pMsg=0x9742938) at ApplicationMessenger.cpp:488
#23 0x0855f989 in CApplicationMessenger::ProcessWindowMessages 
(this=0x8c07cc4) at ApplicationMessenger.cpp:610
#24 0x083210c3 in CApplication::Process (this=0x8c070a0) at 
Application.cpp:4779
#25 0x085779bc in CXBApplicationEx::Run (this=0x8c070a0) at 
XBApplicationEx.cpp:89
#26 0x085781fc in main (argc=5, argv=0xbf9dcfb4) at xbmc.cpp:150
A debugging session is active.

     Inferior 1 [process 587] will be detached.

greetings

Stephan

-- 
               ### OpenELEC.tv ###
The free and open Mediacenter Distribution 4 you
              http://www.openelec.tv

Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

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

> I don't think anybody has tried hooking it up - so far the primary
> purpose of the svga gallium driver has been GL support, but thinking
> about it you're probably right.

I'm a bit confused about this: I was under the impression that VMware
Tools for Windows used your DirectX state tracker and a WGL version of
Mesa, talking to the svga Gallium driver.
How does it actually work?
What do you normally use the DirectX 9 state tracker with?

> The details of the closed code aren't terribly important as they could
> always be changed.
Sure, but it currently is the only Gallium user that supports the SM3
model and thus the only one that really needs arbitrary semantic
indices, and puts constraints on them.

>> The correct value in this case seems to be 219 = 14 * 16 SM3 semantics
>> - 5 for COLOR0, COLOR1, PSIZE0, POSITION0, FOG0 which have specific
>> TGSI semantics which they need to mapped to/from.
>
> Agree, though I'd opt for 255 as a round number.

The problem with this is that you only have 14 SM3 semantics with 16
indices each, so you can't map 256 generic indices into the VMware
interface, or directly into an SM3 shader.
You only have 14 * 16 minus the ones used for non-GENERIC semantics
(the one mentioned above).
And of course, if you choose a smaller number, you can't map SM3
_into_ Gallium, so you need to choose the exact number required for
SM3.

Tying Gallium in this way to SM3 is surely a bit ugly, but it's just a
constant, and I don't see any other way to implement SM3 without doing
linkage in software in the r600 and svga drivers and/or in SM3 state
trackers.

Re: [Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

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

On Tue, 2010-03-02 at 03:26 -0800, Luca Barbieri wrote:
> I've been looking at shader semantics some more, and I'm a bit
> surprised by how the svga driver works.
> It seems that an obvious implementation of a DirectX 9 state tracker
> just won't work with the svga driver.

I don't think anybody has tried hooking it up - so far the primary
purpose of the svga gallium driver has been GL support, but thinking
about it you're probably right.

> In SM3, vertex/fragment semantics can be arbitrary (independent of
> hardware resources), but indices are limited to a 0-15 range.
> 
> A DirectX 9 state tracker must convert those to TGSI_SEMANTIC_GENERIC.
> How does the VMware one do that?
> Assuming that it maps them directly, this means that the driver must
> support GENERIC semantic indices up to a number that varies between
> about 200 and 255.

The details of the closed code aren't terribly important as they could
always be changed.

But you're right that any DX9 state tracker would have to try to pack
all or almost all the DX9 semantics into the TGSI GENERIC range.  The
simplest implementation would end up using 0..255.

> The problem is that the vmware svga driver, as far as I can see,
> doesn't support indices greater than 15.
> This is caused by the fact that it maps all GENERIC semantics to
> SVGA3D_DECLUSAGE_TEXCOORD, and the index bitfield in the svga virtual
> interface only supports 4 bits.

Indeed, good point.  That's basically a shortcoming of the current svga
gallium driver which needs to be addressed somehow.

> In other words, SM3 under VMware with arbitrary semantics (allowed by
> SM3 and other drivers) really seems broken, for a straightforward
> DirectX9 state tracker implementation.
> 
> The only way it can work now is if the DirectX 9 state tracker looks
> at both the vertex and pixel shaders, links them, and outputs
> sequential semantic indices.
> 
> It seems to me that the svga driver should be fixed to map GENERIC to
> *all* SM3 semantic types, ideally in a way that reverses the SM3 ->
> GENERIC transformation done by the DX9 state tracker.

Agree, though I don't think reversibility is necessary.

> Doing this requires to specify a maximum index for
> TGSI_SEMANTIC_GENERIC which is very carefully chosen to allow 1:1
> mapping with SM3, so that DirectX 9 state trackers have enough indices
> to represent all SM3, and the svga driver can fit all indices in the
> SM3-like semantics of the VMware virtual GPU interface.
> 
> The correct value in this case seems to be 219 = 14 * 16 SM3 semantics
> - 5 for COLOR0, COLOR1, PSIZE0, POSITION0, FOG0 which have specific
> TGSI semantics which they need to mapped to/from.

Agree, though I'd opt for 255 as a round number.

> I'm looking at this because this seems the strictest constraint on
> choosing a limit for TGSI_SEMANTIC_GENERIC indices.
> The other constraint is due to r600 supporting only byte-sized
> semantic/index combinations, which is less strict than SM3.
> 
> BTW, glsl also looks artificially limited on svga, as only 6 varyings
> will be supported, due to it starting from 10.

Agree, well spotted.  I'll take a look at that.

Keith

[Mesa3d-dev] Does DX9 SM3 -> VMware svga with arbitrary semantics work? How?

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

I've been looking at shader semantics some more, and I'm a bit
surprised by how the svga driver works.
It seems that an obvious implementation of a DirectX 9 state tracker
just won't work with the svga driver.

In SM3, vertex/fragment semantics can be arbitrary (independent of
hardware resources), but indices are limited to a 0-15 range.

A DirectX 9 state tracker must convert those to TGSI_SEMANTIC_GENERIC.
How does the VMware one do that?
Assuming that it maps them directly, this means that the driver must
support GENERIC semantic indices up to a number that varies between
about 200 and 255.

The problem is that the vmware svga driver, as far as I can see,
doesn't support indices greater than 15.
This is caused by the fact that it maps all GENERIC semantics to
SVGA3D_DECLUSAGE_TEXCOORD, and the index bitfield in the svga virtual
interface only supports 4 bits.

In other words, SM3 under VMware with arbitrary semantics (allowed by
SM3 and other drivers) really seems broken, for a straightforward
DirectX9 state tracker implementation.

The only way it can work now is if the DirectX 9 state tracker looks
at both the vertex and pixel shaders, links them, and outputs
sequential semantic indices.

It seems to me that the svga driver should be fixed to map GENERIC to
*all* SM3 semantic types, ideally in a way that reverses the SM3 ->
GENERIC transformation done by the DX9 state tracker.

Doing this requires to specify a maximum index for
TGSI_SEMANTIC_GENERIC which is very carefully chosen to allow 1:1
mapping with SM3, so that DirectX 9 state trackers have enough indices
to represent all SM3, and the svga driver can fit all indices in the
SM3-like semantics of the VMware virtual GPU interface.

The correct value in this case seems to be 219 = 14 * 16 SM3 semantics
- 5 for COLOR0, COLOR1, PSIZE0, POSITION0, FOG0 which have specific
TGSI semantics which they need to mapped to/from.

I'm looking at this because this seems the strictest constraint on
choosing a limit for TGSI_SEMANTIC_GENERIC indices.
The other constraint is due to r600 supporting only byte-sized
semantic/index combinations, which is less strict than SM3.

BTW, glsl also looks artificially limited on svga, as only 6 varyings
will be supported, due to it starting from 10.

Re: [Mesa3d-dev] PK/UP* and NV_[vertex|fragment]_program* support in Gallium?

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

> At some stage we're definitely interested in the gpu_program4 extension.
> I'm not sure the older ones will ever be pulled in.
swrast already supports NV_fragment_program_option (nv30) and
NV_vertex_program_1_1 (nv20).
nv30/nv40 support of those should be easy, but requires to extend TGSI
with condition codes and ideally precision and precision hints too.
nv50 support is probably harder.
Note that NV_gpu_program4 is mostly a superset of the older
extensions, so it doesn't make much sense to have it in isolation.

> Basically I'd like to see them removed until they actually get used, at
> which time they're welcome back in...
Yes, seems a good idea.
In particular, all the "assert(0)" or similar implementations make no
sense: all instructions should be implemented, unless they are
conditional on some capability bit, in which case they should be
handled by the default switch case.

Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium format swizzles)

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

On Tue, 2010-03-02 at 02:44 -0800, José Fonseca wrote:
> On Wed, 2010-02-24 at 08:19 -0800, José Fonseca wrote:
> > On Tue, 2010-02-23 at 09:20 -0800, José Fonseca wrote:
> > > On Mon, 2010-02-22 at 06:34 -0800, José Fonseca wrote:
> > > > On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
> > > > > Hi José,
> > > > > 
> > > > > the attached patch fixes incorrect swizzles in u_format.csv. There are
> > > > > basically just 2 drivers which depend on the swizzles in this table:
> > > > > llvmpipe and r300g. Since r300g started supporting pretty much every
> > > > > texture format except SCALED ones, a few regressions have showed up.
> > > > > This patch resolves all issues I had, especially with the SRGB formats
> > > > > but I decided to clean it up all. git log:
> > > > > 
> > > > >     util: fix swizzles in the format table for 8-bits-per-channel
> > > > > formats
> > > > >     
> > > > >     The 8-bits-per-channel formats having the same channel order had
> > > > > completely
> > > > >     different swizzles, and at the same time, the same swizzles were
> > > > > used for
> > > > >     completely different channel orders of 8bpc formats.
> > > > >     
> > > > >     This made the whole table self-contradicting, caused headaches,
> > > > > and last
> > > > >     but not least, incorrent rendering for the drivers relying on
> > > > > these swizzles.
> > > > > 
> > > > > I hope I got it right. I didn't make a special distinction between the
> > > > > array and arith layouts. All I did was to make sure that if I grep
> > > > > e.g. A8R8G8B8, I'll get the same swizzles and not entirely different
> > > > > ones.
> > > > 
> > > > Hi Marek,
> > > > 
> > > > I'll need a bit more time to investigate this.
> > > > 
> > > > One problem is that the interpretation of the swizzle varies with array
> > > > vs arith. The ordering for array is the lowest significant word to the
> > > > highest significant word (where word for 8bit formats is a byte), where
> > > > for arith it goes from least significant bit to the highest significant
> > > > bit. This is the same difference as array indexation and bit shifts.
> > > > 
> > > > There is also the problem of byte order which affects the bit shift
> > > > interpretation... 
> > > > 
> > > > I admit thet the current format description table is terribly
> > > > underdocumented/confusing and likely broken in several ways. I wrote it
> > > > to be able to code generate pixel format translation (which is wroking
> > > > reasonably) and never expected people to use it for hardware drivers as
> > > > well, although it is perfectly legitimate use. 
> > > > 
> > > > I have my own interpretation of these concepts, you and others hw driver
> > > > writers have their own different interpretation. Furthermore in
> > > > draw/translate/util modules there are some inconsistencies in these
> > > > interpretations too. So I need to read the GL and DX10 specs very well,
> > > > see how current drivers are using the descriptions, and come up with
> > > > something that makes sense for everybody.
> > > > 
> > > > So please hold on to your patch for a couple of days.
> > > > 
> > > > I'd appreciate if the interested parties could take a good look to
> > > > u_format.h comments, and summarize what they think the format semantics
> > > > should be.
> > > > 
> > > > Jose
> > > 
> > > 
> > > There are two inconsistencies in formats ATM: 
> > > a) the notation used in PIPE_FORMAT_xxx, and 
> > > b) the values in util_format_description::swizzles .
> > > 
> > > 
> > > There's a D3D9 <-> D3D10 format conversion table  in 
> > > http://msdn.microsoft.com/en-us/library/ee415668(VS.85).aspx#Porting_Content
> > > and D3D9 <-> GL format table in
> > > http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/utils.c;hb=HEAD .
> > > 
> > > D3D10 dropped all arithmetically encoded formats, and inverted the
> > > swizzle notation (e.g., D3DFMT_A2B10G10R10 and  DXGI_FORMAT_R10G10B10A2
> > > are equivalent).
> > > 
> > > Gallium has to represent both kinds and mixes both notations (the
> > > MSB->LSB notation traditionally used for texture formats, the LSB->MSB
> > > for vertex declarations). So instead of the current inconsistencies,
> > > both on p_format.h and u_format.csv, I suggest we all normalize on one
> > > notation, lets say MSB->LSB for pixel/vertex formats.
> > > 
> > > For example, the vertex format
> > > 
> > >    struct vertex {
> > >       float x; 
> > >       float y;
> > >    };
> > > 
> > > should be described the format PIPE_FORMAT_G32R32_FLOAT (not the current
> > > PIPE_FORMAT_R32G32_FLOAT), which is equivalent:
> > > - D3D9's D3DFMT_G32R32F texture format
> > > - D3D9's D3DDECLTYPE_FLOAT2 vertex declaration type
> > > - D3D10's DXGI_FORMAT_R32G32_FLOAT
> > > - OpenGL's GL_RG32F format
> > > - OpenGL's glVertexAttrib2f attribute
> > > - OpenGL's glVertexPointer(2, GL_FLOAT, 0, 0);
> > > - etc.
> > > 
> > > 
> > > For the util_format_description::swizzles I suggest we always refer the
> > > swizzles from LSB->MSB.
> > > 
> > > 
> > > Leaving the interface change aside for now (Keith is away this week),
> > > unless somebody has a better suggestion I'll update at least the meaning
> > > of util_format_description::swizzles and u_format.csv to be consistent
> > > with this.
> > 
> > I'm finished with my u_format* cleanups for now. 
> > 
> > We have no unit tests for pixel formats yet so there might be some
> > regressions. Let me know. 
> > 
> > As said in the bottom of u_format.csv, there are the formats with
> > unclear / inconsistent semantics:
> > 
> > # Ambiguous formats
> > # FIXME: They are used with different meanings in different places!!!
> > PIPE_FORMAT_R8G8B8_UNORM          , plain, 1, 1, un8 , un8 , un8 ,     , zyx1, rgb
> > PIPE_FORMAT_R8G8B8A8_UNORM        , plain, 1, 1, un8 , un8 , un8 , un8 , wzyx, rgb
> > 
> > # Unused formats
> > # XXX: Couldn't find any state tracker using them!!
> > PIPE_FORMAT_B6G5R5_SNORM          , plain, 1, 1, sn5 , sn5 , sn6 ,     , xyz1, rgb
> > PIPE_FORMAT_R8G8B8X8_SNORM        , plain, 1, 1, sn8 , sn8 , sn8 , sn8 , wzy1, rgb
> > PIPE_FORMAT_R8G8B8X8_USCALED      , plain, 1, 1, u8  , u8  , u8  , u8  , wzy1, rgb
> > PIPE_FORMAT_R8G8B8X8_SSCALED      , plain, 1, 1, s8  , s8  , s8  , s8  , wzy1, rgb
> > # XXX: This one is mentioned in mesa and r300, but not anywhere else. Not sure it is actually needed
> > PIPE_FORMAT_R8G8B8X8_UNORM        , plain, 1, 1, un8 , un8 , un8 , un8 , wzy1, rgb
> > 
> > The former formats need to be split in two formats to unalias their
> > semantics, and the latter formats should probably be removed.
> 
> I've done with the pipe format cleanup:
> - removing duplicate formats with same semantics
> - un-aliased different formats with the same name
> - standardize on LSB->MSB swizzle notation (it seemed to gather more
> consensus, and is used D3D10 and many places)
> - ditto for YUV formats

It looks good to me Jose.

Keith

Re: [Mesa3d-dev] [RFC] gallium-no-rhw-position branch merge

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

Michal,

This is looking good to me - feel free to merge once any loose ends are
tied up.

Keith

On Mon, 2010-03-01 at 17:46 -0800, Marek Olšák wrote:
> Ahhh, I am a bad liar. The attached patch fixes the regressions.
> 
> -Marek
> 
> On Tue, Mar 2, 2010 at 2:08 AM, Marek Olšák <ma...@gm...> wrote:
>         Hi Michal,
>         
>         This branch breaks 2 piglit tests with r300g:
>         
>         depthrange-clear
>         texdepth
>         
>         However I haven't investigated these and won't get to them
>         until the weekend. I personally don't mind fixing the
>         regressions after the merge (but I'm not the maintainer of
>         r300g). Anyway I'm glad to see bypass_vs_clip_and_viewport
>         dying.
>         
>         -Marek
>         
>         
>         
>         On Mon, Mar 1, 2010 at 5:08 PM, michal <mi...@vm...>
>         wrote:
>                 Hi,
>                 
>                 This branch removes bypass_vs_clip_and_viewport flag
>                 from pipe
>                 rasterizer state. The benefits of having this bit
>                 around were dubious
>                 for everybody and burdensome for driver writers.
>                 
>                 All the utility code that relied on this flag have
>                 been rewritten to
>                 pass vertex positions in clip space and set clip and
>                 viewport state. I
>                 would like to ask the maintainers of u_blitter module
>                 to please test my
>                 changes and provide feedback.
>                 
>                 Please review.
>                 
>                 Thanks.
>                 
>                 
>                 ------------------------------------------------------------------------------
>                 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] RFC: gallium-format-cleanup branch (was Gallium format swizzles)

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

On Wed, 2010-02-24 at 08:19 -0800, José Fonseca wrote:
> On Tue, 2010-02-23 at 09:20 -0800, José Fonseca wrote:
> > On Mon, 2010-02-22 at 06:34 -0800, José Fonseca wrote:
> > > On Sun, 2010-02-21 at 06:40 -0800, Marek Olšák wrote:
> > > > Hi José,
> > > > 
> > > > the attached patch fixes incorrect swizzles in u_format.csv. There are
> > > > basically just 2 drivers which depend on the swizzles in this table:
> > > > llvmpipe and r300g. Since r300g started supporting pretty much every
> > > > texture format except SCALED ones, a few regressions have showed up.
> > > > This patch resolves all issues I had, especially with the SRGB formats
> > > > but I decided to clean it up all. git log:
> > > > 
> > > >     util: fix swizzles in the format table for 8-bits-per-channel
> > > > formats
> > > >     
> > > >     The 8-bits-per-channel formats having the same channel order had
> > > > completely
> > > >     different swizzles, and at the same time, the same swizzles were
> > > > used for
> > > >     completely different channel orders of 8bpc formats.
> > > >     
> > > >     This made the whole table self-contradicting, caused headaches,
> > > > and last
> > > >     but not least, incorrent rendering for the drivers relying on
> > > > these swizzles.
> > > > 
> > > > I hope I got it right. I didn't make a special distinction between the
> > > > array and arith layouts. All I did was to make sure that if I grep
> > > > e.g. A8R8G8B8, I'll get the same swizzles and not entirely different
> > > > ones.
> > > 
> > > Hi Marek,
> > > 
> > > I'll need a bit more time to investigate this.
> > > 
> > > One problem is that the interpretation of the swizzle varies with array
> > > vs arith. The ordering for array is the lowest significant word to the
> > > highest significant word (where word for 8bit formats is a byte), where
> > > for arith it goes from least significant bit to the highest significant
> > > bit. This is the same difference as array indexation and bit shifts.
> > > 
> > > There is also the problem of byte order which affects the bit shift
> > > interpretation... 
> > > 
> > > I admit thet the current format description table is terribly
> > > underdocumented/confusing and likely broken in several ways. I wrote it
> > > to be able to code generate pixel format translation (which is wroking
> > > reasonably) and never expected people to use it for hardware drivers as
> > > well, although it is perfectly legitimate use. 
> > > 
> > > I have my own interpretation of these concepts, you and others hw driver
> > > writers have their own different interpretation. Furthermore in
> > > draw/translate/util modules there are some inconsistencies in these
> > > interpretations too. So I need to read the GL and DX10 specs very well,
> > > see how current drivers are using the descriptions, and come up with
> > > something that makes sense for everybody.
> > > 
> > > So please hold on to your patch for a couple of days.
> > > 
> > > I'd appreciate if the interested parties could take a good look to
> > > u_format.h comments, and summarize what they think the format semantics
> > > should be.
> > > 
> > > Jose
> > 
> > 
> > There are two inconsistencies in formats ATM: 
> > a) the notation used in PIPE_FORMAT_xxx, and 
> > b) the values in util_format_description::swizzles .
> > 
> > 
> > There's a D3D9 <-> D3D10 format conversion table  in 
> > http://msdn.microsoft.com/en-us/library/ee415668(VS.85).aspx#Porting_Content
> > and D3D9 <-> GL format table in
> > http://source.winehq.org/git/wine.git/?a=blob;f=dlls/wined3d/utils.c;hb=HEAD .
> > 
> > D3D10 dropped all arithmetically encoded formats, and inverted the
> > swizzle notation (e.g., D3DFMT_A2B10G10R10 and  DXGI_FORMAT_R10G10B10A2
> > are equivalent).
> > 
> > Gallium has to represent both kinds and mixes both notations (the
> > MSB->LSB notation traditionally used for texture formats, the LSB->MSB
> > for vertex declarations). So instead of the current inconsistencies,
> > both on p_format.h and u_format.csv, I suggest we all normalize on one
> > notation, lets say MSB->LSB for pixel/vertex formats.
> > 
> > For example, the vertex format
> > 
> >    struct vertex {
> >       float x; 
> >       float y;
> >    };
> > 
> > should be described the format PIPE_FORMAT_G32R32_FLOAT (not the current
> > PIPE_FORMAT_R32G32_FLOAT), which is equivalent:
> > - D3D9's D3DFMT_G32R32F texture format
> > - D3D9's D3DDECLTYPE_FLOAT2 vertex declaration type
> > - D3D10's DXGI_FORMAT_R32G32_FLOAT
> > - OpenGL's GL_RG32F format
> > - OpenGL's glVertexAttrib2f attribute
> > - OpenGL's glVertexPointer(2, GL_FLOAT, 0, 0);
> > - etc.
> > 
> > 
> > For the util_format_description::swizzles I suggest we always refer the
> > swizzles from LSB->MSB.
> > 
> > 
> > Leaving the interface change aside for now (Keith is away this week),
> > unless somebody has a better suggestion I'll update at least the meaning
> > of util_format_description::swizzles and u_format.csv to be consistent
> > with this.
> 
> I'm finished with my u_format* cleanups for now. 
> 
> We have no unit tests for pixel formats yet so there might be some
> regressions. Let me know. 
> 
> As said in the bottom of u_format.csv, there are the formats with
> unclear / inconsistent semantics:
> 
> # Ambiguous formats
> # FIXME: They are used with different meanings in different places!!!
> PIPE_FORMAT_R8G8B8_UNORM          , plain, 1, 1, un8 , un8 , un8 ,     , zyx1, rgb
> PIPE_FORMAT_R8G8B8A8_UNORM        , plain, 1, 1, un8 , un8 , un8 , un8 , wzyx, rgb
> 
> # Unused formats
> # XXX: Couldn't find any state tracker using them!!
> PIPE_FORMAT_B6G5R5_SNORM          , plain, 1, 1, sn5 , sn5 , sn6 ,     , xyz1, rgb
> PIPE_FORMAT_R8G8B8X8_SNORM        , plain, 1, 1, sn8 , sn8 , sn8 , sn8 , wzy1, rgb
> PIPE_FORMAT_R8G8B8X8_USCALED      , plain, 1, 1, u8  , u8  , u8  , u8  , wzy1, rgb
> PIPE_FORMAT_R8G8B8X8_SSCALED      , plain, 1, 1, s8  , s8  , s8  , s8  , wzy1, rgb
> # XXX: This one is mentioned in mesa and r300, but not anywhere else. Not sure it is actually needed
> PIPE_FORMAT_R8G8B8X8_UNORM        , plain, 1, 1, un8 , un8 , un8 , un8 , wzy1, rgb
> 
> The former formats need to be split in two formats to unalias their
> semantics, and the latter formats should probably be removed.

I've done with the pipe format cleanup:
- removing duplicate formats with same semantics
- un-aliased different formats with the same name
- standardize on LSB->MSB swizzle notation (it seemed to gather more
consensus, and is used D3D10 and many places)
- ditto for YUV formats

Jose

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

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

On Mon, 2010-03-01 at 10:02 -0800, Roland Scheidegger wrote:
> Hi,
> 
> this branch turns vertex element into a cso, so instead of
> set_vertex_elements there's now the triad of
> create/bind/delete_vertex_elements_state. I have converted all the
> drivers except nouveau (I didn't do it because Christoph Bumiller
> already did nv50, but I can give the rest of them a shot), though that
> doesn't necessarily mean they are optimized for it (the idea is of
> course to precalculate state on create, not just copy the pipe structs
> and do everything on bind) - only i965g really does something close to
> it (though still emits the state always). Drivers doing both hw vertex
> shaders and using draw in some circumstances of course will have to
> store both representations on create.
> Also note that util_draw_vertex_buffer semantics have changed a bit
> (caller needs to set vertex element state, which is a bit odd).

Roland,

The branch looks good to me, happy to see it merged when you're ready to
go.

Keith

Re: [Mesa3d-dev] PK/UP* and NV_[vertex|fragment]_program* support in Gallium?

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

On Mon, 2010-03-01 at 10:25 -0800, Luca Barbieri wrote: 
> I see that PK2US and friends are being removed.
> These would be necessary to implement NV_fragment_program_option,
> NV_fragment_program2 and NV_gpu_program4.


> Currently the no drivers (including Nouveau) support them, but since
> we already have some support in Mesa (even parsers for the nVidia
> syntax), it would be nice to support them in Gallium eventually.
> 
> Not sure about STR/SFL though: they can be encoded/decoded as MOV x,
> 0/1, but they "complete" the SETcond instruction set.
> 
> How about keeping them and adding a capability bit for them?


At some stage we're definitely interested in the gpu_program4 extension.
I'm not sure the older ones will ever be pulled in.

There is more than just these few pack/unpack opcodes to support gpu4
though.  I don't see much point keeping them hanging around as
placeholders until somebody commits to do the real work of implementing
the extension.

Basically I'd like to see them removed until they actually get used, at
which time they're welcome back in...

Keith

Re: [Mesa3d-dev] PK/UP* and NV_[vertex|fragment]_program* support in Gallium?

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

Luca Barbieri wrote on 2010-03-01 18:25:
> I see that PK2US and friends are being removed.
> These would be necessary to implement NV_fragment_program_option,
> NV_fragment_program2 and NV_gpu_program4.
>
> Currently the no drivers (including Nouveau) support them, but since
> we already have some support in Mesa (even parsers for the nVidia
> syntax), it would be nice to support them in Gallium eventually.
>
> Not sure about STR/SFL though: they can be encoded/decoded as MOV x,
> 0/1, but they "complete" the SETcond instruction set.
>
> How about keeping them and adding a capability bit for them?
>   
I don't know if anybody cares about those NV extensions, and if there's 
somebody eager enough to add support for them to the whole gallium 
stack, nothing stops him/her from re-adding those opcodes.

The point of gallium-no-nvidia-opcodes is to strip down TGSI instruction 
set to what's being actually used by state trackers and implemented by 
drivers.

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

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

On Mon, 2010-03-01 at 20:18 -0800, Joakim Sindholt wrote:
> On Tue, 2010-03-02 at 04:02 +0100, Roland Scheidegger wrote:
> > On 02.03.2010 00:18, Joakim Sindholt wrote:
> > > On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
> > >> Hi,
> > >>
> > >> this branch turns vertex element into a cso, so instead of
> > >> set_vertex_elements there's now the triad of
> > >> create/bind/delete_vertex_elements_state. I have converted all the
> > >> drivers except nouveau (I didn't do it because Christoph Bumiller
> > >> already did nv50, but I can give the rest of them a shot), though that
> > >> doesn't necessarily mean they are optimized for it (the idea is of
> > >> course to precalculate state on create, not just copy the pipe structs
> > >> and do everything on bind) - only i965g really does something close to
> > >> it (though still emits the state always). Drivers doing both hw vertex
> > >> shaders and using draw in some circumstances of course will have to
> > >> store both representations on create.
> > >> Also note that util_draw_vertex_buffer semantics have changed a bit
> > >> (caller needs to set vertex element state, which is a bit odd).
> > >>
> > >> Roland
> > > 
> > > Can I still do things like:
> > > element 0: -> vbo 5
> > > element 1: -> vbo 2
> > > and then set_vertex_buffers() with an array { zeros, zeros, vbo 2, zeros
> > > zeros, vbo 5 } ?
> > > 
> > 
> > The branch doesn't change pipe_vertex_element itself (except
> > nr_components got removed as that's really derived from the associated
> > pipe_format), only how those vertex elements are set. Hence you can do
> > exactly the same things you could do before. Though I'm not quite sure
> > what your zeros mean, if that's just a unused vbo it should be ok, but
> > it is probably not ok to just pass in a null pointer for a unused
> > pipe_vertex_buffer.
> > 
> > Roland
> 
> I did just mean empty buffers, but they're not actual buffers. I wrote
> "zeros" because I literally just zero out everything in that particular
> struct. There's no sense in binding 6 vbos when I really only have 2
> 

Yes, this looks legal to me.

Keith

Re: [Mesa3d-dev] Searching for the Depth Buffer implementation

[Olivier G. <gal...@po...>]

On Mon, Mar 01, 2010 at 08:22:37PM -0800, asimov01 wrote:
> I am trying to implement the openGL Readpixels for depth buffer in plain
> c++.  I have tried to dig into openGL for this but I think this is protected
> and I think its done in hardware.  I tried to look in mesa but can't seem to
> track it down.  If anyone knows which file the mesa code is in please point
> me in the right direction, I would really appreciate it.  I just need to see
> how mesa deals with this.

Mesa includes both software and hardware renderers.  For software, the
readpixels implementation is in mesa/src/mesa/swrast/s_readpix.c and
eventually calls read_depth_pixels.  For hardware support it varies,
grep for ReadPixels in mesa/src/mesa/drivers/dri/*/*.c


> I am actually also trying to find glViewPort implementation.  I have the
> math that goes with it but again want to see how mesa has implemented it.

mesa/src/main/viewport.c is probably what you're interested in.

  OG.

[Mesa3d-dev] [Bug 26820] Sharing contexts crashes on Windows

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

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





--- Comment #3 from Stefan Zerbst <s.z...@go...>  2010-03-01 23:32:54 PST ---
Created an attachment (id=33681)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33681)
Sample program to reproduce the crash

This sample program (simple Windows OpenGL sample) crashes with the current
stable release 7.6.1. I have not tested with the trunk of mesa but received
notice that there seems to be no problem. I will give the trunk a try today and
check 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 26832] [bisected glx]: assert triggered by kwin, when glxCreateWindow is called with NULL attrib_list

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

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





--- Comment #1 from Magnus Kessler <Mag...@gm...>  2010-03-01 22:50:14 PST ---
Created an attachment (id=33677)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33677)
proposed fix

On closer inspection it appears that the variable "data" in glx_puffer.c
CreateDrawable is essentially unused. Removing this variable should fix the
issue of copying data from NULL, which commit
706fffbff59be0dc884e1938f1bdf731af1efa3e tried to guard against.


-- 
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 26832] New: [bisected glx]: assert triggered by kwin, when glxCreateWindow is called with NULL attrib_list

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

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

           Summary: [bisected glx]: assert triggered by kwin, when
                    glxCreateWindow is called with NULL attrib_list
           Product: Mesa
           Version: git
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: GLX
        AssignedTo: mes...@li...
        ReportedBy: Mag...@gm...


KDE's kwin calls glxCreateWindow with NULL as the attrib_list parameter when it
sets up OpenGL based compositing. Since Mesa commit
706fffbff59be0dc884e1938f1bdf731af1efa3e this triggers an assert in
CreateDrawable (glx_pbuffer.c:382), and the application crashes.

The man page for glxCreateWindow states explicitly that NULL is allowed to be
passed as a value to the attrib_list parameter
(http://www.opengl.org/sdk/docs/man/xhtml/glXCreateWindow.xml).


-- 
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] Searching for the Depth Buffer implementation

[asimov01 <mh...@ya...>]

Hi Guys,

I am trying to implement the openGL Readpixels for depth buffer in plain
c++.  I have tried to dig into openGL for this but I think this is protected
and I think its done in hardware.  I tried to look in mesa but can't seem to
track it down.  If anyone knows which file the mesa code is in please point
me in the right direction, I would really appreciate it.  I just need to see
how mesa deals with this.

I am actually also trying to find glViewPort implementation.  I have the
math that goes with it but again want to see how mesa has implemented it.

Any help will be appreciated...


-- 
View this message in context: http://old.nabble.com/Searching-for-the-Depth-Buffer-implementation-tp27752068p27752068.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

[Joakim S. <ba...@zh...>]

On Tue, 2010-03-02 at 04:02 +0100, Roland Scheidegger wrote:
> On 02.03.2010 00:18, Joakim Sindholt wrote:
> > On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
> >> Hi,
> >>
> >> this branch turns vertex element into a cso, so instead of
> >> set_vertex_elements there's now the triad of
> >> create/bind/delete_vertex_elements_state. I have converted all the
> >> drivers except nouveau (I didn't do it because Christoph Bumiller
> >> already did nv50, but I can give the rest of them a shot), though that
> >> doesn't necessarily mean they are optimized for it (the idea is of
> >> course to precalculate state on create, not just copy the pipe structs
> >> and do everything on bind) - only i965g really does something close to
> >> it (though still emits the state always). Drivers doing both hw vertex
> >> shaders and using draw in some circumstances of course will have to
> >> store both representations on create.
> >> Also note that util_draw_vertex_buffer semantics have changed a bit
> >> (caller needs to set vertex element state, which is a bit odd).
> >>
> >> Roland
> > 
> > Can I still do things like:
> > element 0: -> vbo 5
> > element 1: -> vbo 2
> > and then set_vertex_buffers() with an array { zeros, zeros, vbo 2, zeros
> > zeros, vbo 5 } ?
> > 
> 
> The branch doesn't change pipe_vertex_element itself (except
> nr_components got removed as that's really derived from the associated
> pipe_format), only how those vertex elements are set. Hence you can do
> exactly the same things you could do before. Though I'm not quite sure
> what your zeros mean, if that's just a unused vbo it should be ok, but
> it is probably not ok to just pass in a null pointer for a unused
> pipe_vertex_buffer.
> 
> Roland

I did just mean empty buffers, but they're not actual buffers. I wrote
"zeros" because I literally just zero out everything in that particular
struct. There's no sense in binding 6 vbos when I really only have 2

Re: [Mesa3d-dev] [RFC] gallium-vertexelementcso branch merge

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

On 02.03.2010 00:18, Joakim Sindholt wrote:
> On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
>> Hi,
>>
>> this branch turns vertex element into a cso, so instead of
>> set_vertex_elements there's now the triad of
>> create/bind/delete_vertex_elements_state. I have converted all the
>> drivers except nouveau (I didn't do it because Christoph Bumiller
>> already did nv50, but I can give the rest of them a shot), though that
>> doesn't necessarily mean they are optimized for it (the idea is of
>> course to precalculate state on create, not just copy the pipe structs
>> and do everything on bind) - only i965g really does something close to
>> it (though still emits the state always). Drivers doing both hw vertex
>> shaders and using draw in some circumstances of course will have to
>> store both representations on create.
>> Also note that util_draw_vertex_buffer semantics have changed a bit
>> (caller needs to set vertex element state, which is a bit odd).
>>
>> Roland
> 
> Can I still do things like:
> element 0: -> vbo 5
> element 1: -> vbo 2
> and then set_vertex_buffers() with an array { zeros, zeros, vbo 2, zeros
> zeros, vbo 5 } ?
> 

The branch doesn't change pipe_vertex_element itself (except
nr_components got removed as that's really derived from the associated
pipe_format), only how those vertex elements are set. Hence you can do
exactly the same things you could do before. Though I'm not quite sure
what your zeros mean, if that's just a unused vbo it should be ok, but
it is probably not ok to just pass in a null pointer for a unused
pipe_vertex_buffer.

Roland

Re: [Mesa3d-dev] [RFC] gallium-no-rhw-position branch merge

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

Ahhh, I am a bad liar. The attached patch fixes the regressions.

-Marek

On Tue, Mar 2, 2010 at 2:08 AM, Marek Olšák <ma...@gm...> wrote:

> Hi Michal,
>
> This branch breaks 2 piglit tests with r300g:
>
> depthrange-clear
> texdepth
>
> However I haven't investigated these and won't get to them until the
> weekend. I personally don't mind fixing the regressions after the merge (but
> I'm not the maintainer of r300g). Anyway I'm glad to see
> bypass_vs_clip_and_viewport dying.
>
> -Marek
>
>
> On Mon, Mar 1, 2010 at 5:08 PM, michal <mi...@vm...> wrote:
>
>> Hi,
>>
>> This branch removes bypass_vs_clip_and_viewport flag from pipe
>> rasterizer state. The benefits of having this bit around were dubious
>> for everybody and burdensome for driver writers.
>>
>> All the utility code that relied on this flag have been rewritten to
>> pass vertex positions in clip space and set clip and viewport state. I
>> would like to ask the maintainers of u_blitter module to please test my
>> changes and provide feedback.
>>
>> Please review.
>>
>> Thanks.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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] [PATCH] Build failure in glapi/glapi_getproc.c

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

that was me, should compile now

On Tue, Mar 2, 2010 at 3:22 AM, Mike Stroyan <mi...@lu...> wrote:
> The recent changes to _glapi_check_table included building the full
> version build every time.  That broke builds for OpenGL ES1 and
> OpenGL ES2.  They don't have all of the table members that OpenGL
> does.
> This first broke in commit 42f3241e04b6cd74829dfb64b4a154ac8a4e6a48
> in glapi/glapi.c.
> But the problem function moved from glapi/glapi.c to glapi/glapi_getproc.c
> in commit fae5758fac963ce014e3d43f1bca7fb489e02bf9 .
>
> --
>
>  Mike Stroyan - Software Architect
>  LunarG, Inc.  - The Graphics Experts
>  Cell:  (970) 219-7905
>  Email: Mi...@Lu...
>  Website: http://www.lunarg.com
>
> ------------------------------------------------------------------------------
> 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] [PATCH] Build failure in glapi/glapi_getproc.c

[Mike S. <mi...@lu...>]

The recent changes to _glapi_check_table included building the full
version build every time.  That broke builds for OpenGL ES1 and
OpenGL ES2.  They don't have all of the table members that OpenGL
does.
This first broke in commit 42f3241e04b6cd74829dfb64b4a154ac8a4e6a48
in glapi/glapi.c.
But the problem function moved from glapi/glapi.c to glapi/glapi_getproc.c
in commit fae5758fac963ce014e3d43f1bca7fb489e02bf9 .

-- 

 Mike Stroyan - Software Architect
 LunarG, Inc.  - The Graphics Experts
 Cell:  (970) 219-7905
 Email: Mi...@Lu...
 Website: http://www.lunarg.com