mesa3d-dev

Re: [Mesa3d-dev] [PATCH] glsl: optimize sqrt

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

On 29.03.2010 04:50, Marek Olšák wrote:
>  We were talking a bit on IRC that the GLSL compiler implements the sqrt
> function somewhat inefficiently. Instead of rsq+rcp+cmp instructions as
> is in the original code, the proposed patch uses just rsq+mul. Please
> see the patch log for further explanation, and please review.

I'll definitely agree with the mul instead of rcp part, as that should
be more efficient on a lot of modern hardware (rcp usually being part of
some special function block instead of main alu).
As far as I can tell though we still need the cmp unfortunately, since
invsqrt(0) is infinite and multiplying by 0 will give some undefined
result, for IEEE it should be NaN (well depending on hardware I guess,
if you have implementation which clamps infinity to its max
representable number it should be ok). In any case, glsl says invsqrt(0)
is undefined, hence can't rely on this.
Thinking about it, we'd possibly want a SQRT opcode, both in mesa and
tgsi. Because there's actually hardware which can do sqrt (i965
MathBox), and just as importantly because this gives drivers a way to
implement this as invsqrt + mul without the cmp, if they can. For
instance AMD hardware generally has 3 rounding modes for these ops,
"IEEE" (which gives infinity for invsqrt(0)), "DX" (clamps to
MAX_FLOAT), and "FF" (which clamps infinity to 0, exactly what you need
to implement sqrt with a mul and invsqrt and no cmp - though actually it
should work with "DX" clamping as well).

Roland




> -Marek
> 
> 
> ------------------------------------------------------------------------
> 
> From 9b834a79a1819f3b4b9868be3e2696667791c83e Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= <ma...@gm...>
> Date: Sat, 27 Mar 2010 13:49:09 +0100
> Subject: [PATCH] glsl: optimize sqrt
> 
> The new version can be derived from sqrt as follows:
> 
> sqrt(x) =
> sqrt(x)^2 / sqrt(x) =
> x / sqrt(x) =
> x * rsqrt(x)
> 
> Also the need for the CMP instruction is gone because there is no division
> by zero.
> ---
>  .../shader/slang/library/slang_common_builtin.gc   |   22 +++----------------
>  1 files changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/src/mesa/shader/slang/library/slang_common_builtin.gc b/src/mesa/shader/slang/library/slang_common_builtin.gc
> index a25ca55..3f6596c 100644
> --- a/src/mesa/shader/slang/library/slang_common_builtin.gc
> +++ b/src/mesa/shader/slang/library/slang_common_builtin.gc
> @@ -602,50 +602,36 @@ vec4 exp2(const vec4 a)
>  
>  float sqrt(const float x)
>  {
> -   const float nx = -x;
>     float r;
>     __asm float_rsq r, x;
> -   __asm float_rcp r, r;
> -   __asm vec4_cmp __retVal, nx, r, 0.0;
> +   __retVal = r * x;
>  }
>  
>  vec2 sqrt(const vec2 x)
>  {
> -   const vec2 nx = -x, zero = vec2(0.0);
>     vec2 r;
>     __asm float_rsq r.x, x.x;
>     __asm float_rsq r.y, x.y;
> -   __asm float_rcp r.x, r.x;
> -   __asm float_rcp r.y, r.y;
> -   __asm vec4_cmp __retVal, nx, r, zero;
> +   __retVal = r * x;
>  }
>  
>  vec3 sqrt(const vec3 x)
>  {
> -   const vec3 nx = -x, zero = vec3(0.0);
>     vec3 r;
>     __asm float_rsq r.x, x.x;
>     __asm float_rsq r.y, x.y;
>     __asm float_rsq r.z, x.z;
> -   __asm float_rcp r.x, r.x;
> -   __asm float_rcp r.y, r.y;
> -   __asm float_rcp r.z, r.z;
> -   __asm vec4_cmp __retVal, nx, r, zero;
> +   __retVal = r * x;
>  }
>  
>  vec4 sqrt(const vec4 x)
>  {
> -   const vec4 nx = -x, zero = vec4(0.0);
>     vec4 r;
>     __asm float_rsq r.x, x.x;
>     __asm float_rsq r.y, x.y;
>     __asm float_rsq r.z, x.z;
>     __asm float_rsq r.w, x.w;
> -   __asm float_rcp r.x, r.x;
> -   __asm float_rcp r.y, r.y;
> -   __asm float_rcp r.z, r.z;
> -   __asm float_rcp r.w, r.w;
> -   __asm vec4_cmp __retVal, nx, r, zero;
> +   __retVal = r * x;
>  }
>  
>  
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] gallium cached bufmgr busy change

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

On Tue, 2010-03-23 at 02:07 -0700, Dave Airlie wrote:
> On Mon, Mar 8, 2010 at 5:51 PM, Jose Fonseca <jfo...@vm...> wrote:
> > Dave,
> >
> > I don't oppose this new method -- it shouldn't be necessary to add fencing just to use pb_cache --,  but this method adds a new way of doing the same thing.
> >
> > Does the underlying buffer support PIPE_BUFFER_USAGE_DONT_BLOCK? If so what about doing:
> >
> > boolean
> > pb_cache_is_buffer_compat()
> > {
> >     void map;
> >
> >     map = pb_map(buf->buffer, PIPE_BUFFER_USAGE_DONT_BLOCK | PIPE_BUFFER);
> >     if (map) {
> >        /* TODO: cache the map value for the first map */
> >        pb_unmap(buf->buffer);
> >        return TRUE;
> >     }
> >
> >     return FALSE;
> > }
> 
> Hi Jose
> 
> I've used your scheme but I'm not sure 100% of its correctness since
> we might expect
> different behaviour from maps that are referenced in flushed command
> streams and maps
> referenced in the current command stream. I've pushed the r300g bits
> that do it correctly and
> we haven't seen any regressions.

Hi Dave,

I'm fine with adding an is_busy method as your original implementation
if you find it useful.  And we could provide a default implementation
thatr uses  PIPE_BUFFER_USAGE_DONT_BLOCK map/unmap to check.

> So my next bit is to bail out after is_busy check to avoid kernel
> overheads for checking all
> the buffers, but I'm a bit worried it might change behaviour of the
> fenced/cached use case,
> so I'd appreciate a bit of a review of it.

It looks good to me. 

