[Mesa-dev] [PATCH 6/6] st/mesa: choose an appropriate texture format for DrawPixels

--- src/mesa/state_tracker/st_cb_drawpixels.c | 46 +++-- 1 files changed, 43 insertions(+), 3 deletions(-) diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c b/src/mesa/state_tracker/st_cb_drawpixels.c index dc53e27..8808f62 100644 --- a/src/mesa/state_tracker/st_c

[Mesa-dev] [PATCH 5/6] gallium: add EXT_texture_snorm support

--- src/gallium/auxiliary/util/u_format.csv |8 + src/gallium/include/pipe/p_format.h |9 ++ src/mesa/state_tracker/st_extensions.c |6 + src/mesa/state_tracker/st_format.c | 232 ++- 4 files changed, 253 insertions(+), 2 deletions(-) diff --git

[Mesa-dev] [PATCH 4/6] mesa: implement texstore and texfetch hooks for signed normalized formats

The snorm texstore functions were all broken. swrast support done except for mipmap generation, but I leave it disabled. --- src/mesa/main/texfetch.c | 86 ++-- src/mesa/main/texfetch_tmp.h | 227 +++--- src/mesa/main/texstore.c | 319 ++

[Mesa-dev] [PATCH 3/6] mesa: initial EXT_texture_snorm support

The component ordering of some formats has been been reversed to match Gallium types. --- src/mesa/main/extensions.c |3 +- src/mesa/main/fbobject.c | 38 - src/mesa/main/formats.c| 100 src/mesa/main/formats.h| 15 +++

[Mesa-dev] [PATCH 2/6] gallium: implement clamping controls (ARB_color_buffer_float)

From: Luca Barbieri BTW this changes the gallium interface. Some rather cosmetic changes by Marek. Squashed commit of the following: commit 513b37d484f0318311e84bb86ed4c93cdff71f13 Author: Luca Barbieri Date: Thu Aug 26 18:17:54 2010 +0200 mesa/st: respect fragment clamping in st_DrawPi

[Mesa-dev] [PATCH 0/6] ARB_color_buffer_float and EXT_texture_snorm

Hi, this patch series adds two new OpenGL extensions to Mesa: - ARB_color_buffer_float, a subset of GL3.0 - EXT_texture_snorm, a part of which is also a subset of GL3.1 The work on ARB_color_buffer_float (it's about clamping controls, not float buffers) was originally started by Luca Barbieri. I

Re: [Mesa-dev] News about my GSoC proposal

Hi Denis, I think the work to replace Mesa IR with GLSL IR is being done by Intel (it was mentioned on #dri-devel, feel free to drop by), but I don't think they will want to touch the st_mesa_to_tgsi part. Have you considered working on a hardware driver? Sometimes, stable and fast drivers are al

Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

On 20.3.2011 22:21, Patrick Baggett wrote: Offhand, anyone know when these patents expire? Patrick If the following is right: http://en.wikipedia.org/wiki/Term_of_patent_in_the_United_States then given S3TC patent http://v3.espacenet.com/publicationDetails/biblio?CC=US&NR=5956431&KC=&FT=E

Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

Offhand, anyone know when these patents expire? Patrick ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

On Sun, 2011-03-20 at 21:31 +0100, Petr Sebor wrote: > On 20.3.2011 20:23, Mathias Gottschlag wrote: > > > > Argh, meant to reply to list. > > > > If this nvidia library has a s3tc patent license, cannot this be used > > as a starting point, as done with the current dxt library? Unmodified, > > a

Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

On 20.3.2011 20:23, Mathias Gottschlag wrote: Argh, meant to reply to list. If this nvidia library has a s3tc patent license, cannot this be used as a starting point, as done with the current dxt library? Unmodified, as an external binary? Wouldn't that circumvent the whole issue as you do n

Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

On 20.3.2011 16:42, Jose Fonseca wrote: Petr, You don't believe that IHVs may have narrow licenses of the S3TC patent. How do you explain the statement: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same fun

Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

Argh, meant to reply to list. If this nvidia library has a s3tc patent license, cannot this be used as a starting point, as done with the current dxt library? Unmodified, as an external binary? Wouldn't that circumvent the whole issue as you do not need a license for the hardware as it alread

[Mesa-dev] News about my GSoC proposal

Hello, One week has passed since my last mail, talking about an OpenGL 4.1 Core state tracker. There has been great interest and many remarks, so thanks to you all. I write this mail to give some more information about my future proposal, and to say that I have not disappeared and that I'm alre

Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

Petr, You don't believe that IHVs may have narrow licenses of the S3TC patent. How do you explain the statement: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same functionality in OpenGL. in http://oss.sg

Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

On 20.3.2011 12:50, Joakim Sindholt wrote: I'd just like to point out that the nvidia-texture-tools FAQ has this to say: Can I use the NVIDIA Texture Tools in the US? Do I have to obtain a license of the S3TC patent (US patent 5,956,431)? NVIDIA has a license of the S3TC patent that covers all

Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

On Sun, 2011-03-20 at 10:55 +0100, Petr Sebor wrote: > On 20.3.2011 1:40, Henri Verbeet wrote: > > On 20 March 2011 00:42, Petr Sebor wrote: > > > And this is not an undocumented hack. ARB_texture_compression explicitly > > > defines mechanisms to work with 'unknown' formats providing a safe > >

Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?

On 20.3.2011 1:40, Henri Verbeet wrote: On 20 March 2011 00:42, Petr Sebor wrote: And this is not an undocumented hack. ARB_texture_compression explicitly defines mechanisms to work with 'unknown' formats providing a safe passthrough. Thats what glCompressedTexImage actually is for. Sure, the