Re: Mesa llvmpipe for WebGL software rendering

----- Original Message -----
> On Tue, 28 Feb 2012 09:08:39 -0800 (PST), Benoit Jacob
> <bjacob <at> mozilla.com> wrote:
> > Hi List,
> > 
> > At Mozilla we've been wondering if we could get a good software
> > fallback for users who can't get hardware-accelerated WebGL. Mesa
> > llvmpipe seems like the best open source OpenGL renderer, right?
> > At least, it performed superbly in our quick tests.
> > 
> > Questions:
> >  
> >  1. Is it possible for the application to choose between Mesa
> >  renderers? Ideally I would like to be able to evaluate the driver
> >  blacklist, and depending on that, use either the default renderer
> >  or Mesa llvmpipe. Is that possible?
> > 
> >  2. Related question: are you planning to update OSMesa, base it on
> >  llvmpipe? Last I checked, OSMesa was based on swrast from an old
> >  Mesa
> >  version. An updated OSMesa would offer a great solution to
> >  question
> >  1.
> 
> I'd rather see us create a software-only EGL platform.  It seems like
> it
> ought to be easier to maintain than the special OSMesa system that
> developers other than Brian Paul break, and provides a better-known
> API

Re: [PATCH 12/21] r600g: permit blitting between textures with STREAM and STAGING usage

2012/2/29 Christian König <deathsimple <at> vodafone.de>:
> On 29.02.2012 17:53, Marek Olšák wrote:
>>
>> Why this wasn't allowed is beyond me.
>
> Because that resulted in allot better performance.
>
> It doesn't make much sense to let the driver blit the content of a texture
> into a tilled version and make a single draw and then throw away that tilled
> version before the next draw.
>
> So either leave the test there or move it into r600_texture_create, but
> don't remove it altogether.

Ah, so you want to disable tiling for staging and stream usage cases,
not blitting. That makes sense.

However blitting between non-tiled textures in our transfer path is
completely valid and recommended if the transfer is write-only and
mapping would require synchronization (flush + bo_wait). In such a
case, the blit will almost always be faster regardless of whether
tiling is enabled or not.

Marek
_______________________________________________
mesa-dev mailing list
mesa-dev <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: Mesa llvmpipe for WebGL software rendering

----- Original Message -----
> On Die, 2012-02-28 at 09:08 -0800, Benoit Jacob wrote:
> > 
> > At Mozilla we've been wondering if we could get a good software
> > fallback for users who can't get hardware-accelerated WebGL. Mesa
> > llvmpipe seems like the best open source OpenGL renderer, right? At
> > least, it performed superbly in our quick tests.
> 
> [...]
> 
> > 3. On GNU/Linux: why isn't Mesa llvmpipe installed by default by
> > most
> > distros? Is there a real reason or is it just that nobody asked for
> > it, or nobody saw a need for it? Trying to figure if llvmpipe
> > installed by default everywhere (on Linux) is something we can
> > realistically hope for.
> 
> One thing to keep in mind for this is that llvmpipe currently doesn't
> work on PowerPC architectures

PowerPC is not a big concern for us.
https://developer.mozilla.org/en/Supported_build_configurations

Besides x86 and x86-64, the other arch we care about is ARM (v7 and soon v6 too).

Cheers
Benoit

Re: Mesa llvmpipe for WebGL software rendering

----- Original Message -----
> I think the old Mesa software renderer
> is faster for some fixed function cases, as it has special hand
> written paths for that.

Not a concern for us: WebGL doesn't expose, or rely on, the fixed function API. It stays close to OpenGL ES 2.

Cheers,
Benoit

[PATCH] mesa: Strip texture border for proxy texture as well

Intel and Gallium drivers don't support texture borders. Border is stripped
before texture is used inside the driver. So, glGetTexLevelParameteriv()
returns the stripped values of texture dimensions. But it returns un-
stripped values for proxy textures. This patch adds strip_texture_border()
for proxy textures as well.