It would benefit readability to split the is_busy parts of
pb_cache_is_buffer_compat() into a new pb_cache_is_buffer_busy()
function but it is purely cosmetic.

> If this isn't possible I'm tempted to create pb_bufmgr_busy_cached and
> do it all there,
> I think nouveau could use something similiar.

I don't know if it's still relevant given your patch looks good to me,
but if so what would this pb_bufmgr_busy_cached function do exactly?

Jose

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

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

On Mon, Mar 29, 2010 at 1:20 AM, SpliFF <sp...@wa...> wrote:
> On 03/29/10 17:06, Ian Romanick wrote:
>> SpliFF wrote:
>> > So to clarify, you're saying a partial implementation (decoder only)
>> > isn't an option at all? If you expose an extension it must be complete?
>>
>> See the documentation for glGetCompressedTexImage.
>
> That does not appear to imply a run-time encoder. It seems to imply the
> data is already compressed - which could (and really should) be done
> prior to distribution (via the nvidia tools for example). The
> documentation does quite clearly state that the application should
> verify the texture really was compressed so you're only going to run
> into issues when the programmer made assumptions about the supported
> hardware. Not saying that's impossible, just that that's the
> programmers' responsibility, not the drivers.
>
> Runtime compression is actually performed by glTexImage2D with its
> internalFormat set to a supported *_S3TC_* value, however the 2.1 spec says:
>
> "If no corresponding internal format is available, or the GL can not
> compress that image for any reason, the internal format is instead
> replaced with a corresponding base internal format."
>
> For S3TC textures that is:
>
> GL_COMPRESSED_RGB_S3TC_DXT1_EXT  -> RGB
> GL_COMPRESSED_RGBA_S3TC_DXT1_EXT ->  RGBA
> GL_COMPRESSED_RGBA_S3TC_DXT3_EXT ->  RGBA
> GL_COMPRESSED_RGBA_S3TC_DXT5_EXT ->  RGBA
>
> So the spec specifically says you don't need runtime compression to be
> compliant, you can fall back to uncompressed and hide the distinction
> from the application (or expose it via glGetTexLevelParameteriv). Also,
> for the purpose of mesa3d software rendering, why would you really want
> to compress an image intended for system RAM? Chances are you'd lose
> significantly on rendering performance. The way I see it the worst case
> scenario is you use more memory than the developer intended but at least
> you're displaying the textures. I know from experience that any normal
> game rendered entirely without textures is basically unplayable.
>
> So really, what I'd like clarification on is whether anyone knows of
> potential non-infringing workarounds for the independent claims of the
> s3tc decoding process only (claims 5, 16, 21 and 22 in the patent). The
> rest (encoding) isn't as important as there are already free licensed
> tools available for that part (not to mention existing compressed assets
> to be rendered).
>
> Finally, if anyone on the nouveau/radeonhd lists would prefer I stop
> posting there please email me privately and I'll comply. If hardware
> passthrough of s3tc textures is in fact supported by those drivers (and
> the user has compatible hardware) then s3tc decoding is less relevant
> for that purpose and the discussion is really only relevant to mesa3d
> software rendering. I'm new to these lists and I didn't come here just
> to make people upset. I don't know how much crossover exists between the
> groups and who is getting three copies of these posts.

Un-CCing nouveau and radeonhd; the former are all subscribed here, and
the latter isn't a 3D driver list.

After re-reading ARB_texture_compression, it does seem like it is
legal for extensions such as EXT_texture_compression_s3tc to fall
back, using a basic mechanism: glGetTexLevelParameter can return
GL_FALSE for GL_TEXTURE_COMPRESSED_ARB (now GL_TEXTURE_COMPRESSED) if
the texture could not successfully be compressed. Issue (10) of
ARB_texture_compression deals with this explicitly:

"""
    (10) Should functionality be provided to allow applications to save
    compressed images to disk and reuse them in subsequent runs without
    programming to specific formats?  If so, how?

      RESOLVED:  Yes.  This can be done without knowledge of specific
      compression formats in the following manner:

        * Call TexImage with an uncompressed image and a generic compressed
          internal format.  The texture image will be compressed by the GL, if
          possible.

        * Call GetTexLevelParameteriv with a <value> of TEXTURE_COMPRESSED_ARB
          to determine if the GL was able to store the image in compressed
          form.

        * Call GetTexLevelParameteriv with a <value> of
          TEXTURE_INTERNAL_FORMAT to determine the specific compressed image
          format in which the image is stored.

        * Call GetTexLevelParameteriv with a <value> of
          TEXTURE_COMPRESSED_IMAGE_SIZE_ARB to determine the size (in ubytes)
          of the compressed image that will be returned by the GL.  Allocate a
          buffer of at least this size.

        * Call GetCompressedTexImageARB.  The GL will write the compressed
          texture image into the allocated buffer.

        * Save the returned compressed image to disk, along with the
          associated width, height, depth, border parameters and the returned
          values of TEXTURE_COMPRESSED_IMAGE_SIZE_ARB and
          TEXTURE_INTERNAL_FORMAT.

        * Load the compressed image and its parameters, and call
          CompressedTexImage_[123]DARB to use the compressed image.  The value
          of TEXTURE_INTERNAL_FORMAT should be used as <internalFormat> and
          the value of TEXTURE_COMPRESSED_IMAGE_SIZE_ARB should be used as
          <imageSize>.

      The saved images will be valid as long as they are used on a device
      supporting the returned <internalFormat> parameter.  If the saved images
      are used on a device that does not support the compressed internal
      format, an INVALID_ENUM error would be generated by the call to
      CompressedTexImage_[123]D because of the unknown format.

      Note also that to reliably determine if the GL will compress an image
      without actually compressing it, an application need only define a proxy
      texture image and query TEXTURE_COMPRESSED_ARB as above.
"""

