mesa3d-dev

Re: [Mesa3d-dev] LLVM and udis86 dependencies

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

On Mon, 2010-05-03 at 01:42 -0700, Török Edwin wrote:
> On 05/03/2010 11:36 AM, mes...@li... wrote:
> > From: Francis Galiegue <fga...@gm...>
> > Subject: [Mesa3d-dev] LLVM and udis86 dependencies
> > To: mes...@li...
> > Message-ID:
> > 	<x2z...@ma...>
> > Content-Type: text/plain; charset=ISO-8859-1
> > 
> > In the current HEAD, in configure.ac:
> > 
> > ----
> > 1182-    [enable_gallium=yes])
> > 1183-if test "x$enable_gallium" = xyes; then
> > 1184-    SRC_DIRS="$SRC_DIRS gallium gallium/winsys gallium/targets"
> > 1185:    AC_CHECK_HEADER([udis86.h], [HAS_UDIS86="yes"],
> > 1186-                [HAS_UDIS86="no"])
> > 1187-    AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no])
> > 1188-fi
> > --
> > 1340-   LLVM_LIBS="`$LLVM_CONFIG --libs jit interpreter nativecodegen
> > bitwriter` -lstdc++"
> > 1341-
> > 1342-   if test "x$HAS_UDIS86" != xno; then
> > 1343:       LLVM_LIBS="$LLVM_LIBS -ludis86"
> > 1344-       DEFINES="$DEFINES -DHAVE_UDIS86"
> > 1345-   fi
> > 1346-   LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
> > ----
> > 
> > This means basically that the udis86 dependency is "automagic" if you
> > elect to build with LLVM support.
> > 
> > I have a case here of a miscompiled udis86 (missing -fPIC, preventing
> > relocation) on a setup where LLVM was NOT compiled with udis86.
> > 
> > Would it be possible to make the udis86 dependency optional (ie,
> > --with-udis86 option to ./configure)?
> 
> LLVM 2.7 includes a disassembler of its own (libEnhancedDisassembly.so),
> could that one be used instead of udis86?

Yes, that would be nice. 

udis86 seems a bit unmaintained a the moment. I've sent a few patches
for some SSE4 opcodes to the maintainer and they weren't checked in yet.
I thought about bundling its source in mesa, but when I saw news of
LLVM's disassembler plans I thought it was better to wait.

But I don't have time to look into this myself. If you don't have time
either then a simple patch to make udis86 optional should be good enough
for now.

Jose

Re: [Mesa3d-dev] LLVM and udis86 dependencies

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

On 05/03/2010 11:36 AM, mes...@li... wrote:
> From: Francis Galiegue <fga...@gm...>
> Subject: [Mesa3d-dev] LLVM and udis86 dependencies
> To: mes...@li...
> Message-ID:
> 	<x2z...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> In the current HEAD, in configure.ac:
> 
> ----
> 1182-    [enable_gallium=yes])
> 1183-if test "x$enable_gallium" = xyes; then
> 1184-    SRC_DIRS="$SRC_DIRS gallium gallium/winsys gallium/targets"
> 1185:    AC_CHECK_HEADER([udis86.h], [HAS_UDIS86="yes"],
> 1186-                [HAS_UDIS86="no"])
> 1187-    AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no])
> 1188-fi
> --
> 1340-   LLVM_LIBS="`$LLVM_CONFIG --libs jit interpreter nativecodegen
> bitwriter` -lstdc++"
> 1341-
> 1342-   if test "x$HAS_UDIS86" != xno; then
> 1343:       LLVM_LIBS="$LLVM_LIBS -ludis86"
> 1344-       DEFINES="$DEFINES -DHAVE_UDIS86"
> 1345-   fi
> 1346-   LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
> ----
> 
> This means basically that the udis86 dependency is "automagic" if you
> elect to build with LLVM support.
> 
> I have a case here of a miscompiled udis86 (missing -fPIC, preventing
> relocation) on a setup where LLVM was NOT compiled with udis86.
> 
> Would it be possible to make the udis86 dependency optional (ie,
> --with-udis86 option to ./configure)?

LLVM 2.7 includes a disassembler of its own (libEnhancedDisassembly.so),
could that one be used instead of udis86?

Best regards,
--Edwin

[Mesa3d-dev] _mesa_init_texture_s3tc() vs util_format_s3tc_init()

[Xavier C. <cha...@gm...>]

I am trying to understand the s3tc init code as nv50 gallium has a
problem with that.

It looks like some drivers (r300g and llvmpipe) actually inits s3tc in
two places :
./src/mesa/main/texcompress_s3tc.c _mesa_init_texture_s3tc()
./src/gallium/auxiliary/util/u_format_s3tc.c util_format_s3tc_init()

Here is an extract of the backtrace calls while loading fgfs on llvmpipe :
driCreateScreen -> llvmpipe_create_screen -> util_format_s3tc_init
driCreateContext -> st_create_context -> _mesa_create_context_for_api
-> init_attrib_groups -> _mesa_init_texture_s3tc

These two functions seem to do more or less the same job, and
apparently, the classic mesa init is unused for a gallium driver.
So I suppose that init is not necessary, but it happens because
gallium and mesa are tightly tied together, and create context is
handled similarly, but it shouldn't hurt ?

Additionally r300g and llvmpipe added util_format_s3tc_init to their
create_screen functions, and util/u_format_s3tc.c apparently contains
all the functions that a gallium driver uses.
So I suppose that nvfx and nv50 should do the same ?

If that's correct, the patch below might not be completely wrong.

On Mon, May 3, 2010 at 12:44 AM, Xavier Chantry
<cha...@gm...> wrote:
> flightgear now dies with :
> Mesa warning: external dxt library not available: texstore_rgba_dxt3
> util/u_format_s3tc.c:66:util_format_dxt3_rgba_fetch_stub: Assertion `0' failed.
>
> I don't really understand what these stubs are about, they were
> introduced by following commit :
> commit d96e87c3c513f8ed350ae24425edb74b6d6fcc13
> Author: José Fonseca <jfo...@vm...>
> Date:   Wed Apr 7 20:47:38 2010 +0100
>
>    util: Use stubs for the dynamically loaded S3TC functions.
>
>    Loosely based on Luca Barbieri's commit
>    52e9b990a192a9329006d5f7dd2ac222effea5a5.
>
> Looking at llvm and r300 code and trying to guess, I came up with the
> following patch that allows flightgear to start again. But I don't
> really understand that stuff so it could be wrong.
> nvfx is probably affected as well.
>
>
> diff --git a/src/gallium/drivers/nouveau/nouveau_screen.c
> b/src/gallium/drivers/nouveau/nouveau_screen.c
> index 233a91a..a91b00b 100644
> --- a/src/gallium/drivers/nouveau/nouveau_screen.c
> +++ b/src/gallium/drivers/nouveau/nouveau_screen.c
> @@ -5,6 +5,7 @@
>  #include "util/u_memory.h"
>  #include "util/u_inlines.h"
>  #include "util/u_format.h"
> +#include "util/u_format_s3tc.h"
>
>  #include <stdio.h>
>  #include <errno.h>
> @@ -248,6 +249,8 @@ nouveau_screen_init(struct nouveau_screen *screen,
> struct nouveau_device *dev)
>        pscreen->fence_signalled = nouveau_screen_fence_signalled;
>        pscreen->fence_finish = nouveau_screen_fence_finish;
>
> +       util_format_s3tc_init();
> +
>        return 0;
>  }
>
> diff --git a/src/gallium/drivers/nv50/nv50_screen.c
> b/src/gallium/drivers/nv50/nv50_screen.c
> index 2dd1042..0d74c90 100644
> --- a/src/gallium/drivers/nv50/nv50_screen.c
> +++ b/src/gallium/drivers/nv50/nv50_screen.c
> @@ -20,6 +20,7 @@
>  * SOFTWARE.
>  */
>
> +#include "util/u_format_s3tc.h"
>  #include "pipe/p_screen.h"
>
>  #include "nv50_context.h"
> @@ -72,10 +73,6 @@ nv50_screen_is_format_supported(struct pipe_screen *pscreen,
>                case PIPE_FORMAT_A8_UNORM:
>                case PIPE_FORMAT_I8_UNORM:
>                case PIPE_FORMAT_L8A8_UNORM:
> -               case PIPE_FORMAT_DXT1_RGB:
> -               case PIPE_FORMAT_DXT1_RGBA:
> -               case PIPE_FORMAT_DXT3_RGBA:
> -               case PIPE_FORMAT_DXT5_RGBA:
>                case PIPE_FORMAT_S8_USCALED_Z24_UNORM:
>                case PIPE_FORMAT_Z24_UNORM_S8_USCALED:
>                case PIPE_FORMAT_Z32_FLOAT:
> @@ -85,6 +82,11 @@ nv50_screen_is_format_supported(struct pipe_screen *pscreen,
>                case PIPE_FORMAT_R16G16_SNORM:
>                case PIPE_FORMAT_R16G16_UNORM:
>                        return TRUE;
> +               case PIPE_FORMAT_DXT1_RGB:
> +               case PIPE_FORMAT_DXT1_RGBA:
> +               case PIPE_FORMAT_DXT3_RGBA:
> +               case PIPE_FORMAT_DXT5_RGBA:
> +                       return util_format_s3tc_enabled;
>                default:
>                        break;
>                }
>

Re: [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures

[Maxim L. <max...@gm...>]

On Sun, 2010-05-02 at 15:16 +0200, Marek Olšák wrote: 
> On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky
> <max...@gm...> wrote:
>         This commit breaks compiz completely here on nvidia G50
>         (Geforce 8400M)
>         Compiz shows dark screen.
>         (Using nouveau drivers)
>         
>         Without this commit compiz works almost perfectly.
>         
>         The error messages from compiz:
>         
>         
>         debug_get_bool_option: NV50_ALWAYS_PUSH = FALSE
>         debug_get_bool_option: DRAW_FSE = FALSE
>         debug_get_bool_option: DRAW_NO_FSE = FALSE
>         debug_get_bool_option: GALLIUM_DUMP_VS = FALSE
>         Mesa: Mesa 7.9-devel DEBUG build May  1 2010 19:02:06
>         Mesa warning: software DXTn compression/decompression
>         available
>         debug_get_bool_option: MESA_MVP_DP4 = FALSE
>         debug_get_flags_option: ST_DEBUG = 0x0
>         Mesa: User error: GL_OUT_OF_MEMORY in glTexImage
>         compiz (cube) - Warn: Failed to load
>         slide: /usr/share/gdm/themes/Human/ubuntu.png
>         ^CMesa: User error: GL_OUT_OF_MEMORY in glTexImage 
> 
> The commit also causes surface_copy to be called with S3TC textures,
> breaking loading of such textures in r300g. I am working on a fix for
> r300g but I haven't expected to get such weird formats in
> surface_copy.
Note that I installed the txc_dxtn, therefore the warning message. I
don't know if compiz uses these textures though.


> 
> FYI Maxim, please use mes...@li... instead.
Point taken, thanks!


Best regards,
Maxim Levitsky

Re: [Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures

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

On Sat, May 1, 2010 at 11:31 PM, Maxim Levitsky <max...@gm...>wrote:

> This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
> Compiz shows dark screen.
> (Using nouveau drivers)
>
> Without this commit compiz works almost perfectly.
>
> The error messages from compiz:
>
>
> debug_get_bool_option: NV50_ALWAYS_PUSH = FALSE
> debug_get_bool_option: DRAW_FSE = FALSE
> debug_get_bool_option: DRAW_NO_FSE = FALSE
> debug_get_bool_option: GALLIUM_DUMP_VS = FALSE
> Mesa: Mesa 7.9-devel DEBUG build May  1 2010 19:02:06
> Mesa warning: software DXTn compression/decompression available
> debug_get_bool_option: MESA_MVP_DP4 = FALSE
> debug_get_flags_option: ST_DEBUG = 0x0
> Mesa: User error: GL_OUT_OF_MEMORY in glTexImage
> compiz (cube) - Warn: Failed to load
> slide: /usr/share/gdm/themes/Human/ubuntu.png
> ^CMesa: User error: GL_OUT_OF_MEMORY in glTexImage
>

The commit also causes surface_copy to be called with S3TC textures,
breaking loading of such textures in r300g. I am working on a fix for r300g
but I haven't expected to get such weird formats in surface_copy.

FYI Maxim, please use mes...@li... instead.

-Marek

[Mesa3d-dev] mesa commit e648d4a1d1c0c5f70916e38366b863f0bec79a62 st/mesa: ignore gl_texture_object::BaseLevel when allocating gallium textures

[Maxim L. <max...@gm...>]

This commit breaks compiz completely here on nvidia G50 (Geforce 8400M)
Compiz shows dark screen.
(Using nouveau drivers)

Without this commit compiz works almost perfectly.

The error messages from compiz:


debug_get_bool_option: NV50_ALWAYS_PUSH = FALSE
debug_get_bool_option: DRAW_FSE = FALSE
debug_get_bool_option: DRAW_NO_FSE = FALSE
debug_get_bool_option: GALLIUM_DUMP_VS = FALSE
Mesa: Mesa 7.9-devel DEBUG build May  1 2010 19:02:06
Mesa warning: software DXTn compression/decompression available
debug_get_bool_option: MESA_MVP_DP4 = FALSE
debug_get_flags_option: ST_DEBUG = 0x0
Mesa: User error: GL_OUT_OF_MEMORY in glTexImage
compiz (cube) - Warn: Failed to load
slide: /usr/share/gdm/themes/Human/ubuntu.png
^CMesa: User error: GL_OUT_OF_MEMORY in glTexImage


Best regards,
Maxim Levitsky

[Mesa3d-dev] LLVM and udis86 dependencies

[Francis G. <fga...@gm...>]

In the current HEAD, in configure.ac:

----
1182-    [enable_gallium=yes])
1183-if test "x$enable_gallium" = xyes; then
1184-    SRC_DIRS="$SRC_DIRS gallium gallium/winsys gallium/targets"
1185:    AC_CHECK_HEADER([udis86.h], [HAS_UDIS86="yes"],
1186-                [HAS_UDIS86="no"])
1187-    AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no])
1188-fi
--
1340-   LLVM_LIBS="`$LLVM_CONFIG --libs jit interpreter nativecodegen
bitwriter` -lstdc++"
1341-
1342-   if test "x$HAS_UDIS86" != xno; then
1343:       LLVM_LIBS="$LLVM_LIBS -ludis86"
1344-       DEFINES="$DEFINES -DHAVE_UDIS86"
1345-   fi
1346-   LLVM_LDFLAGS=`$LLVM_CONFIG --ldflags`
----

This means basically that the udis86 dependency is "automagic" if you
elect to build with LLVM support.

I have a case here of a miscompiled udis86 (missing -fPIC, preventing
relocation) on a setup where LLVM was NOT compiled with udis86.

Would it be possible to make the udis86 dependency optional (ie,
--with-udis86 option to ./configure)?

-- 
Francis Galiegue, fga...@gm...
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

Re: [Mesa3d-dev] Mesa (gallium-msaa): gallium: interface changes for multisampling

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

On 26.04.2010 20:26, José Fonseca wrote:
> Hi Roland,
> 
> Overall looks good. It's nice to finally have a way to export MSAA
> capabilities, and see the pipe_surfaces use being more constrained.
> 
> A few comments inline, but no strong feelings so feel free to do as you
> wish.
>> diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c b/src/gallium/auxiliary/cso_cache/cso_context.c
>> index 6d0b420..50736f0 100644
>> --- a/src/gallium/auxiliary/cso_cache/cso_context.c
>> +++ b/src/gallium/auxiliary/cso_cache/cso_context.c
>> @@ -98,6 +98,7 @@ struct cso_context {
>>     struct pipe_framebuffer_state fb, fb_saved;
>>     struct pipe_viewport_state vp, vp_saved;
>>     struct pipe_blend_color blend_color;
>> +   unsigned sample_mask sample_mask;
> 
> This doesn't look correct. sample_mask appears twice.
Of course you're right. Since things don't compile yet I didn't notice :-).

>> +   void (*resource_fill_region)(struct pipe_context *pipe,
>> +                                struct pipe_resource *dst,
>> +                                struct pipe_subresource subdst,
>> +                                struct pipe_box *dstbox,
>> +                                unsigned srcx, unsigned srcy, unsigned srcz,
>> +                                unsigned width, unsigned height,
>> +                                unsigned value);
> 
> I think that once you're done with this change we should remove
> surface_fill/resource_fill_region(), as no state tracker uses it -- only
> drivers internally, and the 32bit value is hopeless for formats more
> than 32bits.
I wondered about the unsigned value too. One of the non-public state
trackers seems to use it though. It is a bit odd though, maybe we really
should find a way to express that in the clear function.

>> +    * Check if the given pipe_format is supported with a requested
>> +    * number of samples for msaa.
>> +    * \param sample_count number of samples for multisampling
>> +    */
>> +   boolean (*is_msaa_supported)( struct pipe_screen *,
>> +                                 enum pipe_format format,
>> +                                 unsigned sample_count );
> 
> Instead of a new is_msaa_support() I'd prefer see sample_count in
> is_format_supported or better, replace both with is_resource_supported
> which takes a resource template. But I understand that's a bit beyond
> the scope of this change.
Yes, that's what it first looked like. I don't feel strongly either way.
For reference, d3d10 has a CheckFormatSupport() query which will return
if a format supports multisampling (for rendertarget or for sampling) -
but no indication of sample count. Sample count (along with quality
levels) can be queried with CheckMultisampleQualityLevels(). I realize
our is_format_supported() query looks quite a bit different, so maybe
the approach you suggest with giving it a template is the right thing to do.


Roland

Re: [Mesa3d-dev] Mesa (gallium-msaa): gallium: interface changes for multisampling

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

Hi Roland,

Overall looks good. It's nice to finally have a way to export MSAA
capabilities, and see the pipe_surfaces use being more constrained.

A few comments inline, but no strong feelings so feel free to do as you
wish.

Jose

On Mon, 2010-04-26 at 11:05 -0700, Roland Scheidegger wrote:
> Module: Mesa
> Branch: gallium-msaa
> Commit: aac2cccccfd701ae8d7ce0813c28c64498d4a076
> URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=aac2cccccfd701ae8d7ce0813c28c64498d4a076
> 
> Author: Roland Scheidegger <sr...@vm...>
> Date:   Mon Apr 26 19:50:57 2010 +0200
> 
> gallium: interface changes for multisampling
> 
> add function to set sample mask, and state for alpha-to-coverage and
> alpha-to-one. Also make it possible to query for supported sample count
> with is_msaa_supported().
> 
> Use explicit resource_resolve() to resolve a resource. Note that it is illegal
> to bind a unresolved resource as a sampler view, must be resolved first (as per
> d3d10 and OGL APIs, binding unresolved resource would mean that special texture
> fetch functions need to be used which give explicit control over what samples
> to fetch, which isn't supported yet).
> 
> Also change surface_fill() and surface_copy() to operate directly on resources.
> Blits should operate directly on resources, most often state trackers just used
> get_tex_surface() then did a blit. Note this also means the blit bind flags are
> gone, if a driver implements this functionality it is expected to handle it for
> all resources having depth_stencil/render_target/sampler_view bind flags (might
> even require it for all bind flags?).
> 
> Might want to introduce quality levels for MSAA later.
> Might need to revisit this for hw which does instant resolve.
> 
> ---
> 
>  src/gallium/auxiliary/cso_cache/cso_context.c |   11 +++++
>  src/gallium/auxiliary/cso_cache/cso_context.h |    2 +
>  src/gallium/docs/source/context.rst           |   16 +++++--
>  src/gallium/docs/source/screen.rst            |   13 +++++-
>  src/gallium/include/pipe/p_context.h          |   51 +++++++++++++++++-------
>  src/gallium/include/pipe/p_defines.h          |    2 -
>  src/gallium/include/pipe/p_screen.h           |   11 +++++-
>  src/gallium/include/pipe/p_state.h            |    2 +
>  8 files changed, 82 insertions(+), 26 deletions(-)
> 
> diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c b/src/gallium/auxiliary/cso_cache/cso_context.c
> index 6d0b420..50736f0 100644
> --- a/src/gallium/auxiliary/cso_cache/cso_context.c
> +++ b/src/gallium/auxiliary/cso_cache/cso_context.c
> @@ -98,6 +98,7 @@ struct cso_context {
>     struct pipe_framebuffer_state fb, fb_saved;
>     struct pipe_viewport_state vp, vp_saved;
>     struct pipe_blend_color blend_color;
> +   unsigned sample_mask sample_mask;

This doesn't look correct. sample_mask appears twice.

>     struct pipe_stencil_ref stencil_ref, stencil_ref_saved;
>  };
> 
> @@ -984,6 +985,16 @@ enum pipe_error cso_set_blend_color(struct cso_context *ctx,
>     return PIPE_OK;
>  }
> 
> +enum pipe_error cso_set_sample_mask(struct cso_context *ctx,
> +                                    unsigned sample_mask)
> +{
> +   if (ctx->sample_mask != sample_mask) {
> +      ctx->sample_mask = sample_mask;
> +      ctx->pipe->set_sample_mask(ctx->pipe, sample_mask);
> +   }
> +   return PIPE_OK;
> +}
> +
>  enum pipe_error cso_set_stencil_ref(struct cso_context *ctx,
>                                      const struct pipe_stencil_ref *sr)
>  {
> diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h b/src/gallium/auxiliary/cso_cache/cso_context.h
> index d6bcb1f..f0b07f7 100644
> --- a/src/gallium/auxiliary/cso_cache/cso_context.h
> +++ b/src/gallium/auxiliary/cso_cache/cso_context.h
> @@ -159,6 +159,8 @@ void cso_restore_viewport(struct cso_context *cso);
>  enum pipe_error cso_set_blend_color(struct cso_context *cso,
>                                      const struct pipe_blend_color *bc);
> 
> +enum pipe_error cso_set_sample_mask(struct cso_context *cso,
> +                                    unsigned stencil_mask);
> 
>  enum pipe_error cso_set_stencil_ref(struct cso_context *cso,
>                                      const struct pipe_stencil_ref *sr);
> diff --git a/src/gallium/docs/source/context.rst b/src/gallium/docs/source/context.rst
> index c82e681..374711b 100644
> --- a/src/gallium/docs/source/context.rst
> +++ b/src/gallium/docs/source/context.rst
> @@ -54,6 +54,7 @@ objects. They all follow simple, one-method binding calls, e.g.
>  * ``set_stencil_ref`` sets the stencil front and back reference values
>    which are used as comparison values in stencil test.
>  * ``set_blend_color``
> +* ``set_sample_mask``
>  * ``set_clip_state``
>  * ``set_polygon_stipple``
>  * ``set_scissor_state`` sets the bounds for the scissor test, which culls
> @@ -255,15 +256,20 @@ Blitting
>  These methods emulate classic blitter controls. They are not guaranteed to be
>  available; if they are set to NULL, then they are not present.
> 
> -These methods operate directly on ``pipe_surface`` objects, and stand
> +These methods operate directly on ``pipe_resource`` objects, and stand
>  apart from any 3D state in the context.  Blitting functionality may be
>  moved to a separate abstraction at some point in the future.
> 
> -``surface_fill`` performs a fill operation on a section of a surface.
> +``resource_fill_region`` performs a fill operation on a section of a resource.
> 
> -``surface_copy`` blits a region of a surface to a region of another surface,
> -provided that both surfaces are the same format. The source and destination
> -may be the same surface, and overlapping blits are permitted.
> +``resource_copy_region`` blits a region of a subresource of a resource to a
> +region of another subresource of a resource, provided that both resources have the
> +same format. The source and destination may be the same resource, and overlapping
> +blits are permitted.
> +
> +``resource_resolve`` resolves a multisampled resource into a non-multisampled
> +one. Formats and dimensions must match. This function must be present if a driver
> +supports multisampling.
> 
>  The interfaces to these calls are likely to change to make it easier
>  for a driver to batch multiple blits with the same source and
> diff --git a/src/gallium/docs/source/screen.rst b/src/gallium/docs/source/screen.rst
> index c5815f8..2a8f696 100644
> --- a/src/gallium/docs/source/screen.rst
> +++ b/src/gallium/docs/source/screen.rst
> @@ -128,9 +128,6 @@ resources might be created and handled quite differently.
>  * ``PIPE_BIND_VERTEX_BUFFER``: A vertex buffer.
>  * ``PIPE_BIND_INDEX_BUFFER``: An vertex index/element buffer.
>  * ``PIPE_BIND_CONSTANT_BUFFER``: A buffer of shader constants.
> -* ``PIPE_BIND_BLIT_SOURCE``: A blit source, as given to surface_copy.
> -* ``PIPE_BIND_BLIT_DESTINATION``: A blit destination, as given to surface_copy
> -  and surface_fill.
>  * ``PIPE_BIND_TRANSFER_WRITE``: A transfer object which will be written to.
>  * ``PIPE_BIND_TRANSFER_READ``: A transfer object which will be read from.
>  * ``PIPE_BIND_CUSTOM``:
> @@ -223,6 +220,16 @@ Determine if a resource in the given format can be used in a specific manner.
> 
>  Returns TRUE if all usages can be satisfied.
> 
> +is_msaa_supported
> +^^^^^^^^^^^^^^^^^
> +
> +Determine if a format supports multisampling with a given number of samples.
> +
> +**format** the resource format
> +
> +**sample_count** the number of samples. Valid query range is 2-32.
> +
> +Returns TRUE if sample_count number of samples is supported with this format.
> 
>  .. _resource_create:
> 
> diff --git a/src/gallium/include/pipe/p_context.h b/src/gallium/include/pipe/p_context.h
> index 6f47845..c385481 100644
> --- a/src/gallium/include/pipe/p_context.h
> +++ b/src/gallium/include/pipe/p_context.h
> @@ -198,6 +198,9 @@ struct pipe_context {
>     void (*set_stencil_ref)( struct pipe_context *,
>                              const struct pipe_stencil_ref * );
> 
> +   void (*set_sample_mask)( struct pipe_context *,
> +                            unsigned sample_mask );
> +
>     void (*set_clip_state)( struct pipe_context *,
>                              const struct pipe_clip_state * );
> 
> @@ -233,32 +236,50 @@ struct pipe_context {
> 
> 
>     /**
> -    * Surface functions
> +    * Resource functions for blit-like functionality
>      *
>      * The pipe driver is allowed to set these functions to NULL, and in that
>      * case, they will not be available.
> +    * If a driver supports multisampling, resource_resolve must be available.
>      */
>     /*@{*/
> 
>     /**
> -    * Copy a block of pixels from one surface to another.
> -    * The surfaces must be of the same format.
> +    * Copy a block of pixels from one resource to another.
> +    * The resource must be of the same format.
> +    * Resources with nr_samples > 1 are not allowed.
>      */
> -   void (*surface_copy)(struct pipe_context *pipe,
> -                       struct pipe_surface *dest,
> -                       unsigned destx, unsigned desty,
> -                       struct pipe_surface *src,
> -                       unsigned srcx, unsigned srcy,
> -                       unsigned width, unsigned height);
> +   void (*resource_copy_region)(struct pipe_context *pipe,
> +                                struct pipe_resource *dst,
> +                                struct pipe_subresource subdst,
> +                                unsigned dstx, unsigned dsty, unsigned dstz,
> +                                struct pipe_resource *src,
> +                                struct pipe_subresource subsrc,
> +                                unsigned srcx, unsigned srcy, unsigned srcz,
> +                                unsigned width, unsigned height);
> 
>     /**
> -    * Fill a region of a surface with a constant value.
> +    * Fill a region of a resource with a constant value.
> +    * Resources with nr_samples > 1 are not allowed.
>      */
> -   void (*surface_fill)(struct pipe_context *pipe,
> -                       struct pipe_surface *dst,
> -                       unsigned dstx, unsigned dsty,
> -                       unsigned width, unsigned height,
> -                       unsigned value);
> +   void (*resource_fill_region)(struct pipe_context *pipe,
> +                                struct pipe_resource *dst,
> +                                struct pipe_subresource subdst,
> +                                struct pipe_box *dstbox,
> +                                unsigned srcx, unsigned srcy, unsigned srcz,
> +                                unsigned width, unsigned height,
> +                                unsigned value);

I think that once you're done with this change we should remove
surface_fill/resource_fill_region(), as no state tracker uses it -- only
drivers internally, and the 32bit value is hopeless for formats more
than 32bits.

> +
> +   /**
> +    * Resolve a multisampled resource into a non-multisampled one.
> +    * Source and destination must have the same size and same format.
> +    */
> +   void (*resource_resolve)(struct pipe_context *pipe,
> +                            struct pipe_resource *dst,
> +                            struct pipe_subresource subdst,
> +                            struct pipe_resource *src,
> +                            struct pipe_subresource subsrc);
> +
>     /*@}*/
> 
>     /**
> diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h
> index 48edfbf..3223e8d 100644
> --- a/src/gallium/include/pipe/p_defines.h
> +++ b/src/gallium/include/pipe/p_defines.h
> @@ -284,8 +284,6 @@ enum pipe_transfer_usage {
>  #define PIPE_BIND_VERTEX_BUFFER        (1 << 3) /* set_vertex_buffers */
>  #define PIPE_BIND_INDEX_BUFFER         (1 << 4) /* draw_elements */
>  #define PIPE_BIND_CONSTANT_BUFFER      (1 << 5) /* set_constant_buffer */
> -#define PIPE_BIND_BLIT_SOURCE          (1 << 6) /* surface_copy */
> -#define PIPE_BIND_BLIT_DESTINATION     (1 << 7) /* surface_copy, fill */
>  #define PIPE_BIND_DISPLAY_TARGET       (1 << 8) /* flush_front_buffer */
>  #define PIPE_BIND_TRANSFER_WRITE       (1 << 9) /* get_transfer */
>  #define PIPE_BIND_TRANSFER_READ        (1 << 10) /* get_transfer */
> diff --git a/src/gallium/include/pipe/p_screen.h b/src/gallium/include/pipe/p_screen.h
> index beff1ae..1bad045 100644
> --- a/src/gallium/include/pipe/p_screen.h
> +++ b/src/gallium/include/pipe/p_screen.h
> @@ -99,10 +99,19 @@ struct pipe_screen {
>     boolean (*is_format_supported)( struct pipe_screen *,
>                                     enum pipe_format format,
>                                     enum pipe_texture_target target,
> -                                   unsigned bindings,
> +                                   unsigned bindings,
>                                     unsigned geom_flags );
> 
>     /**
> +    * Check if the given pipe_format is supported with a requested
> +    * number of samples for msaa.
> +    * \param sample_count number of samples for multisampling
> +    */
> +   boolean (*is_msaa_supported)( struct pipe_screen *,
> +                                 enum pipe_format format,
> +                                 unsigned sample_count );

Instead of a new is_msaa_support() I'd prefer see sample_count in
is_format_supported or better, replace both with is_resource_supported
which takes a resource template. But I understand that's a bit beyond
the scope of this change.

> +   /**
>      * Create a new texture object, using the given template info.
>      */
>     struct pipe_resource * (*resource_create)(struct pipe_screen *,
> diff --git a/src/gallium/include/pipe/p_state.h b/src/gallium/include/pipe/p_state.h
> index a504757..f9ad07d 100644
> --- a/src/gallium/include/pipe/p_state.h
> +++ b/src/gallium/include/pipe/p_state.h
> @@ -218,6 +218,8 @@ struct pipe_blend_state
>     unsigned logicop_enable:1;
>     unsigned logicop_func:4;      /**< PIPE_LOGICOP_x */
>     unsigned dither:1;
> +   unsigned alpha_to_coverage:1;
> +   unsigned alpha_to_one:1;
>     struct pipe_rt_blend_state rt[PIPE_MAX_COLOR_BUFS];
>  };
> 
> 
> _______________________________________________
> mesa-commit mailing list
> mes...@li...
> http://lists.freedesktop.org/mailman/listinfo/mesa-commit

Re: [Mesa3d-dev] [r300g] BROKEN st/dri: state_tracker/st_atom_framebuffer.c:162:update_framebuffer_state: Assertion `framebuffer->zsbuf->texture->bind & (1 << 0)' failed.

