mesa3d-dev

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

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

On Wed, 2010-03-03 at 04:27 -0800, Luca Barbieri wrote:
> > PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be unnecessary. So it doesn't make sense to rename.
> 
> How about D3DFMT_X8B8G8R8? That should map to PIPE_FORMAT_R8G8B8X8_UNORM.

Yes, you're right.

> BTW, we are also missing D3DFMT_X4R4G4B4, D3DFMT_X1R5G5B5,
> D3DFMT_A4L4, D3DFMT_A1, D3DFMT_L6V5U5, D3DFMT_D15S1, D3DFMT_D24X4S4,
> D3DFMT_CxV8U8 and perhaps others I did not notice.

D3DFMT_L6V5U5 is there (PIPE_FORMAT_R5SG5SB6U_NORM). The others are
indeed missing. Neither of the mentioned formats is required for D3D9
conformance, but we could add them to gallium.

D3DFMT_A1 is special: it has less than 1 byte per pixel. Probably the
best way to support it would be to treat it as a 8x1 macro pixel, 8bits,
similarly to compressed formats.

D3DFMT_CxV8U8 too as special semantics.


Jose

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

[Florian M. <fl...@mi...>]

On Wed, 03 Mar 2010 12:31:24 +0100
Francisco Jerez <cur...@ri...> wrote:

> Florian Mickler <fl...@mi...> writes:
> 
> > [...]
> > p.s.: my software stack is git master of libdrm, mesa
> > and xf86-video-intel as well as xserver-master + krh's pull request, so
> > that it looks light that:
> > 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its buffers become invalid.
> > 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the DRI2InvalidateBuffers event.
> > 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on DRI2GetBuffers if they're just being reused.
> > 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the intel DDX.
> > 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook.
> > de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled compat_output
> > fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for det_monrec_parameter sync_source
> > 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in DRI2SwapEvent
> > 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith'
> 
> Is it a side effect of this patch series? Could you try without?

Ah yes. Of course. Should have checked that before... Anyway, I just
did, and with current xserver-master it is hanging nontheless... 

,
Flo

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

[Simon T. <sim...@gm...>]