So this gives us a way to language-lawyer our way out of that entire
half of the implementation. The other half, decompression, works if
the compressed format is supported as a texture: see
decompress_with_blit in the Gallium source. Gallium actually
explicitly enables the basic parts of the extension based on whether
or not it can use the compressed formats as samplers. (I am not sure
if it's going to be that easy for classic Mesa.)

So I think this covers all the paths, assuming Mesa implements the
internal_format semantics necessary, although I haven't done any
code-reading this morning yet. Ian, Brian, could you check my
reasoning? We might be able to save this.

~ C.

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

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

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

[SpliFF <sp...@wa...>]

On 03/29/10 17:06, Ian Romanick wrote:
> SpliFF wrote:
> > So to clarify, you're saying a partial implementation (decoder only)
> > isn't an option at all? If you expose an extension it must be complete?
>
> See the documentation for glGetCompressedTexImage.

That does not appear to imply a run-time encoder. It seems to imply the
data is already compressed - which could (and really should) be done
prior to distribution (via the nvidia tools for example). The
documentation does quite clearly state that the application should
verify the texture really was compressed so you're only going to run
into issues when the programmer made assumptions about the supported
hardware. Not saying that's impossible, just that that's the
programmers' responsibility, not the drivers.

Runtime compression is actually performed by glTexImage2D with its
internalFormat set to a supported *_S3TC_* value, however the 2.1 spec says:

"If no corresponding internal format is available, or the GL can not
compress that image for any reason, the internal format is instead
replaced with a corresponding base internal format."

For S3TC textures that is:

GL_COMPRESSED_RGB_S3TC_DXT1_EXT  -> RGB
GL_COMPRESSED_RGBA_S3TC_DXT1_EXT ->  RGBA
GL_COMPRESSED_RGBA_S3TC_DXT3_EXT ->  RGBA
GL_COMPRESSED_RGBA_S3TC_DXT5_EXT ->  RGBA

So the spec specifically says you don't need runtime compression to be
compliant, you can fall back to uncompressed and hide the distinction
from the application (or expose it via glGetTexLevelParameteriv). Also,
for the purpose of mesa3d software rendering, why would you really want
to compress an image intended for system RAM? Chances are you'd lose
significantly on rendering performance. The way I see it the worst case
scenario is you use more memory than the developer intended but at least
you're displaying the textures. I know from experience that any normal
game rendered entirely without textures is basically unplayable.

So really, what I'd like clarification on is whether anyone knows of
potential non-infringing workarounds for the independent claims of the
s3tc decoding process only (claims 5, 16, 21 and 22 in the patent). The
rest (encoding) isn't as important as there are already free licensed
tools available for that part (not to mention existing compressed assets
to be rendered).

Finally, if anyone on the nouveau/radeonhd lists would prefer I stop
posting there please email me privately and I'll comply. If hardware
passthrough of s3tc textures is in fact supported by those drivers (and
the user has compatible hardware) then s3tc decoding is less relevant
for that purpose and the discussion is really only relevant to mesa3d
software rendering. I'm new to these lists and I didn't come here just
to make people upset. I don't know how much crossover exists between the
groups and who is getting three copies of these posts.

SpliFF

Re: [Mesa3d-dev] [Nouveau] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds

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

Interestingly, the post-trial judge opinion at
http://wi.findacase.com/research/wfrmDocViewer.aspx/xq/fac.%5CFDCT%5CWWI%5C2008%5C20080801_0000734.WWI.htm/qx
contains the following text:

<<
Plaintiff’s expert, Dr. Stevenson, testified that the ‘327 patent is
directed to “a special
purpose hardware component designed and optimized specifically for
high speed graphics
processing. "
The specification makes it plain that the invention does not relate to
software for graphics. As the inventors noted, such programs “are well
known in the art."
[...]
Claim 17 does not say in so many words that the method it discloses is
a rasterization
circuit operating on a floating point format, but that is what it describes.
Reading the disputed claims as disclosing hardware is not reading a
preferred embodiment in the claims; it is simply
reading the claims as the person of ordinary skill would read a patent
directed to special purpose hardware.
>>

This seems to indicate that it would be safe to implement floating
point textures/framebuffers in Mesa, as both SGI and ATI and the court
seemed to agree that the patent applies specifically to hardware.

Re: [Mesa3d-dev] gallium "raw" interfaces

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

On Mon, Mar 29, 2010 at 1:51 AM, Keith Whitwell
<kei...@go...> wrote:
> I've just pushed a variation on a theme a couple of people have
> explored in the past, ie. an interface to gallium without an
> intervening state-tracker.
> The purpose of this is for writing minimal test programs to exercise
> new gallium drivers in isolation from the rest of the codebase.
> In fact it doesn't really make sense to say "without a state tracker",
> unless you don't mind creating test programs which are specific to the
> windowing system you're currently working with.  Some similar work has
> avoided window-system issues altogether by dumping bitmaps to files,
> or using eg. python to abstract over window systems.
> This approach is a little different - I've defined a super-minimal api
> for creating/destroying windows, currently calling this "graw", and we
> have a tiny little co-state-tracker that each implementation provides.
>  This is similar to the glut approach of abstracting over window
> systems, though much less complete.
> It currently consists of three calls:
>   struct pipe_screen *graw_init( void );
>   void *graw_create_window(...);
>   void graw_destroy_window( void *handle );
> which are sufficient to build simple demos on top of.  A future
> enhancement would be to add a glut-style input handling facility.
> Right now there's a single demo, "clear.c" which displays an ugly
> purple box.  Builds so far only with scons, using winsys=graw-xlib.
I happened to be playing with the idea yesterday.  My take is to define an EGL
extension, EGL_MESA_gallium.  The extension defines Gallium as a rendering API
of EGL.  The downside of this approach is that it depends on st/egl.  The
upside is that, it will work on whatever platform st/egl supports.

I've cleaned up my work a little bit.  You can find it in the attachments.
There is a port of "clear" raw demo to use EGL_MESA_gallium.  The demo supports
window resizing, and is accelerated if a hardware EGL driver is used.

The demo renders into a X11 window.  It is worth noting that, when there is no
need to render into an EGLSurface, eglCreateWindowSurface or eglMakeCurrent is
not required.  To interface with X11, I've also borrowed some code from OpenVG
demos and renamed it to EGLUT.

-- 
ol...@Lu...

Re: [Mesa3d-dev] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SpliFF wrote:
> So to clarify, you're saying a partial implementation (decoder only)
> isn't an option at all? If you expose an extension it must be complete?

See the documentation for glGetCompressedTexImage.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuwQ3AACgkQX1gOwKyEAw9LIgCfemo+7toGx7bpVMjJs0Im6OF6
0bUAniJWsC75twOeyyS/7f3eu8OgueWM
=26xL
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [Nouveau] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephane Marchesin wrote:

> The core issue is that some people do not want to see this code in mesa
> in whatever form, because they're afraid of lawsuits. Rumour has it that
> VIA told them that they would sue. And the same things happened with SGI
> for the float patents by the way. So blame VIA and SGI for their
> anti-oss behaviour instead. For example next time you see a motherboard
> with a VIA chipset, think twice...

The SGI situation is slightly different.  SGI *did* sue.

http://www.sgi.com/company_info/newsroom/press_releases/2006/october/ati.html
http://271patent.blogspot.com/2008/08/wd-wis-all-instances-of-materiality.html
http://www.patentlit.com/2008/05/02/silicon-graphics-v-ati-is-a-draw/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuwQyEACgkQX1gOwKyEAw8IoQCeIwJRaEZz3BiJIE3kUB+fG4mw
R8UAn0+Y1m3WDLGfB7ZznyLrgOrbNeOG
=M4I4
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds

[SpliFF <sp...@wa...>]

On 03/29/10 15:34, Corbin Simpson wrote:
>
> There is already a non-infringing decoder inside Mesa, wired up
> correctly, that kicks in when the HW supports it, but there's no
> extension that exposes only decoding and loading functionality. As Ian
> said, you need an encoder as well, and no HW has it, so you'd have to
> write some questionable code.
>   

So to clarify, you're saying a partial implementation (decoder only)
isn't an option at all? If you expose an extension it must be complete?
Can't you just do a NOOP on encoding or handle it uncompressed? I don't
see why the encoder is so important since it seems to me that
uncompressed data would cause no issues for software rendering and
compressed data should cause no issues for hardware rendering (as stated
earlier, on most modern hardware you can pass it through to VRAM). The
main problem seems to be the lack of a decoder as it makes assets
completely unusable on certain platforms whereas lack of an encoder
typically only impairs efficiency except in fringe cases (games that
compress textures "on-the-fly").

> I'm kind of confused. Are you just trying to see if any of us can be
> convinced to write this code for you?
>   

Yes. Though not for me as I don't play the games in question.

However that's an oversimplification. What I'm really asking is when it
was concluded no workaround is possible, to what extent was it discussed
or was it agreed that nobody should look at the patent at all (willful
infringement defense)? Are the legal opinions you are referring to made
public? Is the issue a lack or resources, lack of interest, lack of
alternatives, lack of understanding or just a general fear of
unspecified litigation or vague threats.

It was also an attempt to see where the EFF sits on this issue and
whether that would consider investigating some of the broader claims in
the patent as part of their patent busting efforts. After all, if there
really is NO possible workaround it kind of implies, to a layman at
least, that the patents claims may be overly broad.

I am simply following a sensible process of elimination, which is:

a.) Determine what can't be done.
b.) Determine what can be done.
c.) Substitute b for a.