[Sedat D. <sed...@go...>]

THX - Problem fixed.

- Sedat -

sd@seduxbox:~/src/mesa$ grep -A4 "git log" build.log
+ git log --pretty=short -1
commit a523b622036117e8bc1be0a1496d4368562e9702
Author: Jakob Bornecrantz <wal...@gm...>

    st/dri: DRI2 give proper binding to depth buffer


On Sat, Apr 24, 2010 at 12:42 PM, Jakob Bornecrantz
<wal...@gm...> wrote:
> On Sat, Apr 24, 2010 at 11:04 AM, Sedat Dilek
> <sed...@go...> wrote:
>> Hi,
>>
>> Backlog from #radeon/freenode (24-Apr-2010, German local-time UTC+2):
>> [...]
>> [11:49:16] <dileX> here I get w/ openaren and mesa (commit
>> 94b04d3d1ccd1b717dbc9d797341f1170121645a) compiled with --debug:
>> state_tracker/st_atom_framebuffer.c:162:update_framebuffer_state:
>> Assertion `framebuffer->zsbuf->texture->bind & (1 << 0)' failed.
>> [11:49:45] <dileX> commit 17249ae8e0e459dea250733a0b3e45036cdb67bd
>> "st/mesa: assert that binding flags are properly set for drawing
>> surfaces" seems to be culprit
>> [11:54:59] <dileX> that works: GALLIUM_ABORT_ON_ASSERT=false openarena
>> [...]
>> [11:59:27] <dileX> Reverting culprit commit lets openarena play with
>> r300g st/dri
>> [...]
>
> Should be fixed on master with commit: a523b622036117e8bc1be0a1496d4368562e9702
>
> Cheers Jakob.
>

Re: [Mesa3d-dev] [r300g] BROKEN st/dri: state_tracker/st_atom_framebuffer.c:162:update_framebuffer_state: Assertion `framebuffer->zsbuf->texture->bind & (1 << 0)' failed.