Florian Mickler wrote:
> On Tue, 2 Mar 2010 11:50:05 -0800
> Jesse Barnes <jb...@vi...> wrote:
> 
>> So the server is hanging when the client tries to get buffers?  Can you
>> see what it's doing at the time?
>>
> 
> i'll try tomorrow...
> 
> meanwhile, i watched a film and did some other things and now glxgears
> doesn't start anymore:
> 
> dmk@schatten ~ $glxgears 
> Mesa: Mesa 7.8-devel DEBUG build Mar  2 2010 19:57:41
> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
> Mesa: Initializing x86-64 optimizations
> Running synchronized to the vertical refresh.  The framerate should be
> approximately 1/8504368 the monitor refresh rate.
> X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
>   Major opcode of failed request:  133 (DRI2)
>   Minor opcode of failed request:  8 (DRI2SwapBuffers           )
>   Resource id in failed request:  0x1c00002
>   Serial number of failed request:  32
>   Current serial number in output stream:  32
> 
> 
> does this 1/[bignumber] look alright? maybe that is the culprit...
> waiting some 10^6 time ... i think the monitor refresh rate is
> something about 60 hz? not over some khz?  which means that 1khz/8504368
> is something about 1/8500 hz  which amounts to about 140 secs? (it is
> late and i may have switched nominater and denominator a bit too
> often... but if i don't have crossed anything, than that could
> cause some hang... don't it?) 
FWIW, my glxgears says:
The framerate should beapproximately 1/1835103081 the monitor refresh rate.

It then runs fine. I'm on radeon r200, but since my update yesterday
(git master stack using gentoo overlay) I also have OpenGL problems,
most notably, KWin 4.4's compositing doesn't work any more. Probably,
this isn't just intel then.

My old X did work fine, dating from when the DRI2 Swapbuffers lifetime
bugfix hit master (711e26466ae04ae93ff4c48d377d83d68a6320e9).

If it helps, I can provide anything that doesn't take me a whole day to
gather.

> 
> 
> cheers,
> Flo
> 
> p.s.: my software stack is git master of libdrm, mesa
> and xf86-video-intel as well as xserver-master + krh's pull request, so
> that it looks light that:
> 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its buffers become invalid.
> 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the DRI2InvalidateBuffers event.
> 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on DRI2GetBuffers if they're just being reused.
> 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the intel DDX.
> 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook.
> de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled compat_output
> fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for det_monrec_parameter sync_source
> 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in DRI2SwapEvent
> 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith'
> 
> 
> _______________________________________________
> xorg-devel mailing list
> xor...@li...
> http://lists.x.org/mailman/listinfo/xorg-devel
> 

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

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

> PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be unnecessary. So it doesn't make sense to rename.

How about D3DFMT_X8B8G8R8? That should map to PIPE_FORMAT_R8G8B8X8_UNORM.

BTW, we are also missing D3DFMT_X4R4G4B4, D3DFMT_X1R5G5B5,
D3DFMT_A4L4, D3DFMT_A1, D3DFMT_L6V5U5, D3DFMT_D15S1, D3DFMT_D24X4S4,
D3DFMT_CxV8U8 and perhaps others I did not notice.

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

[Francisco J. <cur...@ri...>]

Florian Mickler <fl...@mi...> writes:

> [...]
> p.s.: my software stack is git master of libdrm, mesa
> and xf86-video-intel as well as xserver-master + krh's pull request, so
> that it looks light that:
> 90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its buffers become invalid.
> 68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the DRI2InvalidateBuffers event.
> 2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on DRI2GetBuffers if they're just being reused.
> 543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the intel DDX.
> 31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook.
> de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled compat_output
> fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for det_monrec_parameter sync_source
> 4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in DRI2SwapEvent
> 780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith'

Is it a side effect of this patch series? Could you try without?

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

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

On Tue, 2010-03-02 at 12:43 -0800, Luca Barbieri wrote:
> The difference between an easier and harder life for (some) drivers is
> whether the limit is tied to hardware interpolators or not.
> Once we decide to not tie it, whether the limit is 128 or 256 is of
> course quite inconsequential.
> Allowing arbitrary 32-bit values would however require use of binary
> search or an hash table.
> 
> I think you or someone else from the Mesa team should decide how to
> proceed, and most drivers would need to be fixed.
> 
> As I understand, the constraints are the following:
> 
> Hardware with no capabilities.
> - nv30 does not support any mapping. However, we already need to patch
> fragment programs to insert constants, so we can patch input register
> numbers as well. The current driver only supports 0-7 generic indices,
> but I already implemented support for 0-255 indices with in-driver
> linkage and patching. Note that nv30 lacks control flow in fragment
> programs.
> - nv40 is like nv30, but supports fp control flow, and may have some
> configurable mapping support, with unknown behavior
> 
> Hardware with capabilities that must be configured for each fp/vp pair.
> - nv40 might have this but the nVidia OpenGL driver does not use them
> - nv50 has configurable vp->gp and gp->fp mappings with 64 entries.
> The current driver seems to support arbitrary 0-2^32 indices.
> - r300 appears to have a configurable vp->fp mapping. The current
> driver only supports 0-15 generic indices, but redefining
> ATTR_GENERIC_COUNT could be enough to have it support larger numbers.
> 
> Hardware with automatic linkage when semantics match:
> - VMWare svga appears to support 14 * 16 semantics, but the current
> driver only supports 0-15 generic indices. This could be fixed by
> mapping GENERIC into all non-special SM3 semantics.
> 
> Hardware that can do both configurable mappings and automatic linkage:
> - r600 supports linkage in hardware between matching apparently
> byte-sized semantic ids
> 
> Other hardware;
> - i915 has no hardware vertex shading
> - Not sure about i965
> 
> Software:
> 1. SM3 wants to use 14 * 16 indices overall. This is apparently only
> supported by the VMware closed source state tracker.
> 2. SM2 and non-GLSL OpenGL just want to use as many indices as the
> hardware interpolator count
> 3. Current GLSL currently wants to use at most about 10 indices more
> than the hardware interpolator count. This can be fixed since we see
> both the fragment and vertex shaders during linkage (the patch I sent
> did that)
> 4. GLSL with EXT_separate_shader_objects does not add requirements
> because only gl_TexCoord and other builtin varyings are supported.
> User-defined varyings are not supported
> 5. An hypotetical version of EXT_separate_shader_objects extended to
> support user-defining varyings would either want arbitrary 32-bit
> generic indices (by interning strings to generate the indices) or the
> ability to specify a custom mapping between shader indices
> 6. An hypotetical "no-op" implementation of the GLSL linker would have
> the same requirement
> 
> Also note that non-GENERIC indices have peculiar properties.
> 
> For COLOR and BCOLOR:
> 1. SM3 and OpenGL with glColorClamp appropriately set wants it to
> _not_ be clamped to [0, 1]
> 2. SM2 and normal OpenGL apparently want it to be clamped to [0, 1]
> (sometimes for fixed point targets only) and may also allow using
> U8_UNORM precision for it instead of FP32
> 3. OpenGL allows to enable two-sided lighting, in which case COLOR in
> the fragment shader is automagically set to BCOLOR for back faces
> 4. Older hardware (e.g. nv30) tends to support BCOLOR but not FACING.
> Some hardware (e.g. nv40) supports both FACING and BCOLOR in hardware.
> The latest hardware probably supports FACING only.
> 
> Any API that requires special semantics for COLOR and BCOLOR (i.e.
> non-SM3) seems to only want 0-1 indices.
> 
> Note that SM3 does *not* include BCOLOR, so basically the limits for
> generic indices would need to be conditional on BCOLOR being present
> or not (e.g. if it is present, we must reserve two semantic slots in
> svga for it).
> 
> POSITION0 is obviously special.
> PSIZE0 is also special for points.
> 
> FOG0 seems right now to just be a GENERIC with a single component.
> Gallium could be extended to support fixed function fog, which most
> DX9 hardware supports (nv30/nv40 and r300). This is mostly orthogonal
> to the semantic issue.
> 
> TGSI_SEMANTIC_NORMAL is essentially unused and should probably be removed
> 
> The options are the ones you outlined, plus:
> (e) Allow arbitrary 32-bit indices. This requires slightly more
> complicated data structures in some cases, and will require svga and
> r600 to fallback to software linkage if numbers are too high.
> (f) Limit semantic indices to hardware interpolators _and_ introduce
> an interface to let the user specify an
> 
> Personally I think the simplest idea for now could be to have all
> drivers support 256 indices or, in the case of r600 and svga, the
> maximum value supported by the hardware, and expose that as a cap (as
> well as another cap for the number of different semantic values
> supported at once).
> The minimum guaranteed value is set to the lowest hardware constraint,
> which would be svga with 219 indices (assuming no bcolor is used).
> If some new constraints pop up, we just lower it and change SM3 state
> trackers to check for it and fallback otherwise.
> 
> This should just require simple fixes to svga and r300, and
> significant code for nv30/nv40, which is however already implemented.

OK, if we require drivers to support at least 219 indices and have a
query to permit larger numbers, I'm OK with that too.

Keith

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

[Florian M. <fl...@mi...>]

On Tue, 2 Mar 2010 13:59:00 -0800
Jesse Barnes <jb...@vi...> wrote:
> commit 529bf185fbcb9f7705b315a5106054ee25c1c77f
> Author: Eric Anholt <er...@an...>
> Date:   Wed Feb 24 17:54:13 2010 -0800
> 
>     In frame event handling, track drawable id instead of drawable
>     pointer.
> 
> in your xf86-video-intel tree?
> 

yes. before that, glxgears wouldn't ever start ... the error goes away if i restart the xserver... 


Am Dienstag, den 02.03.2010, 22:48 +0100 schrieb Florian Mickler:
> On Tue, 2 Mar 2010 11:50:05 -0800
> Jesse Barnes <jb...@vi...> wrote:
> 
> > So the server is hanging when the client tries to get buffers?  Can you
> > see what it's doing at the time?
> > 
> 
> i'll try tomorrow...

btw, no. it is glxgears which is hanging. everything else works as it
should.

and it is hanging on this _XReply (@428) here:

 @line 428 in mesa/src/glx/dri2.c:
416    XextCheckExtension(dpy, info, dri2ExtensionName, False);
417 
418    LockDisplay(dpy);
419    GetReqExtra(DRI2GetBuffers, count * (4 * 2), req);
420    req->reqType = info->codes->major_opcode;
421    req->dri2ReqType = X_DRI2GetBuffersWithFormat;
422    req->drawable = drawable;
423    req->count = count;
424    p = (CARD32 *) & req[1];
425    for (i = 0; i < (count * 2); i++)
426       p[i] = attachments[i];
427 
428    if (!_XReply(dpy, (xReply *) & rep, 0, xFalse)) {
429       UnlockDisplay(dpy);
430       SyncHandle();
431       return NULL;
432    }
433 
434    *width = rep.width;
435    *height = rep.height;


it's not looping... i verified with strace that glxgears is blocking on
that poll() here...


I tried to follow the program flow up into that.. but besides me
thinking that this _XReply is surfacing in the xserver's dispatch.c
i'm not really advancing here ;) where does this request get handled?
when does _XReply return?

cheers,
Flo

p.s.: if the screen is idle and get's turned off, glxgears is running
fine...  (started via ssh... i see the framerate reporting...)

p.p.s.: the whole backtrace when glxgears is hanging:

(gdb) bt full
#0  0x00007f3aef5ea10f in poll () from /lib/libc.so.6
No symbol table info available.
#1  0x00007f3aee19fa32 in _xcb_conn_wait () from /usr/lib/libxcb.so.1
No symbol table info available.
#2  0x00007f3aee1a15e1 in xcb_wait_for_reply ()
from /usr/lib/libxcb.so.1
No symbol table info available.
#3  0x00007f3aef2460be in _XReply () from /usr/lib/libX11.so.6
No symbol table info available.
#4  0x00007f3aefb44f76 in DRI2GetBuffersWithFormat (dpy=0x234c010, 
    drawable=<value optimized out>, width=0x235f3b4, height=0x235f3b8, 
    attachments=0x7fffc5ac6450, count=2, outCount=0x7fffc5ac648c) at
