Re: [Mesa3d-dev] gallium "raw" interfaces
On Mon, Mar 29, 2010 at 1:51 AM, Keith Whitwell 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. -- o...@lunarg.com From 8b40fe56be030b19281971ac7db0a19625ae734e Mon Sep 17 00:00:00 2001 From: Chia-I Wu Date: Mon, 29 Mar 2010 01:46:16 +0800 Subject: [PATCH 1/4] egl: Export _eglCheckDisplayHandle. --- src/egl/main/egldisplay.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/egl/main/egldisplay.h b/src/egl/main/egldisplay.h index 21bf22b..57e7132 100644 --- a/src/egl/main/egldisplay.h +++ b/src/egl/main/egldisplay.h @@ -101,7 +101,7 @@ PUBLIC void _eglCleanupDisplay(_EGLDisplay *disp); -extern EGLBoolean +PUBLIC EGLBoolean _eglCheckDisplayHandle(EGLDisplay dpy); -- 1.7.0 From 636480770965187ce09d8b59a2c6bdec572dd52d Mon Sep 17 00:00:00 2001 From: Chia-I Wu Date: Mon, 29 Mar 2010 00:26:50 +0800 Subject: [PATCH 2/4] egl: Define EGL_MESA_gallium. --- include/EGL/eglext.h |8 src/egl/main/eglconfig.c |3 +++ src/egl/main/eglcurrent.h |6 ++ src/gallium/include/state_tracker/st_api.h |3 +++ src/gallium/state_trackers/egl/common/egl_g3d.c|5 + src/gallium/state_trackers/egl/common/egl_g3d_st.c |3 +++ src/gallium/state_trackers/egl/common/egl_g3d_st.h |5 + 7 files changed, 33 insertions(+), 0 deletions(-) diff --git a/include/EGL/eglext.h b/include/EGL/eglext.h index a9e598d..e797523 100644 --- a/include/EGL/eglext.h +++ b/include/EGL/eglext.h @@ -197,6 +197,14 @@ typedef const char * (EGLAPIENTRYP PFNEGLQUERYMODESTRINGMESA) (EGLDisplay dpy, E #endif /* EGL_MESA_screen_surface */ +/* EGL_MESA_gallium extension >>> PRELIMINARY <<< */ +#ifndef EGL_MESA_gallium +#define EGL_MESA_gallium 1 +#define EGL_GALLIUM_API_MESA 0x30A3 +#define EGL_GALLIUM_BIT_MESA 0x0010 /* EGL_RENDERABLE_TYPE mask bits */ +#endif /* EGL_MESA_gallium */ + + #ifndef EGL_MESA_copy_context #define EGL_MESA_copy_context 1 diff --git a/src/egl/main/eglconfig.c b/src/egl/main/eglconfig.c index 21d13cb..9a4de7e 100644 --- a/src/egl/main/eglconfig.c +++ b/src/egl/main/eglconfig.c @@ -332,6 +332,9 @@ _eglValidateConfig(const _EGLConfig *conf, EGLBoolean for_matching) EGL_OPENVG_BIT | EGL_OPENGL_ES2_BIT | EGL_OPENGL_BIT; +#ifdef EGL_MESA_gallium +mask |= EGL_GALLIUM_BIT_MESA; +#endif break; default: assert(0); diff --git a/src/egl/main/eglcurrent.h b/src/egl/main/eglcurrent.h index e5c94ce..5bd11ae 100644 --- a/src/egl/main/eglcurrent.h +++ b/src/egl/main/eglcurrent.h @@ -13,7 +13,13 @@ #define _EGL_API_FIRST_API EGL_OPENGL_ES_API + +#ifdef EGL_MESA_gallium +#define _EGL_API_LAST_API EGL_GALLIUM_API_MESA +#else #define _EGL_A
Re: [Mesa3d-dev] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds
-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- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Nouveau] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds
-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- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds
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 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Nouveau] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds
On Sun, Mar 28, 2010 at 18:39, SpliFF 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 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds
On Sun, Mar 28, 2010 at 6:39 PM, SpliFF 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 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] glsl: optimize sqrt
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
From 9b834a79a1819f3b4b9868be3e2696667791c83e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?=
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;
}
--
1.6.3.3
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [radeonhd] Re: Status of s3tc patent in respect to open-source drivers and workarounds
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 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds
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. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds
On Sun, Mar 28, 2010 at 4:47 AM, SpliFF 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 > portio
[Mesa3d-dev] Mesa 7.7.1 and Mesa 7.8 released!
-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- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium "raw" interfaces
On Sun, Mar 28, 2010 at 12:19 PM, Luca Barbieri 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 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds
-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- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)
On Sun, Mar 28, 2010 at 3:07 PM, Luca Barbieri wrote: > On Sun, Mar 28, 2010 at 7:36 PM, Chris Ball 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 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium "raw" interfaces
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 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)
On Sun, Mar 28, 2010 at 7:36 PM, Chris Ball 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. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium "raw" interfaces
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 -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Current tinderbox regression (swrastg_dri, sparc64)
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 One Laptop Per Child -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds
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. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH-RFC] st/mesa: Add GL_OES_EGL_image support
Hi Jakob,
This patch series adds support for GL_OES_EGL_image to st/mesa. The first
patch implements st_manager::get_egl_image in st/egl. The hook is used to
check and return an st_egl_image, which describes an EGLImageKHR. The second
patch implements GL_OES_EGL_image in st/mesa, and the last patch adds a demo
for the new functionality. I've tested it with egl_x11_i915.so, but it should
work with other hardware drivers.
Do you mind having a look at the patches, especially the first one? I'd like
to hear your opinions before merging the patches, and going on to work on
EGLImage support in st/dri.
--
o...@lunarg.com
From 9dda3e2377abda21f6260c7cc2c2d6e9244e2685 Mon Sep 17 00:00:00 2001
From: Chia-I Wu
Date: Fri, 12 Mar 2010 09:56:11 +0800
Subject: [PATCH 1/3] st/egl: Implement get_egl_image hook.
This hook may be used by rendering state trackers to implement EGLImage
extensions.
---
src/gallium/state_trackers/egl/common/egl_g3d_st.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/src/gallium/state_trackers/egl/common/egl_g3d_st.c b/src/gallium/state_trackers/egl/common/egl_g3d_st.c
index 3609409..a9343ea 100644
--- a/src/gallium/state_trackers/egl/common/egl_g3d_st.c
+++ b/src/gallium/state_trackers/egl/common/egl_g3d_st.c
@@ -85,6 +85,37 @@ egl_g3d_create_st_api(enum st_api_type api)
return mod->create_api();
}
+static boolean
+egl_g3d_st_manager_get_egl_image(struct st_manager *smapi,
+ struct st_egl_image *stimg)
+{
+ struct egl_g3d_st_manager *gsmapi = egl_g3d_st_manager(smapi);
+ EGLImageKHR handle = (EGLImageKHR) stimg->egl_image;
+ _EGLImage *img;
+ struct egl_g3d_image *gimg;
+
+ /* this is called from state trackers */
+ _eglLockMutex(&gsmapi->display->Mutex);
+
+ img = _eglLookupImage(handle, gsmapi->display);
+ if (!img) {
+ _eglUnlockMutex(&gsmapi->display->Mutex);
+ return FALSE;
+ }
+
+ gimg = egl_g3d_image(img);
+
+ stimg->texture = NULL;
+ pipe_texture_reference(&stimg->texture, gimg->texture);
+ stimg->face = gimg->face;
+ stimg->level = gimg->level;
+ stimg->zslice = gimg->zslice;
+
+ _eglUnlockMutex(&gsmapi->display->Mutex);
+
+ return TRUE;
+}
+
struct st_manager *
egl_g3d_create_st_manager(_EGLDisplay *dpy)
{
@@ -96,6 +127,7 @@ egl_g3d_create_st_manager(_EGLDisplay *dpy)
gsmapi->display = dpy;
gsmapi->base.screen = gdpy->native->screen;
+ gsmapi->base.get_egl_image = egl_g3d_st_manager_get_egl_image;
}
return &gsmapi->base;;
--
1.7.0
From d36c035ccff06d188b244ee55d258b96a8abe184 Mon Sep 17 00:00:00 2001
From: Chia-I Wu
Date: Thu, 25 Feb 2010 23:10:47 +0800
Subject: [PATCH 2/3] st/mesa: Implement GL_OES_EGL_image driver hooks.
Use st_manager::get_egl_image to look up GLeglImageOES and implement
EGLImageTargetTexture2D and EGLImageTargetRenderbufferStorage.
---
src/mesa/SConscript |1 +
src/mesa/sources.mak|1 +
src/mesa/state_tracker/st_cb_eglimage.c | 160 +++
src/mesa/state_tracker/st_cb_eglimage.h | 48 +
src/mesa/state_tracker/st_context.c |3 +
src/mesa/state_tracker/st_manager.c | 28 ++
src/mesa/state_tracker/st_manager.h |4 +
7 files changed, 245 insertions(+), 0 deletions(-)
create mode 100644 src/mesa/state_tracker/st_cb_eglimage.c
create mode 100644 src/mesa/state_tracker/st_cb_eglimage.h
diff --git a/src/mesa/SConscript b/src/mesa/SConscript
index c850854..d368b8b 100644
--- a/src/mesa/SConscript
+++ b/src/mesa/SConscript
@@ -166,6 +166,7 @@ if env['platform'] != 'winddk':
'state_tracker/st_cb_condrender.c',
'state_tracker/st_cb_flush.c',
'state_tracker/st_cb_drawpixels.c',
+ 'state_tracker/st_cb_eglimage.c',
'state_tracker/st_cb_fbo.c',
'state_tracker/st_cb_feedback.c',
'state_tracker/st_cb_program.c',
diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index d6ae696..15988ba 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -198,6 +198,7 @@ STATETRACKER_SOURCES = \
state_tracker/st_cb_condrender.c \
state_tracker/st_cb_flush.c \
state_tracker/st_cb_drawpixels.c \
+ state_tracker/st_cb_eglimage.c \
state_tracker/st_cb_fbo.c \
state_tracker/st_cb_feedback.c \
state_tracker/st_cb_program.c \
diff --git a/src/mesa/state_tracker/st_cb_eglimage.c b/src/mesa/state_tracker/st_cb_eglimage.c
new file mode 100644
index 000..d8d9202
--- /dev/null
+++ b/src/mesa/state_tracker/st_cb_eglimage.c
@@ -0,0 +1,160 @@
+/*
+ * Mesa 3-D graphics library
+ * Version: 7.9
+ *
+ * Copyright (C) 2010 LunarG Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Softwar
Re: [Mesa3d-dev] Mesa (master): llvmpipe: fix up some questionable fence code
Brian,
Your fix is right. The last_fence variable was a remnant of some state
tracker code I based the change on, and had no place here.
Jose
On Wed, 2010-03-24 at 19:50 -0700, Brian Paul wrote:
> Module: Mesa
> Branch: master
> Commit: 9a5241758231b2dd5ae757645158fa33051f5507
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9a5241758231b2dd5ae757645158fa33051f5507
>
> Author: Brian Paul
> Date: Wed Mar 24 20:40:31 2010 -0600
>
> llvmpipe: fix up some questionable fence code
>
> Jose should probably review this since he wrote the original code.
>
> ---
>
> src/gallium/drivers/llvmpipe/lp_flush.c |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_flush.c
> b/src/gallium/drivers/llvmpipe/lp_flush.c
> index 636d72a..782669a 100644
> --- a/src/gallium/drivers/llvmpipe/lp_flush.c
> +++ b/src/gallium/drivers/llvmpipe/lp_flush.c
> @@ -111,7 +111,6 @@ llvmpipe_flush_texture(struct pipe_context *pipe,
> boolean cpu_access,
> boolean do_not_flush)
> {
> - struct pipe_fence_handle *last_fence = NULL;
> unsigned referenced;
>
> referenced = pipe->is_texture_referenced(pipe, texture, face, level);
> @@ -142,7 +141,7 @@ llvmpipe_flush_texture(struct pipe_context *pipe,
>
> pipe->flush(pipe, flush_flags, &fence);
>
> - if (last_fence) {
> + if (fence) {
> pipe->screen->fence_finish(pipe->screen, fence, 0);
> pipe->screen->fence_reference(pipe->screen, &fence, NULL);
> }
>
> ___
> mesa-commit mailing list
> mesa-com...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-commit
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH-RFC] st/mesa: Add GL_OES_EGL_image support
Hi Jakob, This patch series adds support for GL_OES_EGL_image to st/mesa. The first patch implements st_manager::get_egl_image in st/egl. The hook is used to check and return an st_egl_image, which describes an EGLImageKHR. The second patch implements GL_OES_EGL_image in st/mesa, and the last patch adds a demo for the new functionality. I've tested it with egl_x11_i915.so, but it should work with other hardware drivers. Do you mind having a look at the patches, especially the first one? I'd like to hear your opinions before merging the patches, and going on to work on EGLImage support in st/dri. -- o...@lunarg.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Move lists to freedesktop.org?
Jesse Barnes wrote: > On Thu, 4 Mar 2010 15:20:46 -0800 > Jesse Barnes wrote: > >> On Fri, 05 Mar 2010 00:16:45 +0100 >> Michel Dänzer wrote: >> >>> On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: Jesse Barnes wrote: > Would anyone have objections if these lists moved to freedesktop.org? > The recent thread with Linus about the drm pull request highlights the > post lag and non-subscriber aspect of the current lists, and that > leaves aside sf.net's horrible mail archive interface and poor > performance. > > If spam is an issue, another option would be vger.kernel.org. That > team runs lkml and several other very high traffic, high profile lists > and manages quite well; performance is always high and spam is nearly > non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. >>> Ditto for dri-devel. >>> BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? >>> Not really, the lists should still have their own admins. >>> >>> I've been going through the moderation queues for both lists on a daily >>> basis and am volunteering to continue doing so, but other than that I'm >>> not really keen on being a list admin. >> I don't have access to create the new lists, but Daniel or Tollef >> should. >> >> We may as well keep you guys as admins unless someone volunteers that >> you're ok with; but hopefully FDO will make the admin job a little >> easier/faster. > > Brian and Michel, did you guys get what you need to move the lists? > AFAIK Tollef created them, you just need to copy the subscriber lists > over and announce it I think? > > Thanks, If you are going to move the lists, could someone remember to put them on gmane. At least some of us prefer the newsgroup format. sean -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Status of s3tc patent in respect to open-source drivers and workarounds
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
[Mesa3d-dev] llvmpipe autoconf attempt one
I'm not even sure if its fully working, and I've done some nasty stuff in the autoconf.in that probably doesn't belong there, also the dri makefile change to use g++ instead of cc, not sure if there is a cleaner way to do that either. Dave. 0001-llvmpipe-add-initial-autoconf-support.patch Description: Binary data -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 27312] glCopyTexImage2D Doesnt seem to work correctly (returns incorrect alpha component )when internal format is GL_RGB
http://bugs.freedesktop.org/show_bug.cgi?id=27312 --- Comment #8 from Chia-I Wu 2010-03-28 01:51:22 PST --- (In reply to comment #0) > tmpBuf = (GLubyte *)malloc(4*sizeof(GLubyte)); > glReadPixels(12, 12, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, tmpBuf); > > /*## > ## > ## > tmpBuf[0]=tmpBuf[1]=tmpBuf[2] = 143 //Expected > tmpBuf[3] = 143 //Not expected - This should be 255 as we are not using this > component. I have checked this with other vendors NVIDIA and ATI and they > indeed report correct behavior (tmpBuf[3] = 255) > ## > ## > ##*/ I've tested the demo with current git head, using egl_x11_swrast driver and libGLESv2. It has the correct behavior (tmpBuf[3] is 255). Do you want to try again with git head or the to-be-released 7.8? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
