mesa3d-dev

[Mesa3d-dev] Patch to fix -m32 for progs/glsl

[Török E. <edw...@gm...>]

Hi,

I had to apply the following patch to build mesa as 32-bit,
on a 64-bit Debian system (so that wine, and all else get proper
3D accelereration with the new r600 driver).

progs/glsl is built by default, but it was not using -m32.
Please apply the patch to mesa git master, it is a one-line makefile fix.

Best regards,
--Edwin

[Mesa3d-dev] [PATCH] Fix --enable-32-bit: honor -m32 for progs/glsl.

[Török E. <edw...@gm...>]

---
 progs/glsl/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/progs/glsl/Makefile b/progs/glsl/Makefile
index 8928c83..aaa54cb 100644
--- a/progs/glsl/Makefile
+++ b/progs/glsl/Makefile
@@ -16,7 +16,7 @@ LIBS = -L$(TOP)/$(LIB_DIR) -l$(GLUT_LIB) -l$(GLEW_LIB) -l$(GLU_LIB) \
 # using : to avoid APP_CC pointing to CC loop
 CC := $(APP_CC)
 CFLAGS := -I$(INCDIR) $(CFLAGS)
-LDLIBS = $(LIBS)
+LDLIBS = $(LIBS) $(ARCH_FLAGS)
 
 PROG_SOURCES = \
 	array.c \
-- 
1.7.0

Re: [Mesa3d-dev] [PATCH] glx/dri2: Wait for invalidate event rather than guessing if one will arrive.

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

On Thu, 2010-02-25 at 12:56 +0100, Michel Dänzer wrote: 
> From: Michel Dänzer <da...@vm...>
> 
> The guess can be wrong if the DRI driver loaded by the server doesn't support
> invalidate events.
> 
> Also check that the DRI driver actually has an invalidate hook before calling
> it.

Never mind, looks like these issues were due to an inconsistent Mesa
build.


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

Re: [Mesa3d-dev] [PATCH] glapi cleanup: swap dispatch.[ch]

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

On Wed, Feb 24, 2010 at 12:49 PM, Brian Paul <bri...@gm...> wrote:
> On Tue, Feb 23, 2010 at 9:38 PM, Chia-I Wu <ol...@gm...> wrote:
>> This patch series moves
>> src/mesa/dispatch.c to src/glapi/glapi_dispatch.c and
>> src/glapi/dispatch.h to src/mesa/dispatch.h.
>> As can be seen in sources.mak, dispatch.c is actually a glapi source file.  And
>> although not mentioned anywhere, dispatch.h is a core Mesa header file.  It
>> honors IN_DRI_DRIVER and should not be used outside core Mesa.  Another benefit
>> of this clean up is that it is now clear that IN_DRI_DRIVER is not used
>> elsewhere except for in core Mesa.
> I didn't test, but sounds good to me.
Great.  I've pushed the patches.  Please note that "make clean" might be
needed because the files are moved.

-- 
ol...@Lu...

[Mesa3d-dev] [PATCH] glx/dri2: Wait for invalidate event rather than guessing if one will arrive.

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

From: Michel Dänzer <da...@vm...>

The guess can be wrong if the DRI driver loaded by the server doesn't support
invalidate events.

Also check that the DRI driver actually has an invalidate hook before calling
it.
---
 src/glx/dri2_glx.c |   28 +++++++++++++++++++++++-----
 1 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 6cd70be..b41bfe5 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -89,6 +89,7 @@ struct __GLXDRIdrawablePrivateRec
 };
 
 static void dri2WaitX(__GLXDRIdrawable * pdraw);
+static void dri2DoInvalidateBuffers(__GLXDRIdrawable *pdraw);
 
 static void
 dri2DestroyContext(__GLXDRIcontext * context,
@@ -335,7 +336,7 @@ dri2FlushFrontBuffer(__DRIdrawable *driDrawable, void *loaderPrivate)
 
    /* Old servers don't send invalidate events */
    if (!pdp->invalidateAvailable)
-       dri2InvalidateBuffers(priv->dpy, pdraw->base.xDrawable);
+       dri2DoInvalidateBuffers(pdraw);
 
    dri2WaitGL(loaderPrivate);
 }