dri2.c:428
        info = 0x2357960
        rep = {type = 112 'p', pad1 = 100 'd', sequenceNumber = 50604, 
          length = 32767, width = 3984539715, height = 32570, count =
0, 
          pad2 = 0, pad3 = 37116448, pad4 = 0}
        buffers = <value optimized out>
        repBuffer = {attachment = 41009200, name = 0, pitch =
3985030468, 
          cpp = 32570, flags = 2097152}
        i = <value optimized out>
#5  0x00007f3aefb43ca8 in dri2GetBuffersWithFormat (
    driDrawable=<value optimized out>, width=0x235f3b4, 
    height=0xffffffffffffffff, attachments=0x234d6d8, count=5277, 
    out_count=0x7fffc5ac648c, loaderPrivate=0x235f2c0) at dri2_glx.c:435
---Type <return> to continue, or q <return> to quit---
        pdraw = <value optimized out>
        buffers = <value optimized out>
#6  0x00007f3aed6de927 in intel_update_renderbuffers (
    context=<value optimized out>, drawable=0x235f380) at
intel_context.c:252
        rb = <value optimized out>
        region = <value optimized out>
        depth_region = <value optimized out>
        intel = 0x2365a20
        front_rb = <value optimized out>
        back_rb = 0x3
        depth_rb = 0x26b9340
        stencil_rb = 0x26b9340
        buffers = <value optimized out>
        screen = 0x235cf20
        i = 3
        count = <value optimized out>
        attachments = {1, 32, 9, 32, 13, 0, 0, 0, 655360, 0}
        region_name = <value optimized out>
        __func__ = "intel_update_renderbuffers"
#7  0x00007f3aed6decef in intel_prepare_render (intel=0x2365a20)
    at intel_context.c:395
        driContext = 0x2361d70
        drawable = 0x235f380
---Type <return> to continue, or q <return> to quit---
#8  0x00007f3aed70d3ca in brw_try_draw_prims (ctx=0x2365a20,
arrays=0x23b54a8, 
    prim=0x7fffc5ac65a0, nr_prims=1, ib=0x0, 
    index_bounds_valid=<value optimized out>, min_index=0, max_index=3)
    at brw_draw.c:340
        retval = <value optimized out>
        warn = <value optimized out>
        first_time = <value optimized out>
        i = <value optimized out>
        intel = 0x7fffc5ac6200
        __FUNCTION__ = "brw_try_draw_prims"
        warned = 0 '\000'