[Jakob B. <wal...@gm...>]

On Sat, Apr 24, 2010 at 11:04 AM, Sedat Dilek
<sed...@go...> wrote:
> Hi,
>
> Backlog from #radeon/freenode (24-Apr-2010, German local-time UTC+2):
> [...]
> [11:49:16] <dileX> here I get w/ openaren and mesa (commit
> 94b04d3d1ccd1b717dbc9d797341f1170121645a) compiled with --debug:
> state_tracker/st_atom_framebuffer.c:162:update_framebuffer_state:
> Assertion `framebuffer->zsbuf->texture->bind & (1 << 0)' failed.
> [11:49:45] <dileX> commit 17249ae8e0e459dea250733a0b3e45036cdb67bd
> "st/mesa: assert that binding flags are properly set for drawing
> surfaces" seems to be culprit
> [11:54:59] <dileX> that works: GALLIUM_ABORT_ON_ASSERT=false openarena
> [...]
> [11:59:27] <dileX> Reverting culprit commit lets openarena play with
> r300g st/dri
> [...]

Should be fixed on master with commit: a523b622036117e8bc1be0a1496d4368562e9702

Cheers Jakob.

[Mesa3d-dev] [r300g] BROKEN st/dri: state_tracker/st_atom_framebuffer.c:162:update_framebuffer_state: Assertion `framebuffer->zsbuf->texture->bind & (1 << 0)' failed.