If you won't touch it, then you won't. If you don't want to talk about
it (again) I completely understand. I can't force you and I won't nag
you. But there may be others out there, perhaps sitting on the
sidelines, who might have something new to offer. At the least consider
this a case of simple curiousity as the FAQ is somewhat vague on the
matter and the specific claim(s) at issue unclear (at least to me). Even
with access to the archives of this list I don't have the benefit of
knowing the full extent to which this issue has been explored behind the
scenes.

I raised the points I raised to assist in a way that seems positive.
That is to cut through several pages of patent legalese to the specific
claim elements blocking a new type of decoder and then try build a
preliminary technical assessment that could guide programmers around the
hurdles or be reviewed by a patent attorney without completely wasting
their time.

SpliFF

Re: [Mesa3d-dev] [Nouveau] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds

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

On Sun, Mar 28, 2010 at 18:39, SpliFF <sp...@wa...> wrote:

> On 03/29/10 11:07, Corbin Simpson wrote:On 03/29/10 11:07, Corbin
> Simpson wrote:
> > Since neither you nor Andrew are lawyers, I would kindly ask that you
> > refrain from attempting to provide legal advice. :3
> >
>
> If you know I'm not a lawyer (and my nick should be the first clue) then
> it isn't an issue is it? As for Andrew you'll have to ask him that
> yourself. Since it's also clear I'm not a mesa3d developer you assume no
> legal responsibility for what I say either and you are under no
> responsibility to listen.
>
> Which is all irrelevant anyway because proposing to create a new
> invention is not legal advice; it's an engineering suggestion. I
> describe the patent claims and Andrews interpretation of patent law only
> to emphasise things that a hypothetical new invention should *not* do.
>
> > The scant legal advice that *has* been obtained suggests that the
> > current course of action, wherein S3TC is not advertised without the
> > aid of an external library or a configuration option force-enabling
> > it, is the best course of action. I for one would prefer to have
> > firsthand legal advice before making any changes, although I am not a
> > lawyer and cannot provide legal advice.
> >
>
> Solves nothing other than push the legal burden onto someone else
> (distributions) who further push the burden to the end-user. All of
> which makes it harder to use. As far as I can tell the official site of
> the "external project" claims the project is unmaintained and at any
> rate it's rather unpopular with certain distributions for reasons that
> should be obvious.
>
> I'm certainly not sugesting that knowingly infringing material be added
> to mesa3d. What I'm suggesting is that some resources be made available
> to write a new *non-infringing* decompressor and that it seems likely
> the community may have overestimated the difficulty of the task. I often
> wonder if the OSS community isn't becoming a victim of its own FUD. If
> we need lawyers before writing code then we can't write ANY code and we
> might as well all do something else.
>
> I want to reiterate that it is my belief (as in non-legal opinion) that
> the s3tc patent does not cover the s3tc format itself, or even specific
> algorithms. What it covers appear to be specific methods that can be
> used to encode it and some steps that can be used to decode it. The
> issue is whether those claimed steps are the ONLY way of achieving an
> acceptable result and I honestly don't think they are. You are free to
> form your own opinion on that point. Then again if the community plays
> ostrich and assumes the problem is now solved - and worse concludes that
> any discussion of it is heresy - then how can a new invention be
> developed (at least collaboratively)? Unfortunately I lack the indepth
> knowledge of mesa3d internals and s3tc processing requirements required
> to invent such a thing myself.
>

I made a similar proposal a couple of years ago. Basically the patent
explicits the vector quantization scheme, and I wanted to go with another
vector quantization scheme instead. Also that would probably mean better
overall compressed texture quality (the quantization algorithm used in the
patent is approximate to say the least) but longer compression times.

The core issue is that some people do not want to see this code in mesa in
whatever form, because they're afraid of lawsuits. Rumour has it that VIA
told them that they would sue. And the same things happened with SGI for the
float patents by the way. So blame VIA and SGI for their anti-oss behaviour
instead. For example next time you see a motherboard with a VIA chipset,
think twice...