#9  brw_draw_prims (ctx=0x2365a20, arrays=0x23b54a8,
prim=0x7fffc5ac65a0, 
    nr_prims=1, ib=0x0, index_bounds_valid=<value optimized out>,
min_index=0, 
    max_index=3) at brw_draw.c:441
No locals.
#10 0x00007f3aed7c91bf in vbo_exec_DrawArrays (mode=6, start=0, count=4)
    at vbo/vbo_exec_array.c:524
        ctx = 0x2365a20
        prim = {{mode = 6, indexed = 0, begin = 1, end = 1, weak = 0,
pad = 0, 
            start = 0, count = 4, basevertex = 0}}
        __FUNCTION__ = "vbo_exec_DrawArrays"
#11 0x00007f3aed847910 in _mesa_meta_Clear (ctx=0x2365a20, buffers=0)
    at drivers/common/meta.c:1461
---Type <return> to continue, or q <return> to quit---
        clear = 0x26b47e4
        verts = {{x = 0, y = 0, z = -1, r = 0, g = 0, b = 0, a = 0}, {x
= 300, 
            y = 0, z = -1, r = 0, g = 0, b = 0, a = 0}, {x = 300, y =
300, 
            z = -1, r = 0, g = 0, b = 0, a = 0}, {x = 0, y = 300, z =
-1, 
            r = 0, g = 0, b = 0, a = 0}}
        metaSave = 4294967003
        __PRETTY_FUNCTION__ = "_mesa_meta_Clear"
#12 0x00007f3aed6dd8ac in intelClear (ctx=0x2365a20, 
    mask=<value optimized out>) at intel_clear.c:182
        intel = 0x7fffc5ac6200
        colorMask = <value optimized out>
        tri_mask = 18
        blit_mask = 0
        swrast_mask = 0
        fb = 0x26b8e20
        i = 0
#13 0x0000000000402be6 in draw ()
No symbol table info available.
#14 0x000000000040360b in main ()
No symbol table info available.

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

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

Consistency between different formats is not always a good metric here, as there are all sort of historical reasons which make the used set of formats out of all possible quite asymmetric.

PIPE_FORMAT_X8B8G8R8_UNORM is being used by mesa. PIPE_FORMAT_R8G8B8X8_UNORM doesn't exist hence it appears to be unnecessary. So it doesn't make sense to rename.

But I think you stumbled on something: PIPE_FORMAT_R8G8B8X8_SNORM might not be needed. It's not used anywhere, nor can I find mention of such format in D3D9/10. I'll remove it if nobody opposes.

Jose
________________________________________
From: Luca Barbieri [luc...@gm...]
Sent: Tuesday, March 02, 2010 22:16
To: Jose Fonseca
Cc: mes...@li...
Subject: Re: [Mesa3d-dev] RFC: gallium-format-cleanup branch (was Gallium       format swizzles)

Shouldn't
PIPE_FORMAT_X8B8G8R8_UNORM        = 68,

be instead R8G8B8X8_UNORM, which is currently missing, for consistency with:
PIPE_FORMAT_R8G8B8X8_SNORM        = 81,

with X8B8G8R8_UNORM perhaps put at the end next to PIPE_FORMAT_A8B8G8R8_UNORM?

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

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

Shouldn't
PIPE_FORMAT_X8B8G8R8_UNORM        = 68,

be instead R8G8B8X8_UNORM, which is currently missing, for consistency with:
PIPE_FORMAT_R8G8B8X8_SNORM        = 81,

with X8B8G8R8_UNORM perhaps put at the end next to PIPE_FORMAT_A8B8G8R8_UNORM?

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

[Jesse B. <jb...@vi...>]

On Tue, 2 Mar 2010 22:48:31 +0100
Florian Mickler <fl...@mi...> wrote:

> On Tue, 2 Mar 2010 11:50:05 -0800
> Jesse Barnes <jb...@vi...> wrote:
> 
> > So the server is hanging when the client tries to get buffers?  Can
> > you see what it's doing at the time?
> > 
> 
> i'll try tomorrow...
> 
> meanwhile, i watched a film and did some other things and now glxgears
> doesn't start anymore:
> 
> dmk@schatten ~ $glxgears 
> Mesa: Mesa 7.8-devel DEBUG build Mar  2 2010 19:57:41
> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
> compression/decompression unavailable Mesa: Initializing x86-64
> optimizations Running synchronized to the vertical refresh.  The
> framerate should be approximately 1/8504368 the monitor refresh rate.
> X Error of failed request:  BadDrawable (invalid Pixmap or Window
> parameter) Major opcode of failed request:  133 (DRI2)
>   Minor opcode of failed request:  8 (DRI2SwapBuffers           )
>   Resource id in failed request:  0x1c00002
>   Serial number of failed request:  32
>   Current serial number in output stream:  32
> 
> 
> does this 1/[bignumber] look alright? maybe that is the culprit...
> waiting some 10^6 time ... i think the monitor refresh rate is
> something about 60 hz? not over some khz?  which means that
> 1khz/8504368 is something about 1/8500 hz  which amounts to about 140
> secs? (it is late and i may have switched nominater and denominator a
> bit too often... but if i don't have crossed anything, than that could
> cause some hang... don't it?) 

I don't know how gears calculates that these days, but it generally
looks wrong for me too.

You have

commit 529bf185fbcb9f7705b315a5106054ee25c1c77f
Author: Eric Anholt <er...@an...>
Date:   Wed Feb 24 17:54:13 2010 -0800

    In frame event handling, track drawable id instead of drawable
    pointer.

in your xf86-video-intel tree?

-- 
Jesse Barnes, Intel Open Source Technology Center

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

[Florian M. <fl...@mi...>]

On Tue, 2 Mar 2010 11:50:05 -0800
Jesse Barnes <jb...@vi...> wrote:

> So the server is hanging when the client tries to get buffers?  Can you
> see what it's doing at the time?
> 

i'll try tomorrow...

meanwhile, i watched a film and did some other things and now glxgears
doesn't start anymore:

dmk@schatten ~ $glxgears 
Mesa: Mesa 7.8-devel DEBUG build Mar  2 2010 19:57:41
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable
Mesa: Initializing x86-64 optimizations
Running synchronized to the vertical refresh.  The framerate should be
approximately 1/8504368 the monitor refresh rate.
X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  133 (DRI2)
  Minor opcode of failed request:  8 (DRI2SwapBuffers           )
  Resource id in failed request:  0x1c00002
  Serial number of failed request:  32
  Current serial number in output stream:  32


does this 1/[bignumber] look alright? maybe that is the culprit...
waiting some 10^6 time ... i think the monitor refresh rate is
something about 60 hz? not over some khz?  which means that 1khz/8504368
is something about 1/8500 hz  which amounts to about 140 secs? (it is
late and i may have switched nominater and denominator a bit too
often... but if i don't have crossed anything, than that could
cause some hang... don't it?) 


cheers,
Flo

p.s.: my software stack is git master of libdrm, mesa
and xf86-video-intel as well as xserver-master + krh's pull request, so
that it looks light that:
90b6ab4c5f057737b5396f987fdea7dd5716b086 glx/dri2: Notify the driver when its buffers become invalid.
68b1e4e23b008f8fbb74e1cffe200234a3840d91 dri2: Support the DRI2InvalidateBuffers event.
2b44f8ce85ab1d64335c9181864fb4f376783982 dri2: No need to blit from front on DRI2GetBuffers if they're just being reused.
543e3a2adcf63bd7728baf29353a65925d112205 Import linked list helpers from the intel DDX.
31ca49a38c9dbd700c7283e7fd2f8cb6daf1a0cf Add a ConfigNotify hook.
de86a3a3448f0a55c1cd99aee9ea80070a589877 Allow for missing or disabled compat_output
fbbadca7e88391e81ab0f470290f5eec36aa9ce7 Share enum definition for det_monrec_parameter sync_source
4b55b2cf8a52c39b53bae11cd1bc7314481d4c86 DRI2: initialize event->drawable in DRI2SwapEvent
780c95caf9888fa4548dfe4c1c78a7e7ce99a9ed Merge remote branch 'whot/for-keith'

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

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

On Tue, Mar 2, 2010 at 10:20 PM, Luca Barbieri <lu...@lu...>wrote:

> On Tue, Mar 2, 2010 at 10:00 PM, Corbin Simpson
> <mos...@gm...> wrote:
> > FYI r300 only supports 24 interpolators: 16 linear and 8 perspective.
> > (IIRC; not in front of the docs right now.) r600 supports 256 fully
> > configurable interpolators.
>
> Yes, but if you raised ATTR_GENERIC_COUNT, the current driver would
> support higher semantic indices right? (of course, with a limit of
> 8/24 different semantic indices used at once).
>
> That's right.

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

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

On Tue, Mar 2, 2010 at 10:00 PM, Corbin Simpson
<mos...@gm...> wrote:
> FYI r300 only supports 24 interpolators: 16 linear and 8 perspective.
> (IIRC; not in front of the docs right now.) r600 supports 256 fully
> configurable interpolators.

Yes, but if you raised ATTR_GENERIC_COUNT, the current driver would
support higher semantic indices right? (of course, with a limit of
8/24 different semantic indices used at once).

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

[Corbin S. <mos...@gm...>]

FYI r300 only supports 24 interpolators: 16 linear and 8 perspective.
(IIRC; not in front of the docs right now.) r600 supports 256 fully
configurable interpolators.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<Mos...@gm...>

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

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

The difference between an easier and harder life for (some) drivers is
whether the limit is tied to hardware interpolators or not.
Once we decide to not tie it, whether the limit is 128 or 256 is of
course quite inconsequential.
Allowing arbitrary 32-bit values would however require use of binary
search or an hash table.

I think you or someone else from the Mesa team should decide how to
proceed, and most drivers would need to be fixed.

As I understand, the constraints are the following:

Hardware with no capabilities.
- nv30 does not support any mapping. However, we already need to patch
fragment programs to insert constants, so we can patch input register
numbers as well. The current driver only supports 0-7 generic indices,
but I already implemented support for 0-255 indices with in-driver
linkage and patching. Note that nv30 lacks control flow in fragment
programs.
- nv40 is like nv30, but supports fp control flow, and may have some
configurable mapping support, with unknown behavior

Hardware with capabilities that must be configured for each fp/vp pair.
- nv40 might have this but the nVidia OpenGL driver does not use them
- nv50 has configurable vp->gp and gp->fp mappings with 64 entries.
The current driver seems to support arbitrary 0-2^32 indices.
- r300 appears to have a configurable vp->fp mapping. The current
driver only supports 0-15 generic indices, but redefining
ATTR_GENERIC_COUNT could be enough to have it support larger numbers.

Hardware with automatic linkage when semantics match:
- VMWare svga appears to support 14 * 16 semantics, but the current
driver only supports 0-15 generic indices. This could be fixed by
mapping GENERIC into all non-special SM3 semantics.

Hardware that can do both configurable mappings and automatic linkage:
- r600 supports linkage in hardware between matching apparently
byte-sized semantic ids

Other hardware;
- i915 has no hardware vertex shading
- Not sure about i965

Software:
1. SM3 wants to use 14 * 16 indices overall. This is apparently only
supported by the VMware closed source state tracker.
2. SM2 and non-GLSL OpenGL just want to use as many indices as the
hardware interpolator count
3. Current GLSL currently wants to use at most about 10 indices more
than the hardware interpolator count. This can be fixed since we see
both the fragment and vertex shaders during linkage (the patch I sent
did that)
4. GLSL with EXT_separate_shader_objects does not add requirements
because only gl_TexCoord and other builtin varyings are supported.
User-defined varyings are not supported
5. An hypotetical version of EXT_separate_shader_objects extended to
support user-defining varyings would either want arbitrary 32-bit
generic indices (by interning strings to generate the indices) or the
ability to specify a custom mapping between shader indices
6. An hypotetical "no-op" implementation of the GLSL linker would have
the same requirement

Also note that non-GENERIC indices have peculiar properties.

For COLOR and BCOLOR:
1. SM3 and OpenGL with glColorClamp appropriately set wants it to
_not_ be clamped to [0, 1]
2. SM2 and normal OpenGL apparently want it to be clamped to [0, 1]
(sometimes for fixed point targets only) and may also allow using
U8_UNORM precision for it instead of FP32
3. OpenGL allows to enable two-sided lighting, in which case COLOR in
the fragment shader is automagically set to BCOLOR for back faces
4. Older hardware (e.g. nv30) tends to support BCOLOR but not FACING.
Some hardware (e.g. nv40) supports both FACING and BCOLOR in hardware.
The latest hardware probably supports FACING only.

Any API that requires special semantics for COLOR and BCOLOR (i.e.
non-SM3) seems to only want 0-1 indices.

Note that SM3 does *not* include BCOLOR, so basically the limits for
generic indices would need to be conditional on BCOLOR being present
or not (e.g. if it is present, we must reserve two semantic slots in
svga for it).

POSITION0 is obviously special.
PSIZE0 is also special for points.

FOG0 seems right now to just be a GENERIC with a single component.
Gallium could be extended to support fixed function fog, which most
DX9 hardware supports (nv30/nv40 and r300). This is mostly orthogonal
to the semantic issue.

TGSI_SEMANTIC_NORMAL is essentially unused and should probably be removed

The options are the ones you outlined, plus:
(e) Allow arbitrary 32-bit indices. This requires slightly more
complicated data structures in some cases, and will require svga and
r600 to fallback to software linkage if numbers are too high.
(f) Limit semantic indices to hardware interpolators _and_ introduce
an interface to let the user specify an

Personally I think the simplest idea for now could be to have all
drivers support 256 indices or, in the case of r600 and svga, the
maximum value supported by the hardware, and expose that as a cap (as
well as another cap for the number of different semantic values
supported at once).
The minimum guaranteed value is set to the lowest hardware constraint,
which would be svga with 219 indices (assuming no bcolor is used).
If some new constraints pop up, we just lower it and change SM3 state
trackers to check for it and fallback otherwise.

This should just require simple fixes to svga and r300, and
significant code for nv30/nv40, which is however already implemented.

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

[Jesse B. <jb...@vi...>]

On Tue, 2 Mar 2010 19:50:45 +0100
Florian Mickler <fl...@mi...> wrote:

> On Tue, 2 Mar 2010 09:32:57 -0800
> Jamey Sharp <ja...@mi...> wrote:
> 
> > On Tue, Mar 2, 2010 at 4:37 AM, Stephan Raue
> > <mai...@op...> wrote:
> > > 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
> > 
> > A loop? Or just a hang?
> > 
> > > #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
> > 
> > Judging only by the stack trace, it looks like your application is
> > waiting for a reply that never comes. There are a variety of bugs
> > that can cause that. The sequence number (30) looks reasonable for
> > application startup, which rules out one or two things.
> > 
> > For the rest, if the Intel/Mesa folks don't have an answer, it would
> > help if you could get a trace of the X wire protocol using something
> > like Wireshark.
> > 
> > Jamey
> > _______________________________________________
> > xorg-devel mailing list
> > xor...@li...
> > http://lists.x.org/mailman/listinfo/xorg-devel
> 
> 
> 
> i'm seeing the same with glxgears, see below for a gdb run...
> 
> if i login glxgears runs fine, until i start up some programs (licq,
> psi, twinkle, skype)... then it hangs sometimes and doesnt redraw the
> screen anymore. if i start it after that point it never draws...
> 
> seems to me, like some event goes missing somewhere... ? 
> 
> anyway, i'm on amd64 with intel from git, using the new event-driven
> invalidate stuff...
> 
> what debugging would be helpful here? dmesg doesn't show anything
> (abnormal) with kernel drm.debug=1 ...
> 
> cheers,
> Flo
> 
> p.s.: i verified with strace that it hangs on that poll... 

So the server is hanging when the client tries to get buffers?  Can you
see what it's doing at the time?

-- 
Jesse Barnes, Intel Open Source Technology Center

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

[Florian M. <fl...@mi...>]

On Tue, 2 Mar 2010 09:32:57 -0800
Jamey Sharp <ja...@mi...> wrote:

> On Tue, Mar 2, 2010 at 4:37 AM, Stephan Raue <mai...@op...> wrote:
> > 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
> 
> A loop? Or just a hang?
> 
> > #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
> 
> Judging only by the stack trace, it looks like your application is
> waiting for a reply that never comes. There are a variety of bugs that
> can cause that. The sequence number (30) looks reasonable for
> application startup, which rules out one or two things.
> 
> For the rest, if the Intel/Mesa folks don't have an answer, it would
> help if you could get a trace of the X wire protocol using something
> like Wireshark.
> 
> Jamey
> _______________________________________________
> xorg-devel mailing list
> xor...@li...
> http://lists.x.org/mailman/listinfo/xorg-devel



i'm seeing the same with glxgears, see below for a gdb run...

if i login glxgears runs fine, until i start up some programs (licq,
psi, twinkle, skype)... then it hangs sometimes and doesnt redraw the
screen anymore. if i start it after that point it never draws...

seems to me, like some event goes missing somewhere... ? 

anyway, i'm on amd64 with intel from git, using the new event-driven
invalidate stuff...

what debugging would be helpful here? dmesg doesn't show anything
(abnormal) with kernel drm.debug=1 ...

cheers,
Flo

p.s.: i verified with strace that it hangs on that poll... 


(gdb) r
Starting program: /usr/bin/glxgears 
[Thread debugging using libthread_db enabled]
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
^C
Program received signal SIGINT, Interrupt.
0x00007ffff766410f in poll () from /lib/libc.so.6
(gdb) bt
#0  0x00007ffff766410f in poll () from /lib/libc.so.6
#1  0x00007ffff6219a32 in _xcb_conn_wait () from /usr/lib/libxcb.so.1
#2  0x00007ffff621b5e1 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
#3  0x00007ffff72c00be in _XReply () from /usr/lib/libX11.so.6
#4  0x00007ffff7bbe996 in DRI2GetBuffersWithFormat ()
   from //usr/lib64/opengl/xorg-x11/lib/libGL.so.1
#5  0x00007ffff7bbd6c8 in dri2GetBuffersWithFormat ()
   from //usr/lib64/opengl/xorg-x11/lib/libGL.so.1
#6  0x00007ffff5780cef in intel_update_renderbuffers ()
   from /usr/lib64/dri/i965_dri.so
#7  0x00007ffff57810b7 in intel_prepare_render ()
   from /usr/lib64/dri/i965_dri.so
#8  0x00007ffff57af15a in brw_draw_prims () from /usr/lib64/dri/i965_dri.so
#9  0x00007ffff5857383 in vbo_exec_DrawArrays ()
   from /usr/lib64/dri/i965_dri.so
#10 0x00007ffff58d2987 in _mesa_meta_Clear () from /usr/lib64/dri/i965_dri.so
#11 0x00007ffff577fccb in intelClear () from /usr/lib64/dri/i965_dri.so
#12 0x0000000000402be6 in draw ()
#13 0x000000000040360b in main ()
(gdb) 

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

[Jamey S. <ja...@mi...>]

On Tue, Mar 2, 2010 at 4:37 AM, Stephan Raue <mai...@op...> wrote:
> 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

A loop? Or just a hang?

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

Judging only by the stack trace, it looks like your application is
waiting for a reply that never comes. There are a variety of bugs that
can cause that. The sequence number (30) looks reasonable for
application startup, which rules out one or two things.

For the rest, if the Intel/Mesa folks don't have an answer, it would
help if you could get a trace of the X wire protocol using something
like Wireshark.

Jamey

[Mesa3d-dev] Mesa from git stops compiling at NV30 Nouveau

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

HI to all,
            I've just pulled the latest changes/updates today from Mesa git
master.
My ./configure options are:

./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-osmesa-bits=16 

Mesa keeps stopping at this error:

gmake[4]: Leaving directory `/opt/mesa/src/gallium/drivers/nv30'
gmake[4]: Entering directory `/opt/mesa/src/gallium/drivers/nv30'
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -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  nv30_clear.c -o nv30_clear.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -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  nv30_context.c -o nv30_context.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -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  nv30_draw.c -o nv30_draw.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -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  nv30_fragprog.c -o nv30_fragprog.o
gcc -c -I. -I../../../../src/gallium/include
-I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers  -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  nv30_fragtex.c -o nv30_fragtex.o
nv30_fragtex.c:28: error: ‘PIPE_FORMAT_A1R5G5B5_UNORM’ undeclared here (not
in a function)
nv30_fragtex.c:29: error: ‘PIPE_FORMAT_A4R4G4B4_UNORM’ undeclared here (not
in a function)
nv30_fragtex.c:30: error: ‘PIPE_FORMAT_R5G6B5_UNORM’ undeclared here (not in
a function)
nv30_fragtex.c:34: error: ‘PIPE_FORMAT_A8L8_UNORM’ undeclared here (not in a
function)
gmake[4]: *** [nv30_fragtex.o] Error 1
gmake[4]: Leaving directory `/opt/mesa/src/gallium/drivers/nv30'
gmake[3]: *** [default] Error 1
gmake[3]: Leaving directory `/opt/mesa/src/gallium/drivers'
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

Regards,
             STEVE555
-- 
View this message in context: http://old.nabble.com/Mesa-from-git-stops-compiling-at-NV30-Nouveau-tp27758392p27758392.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

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

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

On Tue, 2010-03-02 at 04:36 -0800, Luca Barbieri wrote:


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

I accept that it can be viewed as an arbitrary constant, but maybe it's
a step too far.  If another API or piece of hardware came along that we
decided was important, the calculations might change and we'd be stuck.

I see our options as:

a) Picking a lower number like 128, that an SM3 state tracker could
usually be able to directly translate incoming semantics into, but which
would force it to renumber under rare circumstances.  This would make
life easier for the open drivers at the expense of the closed code.

b) Picking 256 to make life easier for some closed-source SM3 state
tracker, but harder for open drivers.