[Sedat D. <sed...@go...>]

Hi,

Backlog from #radeon/freenode (24-Apr-2010, German local-time UTC+2):
[...]
[11:49:16] <dileX> here I get w/ openaren and mesa (commit
94b04d3d1ccd1b717dbc9d797341f1170121645a) compiled with --debug:
state_tracker/st_atom_framebuffer.c:162:update_framebuffer_state:
Assertion `framebuffer->zsbuf->texture->bind & (1 << 0)' failed.
[11:49:45] <dileX> commit 17249ae8e0e459dea250733a0b3e45036cdb67bd
"st/mesa: assert that binding flags are properly set for drawing
surfaces" seems to be culprit
[11:54:59] <dileX> that works: GALLIUM_ABORT_ON_ASSERT=false openarena
[...]
[11:59:27] <dileX> Reverting culprit commit lets openarena play with
r300g st/dri
[...]

- Sedat -

P.S.: OpenArena Logs and Revert-patch attached

[Mesa3d-dev] Compling Error after Gallium-Index-Bias merge

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

Hi all,
        After getting the latest commits this morning,I keep getting this
compilation error after the merge of gallium-index-bias:
TERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_XEXTPROTO_71 -DMAX_WIDTH=4096
-DMAX_HEIGHT=4096  nvfx_draw.c -o nvfx_draw.o
nvfx_draw.c: In function ‘nvfx_draw_elements_swtnl’:
nvfx_draw.c:261: error: ‘idx_bufbias’ undeclared (first use in this
function)
nvfx_draw.c:261: error: (Each undeclared identifier is reported only once
nvfx_draw.c:261: error: for each function it appears in.)
gmake[4]: *** [nvfx_draw.o] Error 1
gmake[4]: Leaving directory `/opt/mesa/src/gallium/drivers/nvfx'
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'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/opt/mesa/src'
make: *** [default] Error 1