Stephane

Re: [Mesa3d-dev] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds

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

On Sun, Mar 28, 2010 at 6:39 PM, SpliFF <sp...@wa...> wrote:
> Solves nothing other than push the legal burden onto someone else
> (distributions) who further push the burden to the end-user. All of
> which makes it harder to use. As far as I can tell the official site of
> the "external project" claims the project is unmaintained and at any
> rate it's rather unpopular with certain distributions for reasons that
> should be obvious.
>
> I'm certainly not sugesting that knowingly infringing material be added
> to mesa3d. What I'm suggesting is that some resources be made available
> to write a new *non-infringing* decompressor and that it seems likely
> the community may have overestimated the difficulty of the task. I often
> wonder if the OSS community isn't becoming a victim of its own FUD. If
> we need lawyers before writing code then we can't write ANY code and we
> might as well all do something else.

There is already a non-infringing decoder inside Mesa, wired up
correctly, that kicks in when the HW supports it, but there's no
extension that exposes only decoding and loading functionality. As Ian
said, you need an encoder as well, and no HW has it, so you'd have to
write some questionable code.

> I want to reiterate that it is my belief (as in non-legal opinion) that
> the s3tc patent does not cover the s3tc format itself, or even specific
> algorithms. What it covers appear to be specific methods that can be
> used to encode it and some steps that can be used to decode it. The
> issue is whether those claimed steps are the ONLY way of achieving an
> acceptable result and I honestly don't think they are. You are free to
> form your own opinion on that point. Then again if the community plays
> ostrich and assumes the problem is now solved - and worse concludes that
> any discussion of it is heresy - then how can a new invention be
> developed (at least collaboratively)? Unfortunately I lack the indepth
> knowledge of mesa3d internals and s3tc processing requirements required
> to invent such a thing myself.

Cool, I'm glad that you share the opinion of other people on the
Internets on this issue. Feel free to help keep libdxtn from
bitrotting. However, many of the Mesa devs are paid, and their bosses
have indicated that there are issues here, so don't hold your breath
for any of us to do anything beyond maintain the interface to libdxtn.

I'm kind of confused. Are you just trying to see if any of us can be
convinced to write this code for you?

> Unfortunately Spring is an engine, not a game. The issue is that people
> writing games which use the engine typically use DDS textures due to
> various community members bandying the format about like it's the second
> coming. At any rate other than not supporting DDS at all (which would be
> an extremely unpopular and unworkable decision) there isn't much I can
> do to guarantee Spring games don't depend on proprietary drivers until a
> non-infringing s3tc decoder exists.
>
> SpliFF
>

Well, I can't help you there.

I'm sorry if I'm sounding antagonistic, but we've been over this many
times. The patents, to me and to many people who ostensibly have
received better legal advice, are too broadly written to be worked
around.

~ C.

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

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

[Mesa3d-dev] [PATCH] glsl: optimize sqrt

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

We were talking a bit on IRC that the GLSL compiler implements the sqrt
function somewhat inefficiently. Instead of rsq+rcp+cmp instructions as is
in the original code, the proposed patch uses just rsq+mul. Please see the
patch log for further explanation, and please review.

-Marek

Re: [Mesa3d-dev] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds

[SpliFF <sp...@wa...>]

On 03/29/10 11:07, Corbin Simpson wrote:On 03/29/10 11:07, Corbin
Simpson wrote:
> Since neither you nor Andrew are lawyers, I would kindly ask that you
> refrain from attempting to provide legal advice. :3
>   

If you know I'm not a lawyer (and my nick should be the first clue) then
it isn't an issue is it? As for Andrew you'll have to ask him that
yourself. Since it's also clear I'm not a mesa3d developer you assume no
legal responsibility for what I say either and you are under no
responsibility to listen.

Which is all irrelevant anyway because proposing to create a new
invention is not legal advice; it's an engineering suggestion. I
describe the patent claims and Andrews interpretation of patent law only
to emphasise things that a hypothetical new invention should *not* do.

> The scant legal advice that *has* been obtained suggests that the
> current course of action, wherein S3TC is not advertised without the
> aid of an external library or a configuration option force-enabling
> it, is the best course of action. I for one would prefer to have
> firsthand legal advice before making any changes, although I am not a
> lawyer and cannot provide legal advice.
>   

Solves nothing other than push the legal burden onto someone else
(distributions) who further push the burden to the end-user. All of
which makes it harder to use. As far as I can tell the official site of
the "external project" claims the project is unmaintained and at any
rate it's rather unpopular with certain distributions for reasons that
should be obvious.

I'm certainly not sugesting that knowingly infringing material be added
to mesa3d. What I'm suggesting is that some resources be made available
to write a new *non-infringing* decompressor and that it seems likely
the community may have overestimated the difficulty of the task. I often
wonder if the OSS community isn't becoming a victim of its own FUD. If
we need lawyers before writing code then we can't write ANY code and we
might as well all do something else.

I want to reiterate that it is my belief (as in non-legal opinion) that
the s3tc patent does not cover the s3tc format itself, or even specific
algorithms. What it covers appear to be specific methods that can be
used to encode it and some steps that can be used to decode it. The
issue is whether those claimed steps are the ONLY way of achieving an
acceptable result and I honestly don't think they are. You are free to
form your own opinion on that point. Then again if the community plays
ostrich and assumes the problem is now solved - and worse concludes that
any discussion of it is heresy - then how can a new invention be
developed (at least collaboratively)? Unfortunately I lack the indepth
knowledge of mesa3d internals and s3tc processing requirements required
to invent such a thing myself.

> At any rate, since Spring is open-source, I would heavily advise the
> Spring team to remember that OpenGL extensions that are not part of a
> core version are not guaranteed to be available, and in this case,
> there is a trivial workaround for when the extension is not present,
> so you guys could (and should!) include an uncompressed texture path
> and ship uncompressed textures.
>   

Unfortunately Spring is an engine, not a game. The issue is that people
writing games which use the engine typically use DDS textures due to
various community members bandying the format about like it's the second
coming. At any rate other than not supporting DDS at all (which would be
an extremely unpopular and unworkable decision) there isn't much I can
do to guarantee Spring games don't depend on proprietary drivers until a
non-infringing s3tc decoder exists.