c) Picking 219 (or some other magic number) that happens to work with
the current set of constraints, but makes gallium fragile in the face of
new constraints.

d) Abandoning the current gallium linkage rules and coming up with
something new, for instance forcing the state trackers to renumber
always and making life trivial for the drivers...

I suspect we'll end up reworking the whole GENERIC idea at some stage,
ie (d).  But for now, I don't think that some piece of closed code
should be dictating the gallium interface direction, so I'd suggest
something that makes the open driver's lives easier -- ie (a) or (c).

To be honest, I'd suggest keeping a modicum of independence in gallium
plus making the open code simpler, and going with 128...

But if you feel strongly, I don't mind the bigger number (219) either,
except on aesthetic grounds...

Keith

[Mesa3d-dev] [PATCH] Hack for nv04_surfaces.c

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

Allow some texwrap testing. But just hack around for now .....

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

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

On 02.03.2010 11:37, Keith Whitwell wrote:
> 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.

There's actually something in the cso code I was a bit unsure about,
I've looked at it again and indeed it seems wrong. The problem is that
the count value itself isn't stored for the comparison. So in the
unlikely case the hash value is the same for pipe_vertex_elements with
different counts, the comparison itself will also be the same as long as
the first few elements are identical. Which seems very wrong. The
easiest way to fix would probably be to just store the count alongside
the pipe_vertex_element data, but that would need an additional copy of
the incoming data in cso_set_vertex_elements. Hmm...