I'm currently using Fedora Rawhide,I compile DRM,Linux-2.6 kernel
modules,Mesa,and the xf86-video-nouveau driver from git.

I have done gmake -B realclean, and then a git pull to get the latest
commits.The ./configure options I used to re-build Mesa after getting the
latest commits 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-max-width=4096
--with-max-height=4096 --enable-debug

Regards,
             STEVE555
-- 
View this message in context: http://old.nabble.com/Compling-Error-after-Gallium-Index-Bias-merge-tp28287840p28287840.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] [Bug 27628] glxgears prints bogus swap interval information

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

On Wed, 14 Apr 2010 17:57:07 +0200
Mario Kleiner <mar...@tu...> wrote:

> Hmm. The patch inits mesa's local cached copy of swap_interval to  
> zero. The DRI2CreateDrawable() function inside the xserver's xserver/ 
> hw/xfree86/dri2/dri2.c implementation inits its own copy of  
> swap_interval to 1, at least in the DRI2 patch series of Jesse and  
> mine that is supposed be pulled of the next x-server release.
> 
> So until client code calls glXSetSwapIntervalMESA() or  
> glXSetSwapIntervalSGI() the first time, the returned value will not  
> match the true setting.
> 
> Either we need to match the defaults, or propagate the mesa setting  
> to the server at drawable creation time, or query the server's  
> setting to init mesa's copy.