SpliFF

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

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

I just noticed a potentially interesting thing.

nVidia publishes under the MIT license a software suite called "nVidia
texture tools".
This includes a library called "nvtt" that provides DXT* compression,
plus a library called "nvimage" that provides decompression.
It looks like the libraries can be used unmodified and nVidia is
almost surely a licensee of that patent.

So, if using and shipping a possibly-patent-covered library published
by a patent licensee does not risk violating the patent, we may have a
workable solution.

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

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

On Sun, Mar 28, 2010 at 4:47 AM, SpliFF <sp...@wa...> wrote:
> Hi radeonhd, nouveau, mesa3d developers,
>
> Firstly, thank you all very much for all the important work you do.
>
> I've been working as a part-time developer on the "Spring RTS" project
> (open-source game engine) which runs on linux (and other os). Some time
> ago I tried the engine on the open-source ATI radeonhd driver, which I
> understand to be partly based on mesa 3d, and all textures were white. I
> originally assumed it was an engine bug but after some investigation
> tracked it down to s3tc texture (de)compression not being integrated in
> the open driver for legal reasons. It seems the same issue applies to
> Mesa3d and Nouveau - that is s3tc being patented and the patent owner
> refusing to comment or provide cover for open-source projects
> implementing the techniques discussed in US Patent 5956431
> (http://v3.espacenet.com/publicationDetails/claims?DB=&locale=&FT=D&date=19990921&CC=US&NR=5956431A&KC=A&tree=true)
>
> I recently took inspiration from an article/talk presented by Andrew
> Trigell regarding patents where he claims developers often overestimate
> the scope of patents
> (http://news.swpat.org/2010/03/transcript-tridgell-patents/) because
> they fixate on the title and summary instead of the actual claims.
>
> The key point he was making is that in order to infringe a patent you
> apparently have to infringe on ALL ELEMENTS of a PRIMARY claim. If you
> don't do something in the primary claim then by definition you aren't
> doing the things in secondary claims that reference it (ie, where the
> claim reads "... in claim X ..."). In short if you workaround the
> primary claims you probably aren't infringing. Wikipeadia, with some
> jurisdictional hand-waving, appears to agree: "If all of the claim's
> elements are found in the technology, the claim is said to "read on" the
> technology; if a single element from the claim is missing from the
> technology, the claim does not literally read on the technology and the
> technology does not infringe the patent with respect to that claim."
>
> So I took a look at the 4 primary claims that apply to DECODING s3tc
> textures. All other claims either rely on these claims or involve
> encoding, which Mesa 3D / Xorg drivers should not need to do. Finding a
> workaround for these primary claims is necessary to avoid infringement
> for an s3tc decoder. I'll break these into seperate elements because a
> workaround (non-infringement) for ANY element is a workaround for the
> ENTIRE claim itself. The elements are seperated by semicolons and I've
> added line-breaks to make them clearer).
>
> To avoid confusion I've removed the preamble from each claim, they don't
> count as elements of the claim.
>
> In short, if anyone on these lists can see a way to decompress an s3tc
> image without doing just 1 of the items from EACH of the following 4
> claims then a legal s3tc decoder should be possible.
>
> ================
> 5.
> an encoded image decomposer,
> coupled to receive encoded image data file having at least one
> compressed image block,
> for breaking the encoded image data file into individual compressed
> image blocks,
> each compressed image block having at least one associated codeword,
> each codeword generated through selecting a block type for an original
> image block comprising the compressed image block,
> computing an analog curve for the block type,
> selecting a partition along the analog curve for the computed analog curve,
> and computing the set of codewords for the partition;
>
> at least one block decoder,
> coupled to the encoded image decomposer,
> for decompressing the compressed image blocks;
>
> and an image composer,
> coupled to each block decoder,
> for ordering the decompressed image blocks in an output file.
>
> ==================
> 16.
> receiving the encoded image data;
>
> decomposing the encoded image into the modified header and the
> individual encoded image blocks;
>
> reading the modified header to generate an output header;
>
> decoding each individual encoded image block to generate a decoded image
> block,
> including receiving each individual encoded image block, including a
> plurality of codewords,
> and a bitmap of at least one pixel,
> the plurality of codewords derived through selecting a block type for an
> original image block of the encoded image block,
> computing an analog curve for the block type,
> selecting a partition along the analog curve for the computed analog curve,
> and computing the plurality of codewords for the partition;
>
> and composing the output header and the individual decoded image blocks
> to generate an output file of the original image.
>
> ==================
> 21.
> a block address computation module, coupled to receive each codeword
> from the header information, for computing an address of an encoded
> image block having the identified pixel;
>
> a block fetching module, coupled to receive the encoded image block
> portion and the computed address, for fetching the encoded image block
> having the identified pixel;
>
> and a block decoder, coupled to receive the fetched encoded image block,
> for decoding the image block to generate a quantized color associated
> with the identified pixel.
>
> ==================
> 22.
> computing an address for an encoded image block having the identified
> pixel,
> the address computed from the at least one codeword for the encoded
> image block;
>
> fetching the encoded image block using the computed address;
>
> computing quantized color levels for the fetched encoded image block;
>
> and selecting a color of the identified pixel from the quantized color
> levels to output.
>
> ===================
>
>
> One thing that stands out to me are that none of the primary claims seem
> to describe the technical format itself (ie, no algorithms, keywords,
> block sizes, byte-alignment, etc..) This means the claims at issue seem
> to be *methods* of data handling, (and not particularly inventive ones
> in my opinion). That suggests to me that with a little thought it should
> be possible to generate the same results via a method that doesn't
> infringe one of the 4 specific claims listed above. To clarify, despite
> all the technical mumbling in the abstract the claimed invention does
> not appear to be a "format" as such, but a method of pulling "blocks"
> and a "header" out of an undefined format and generating "color pixels".
> Even the abstract claims all the presented examples of keywords, values
> and structure for s3tc are not the actual invention being claimed.
> Another important point is that some of the wording in the claims may
> not mean what it appears to mean (ie, the generally accepted
> definition), the full patent may redefine some common software terms in
> the wrapper.
>
> Some possible avenues of investigation, straight off the top of my head are:
>
> * Determine the patents' definition of a "unit" and/or "module", and use
> something else (ie, a monolithic function)
> * Determine the patents' definition of a "block", and use something
> else. (characters, a bytestream, ...)
> * Determine the patents' definition of "compose / decompose", and do
> something else.
> * Do we need to "compose a header" as a seperate stage (use a footer,
> temporary vars, registers)
> * Does the curve have to be "analog"? What about a lookup table with
> discreet points that approximate a curve?
> * Can the algorithms work on groups of blocks or sub-blocks instead of
> "individual blocks".
>
> More for DRI projects than Mesa, but I'll ask anyway:
> * Do we need to decode anything; could an X11 driver force-feed the raw
> bytes to hardware instead?
>
> Claim 22 seems like a pretty important step and possibly a hard one to
> workaround but it also appears to be claiming the invention of using a
> key lookup to fetch values with some vague notion of quantising them. Is
> it just me or are they claiming to have invented indexed color?
>
> PS. If some of the points above seem pedantic that's deliberate. My
> understanding is that patent claims are actually intended or required to
> be NARROW in scope as broad claims are usually rejected. That means a
> workaround that doesn't do PRECISELY the things in each claim above is,
> by definition, a new invention. I'm hoping an invention that members of
> this community are capable of finding before someone else patents it.
>
> I've CC'ed the EFF on this because I'd like to see it become a part of
> their patent-busting efforts. Fear of this patent is blocking an
> extremely important component of 3D gaming under linux (the use of DDS
> textures under an open-source driver). Not that I'm a fan of DDS, just
> that it's the format of choice for commercial and non-commercial games
> until hardware supports something better, and even then still a
> requirement for running many classic games under WINE +
> radeonhd/mesa3d/nouveau. It seems absurd that I can buy a product with a
> patent license granted (NVIDIA/ATI card) but then be denied the
> protection of that license because I don't use part of the product (the
> official driver). I really hope that as a community we can either invent
> around this patent or bust it (at least in US / EU where it is most
> problematic) without losing hardware support or requiring the
> reformatting/conversion of digital assets.\