Signed-off-by: Anuj Phogat <anuj.phogat <at> gmail.com>
---
A piglit test case for this patch will be posted on piglit mailing list
for review.

 src/mesa/main/teximage.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index b8ff67e..5a2ef70 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
 <at>  <at>  -2543,6 +2543,15  <at>  <at>  teximage(struct gl_context *ctx, GLuint dims,
       }
       else {
          /* no error, set the tex image parameters */
+
+	 /* Allow a hardware driver to just strip out the border, to provide
+	  * reliable but slightly incorrect hardware rendering instead of
+	  * rarely-tested software fallback rendering.
+	  */
+	 if (border && ctx->Const.StripTextureBorder)
+	    strip_texture_border(target, &border, &width, &height, &depth, unpack,
+				 &unpack_no_border);

Re: [PATCH] mesa: Fix an issue with texture border in strip_texture_border()

On Wed, Feb 29, 2012 at 3:07 PM, Anuj Phogat <anuj.phogat <at> gmail.com> wrote:
> Border only applies to the width for a 1D texture array and for a 2D
> texture array the it applies to the width and height but not to the
> depth.  This was not handled correctly in strip_texture_border().
>
> v2: height is also affected by border if target is GL_TEXTURE_3D
>
> Note: This is a candidate for stable branches
>
> Signed-off-by: Anuj Phogat <anuj.phogat <at> gmail.com>
> ---
> A piglit test case for this patch will be posted on piglit mailing list.
>
>  src/mesa/main/teximage.c |   57 +++++++++++++++++++++++++++++++++++++--------
>  1 files changed, 47 insertions(+), 10 deletions(-)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index 5328ae2..b8ff67e 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
>  <at>  <at>  -2426,7 +2426,7  <at>  <at>  _mesa_choose_texture_format(struct gl_context *ctx,
>  * \param unpackNew returns the new pixel unpack parameters
>  */
>  static void
> -strip_texture_border(GLint *border,
> +strip_texture_border(GLenum target, GLint *border,
>                      GLint *width, GLint *height, GLint *depth,
>                      const struct gl_pixelstore_attrib *unpack,
>                      struct gl_pixelstore_attrib *unpackNew)
>  <at>  <at>  -2442,17 +2442,54  <at>  <at>  strip_texture_border(GLint *border,

Re: [PATCH] mesa: Fix an issue with texture border in strip_texture_border()

On Wed, 29 Feb 2012 14:07:36 -0800, Anuj Phogat <anuj.phogat <at> gmail.com> wrote:
> Border only applies to the width for a 1D texture array and for a 2D
> texture array the it applies to the width and height but not to the
> depth.  This was not handled correctly in strip_texture_border().
> 
> v2: height is also affected by border if target is GL_TEXTURE_3D

It seems like the patch would be a lot shorter if you just special-cased
texture arrays in the previous code instead of adding the big switch
statement.

_______________________________________________
mesa-dev mailing list
mesa-dev <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

[PATCH] mesa: handle array textures in strip_texture_border()

If the texture is a 1D array, don't remove the border pixel from the
height.  Similarly for 2D array textures and the depth direction.
Simplify the function by assuming the border is always one pixel.
---
 src/mesa/main/teximage.c |   37 ++++++++++++++++++++-----------------
 1 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 4fb81e6..29d1d36 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
 <at>  <at>  -2422,7 +2422,7  <at>  <at>  _mesa_choose_texture_format(struct gl_context *ctx,

 /**
  * Adjust pixel unpack params and image dimensions to strip off the
- * texture border.
+ * one-pixel texture border.
  *
  * Gallium and intel don't support texture borders.  They've seldem been used
  * and seldom been implemented correctly anyway.
 <at>  <at>  -2430,34 +2430,37  <at>  <at>  _mesa_choose_texture_format(struct gl_context *ctx,
  * \param unpackNew returns the new pixel unpack parameters
  */
 static void
-strip_texture_border(GLint *border,
+strip_texture_border(GLenum target,
                      GLint *width, GLint *height, GLint *depth,
                      const struct gl_pixelstore_attrib *unpack,
                      struct gl_pixelstore_attrib *unpackNew)
 {

Re: [PATCH] mesa: Strip texture border for proxy texture as well

On Wed, Feb 29, 2012 at 6:44 PM, Anuj Phogat <anuj.phogat <at> gmail.com> wrote:
> Intel and Gallium drivers don't support texture borders. Border is stripped
> before texture is used inside the driver. So, glGetTexLevelParameteriv()
> returns the stripped values of texture dimensions. But it returns un-
> stripped values for proxy textures. This patch adds strip_texture_border()
> for proxy textures as well.
>
> Signed-off-by: Anuj Phogat <anuj.phogat <at> gmail.com>
> ---
> A piglit test case for this patch will be posted on piglit mailing list
> for review.
>
>  src/mesa/main/teximage.c |    9 +++++++++
>  1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
> index b8ff67e..5a2ef70 100644
> --- a/src/mesa/main/teximage.c
> +++ b/src/mesa/main/teximage.c
>  <at>  <at>  -2543,6 +2543,15  <at>  <at>  teximage(struct gl_context *ctx, GLuint dims,
>       }
>       else {
>          /* no error, set the tex image parameters */
> +
> +        /* Allow a hardware driver to just strip out the border, to provide
> +         * reliable but slightly incorrect hardware rendering instead of
> +         * rarely-tested software fallback rendering.
> +         */
> +        if (border && ctx->Const.StripTextureBorder)
> +           strip_texture_border(target, &border, &width, &height, &depth, unpack,

[PATCH 1/3] mesa: add _mesa_rebase_rgba_float/uint() functions

These will be used by glReadPixels() and glGetTexImage() to fix issues
with reading GL_LUMINANCE and other formats.
---
 src/mesa/main/pack.c |   91 ++++++++++++++++++++++++++++++++++++++++++++++++++
 src/mesa/main/pack.h |    7 ++++
 2 files changed, 98 insertions(+), 0 deletions(-)

diff --git a/src/mesa/main/pack.c b/src/mesa/main/pack.c
index 41485a1..4d4b4a8 100644
--- a/src/mesa/main/pack.c
+++ b/src/mesa/main/pack.c
 <at>  <at>  -5250,3 +5250,94  <at>  <at>  _mesa_unpack_image( GLuint dimensions,
    }
 }

+
+
+/**
+ * If we unpack colors from a luminance surface, we'll get pixel colors
+ * such as (l, l, l, a).
+ * When we call _mesa_pack_rgba_span_float(format=GL_LUMINANCE), that
+ * function will compute L=R+G+B before packing.  The net effect is we'll
+ * accidentally store luminance values = 3*l.
+ * This function compensates for that by converting (aka rebasing) (l,l,l,a)
+ * to be (l,0,0,a).
+ * It's a similar story for other formats such as LUMINANCE_ALPHA, ALPHA
+ * and INTENSITY.
+ *
+ * Finally, we also need to do this when the actual surface format does
+ * not match the logical surface format.  For example, suppose the user