Got distracted by other things last week, but the fix is pushed now to
both 7.8 and master.

commit 385e2896ebf54ac0b016132fe513f21a5b67ba4f
Author: Jesse Barnes <jb...@vi...>
Date:   Mon Apr 19 09:54:08 2010 -0700

    DRI2: synchronize swap interval with server at startup time


-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Mesa3d-dev] to Implement on new GPUs

[Andreas P. <and...@gm...>]

Hi there,

You could try to contact OpenMoko Inc for specifications regarding
S3C6410. They forwarded the  specs  they received for their previous
device to developers that signed an NDA. Before they stopped plans to
develop another open linux phone, they were working with the S3C6410
platform. At least you can try ...

http://wiki.openmoko.org/wiki/GTA03_revisions

But maybe you already have detailed specifications about the 3D processor?

2010/4/15 nitesh suthar <nit...@gm...>:
>
>>GL and GLES are programming APIs, not hardware APIs. In order to
>>support your hardware, you will have to write a backend driver which
>>interfaces with that hardware for Mesa.
>
>   thanks,
>   yes I know these are programming APIs,
>  so how could I start developing this backend driver which interfaces with
> that hardware for Mesa. Is there any fix architecture to interface that
> driver to Mesa lib or mesa's function ?
> and What is procedure for implementing such interface in my backend driver
> so that
> it can interact with Mesa lib.

You would need a drm kernel driver, some extension to the drm to allow
platfrom devices to provde drm drivers - not only pci dvices. User
spaces parts of the DRM  module in libdrm for your hardware. ...
Something similar had been done for another embedded gpu: smedia
glamo:

 http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html

>>We're not all embedded developers, but some of us might be familiar
>>with your hardware. Which chipset and board is this?
> I am using SOC  S3C6410 .
> thanking you

regards
Andreas Pokorny

Re: [Mesa3d-dev] to Implement on new GPUs

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

On Thu, Apr 15, 2010 at 7:12 AM, nitesh suthar <nit...@gm...> wrote:
> I am using SOC  S3C6410 .