Roland

Re: [Mesa3d-dev] Remove color index rendering?

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

On Fri, Feb 26, 2010 at 7:19 PM, Ian Romanick <id...@fr...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ian Romanick wrote:
>> While we're on the topic of removing dead weight, can we remove support
>> for color index rendering?  None of the hardware drivers support color
>> index rendering, and color index rendering is deprecated in OpenGL 3.0
>> (and removed in 3.1).
>>
>> Can it please die in a fire?
>
> I have just pushed a branch that removes color-index rendering.  It is
> available for review in the remove_ci_rendering branch of
> git://anongit.freedesktop.org/~idr/mesa.git.  I have done on minimal
> testing so far, but I intend to do more over the weekend.  It took most
> of the week just to get all the changes made.
>
> There are 38 individual patches.  The patches remove a total of 2,304
> lines of code.  I tried to make it easier to review by keeping the
> individual changes small.
>
> There are probably some additional changes that could be made.  There is
> still a bit of index tracking in TNL and other related places.  I think
> some of this can be removed.  Such removals would be more invasive (grep
> for MAT_*_INDEX),

I think you mean the MAT_INDEX_* tokens there.  We can weed out some
of that little stuff over time.


> and may impact our adherence to the spec.  For
> example, some queries would return incorrect values.
>
> In any case, I'm satisfied with this set of removals for now.