Since neither you nor Andrew are lawyers, I would kindly ask that you
refrain from attempting to provide legal advice. :3

The scant legal advice that *has* been obtained suggests that the
current course of action, wherein S3TC is not advertised without the
aid of an external library or a configuration option force-enabling
it, is the best course of action. I for one would prefer to have
firsthand legal advice before making any changes, although I am not a
lawyer and cannot provide legal advice.

At any rate, since Spring is open-source, I would heavily advise the
Spring team to remember that OpenGL extensions that are not part of a
core version are not guaranteed to be available, and in this case,
there is a trivial workaround for when the extension is not present,
so you guys could (and should!) include an uncompressed texture path
and ship uncompressed textures.

~ C.

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

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

[Mesa3d-dev] Mesa 7.7.1 and Mesa 7.8 released!

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Final versions of both Mesa 7.8 and 7.7.1 have been released.  Links on
the Mesa website will still need to be updated, but I think Brian has to
do that.

The tag in the GIT repository for Mesa 7.8 is 'mesa-7.8'.  I had
originally intended to just use 7.8, but having a tag and a branch with
the same name makes GIT angry (i.e., you get "warning: refname '7.8' is
ambiguous.").

I also noticed that the Mesa-7.7.1 release candidates should have been
in /pub/mesa/7.7.1/RC instead of /pub/mesa/7.7/RC.  I have now linked
the 7.7.1 release candidates in both locations.

Mesa-7.7.1 available at ftp://freedesktop.org/pub/mesa/7.7.1/

md5sums:

3ab0638cfa7ce8157337a229cf0db2c4  MesaLib-7.7.1.tar.gz
46664d99e03f1e3ac078a7fea02af115  MesaLib-7.7.1.tar.bz2
4e73ba8abb59aff79485eb95d7cefff7  MesaLib-7.7.1.zip
bf1b108983995f7a712cf3343df1c918  MesaDemos-7.7.1.tar.gz
aeb39645d80d656e0adebaa09e5bcd03  MesaDemos-7.7.1.tar.bz2
01c49b7454fd292244eaf8bdc6ed8cf0  MesaDemos-7.7.1.zip
37ec6386693dcb6dc770d1efd63a7a93  MesaGLUT-7.7.1.tar.gz
1e16c85282f843791a21f7bc7b6a1ca8  MesaGLUT-7.7.1.tar.bz2
d352c9e36a8e4d1059f4abc017b131e0  MesaGLUT-7.7.1.zip

Mesa 7.8 available at ftp://freedesktop.org/pub/mesa/7.8/

md5sums:

5fcfde5383eccb3e9fd665f08a0ea59b  MesaLib-7.8.tar.gz
85cb891eecb89aae4fdd3499cccd934b  MesaLib-7.8.tar.bz2
754f39593006effc1c8ec3c27c2f1296  MesaLib-7.8.zip
c3869c29fa6c3dbdd763f7428d271e12  MesaDemos-7.8.tar.gz
9fe8ec184c7f78691e43c4c0a7f97d56  MesaDemos-7.8.tar.bz2
063a96947f7b83d4ad789c6cf291b184  MesaDemos-7.8.zip
5f4246756b7daaddb4fb3f970cad1e28  MesaGLUT-7.8.tar.gz
ca7048a4aa7a437dcc84cc2c7d731336  MesaGLUT-7.8.tar.bz2
b54581aeb79b585b158d6a32f94feff2  MesaGLUT-7.8.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuv7DAACgkQX1gOwKyEAw90OwCfTSKh/iZB1+7Rxi93qJvnVb/y
EgkAnjDU46hOCVSd4vsbArUNgKVa6Gxz
=MRYj
-----END PGP SIGNATURE-----

Re: [Mesa3d-dev] gallium "raw" interfaces

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

On Sun, Mar 28, 2010 at 12:19 PM, Luca Barbieri <luc...@gm...> wrote:
> I posted something similar some time ago, that however could use
> hardware accelerated drivers with DRI2 or KMS, provided a substantial
> set of helpers and offered a complement of 3 demos.
>
> My solution to window-system issues was to simply have the application
> provide a "draw" callback to the framework, which would automatically
> create a maximized window with the application name in the title, and
> call draw in a loop, presenting the results.
>
> Then I had a path that woud use the X DRI2 interface if possible, and
> another path that would use the Linux DRM KMS API (and initially some
> EGL+ad-hoc extension paths that were later dropped).
>
> It no longer works due to Gallium interface changes, but maybe it can
> be resurrected and merged with graw.
>
> However, there is a disadvantage to having Gallium programs in-tree:
> they break every time the Gallium interface in changed and avoiding
> that means that in addition to fixing all drivers and state trackers,
> you also need to fix all programs for each change

Presumably this will no longer be a problem when Gallium is a more
mature, stable interface. I much prefer this "try it and see"
mentality over the design-by-committee mess that has popped up
elsewhere.

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

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

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

[Ian R. <id...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

SpliFF wrote:
> In short, if anyone on these lists can see a way to decompress an s3tc
> image without doing just 1 of the items from EACH of the following 4
> claims then a legal s3tc decoder should be possible.

The problem is that, for OpenGL, just having a decoder isn't good
enough.  You have to have an encoder as well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuv6OIACgkQX1gOwKyEAw8GfACdEyN4G6X3uIzU7w41+fFPrBqy
tCoAn3A25sJ+ynMK+A+ftJ4jg6IEX0FE
=EufR
-----END PGP SIGNATURE-----

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

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

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] Current tinderbox regression (swrastg_dri, sparc64)

[Matt T. <mat...@gm...>]

On Sun, Mar 28, 2010 at 3:07 PM, Luca Barbieri <luc...@gm...> wrote:
> On Sun, Mar 28, 2010 at 7:36 PM, Chris Ball <cj...@la...> wrote:
>> Hi,
>>
>>   > http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build
>>   >
>>   > swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4'
>>   > swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4'
>>
>> This regression is still present -- could we get a fix or a revert?
>
> I believe the problem is that sparc does not support atomic operations
> in the basic architecture: I think someone who knows about sparc and
> has such a machine should look into it.
>
> If you don't know anything about sparc, try rebuilding with the
> highest possible sparc -march= level and if that fixes the problem,
> perform a binary search to find the minimum one, and then report the
> results.
>
> If it does not solve the problem, see if anything in /lib or /usr/lib
> exports those symbols.
>
> Also maybe check whether the built swrastg_dri or xlib softpipe
> actually works there.

I think we need to be specifying something like -mcpu=v9 or something
to be able to use the __sync_* primitives. I highly doubt anyone wants
to run any of this code on something older.

I've CC'd Dave Miller--he'll know what to do.

Thanks,
Matt

Re: [Mesa3d-dev] gallium "raw" interfaces

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

I posted something similar some time ago, that however could use
hardware accelerated drivers with DRI2 or KMS, provided a substantial
set of helpers and offered a complement of 3 demos.

My solution to window-system issues was to simply have the application
provide a "draw" callback to the framework, which would automatically
create a maximized window with the application name in the title, and
call draw in a loop, presenting the results.

Then I had a path that woud use the X DRI2 interface if possible, and
another path that would use the Linux DRM KMS API (and initially some
EGL+ad-hoc extension paths that were later dropped).

It no longer works due to Gallium interface changes, but maybe it can
be resurrected and merged with graw.

However, there is a disadvantage to having Gallium programs in-tree:
they break every time the Gallium interface in changed and avoiding
that means that in addition to fixing all drivers and state trackers,
you also need to fix all programs for each change

Re: [Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)

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

On Sun, Mar 28, 2010 at 7:36 PM, Chris Ball <cj...@la...> wrote:
> Hi,
>
>   > http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build
>   >
>   > swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4'
>   > swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4'
>
> This regression is still present -- could we get a fix or a revert?

I believe the problem is that sparc does not support atomic operations
in the basic architecture: I think someone who knows about sparc and
has such a machine should look into it.

If you don't know anything about sparc, try rebuilding with the
highest possible sparc -march= level and if that fixes the problem,
perform a binary search to find the minimum one, and then report the
results.

If it does not solve the problem, see if anything in /lib or /usr/lib
exports those symbols.

Also maybe check whether the built swrastg_dri or xlib softpipe
actually works there.

[Mesa3d-dev] gallium "raw" interfaces

[Keith W. <kei...@go...>]

Hi,

I've just pushed a variation on a theme a couple of people have
explored in the past, ie. an interface to gallium without an
intervening state-tracker.

The purpose of this is for writing minimal test programs to exercise
new gallium drivers in isolation from the rest of the codebase.

In fact it doesn't really make sense to say "without a state tracker",
unless you don't mind creating test programs which are specific to the
windowing system you're currently working with.  Some similar work has
avoided window-system issues altogether by dumping bitmaps to files,
or using eg. python to abstract over window systems.

This approach is a little different - I've defined a super-minimal api
for creating/destroying windows, currently calling this "graw", and we
have a tiny little co-state-tracker that each implementation provides.
 This is similar to the glut approach of abstracting over window
systems, though much less complete.

It currently consists of three calls:

   struct pipe_screen *graw_init( void );
   void *graw_create_window(...);
   void graw_destroy_window( void *handle );

which are sufficient to build simple demos on top of.  A future
enhancement would be to add a glut-style input handling facility.

Right now there's a single demo, "clear.c" which displays an ugly
purple box.  Builds so far only with scons, using winsys=graw-xlib.

Keith

Re: [Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)

[Chris B. <cj...@la...>]

Hi,

   > http://tinderbox.x.org/builds/2010-03-25-0018/logs/libGL/#build
   > 
   > swrastg_dri.so.tmp: undefined reference to `__sync_sub_and_fetch_4'
   > swrastg_dri.so.tmp: undefined reference to `__sync_add_and_fetch_4'

This regression is still present -- could we get a fix or a revert?

Thanks,

- Chris.
-- 
Chris Ball   <cj...@la...>
One Laptop Per Child

Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds

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

If the application provides s3tc-encoded data through
glCompressedTexImage (usually loaded from a pre-compressed texture
stored on disk), Mesa will pass it unaltered to the graphics card (as
long as the driver/card supports DXT* format ids) and will not need to
use any encoding or decoding algorithms.

The problem is that if the application supplies uncompressed data,
Mesa would need to run an encoding algorithm to be able to use
compressed textures.

Conversely, if software rendering is necessary, and the application
provides compressed textures, Mesa will need to run a decoding
algorithm to be able to sample from the texture.

So the workaround (and what commercial games usually do) is to ship
pre-compressed textures along with the game, as well as uncompressed
textures in case the card/rendered do not support texture compression.
An end-user side solution is to download, compile and install
libtxc_dxtn.so, which Mesa will use if present to decode and encode
compressed textures.

Furthermore, a GPU can be used to do decoding using its native
sampling support, and some may also support encoding.