Google doesn't tell me much about this chip other than that it's made
by Samsung and it powers some Android devices. A few posts suggest
that it's either a Samsung original, or an SGX-based core.

If it's the latter, you are out of luck. SGX does not have any
open-source code or free datasheets, and they actively discourage
reverse-engineering by levying strong licensing requirements on their
binary drivers.

Your best bet at this stage may well be to contact Samsung.

At any rate, Mesa drivers are implemented by writing code that uses
the hooks in the general driver context. src/mesa/drivers are all the
drivers, and src/mesa/drivers/dri may be of particular use if you are
planning on doing GL with X.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

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

Re: [Mesa3d-dev] to Implement on new GPUs

[nitesh s. <nit...@gm...>]

>GL and GLES are programming APIs, not hardware APIs. In order to
>support your hardware, you will have to write a backend driver which
>interfaces with that hardware for Mesa.

  thanks,
  yes I know these are programming APIs,

 so how could I start developing this backend driver which interfaces with
that hardware for Mesa. Is there any fix architecture to interface that
driver to Mesa lib or mesa's function ?
and What is procedure for implementing such interface in my backend driver
so that
it can interact with Mesa lib.

>We're not all embedded developers, but some of us might be familiar
>with your hardware. Which chipset and board is this?

I am using SOC  S3C6410 .

thanking you
Nitesh Suthar



On Tue, Apr 13, 2010 at 11:27 PM, Corbin Simpson
<mos...@gm...>wrote:

> On Mon, Apr 12, 2010 at 9:13 PM, nitesh suthar <nit...@gm...>
> wrote:
> > hello all,
> > thank you for reply
> > Actually I am working on arm board which support OpenGLES 1.1 and
> OpenGLES
> > 2.0.
> > which provides hardware acceleration for redering images.
> > What my objective is that I want to implement this OpenGLES 2.0 into mesa
> > for interactive graphics with hardware acceleration to use Mesa in arm
> board
> > with this suppurted OpenGLES libraries.
> > how could I proceed for implement OpenGLES 2.0 in Mesa ?
>
> GL and GLES are programming APIs, not hardware APIs. In order to
> support your hardware, you will have to write a backend driver which
> interfaces with that hardware for Mesa.
>
> We're not all embedded developers, but some of us might be familiar
> with your hardware. Which chipset and board is this?
>
> ~ C.
>
> --
> When the facts change, I change my mind. What do you do, sir? ~ Keynes
>
> Corbin Simpson
> <Mos...@gm...>
>

Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

[RALOVICH, K. <kri...@gm...>]

On Wed, Apr 14, 2010 at 17:49, Eric Anholt <er...@an...> wrote:
> On Sun, 28 Mar 2010 17:52:16 -0400, RALOVICH, Kristóf <kri...@gm...> wrote:
>> Eric,
>>
>> please see the attached patch for piglit. The patch includes 2 new
>> tests based on the demos I provided for mesa.
>>
>> Let me know if I can further help!
>
> The main thing I'm concerned about is that you seem to be looking for
> pixel-precise results.  Do you expect that from this code?  Generally in
> piglit we try to construct some environment that gets a few consistent
> results and probe a few representative pixels out of it.

I'll update the patch based on Brian's conclusion to address this.

>
> Beyond that, since you didn't use git send-email, the patch came out
> mangled and I couldn't apply it to try it out.
>

The patch is actually an attachment to the email. Try saving it as
that, not copy-pasting from the email's text.

Kristof

Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

[Eric A. <er...@an...>]

On Sun, 28 Mar 2010 17:52:16 -0400, RALOVICH, Kristóf <kri...@gm...> wrote:
> Eric,
> 
> please see the attached patch for piglit. The patch includes 2 new
> tests based on the demos I provided for mesa.
> 
> Let me know if I can further help!

The main thing I'm concerned about is that you seem to be looking for
pixel-precise results.  Do you expect that from this code?  Generally in
piglit we try to construct some environment that gets a few consistent
results and probe a few representative pixels out of it.

Beyond that, since you didn't use git send-email, the patch came out
mangled and I couldn't apply it to try it out.

Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

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

Suppose a ray just barely hits/misses a sphere.  Depending on the GPU 
arithmetic and whether the outcome is a hit or miss, the resulting 
pixel color could be completely different.

A per-pixel error margin won't account for this.  But as you 
suggested, if you allow a certain number or percent of pixel 
comparisons to fail, that might do the job here.

How about implementing that?  I'd also suggest putting the comparison 
code into a new piglit utility function (or at least put the code in a 
separate function that could be promoted to piglit-util.c someday).

BTW, the piglit_probe_pixel_rgb() function should really take a 
tolerance parameter, rather than it being hard-coded inside the 
function.  Another piglit utility function to compute tolerances from 
various parameters would be good... but that's another project.

-Brian


RALOVICH, Kristóf wrote:
> Brian,
> 
> you are right, maybe more freedom should be allowed, but
> piglit_probe_pixel_rgb() already uses 0.01 as threshold which should
> be enough if the ray directions do not have large FP differences.
> 
> As a short term goal with the test vsraytrace was, that it should not
> take my GM4500 down.
> 
> As a longer term solution we can allow e.g. 15% of pixels to even fail
> piglit_probe_pixel_rgb() too. I can extend the patch with this if
> you'd like it.
> 
> Kristof
> 
> On Wed, Apr 14, 2010 at 16:49, Brian Paul <br...@vm...> wrote:
>> It looks like the piglit tests use an image comparison to determine
>> pass/fail, right?
>>
>> That may not be too reliable since different drivers will produce slightly
>> different results.
>>
>> Is there any way that the rendering can be checked for correctness without
>> relying on an exact image comparison?
>>
>> -Brian
>>
>>
>> RALOVICH, Kristóf wrote:
>>> Would someone please have a look at this piglit tests?
>>>
>>> Thanks,
>>> Kristof
>>>
>>> On Sun, Mar 28, 2010 at 17:52, RALOVICH, Kristóf
>>> <kri...@gm...> wrote:
>>>> Eric,
>>>>
>>>> please see the attached patch for piglit. The patch includes 2 new
>>>> tests based on the demos I provided for mesa.
>>>>
>>>> Let me know if I can further help!
>>>>
>>>> Thanks,
>>>> Kristof
>>>>
>>>> On Wed, Mar 24, 2010 at 16:33, Eric Anholt <er...@an...> wrote:
>>>>> On Wed, 24 Mar 2010 11:10:47 -0400, RALOVICH, Kristóf
>>>>> <kri...@gm...> wrote:
>>>>>> Brian,
>>>>>>
>>>>>> that was fast! Who do you think I should bug, to get these working on
>>>>>> i965?
>>>>>>
>>>>>> Also as my time allows, I am planning to extend them with mouse input
>>>>>> for orientation and arrow keys for moving to camera to become more
>>>>>> interactive.
>>>>> Make a testcase for piglit, and I'd love to fix your bug.
>>>>>
>>

Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

[RALOVICH, K. <kri...@gm...>]