The branch looks good.  Just one minor thing: please document CI
removal in the 7.8 release notes file.

-Brian

[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


Brian Paul <bri...@gm...> changed:

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




--- Comment #2 from Brian Paul <bri...@gm...>  2010-03-02 06:38:01 PST ---
The proposed fix is incorrect.  We need to append the attrib_list information
to the protocol request.  I'm replacing the assertion with a conditional.  See
commit 44f6bb1ddf2ffda93a8f1ecf3eca3f051939482b on master and
eede72b0f92ae49ed8c22f3210e615108a5e2b0a on the 7.7 branch.


-- 
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] Mesa: regression (with --enable-debug only!) caused by c76d4db25260dd68684bf784efacd7323c7cab8b

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

On Sun, Feb 28, 2010 at 3:44 AM, Magnus Kessler <Mag...@gm...> wrote:
> Here's an interesting regression caused by Mesa commit
> c76d4db25260dd68684bf784efacd7323c7cab8b
> (http://cgit.freedesktop.org/mesa/mesa/commit/?id=c76d4db25260dd68684bf784efacd7323c7cab8b).
> It shows itself only when Mesa is configured with --enable-debug. In this case
> the i965_dri.so driver can't be loaded due to a missing symbol CLAMP:
>
> libGL error: dlopen /usr/lib64/dri/i965_dri.so failed
> (/usr/lib64/dri/i965_dri.so: undefined symbol: CLAMP)
>
> I tracked this down to the removal of the inclusion of "main/macros.h" in
> gen6_cc.c. In color_calc_state_create_from_key() (gen6_cc.c line 220), the
> macro UNCLAMPED_FLOAT_TO_UBYTE is used. This macro is defined in
> "main/imports.h". Unfortunately, for the debug case, this macro calls upon the
> CLAMP macro defined in "main/macros.h", which is no longer included into
> gen6_cc.so.
>
> My feeling is that the macro declaration in "main/imports.h" is at fault. This
> file is included into "main/macros.h", but clearly depends on a macro (CLAMP)
> in there, causing a circular dependency.
>
> To me it sounds like the best way to fix the root cause is to move the
> UNCLAMPED_FLOAT_TO_UBYTE macro to "main/macros.h" where it would sit next to
> other similar macros. gen6_cc.c as a user of this macro would then of course
> include "main/macros.h" again. The minimum fix is just to revert part of
> c76d4db25260dd68684bf784efacd7323c7cab8b for gen6_cc.c
>
> I hope this analysis is useful to you.

I think I'll just undo the change to gen6_cc.c for now.

-Brian