@@ -399,7 +400,7 @@ dri2SwapBuffers(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
 
     /* Old servers don't send invalidate events */
     if (!pdp->invalidateAvailable)
-       dri2InvalidateBuffers(dpyPriv->dpy, pdraw->xDrawable);
+       dri2DoInvalidateBuffers(pdraw);
 
     /* Old servers can't handle swapbuffers */
     if (!pdp->swapAvailable) {
@@ -506,14 +507,31 @@ static const __DRIextension *loader_extensions_old[] = {
    NULL
 };
 
+static void
+dri2DoInvalidateBuffers(__GLXDRIdrawable *pdraw)
+{
+#if __DRI2_FLUSH_VERSION >= 3
+   if (pdraw->psc->f && pdraw->psc->f->base.version >= 3)
+       pdraw->psc->f->invalidate(pdraw->driDrawable);
+#endif
+}
+
 _X_HIDDEN void
 dri2InvalidateBuffers(Display *dpy, XID drawable)
 {
    __GLXDRIdrawable *pdraw = GetGLXDRIDrawable(dpy, drawable, NULL);
 
 #if __DRI2_FLUSH_VERSION >= 3
-   if (pdraw && pdraw->psc->f)
-       pdraw->psc->f->invalidate(pdraw->driDrawable);
+   if (pdraw) {
+      __GLXDRIdrawablePrivate *priv = (__GLXDRIdrawablePrivate *) pdraw;
+      __GLXdisplayPrivate *dpyPriv = __glXInitialize(priv->base.psc->dpy);
+      __GLXDRIdisplayPrivate *pdp =
+         (__GLXDRIdisplayPrivate *)dpyPriv->dri2Display;
+
+      pdp->invalidateAvailable = GL_TRUE;
+
+      dri2DoInvalidateBuffers(pdraw);
+   }
 #endif
 }
 
@@ -684,7 +702,7 @@ dri2CreateDisplay(Display * dpy)
 
    pdp->driPatch = 0;
    pdp->swapAvailable = (pdp->driMinor >= 2);
-   pdp->invalidateAvailable = (pdp->driMinor >= 3);
+   pdp->invalidateAvailable = GL_FALSE; /* Will set to TRUE on event receipt */
 
    pdp->base.destroyDisplay = dri2DestroyDisplay;
    pdp->base.createScreen = dri2CreateScreen;
-- 
1.7.0

Re: [Mesa3d-dev] Continue to allow building src/glx on current distros

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

The ifdef changes to allow building with older libdrm and glproto
header files are working.
But the configure.ac requirements are still aggressive, requiring
LIBDRM_REQUIRED=2.4.15
and
GLPROTO_REQUIRED=1.4.11
Could those back down now that the source code itself is more flexible?
Those version requirements are not met by debian testing or ubuntu 9.10.

-- 

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

[Mesa3d-dev] [Bug 26734] format assertion in driNewRenderbuffer

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

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


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

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




--- Comment #2 from Brian Paul <bri...@gm...>  2010-02-24 13:05:57 PST ---
I've removed the obsolete assertion.  Commit
293f4d51b473783d5c5ab773a1c438e0a2fe46f2.

As I've suspected, the older DRI drivers aren't getting much testing.


-- 
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 26734] format assertion in driNewRenderbuffer

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

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





--- Comment #1 from Tormod Volden <bug...@xo...>  2010-02-24 12:56:48 PST ---
This was also seen on xorg ML:
http://lists.freedesktop.org/archives/xorg/2010-January/048892.html


-- 
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 26734] New: format assertion in driNewRenderbuffer

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

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

           Summary: format assertion in driNewRenderbuffer
           Product: Mesa
           Version: unspecified
          Platform: Other
               URL: https://bugs.launchpad.net/bugs/515846
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: bug...@xo...


Created an attachment (id=33530)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33530)
full backtrace

glxinfo (or the DRI-enabled) xserver crashes with this assertion in mesa 7.7 on
a number of drivers:

glxinfo: ../common/drirenderbuffer.c:69: driNewRenderbuffer: Assertion `format
== 0x1908 || format == 0x8050 || format == 0x8058 || format == 0x81A5 || format
== 0x81A6 || format == 0x81A7 || format == 0x8D48' failed.

>From looking at the code, I think this happened with
http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_7_branch&id=1160acbfea986a821761d18f5f14d5d2cb0dea8c

The assertion should probably be updated or removed.


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

Re: [Mesa3d-dev] [PATCH 10/12] egl_dri2: Implement EGL_KHR_image and EGL_KHR_image_pixmap

[Kristian H. <kr...@bi...>]

2010/2/18 Chia-I Wu <ol...@gm...>:
> On Thu, Feb 18, 2010 at 12:04:14PM -0500, Kristian Høgsberg wrote:
>> 2010/2/12 Ian Romanick <id...@fr...>:
...
>> > Since applications call this function directly, should this give an
>> > error if dri2_dpy->image is NULL, or is it okay to just segfault?
>> If __DRIimage isn't available, eglInitializeDisplay fails.  I suppose
>> we should make that optional and just not advertise any EGLImage
>> extensions instead.
> It should be noted that eglapi.c does not check if an extension is
> available before dispatching (while it probably should).
>
> BTW, it seems
>
>  dri2_dpy->base.Extensions.KHR_image_base and
>  dri2_dpy->base.Extensions.KHR_image_pixmap
>
> are not set in the patch to advertise the extensions.

Done.

thanks,
Kristian

Re: [Mesa3d-dev] Gallium format swizzles (Was: util: fix swizzles in the format table for 8-bits-per-channel formats)

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

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.

Jose

Re: [Mesa3d-dev] [PATCH] pipebuffer: check for unsynchronized usage before looking at flags

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

On Tue, 2010-02-23 at 12:49 -0800, Luca Barbieri wrote:
> > Good catch of the fence_signalled
> > negated logic.
> 
> This was actually mentioned on IRC by Maarten Maathuis (who was
> working on adding pipebuffer support to the nv50 driver).
> Thanks to him :)

Thanks to you both then!

Jose

Re: [Mesa3d-dev] move normalized texel coordinates bit to sampler view

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

On 24.02.2010 12:48, Christoph Bumiller wrote:
> This wasn't a problem before because textures and samplers were
> linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
> this coordinate normalization bit becomes a problem.
> 
> NV50 hardware has that bit in the RESOURCE binding, and not the
> SAMPLER binding, and you can imagine that this will lead to us having
> to jump through a few annoying looking hoops to accomodate.
> 
> As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have
> sampler states that are decoupled from the texture, and which contain
> a normalized coordinates bit, so it's worth considering not having it there
> in gallium either.
> 
> For OpenGL, unnormalized coordinates are only used for RECT textures,
> and in this case it makes sense to make it a property of the texture.

I agree this is not sampler state, but I don't quite agree this should
be texture state.
This changes how texture coordinates get interpreted in the interpolator
- in that sense it is similar to the cylindrical texture coord wrap
which we moved away from sampler state recently. This one got moved to
shader declaration. I wonder if the normalization bit should be treated
the same.
Though OTOH you're quite right that in OpenGL this really is texture
property (it is a different texture target after all), and afaik d3d
doesn't support non-normalized coords (?). Hmm...

Roland



> 
> And, finally, I've seen you reverted the changes for independent image
> and sampler index in the texture opcodes. What's up with that ?
> Is the code not nice enough, or has the idea been discarded and by problem
> disappears ?
> 
> Best regards,
> Christoph
> 
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26730] New: Gallium driver for r500 GL_NV_vertex_program doesn't work

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

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

           Summary: Gallium driver for r500 GL_NV_vertex_program doesn't
                    work
           Product: Mesa
           Version: git
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
        AssignedTo: mes...@li...
        ReportedBy: so...@gm...


Created an attachment (id=33526)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33526)
Example of the problem

Newerwinter Nights 1.69 doesn't display cloaks or clothes if driver exports 
GL_NV_vertex_program. Turning it off, using
MESA_EXTENSION_OVERRIDE=-GL_NV_vertex_program, fixes problems with graphic.

Card:Radeon X1650 Pro
Mesa git:3f5bac8960a5c6d1f08f0dc849676139b9d6ce5c
Kernel drm-radeon-testing git:aa5120d2ef228042416d3023fb7eda9ee487dcf9

Output from 32bit glxinfo:
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_INTEL_swap_event
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, 
    GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, 
    GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, 
    GLX_INTEL_swap_event
GLX version: 1.4
GLX extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, 
    GLX_INTEL_swap_event
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RV530
OpenGL version string: 2.1 Mesa 7.8-devel
OpenGL shading language version string: 1.20
OpenGL extensions:
    GL_ARB_copy_buffer, GL_ARB_depth_texture, GL_ARB_draw_buffers, 
    GL_ARB_fragment_coord_conventions, GL_ARB_fragment_program, 
    GL_ARB_fragment_shader, GL_ARB_framebuffer_object, GL_ARB_imaging, 
    GL_ARB_map_buffer_range, GL_ARB_multisample, GL_ARB_multitexture, 
    GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, 
    GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, 
    GL_ARB_shader_objects, GL_ARB_shading_language_100, 
    GL_ARB_shading_language_120, GL_ARB_shadow, GL_ARB_texture_border_clamp, 
    GL_ARB_texture_compression, GL_ARB_texture_cube_map, 
    GL_ARB_texture_env_add, GL_ARB_texture_env_combine, 
    GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, 
    GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, 
    GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, 
    GL_ARB_vertex_array_bgra, GL_ARB_vertex_array_object, 
    GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, 
    GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, 
    GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, 
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
    GL_EXT_cull_vertex, GL_EXT_compiled_vertex_array, GL_EXT_convolution, 
    GL_EXT_copy_texture, GL_EXT_draw_buffers2, GL_EXT_draw_range_elements, 
    GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, 
    GL_EXT_framebuffer_object, GL_EXT_fog_coord, GL_EXT_histogram, 
    GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, 
    GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, 
    GL_EXT_polygon_offset, GL_EXT_provoking_vertex, GL_EXT_rescale_normal, 
    GL_EXT_secondary_color, GL_EXT_separate_specular_color, 
    GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, 
    GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, 
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, 
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, 
    GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, 
    GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_vertex_array, 
    GL_EXT_vertex_array_bgra, GL_3DFX_texture_compression_FXT1, 
    GL_APPLE_client_storage, GL_APPLE_packed_pixels, 
    GL_APPLE_vertex_array_object, GL_ATI_blend_equation_separate, 
    GL_ATI_separate_stencil, GL_IBM_multimode_draw_arrays, 
    GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, 
    GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, 
    GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, 
    GL_NV_packed_depth_stencil, GL_NV_texture_env_combine4, 
    GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, 
    GL_NV_vertex_program1_1, GL_OES_read_format, GL_SGI_color_matrix, 
    GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, 
    GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays, 
    GL_S3_s3tc

64 GLX Visuals
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x21 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x22 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0xce 24 tc  0 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0xcf 24 tc  0 24  0 r  .  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0xd0 24 tc  0 24  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0xd1 24 tc  0 24  0 r  y  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0xd2 24 tc  0 24  0 r  .  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xd3 24 tc  0 24  0 r  .  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xd4 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xd5 24 tc  0 24  0 r  y  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xd6 24 tc  0 24  0 r  .  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xd7 24 tc  0 24  0 r  .  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xd8 24 tc  0 24  0 r  y  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xd9 24 tc  0 24  0 r  y  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xda 24 tc  0 24  0 r  .  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xdb 24 tc  0 24  0 r  .  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xdc 24 tc  0 24  0 r  y  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xdd 24 tc  0 24  0 r  y  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xde 24 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xdf 24 tc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xe0 24 tc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xe1 24 tc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xe2 24 tc  0 32  0 r  .  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0xe3 24 tc  0 32  0 r  .  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0xe4 24 tc  0 32  0 r  y  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0xe5 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0xe6 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0xe7 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0xe8 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0xe9 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0xea 24 tc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0xeb 24 tc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0xec 24 dc  0 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0xed 24 dc  0 24  0 r  .  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0xee 24 dc  0 24  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0xef 24 dc  0 24  0 r  y  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0xf0 24 dc  0 24  0 r  .  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xf1 24 dc  0 24  0 r  .  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xf2 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xf3 24 dc  0 24  0 r  y  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xf4 24 dc  0 24  0 r  .  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xf5 24 dc  0 24  0 r  .  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xf6 24 dc  0 24  0 r  y  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xf7 24 dc  0 24  0 r  y  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xf8 24 dc  0 24  0 r  .  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xf9 24 dc  0 24  0 r  .  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xfa 24 dc  0 24  0 r  y  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xfb 24 dc  0 24  0 r  y  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xfc 24 dc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xfd 24 dc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xfe 24 dc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xff 24 dc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x100 24 dc  0 32  0 r  .  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0x101 24 dc  0 32  0 r  .  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0x102 24 dc  0 32  0 r  y  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0x103 24 dc  0 32  0 r  y  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0x104 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x105 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x106 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x107 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x108 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x109 24 dc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x10a 24 dc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x6d 32 tc  0 32  0 r  y  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None

64 GLXFBConfigs:
   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x7e  0 tc  0 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x7f  0 tc  0 24  0 r  .  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0x80  0 tc  0 24  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0x81  0 tc  0 24  0 r  y  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0x82  0 tc  0 24  0 r  .  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0x83  0 tc  0 24  0 r  .  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0x84  0 tc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0x85  0 tc  0 24  0 r  y  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0x86  0 tc  0 24  0 r  .  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0x87  0 tc  0 24  0 r  .  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0x88  0 tc  0 24  0 r  y  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0x89  0 tc  0 24  0 r  y  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0x8a  0 tc  0 24  0 r  .  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0x8b  0 tc  0 24  0 r  .  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0x8c  0 tc  0 24  0 r  y  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0x8d  0 tc  0 24  0 r  y  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0x8e  0 tc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x8f  0 tc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x90  0 tc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x91  0 tc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0x92  0 tc  0 32  0 r  .  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0x93  0 tc  0 32  0 r  .  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0x94  0 tc  0 32  0 r  y  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0x95  0 tc  0 32  0 r  y  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0x96  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x97  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x98  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x99  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x9a  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x9b  0 tc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x9c  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x9d  0 tc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0xae  0 dc  0 24  0 r  .  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0xaf  0 dc  0 24  0 r  .  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0xb0  0 dc  0 24  0 r  y  .  8  8  8  0  0  0  0  0  0  0  0  0 0 None
0xb1  0 dc  0 24  0 r  y  .  8  8  8  0  0  0  0 16 16 16  0  0 0 Slow
0xb2  0 dc  0 24  0 r  .  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xb3  0 dc  0 24  0 r  .  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xb4  0 dc  0 24  0 r  y  .  8  8  8  0  0 16  0  0  0  0  0  0 0 None
0xb5  0 dc  0 24  0 r  y  .  8  8  8  0  0 16  0 16 16 16  0  0 0 Slow
0xb6  0 dc  0 24  0 r  .  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xb7  0 dc  0 24  0 r  .  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xb8  0 dc  0 24  0 r  y  .  8  8  8  0  0 24  0  0  0  0  0  0 0 None
0xb9  0 dc  0 24  0 r  y  .  8  8  8  0  0 24  0 16 16 16  0  0 0 Slow
0xba  0 dc  0 24  0 r  .  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xbb  0 dc  0 24  0 r  .  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xbc  0 dc  0 24  0 r  y  .  8  8  8  0  0 24  8  0  0  0  0  0 0 None
0xbd  0 dc  0 24  0 r  y  .  8  8  8  0  0 24  8 16 16 16  0  0 0 Slow
0xbe  0 dc  0 32  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xbf  0 dc  0 32  0 r  .  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xc0  0 dc  0 32  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0xc1  0 dc  0 32  0 r  y  .  8  8  8  8  0  0  0 16 16 16 16  0 0 Slow
0xc2  0 dc  0 32  0 r  .  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0xc3  0 dc  0 32  0 r  .  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0xc4  0 dc  0 32  0 r  y  .  8  8  8  8  0 16  0  0  0  0  0  0 0 None
0xc5  0 dc  0 32  0 r  y  .  8  8  8  8  0 16  0 16 16 16 16  0 0 Slow
0xc6  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0xc7  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0xc8  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0xc9  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0xca  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0xcb  0 dc  0 32  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0xcc  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0xcd  0 dc  0 32  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow


-- 
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] move normalized texel coordinates bit to sampler view

[Christoph B. <e04...@st...>]

This wasn't a problem before because textures and samplers were
linked 1:1, but in view of the gallium-gpu4-texture-opcodes branch,
this coordinate normalization bit becomes a problem.

NV50 hardware has that bit in the RESOURCE binding, and not the
SAMPLER binding, and you can imagine that this will lead to us having
to jump through a few annoying looking hoops to accomodate.

As far as I can see, neither D3D10 nor D3D11 nor OpenGL nor CUDA have
sampler states that are decoupled from the texture, and which contain
a normalized coordinates bit, so it's worth considering not having it there
in gallium either.

For OpenGL, unnormalized coordinates are only used for RECT textures,
and in this case it makes sense to make it a property of the texture.

And, finally, I've seen you reverted the changes for independent image
and sampler index in the texture opcodes. What's up with that ?
Is the code not nice enough, or has the idea been discarded and by problem
disappears ?

Best regards,
Christoph

[Mesa3d-dev] [Bug 25588] [Segmentation fault] vbo_get_minmax_index at vbo/vbo_exec_array.c:81

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

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


Fabio Pedretti <fab...@li...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|NEEDINFO                    |




-- 
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 25588] [Segmentation fault] vbo_get_minmax_index at vbo/vbo_exec_array.c:81

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

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





--- Comment #7 from Fabio Pedretti <fab...@li...>  2010-02-24 00:48:28 PST ---
> > $ glxinfo -l | grep GL_MAX_TEXTURE_
> > Mesa: CPU vendor: GenuineIntel
> > Mesa: CPU name: Genuine Intel(R) CPU           T2600  @ 2.16GHz
> > Mesa: Mesa 7.8-devel DEBUG build Dec 13 2009 18:40:27
> > Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
> > compression/decompression unavailable
> > Mesa: MMX cpu detected.
> > Mesa: SSE cpu detected.
> > Mesa: Not testing OS support for SSE, leaving enabled.
> > Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> > Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> > Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> > Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> > Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> > Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> >     GL_MAX_TEXTURE_STACK_DEPTH = 10
> >     GL_MAX_TEXTURE_SIZE = 4096
> >     GL_MAX_TEXTURE_UNITS_ARB = 8
> >     GL_MAX_TEXTURE_LOD_BIAS_EXT = 16
> >     GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT = 16
> > 
> > Btw, are all those
> > Mesa: User error: GL_INVALID_ENUM in glGetProgramivARB(pname)
> > meaningful (glxinfo bug?) or should I just ignore them?
> 
> These messages are usually produced when glxinfo tries to query limits related
> to fragment programs when the driver does not support fragment programs.  Could
> you attach the full output of 'glxinfo -l'?
> 

The glxinfo 'User error' are now fixed with:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=52cc3b03c3950cd66f9d976b2a3ae9f89dc4a97b

The ETQW game still has the program errors as attached to comment 5.


-- 
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] MMIO/DMA ?

[Stephane M. <ste...@gm...>]

On Tue, Feb 23, 2010 at 22:54, Westermann Fu <wes...@gm...> wrote:
> Thanks very much
>
> As the example when FIFO is full, maybe the 17th or 33th vertex will wait
> for there is room again, so the block happens, I agree. But for correctness,
> need software special handling? I mean after each time a triangle is feeding
> to GPU, then, should software wait for some status register to indicate the
> FIFO is safe? or the 'MOV' instruction itself (or whatever others, here I
> mean no any sync code needed) can promise the correctness automaticly?
> Otherwise I think there is a FIFO overriding risk.
>

[with a proper reply all this time]

On all MMIO GPUs that I know which work like that, the CPU will block
and wait for as long as it takes. But usually you also have a reg you
can poke to know the current filling status of the fifo (full/some
free space), and you can use that to avoid sending too many triangles
and end up in a blocking situation.

Stephane

Re: [Mesa3d-dev] MMIO/DMA ?

[Westermann Fu <wes...@gm...>]

Thanks very much

As the example when FIFO is full, maybe the 17th or 33th vertex will wait
for there is room again, so the block happens, I agree. But for correctness,
need software special handling? I mean after each time a triangle is feeding
to GPU, then, should software wait for some status register to indicate the
FIFO is safe? or the 'MOV' instruction itself (or whatever others, here I
mean no any sync code needed) can promise the correctness automaticly?
Otherwise I think there is a FIFO overriding risk.

Regards


On Wed, Feb 24, 2010 at 1:39 PM, Stephane Marchesin <
ste...@gm...> wrote:

> On Tue, Feb 23, 2010 at 21:06, Westermann Fu <wes...@gm...>
> wrote:
> > Hi, friends:
> >
> > Sorry for my junior level question first, but I don't know where I can
> get
> > it been answered. I have post it to dri-devel list but nobody seems
> > interested, so I hope anyone here can help me.
> >
> > As I know, DMA/CommandParser can provide asynchronous execuation of
> graphics
> > commands with CPU execution, and the direct I/O of course is synchronous
> > with instructions executed on CPU, but what is here 'synchronous' means?
> I
> > take an example of direct I/O triangle setting for 3D engine to render
> > triangle (3 vertexes) as the below piece of code:
> >
> > /*
> >  ** set graphics contexts
> >  */
> >
> > /*
> > ** using direct I/O to write 3 vertex data to 3D engine         **
> register
> > for rendering a triangle, assume the vertex data
> > ** only contain position (x,y,z,w)
> >  */
> > movl vtx.pos.1,  VP_register
> > movl vtx.pos.2,  VP_register
> > movl vtx.pos.3,  VP_register
> >
> > does 'synchronous' mean CPU won't finish the last one 'MOV' instruction
> > until the 3D engine finish rendering this triangle (finishing all TnL,
> > rasterization and pixel processing to framebuffer)? Or my understanding
> is
> > wrong? Thanks very much.
>
> Usually, if you have such an MMIO interface (where writing vertex data
> into MMIO registers directly get things drawn) what is synchronous is
> the hardware write, i.e. the write of the triangle vetex position. Now
> usually what happens after that is the triangle is still drawn
> asychronously.
>
> But wait, that's only with a single triangle. The trick is when you
> start drawing multiple triangles in a row, then maybe the 2nd one is
> blocking until the first one is drawn. Or if the hardware has an
> internal command queue for MMIO submission (which is also very common)
> maybe the 17th or the 33rd triangle will block until there is room in
> the queue.
>
> Stephane
>

Re: [Mesa3d-dev] MMIO/DMA ?

[Stephane M. <ste...@gm...>]

On Tue, Feb 23, 2010 at 21:06, Westermann Fu <wes...@gm...> wrote:
> Hi, friends:
>
> Sorry for my junior level question first, but I don't know where I can get
> it been answered. I have post it to dri-devel list but nobody seems
> interested, so I hope anyone here can help me.
>
> As I know, DMA/CommandParser can provide asynchronous execuation of graphics
> commands with CPU execution, and the direct I/O of course is synchronous
> with instructions executed on CPU, but what is here 'synchronous' means? I
> take an example of direct I/O triangle setting for 3D engine to render
> triangle (3 vertexes) as the below piece of code:
>
> /*
>  ** set graphics contexts
>  */
>
> /*
> ** using direct I/O to write 3 vertex data to 3D engine         ** register
> for rendering a triangle, assume the vertex data
> ** only contain position (x,y,z,w)
>  */
> movl vtx.pos.1,  VP_register
> movl vtx.pos.2,  VP_register
> movl vtx.pos.3,  VP_register
>
> does 'synchronous' mean CPU won't finish the last one 'MOV' instruction
> until the 3D engine finish rendering this triangle (finishing all TnL,
> rasterization and pixel processing to framebuffer)? Or my understanding is
> wrong? Thanks very much.

Usually, if you have such an MMIO interface (where writing vertex data
into MMIO registers directly get things drawn) what is synchronous is
the hardware write, i.e. the write of the triangle vetex position. Now
usually what happens after that is the triangle is still drawn
asychronously.

But wait, that's only with a single triangle. The trick is when you
start drawing multiple triangles in a row, then maybe the 2nd one is
blocking until the first one is drawn. Or if the hardware has an
internal command queue for MMIO submission (which is also very common)
maybe the 17th or the 33rd triangle will block until there is room in
the queue.

Stephane

[Mesa3d-dev] MMIO/DMA ?

[Westermann Fu <wes...@gm...>]

Hi, friends:

Sorry for my junior level question first, but I don't know where I can get
it been answered. I have post it to dri-devel list but nobody seems
interested, so I hope anyone here can help me.

As I know, DMA/CommandParser can provide asynchronous execuation of graphics
commands with CPU execution, and the direct I/O of course is synchronous
with instructions executed on CPU, but what is here 'synchronous' means? I
take an example of direct I/O triangle setting for 3D engine to render
triangle (3 vertexes) as the below piece of code:

/*
 ** set graphics contexts
 */

/*
** using direct I/O to write 3 vertex data to 3D engine         ** register
for rendering a triangle, assume the vertex data
** only contain position (x,y,z,w)
 */
movl vtx.pos.1,  VP_register
movl vtx.pos.2,  VP_register
movl vtx.pos.3,  VP_register

does 'synchronous' mean CPU won't finish the last one 'MOV' instruction
until the 3D engine finish rendering this triangle (finishing all TnL,
rasterization and pixel processing to framebuffer)? Or my understanding is
wrong? Thanks very much.

Regards

Re: [Mesa3d-dev] [PATCH] glapi cleanup: swap dispatch.[ch]

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

On Tue, Feb 23, 2010 at 9:38 PM, Chia-I Wu <ol...@gm...> wrote:
> This patch series moves
>
> src/mesa/dispatch.c to src/glapi/glapi_dispatch.c and
> src/glapi/dispatch.h to src/mesa/dispatch.h.
>
> As can be seen in sources.mak, dispatch.c is actually a glapi source file.  And
> although not mentioned anywhere, dispatch.h is a core Mesa header file.  It
> honors IN_DRI_DRIVER and should not be used outside core Mesa.  Another benefit
> of this clean up is that it is now clear that IN_DRI_DRIVER is not used
> elsewhere except for in core Mesa.

I didn't test, but sounds good to me.

-Brian

[Mesa3d-dev] [PATCH] glapi cleanup: swap dispatch.[ch]

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

This patch series moves

src/mesa/dispatch.c to src/glapi/glapi_dispatch.c and
src/glapi/dispatch.h to src/mesa/dispatch.h.

As can be seen in sources.mak, dispatch.c is actually a glapi source file.  And
although not mentioned anywhere, dispatch.h is a core Mesa header file.  It
honors IN_DRI_DRIVER and should not be used outside core Mesa.  Another benefit
of this clean up is that it is now clear that IN_DRI_DRIVER is not used
elsewhere except for in core Mesa.

-- 
ol...@Lu...

Re: [Mesa3d-dev] [RFC] Integration of EGL and its media APIs

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

On Wed, Feb 24, 2010 at 11:25 AM, Stephane Marchesin
<ste...@gm...> wrote:
> On Tue, Feb 23, 2010 at 18:05, Chia-I Wu <ol...@gm...> wrote:
>> Hi list,
>>
>> We at LunarG are working on resource sharing between EGL and its rendering and
>> non-rendering APIs.  The resource sharing is at the driver level and it enables
>> us to properly support various EGLImage extensions for EGL/OpenGL|ES/OpenVG as
>> well as OpenMax's OMX_UseEGLImage.
>>
>> We would like to formalize our changes to Gallium and the current design
>> document is available at
>>
>>  http://www.lunarg.com/wordpress/wp-content/downloads/surface-manager-design.pdf
>>
>> To summarize, resource sharing between EGL and its rendering APIs (OpenGL ES
>> and OpenVG) will be made possible through the switch to st_api.h[1], which aims
>> to replace st_public.h that is implemented by st/mesa and st/vega.  It has been
>> discussed several times on the list.  The list archive should have more details
>> than the document right now.
>>
>> The only non-rendering API in existence is OpenMax.  What we would like to do
>> is to support decoding video frames into texture objects directly, which is
>> defined in OpenMax IL through the use of EGLImage.  We've picked Bellagio[2]
>> for our work.  As Bellagio is a 3rd party project, what this means to Gallium
>> is that we will work on a new state tracker that grants Bellagio access to
>> pipe_textures.
>>
>> We would like to submit the new state tracker (as well as st_api.h) for
>> upstream review & inclusion when we have a working implementation.  We think it
>> is important for us to start our work publicly to make sure we are working in
>> the direction that Gallium is moving.  It should be beneficial for both Mesa
>> and us.  We are improving the design document as we progress.  Any feedback on
>> our design and the new state tracker will be appreciated.
> I have one comment/question, are you going to use vl for that? It's
> obviously intended to target multiple APIs...
Generally, OpenMax IL components need not to depend on Gallium3D to use
EGLImages as the buffers.  But individual IL components like mpeg4 codec and
such may choose/need to be compiled separately from Bellagio and use v4l in
Gallium3D for hardware acceleration.

As OpenMax IL is not managed by EGL as other rendering APIs are, it is also an
interesting question that where do the Gallium3D-based IL components get the
pipe_screen/pipe_context in the first place?  It is either from EGL or Surface
Manager.  I am leaning toward Surface Manager to avoid adding another internal
interface between EGL and Gallium3D-based IL components.

-- 
ol...@Lu...

Re: [Mesa3d-dev] [RFC] Integration of EGL and its media APIs

[Stephane M. <ste...@gm...>]

On Tue, Feb 23, 2010 at 18:05, Chia-I Wu <ol...@gm...> wrote:
> Hi list,
>
> We at LunarG are working on resource sharing between EGL and its rendering and
> non-rendering APIs.  The resource sharing is at the driver level and it enables
> us to properly support various EGLImage extensions for EGL/OpenGL|ES/OpenVG as
> well as OpenMax's OMX_UseEGLImage.
>
> We would like to formalize our changes to Gallium and the current design
> document is available at
>
>  http://www.lunarg.com/wordpress/wp-content/downloads/surface-manager-design.pdf
>
> To summarize, resource sharing between EGL and its rendering APIs (OpenGL ES
> and OpenVG) will be made possible through the switch to st_api.h[1], which aims
> to replace st_public.h that is implemented by st/mesa and st/vega.  It has been
> discussed several times on the list.  The list archive should have more details
> than the document right now.
>
> The only non-rendering API in existence is OpenMax.  What we would like to do
> is to support decoding video frames into texture objects directly, which is
> defined in OpenMax IL through the use of EGLImage.  We've picked Bellagio[2]
> for our work.  As Bellagio is a 3rd party project, what this means to Gallium
> is that we will work on a new state tracker that grants Bellagio access to
> pipe_textures.
>
> We would like to submit the new state tracker (as well as st_api.h) for
> upstream review & inclusion when we have a working implementation.  We think it
> is important for us to start our work publicly to make sure we are working in
> the direction that Gallium is moving.  It should be beneficial for both Mesa
> and us.  We are improving the design document as we progress.  Any feedback on
> our design and the new state tracker will be appreciated.
>

I have one comment/question, are you going to use vl for that? It's
obviously intended to target multiple APIs...

Stephane