Brian,

you are right, maybe more freedom should be allowed, but
piglit_probe_pixel_rgb() already uses 0.01 as threshold which should
be enough if the ray directions do not have large FP differences.

As a short term goal with the test vsraytrace was, that it should not
take my GM4500 down.

As a longer term solution we can allow e.g. 15% of pixels to even fail
piglit_probe_pixel_rgb() too. I can extend the patch with this if
you'd like it.

Kristof

On Wed, Apr 14, 2010 at 16:49, Brian Paul <br...@vm...> wrote:
> It looks like the piglit tests use an image comparison to determine
> pass/fail, right?
>
> That may not be too reliable since different drivers will produce slightly
> different results.
>
> Is there any way that the rendering can be checked for correctness without
> relying on an exact image comparison?
>
> -Brian
>
>
> RALOVICH, Kristóf wrote:
>>
>> Would someone please have a look at this piglit tests?
>>
>> Thanks,
>> Kristof
>>
>> On Sun, Mar 28, 2010 at 17:52, RALOVICH, Kristóf
>> <kri...@gm...> wrote:
>>>
>>> Eric,
>>>
>>> please see the attached patch for piglit. The patch includes 2 new
>>> tests based on the demos I provided for mesa.
>>>
>>> Let me know if I can further help!
>>>
>>> Thanks,
>>> Kristof
>>>
>>> On Wed, Mar 24, 2010 at 16:33, Eric Anholt <er...@an...> wrote:
>>>>
>>>> On Wed, 24 Mar 2010 11:10:47 -0400, RALOVICH, Kristóf
>>>> <kri...@gm...> wrote:
>>>>>
>>>>> Brian,
>>>>>
>>>>> that was fast! Who do you think I should bug, to get these working on
>>>>> i965?
>>>>>
>>>>> Also as my time allows, I am planning to extend them with mouse input
>>>>> for orientation and arrow keys for moving to camera to become more
>>>>> interactive.
>>>>
>>>> Make a testcase for piglit, and I'd love to fix your bug.
>>>>
>
>

Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

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

It looks like the piglit tests use an image comparison to determine 
pass/fail, right?

That may not be too reliable since different drivers will produce 
slightly different results.

Is there any way that the rendering can be checked for correctness 
without relying on an exact image comparison?

-Brian


RALOVICH, Kristóf wrote:
> Would someone please have a look at this piglit tests?
> 
> Thanks,
> Kristof
> 
> On Sun, Mar 28, 2010 at 17:52, RALOVICH, Kristóf
> <kri...@gm...> wrote:
>> Eric,
>>
>> please see the attached patch for piglit. The patch includes 2 new
>> tests based on the demos I provided for mesa.
>>
>> Let me know if I can further help!
>>
>> Thanks,
>> Kristof
>>
>> On Wed, Mar 24, 2010 at 16:33, Eric Anholt <er...@an...> wrote:
>>> On Wed, 24 Mar 2010 11:10:47 -0400, RALOVICH, Kristóf <kri...@gm...> wrote:
>>>> Brian,
>>>>
>>>> that was fast! Who do you think I should bug, to get these working on i965?
>>>>
>>>> Also as my time allows, I am planning to extend them with mouse input
>>>> for orientation and arrow keys for moving to camera to become more
>>>> interactive.
>>> Make a testcase for piglit, and I'd love to fix your bug.
>>>

Re: [Mesa3d-dev] [PATCH] softpipe: Fix division by zero

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

Arpad Borsos wrote:
> Sorry about my last mail which was empty except for the attached patch.
> The patch fixes a division by zero crash which is triggered when I run 
> the cairo test-suite using its gl backend and the gallium softpipe driver.
> The test-suite still crashes when I'm using llvmpipe, need to look into 
> that.

Thanks.  I'm committing to the 7.8 branch.

Just FYI: the divide by zero results in an inf value here and there 
but it doesn't seem to effect the rendering outcome (though I've never 
tested with cairo).

-Brian

Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos

[RALOVICH, K. <kri...@gm...>]

Would someone please have a look at this piglit tests?

Thanks,
Kristof

On Sun, Mar 28, 2010 at 17:52, RALOVICH, Kristóf
<kri...@gm...> wrote:
> Eric,
>
> please see the attached patch for piglit. The patch includes 2 new
> tests based on the demos I provided for mesa.
>
> Let me know if I can further help!
>
> Thanks,
> Kristof
>
> On Wed, Mar 24, 2010 at 16:33, Eric Anholt <er...@an...> wrote:
>> On Wed, 24 Mar 2010 11:10:47 -0400, RALOVICH, Kristóf <kri...@gm...> wrote:
>>> Brian,
>>>
>>> that was fast! Who do you think I should bug, to get these working on i965?
>>>
>>> Also as my time allows, I am planning to extend them with mouse input
>>> for orientation and arrow keys for moving to camera to become more
>>> interactive.
>>
>> Make a testcase for piglit, and I'd love to fix your bug.
>>
>

Re: [Mesa3d-dev] [Bug 27628] glxgears prints bogus swap interval information

[Mario K. <mar...@tu...>]

Hmm. The patch inits mesa's local cached copy of swap_interval to  
zero. The DRI2CreateDrawable() function inside the xserver's xserver/ 
hw/xfree86/dri2/dri2.c implementation inits its own copy of  
swap_interval to 1, at least in the DRI2 patch series of Jesse and  
mine that is supposed be pulled of the next x-server release.

So until client code calls glXSetSwapIntervalMESA() or  
glXSetSwapIntervalSGI() the first time, the returned value will not  
match the true setting.

Either we need to match the defaults, or propagate the mesa setting  
to the server at drawable creation time, or query the server's  
setting to init mesa's copy.

thanks,
-mario

On Apr 14, 2010, at 4:16 PM, bug...@fr... wrote:

> https://bugs.freedesktop.org/show_bug.cgi?id=27628
>
> Kristian Høgsberg <kr...@bi...> changed:
>
>            What    |Removed                     |Added
> ---------------------------------------------------------------------- 
> ------
>              Status|NEW                         |RESOLVED
>          Resolution|                            |FIXED
>
> --- Comment #2 from Kristian Høgsberg <kr...@bi...>  
> 2010-04-14 07:16:11 PDT ---
> Thanks, looks good. Committed:
>
> commit 0863c7e499a553c2d8e7bcbd09c5de88e396fcd0
> Author: Michael Schmidt <msc...@re...>
> Date:   Wed Apr 14 10:12:42 2010 -0400
>
>     Initialize DRI2 swap interval to 0
>
>     https://bugs.freedesktop.org/show_bug.cgi?id=27628
>
> -- 
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi? 
> tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
> ---------------------------------------------------------------------- 
> --------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany

e-mail: mar...@tu...
office: +49 (0)7071/601-1623
fax:    +49 (0)7071/601-616
www:    http://www.kyb.tuebingen.mpg.de/~kleinerm
*********************************************************************
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)