date:20100119

Re: [Mesa3d-dev] [PATCH] add dfrac, dfracexp, dldexp opcodes to gallium

2010-01-19 Thread michal

Igor Oliveira wrote on 2010-01-20 00:37:
> Hi,
>
> These patches add support to dfrac, dldexp and fracexp opcodes.
> The fracexp opcode i think it is the only opcode that use 2 DST registers.
> The first one is used to store the fractional part(it store in a
> double) and the second one is used to store the exponent part(it is a
> int).
> In the tests we can see it working.
>
>  static void
> +micro_dfrac(union tgsi_double_channel *dst,
> +const union tgsi_double_channel *src)
> +{
> +   dst->d[0] = src->d[0] - floor(src->d[0]);
> +   dst->d[1] = src->d[1] - floor(src->d[0]);
> +   dst->d[2] = src->d[2] - floor(src->d[0]);
> +   dst->d[3] = src->d[3] - floor(src->d[0])
Igor,

Shouldn't the second line have floor(src->d[1]), and so on?

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Is pipe transfer supposed to be temporary?

2010-01-19 Thread Chia-I Wu

2010/1/19 Michel Dänzer :
>> The ximage backend uses only softpipe and that is why I didn't notice that.
>> softpipe seems to work well with permanent pipe transfers, but I think it is
>> vital to use the interface correctly.
> If the ximage backend is intrinsically tied to softpipe, it's kind of
> legitimiate for it to rely on softpipe specific transfer semantics if
> that gives a tangible benefit, e.g. by saving transfer
> creation/destruction overhead.
Yes, that was why it was made permanent.  But I am in favor of making the
change to make the pipe transfer temporary right now.  I will leave it to
others who concern the performance of ximage backend enough to revert the
change :)

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [PATCH] object_purgeable-api-pbo: New testcase to simply exercise API

2010-01-19 Thread Shuang He

---
 tests/all.tests  |1 +
 tests/general/CMakeLists.txt |1 +
 tests/general/object_purgeable-api-pbo.c |  283 ++
 3 files changed, 285 insertions(+), 0 deletions(-)
 create mode 100644 tests/general/object_purgeable-api-pbo.c

diff --git a/tests/all.tests b/tests/all.tests
index cd1933d..6603a31 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -93,6 +93,7 @@ add_plain_test(general, 'linestipple')
 add_plain_test(general, 'occlusion_query')
 add_plain_test(general, 'object_purgeable-api-texture')
 add_plain_test(general, 'object_purgeable-api-vbo')
+add_plain_test(general, 'object_purgeable-api-pbo')
 add_plain_test(general, 'pbo-drawpixels')
 add_plain_test(general, 'pbo-read-argb')
 add_plain_test(general, 'pbo-teximage')
diff --git a/tests/general/CMakeLists.txt b/tests/general/CMakeLists.txt
index f2c2581..d2e3a20 100644
--- a/tests/general/CMakeLists.txt
+++ b/tests/general/CMakeLists.txt
@@ -51,3 +51,4 @@ add_executable (windowoverlap windowoverlap.c)
 add_executable (occlusion_query occlusion_query.c)
 add_executable (object_purgeable-api-texture object_purgeable-api-texture.c)
 add_executable (object_purgeable-api-vbo object_purgeable-api-vbo.c)
+add_executable (object_purgeable-api-pbo object_purgeable-api-pbo.c)
diff --git a/tests/general/object_purgeable-api-pbo.c 
b/tests/general/object_purgeable-api-pbo.c
new file mode 100644
index 000..bbea2c3
--- /dev/null
+++ b/tests/general/object_purgeable-api-pbo.c
@@ -0,0 +1,283 @@
+
+/*
+ * Copyright Â© 2010 Intel Corporation
+ *
+ * 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 Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Shuang He 
+ */
+
+/**
+ * \file object_purgeable-api-pbo.c
+ * Simple test of the API for GL_APPLE_object_purgeable with 
GL_ARB_pixel_buffer_object.
+ */
+
+#include "piglit-util.h"
+
+#define FAIL_ON_ERROR(string)  \
+do {   \
+const GLenum err = glGetError();   \
+if (err != GL_NO_ERROR) {  \
+fprintf(stderr, "%s generated error 0x%04x\n", \
+string, err);   \
+pass = GL_FALSE;   \
+}  \
+} while (0)
+
+#ifndef APIENTRY
+#define APIENTRY
+#endif
+#ifndef APIENTRYP
+#define APIENTRYP APIENTRY *
+#endif
+
+#ifndef GL_APPLE_object_purgeable
+#define GL_APPLE_object_purgeable 1
+
+#define GL_RELEASED_APPLE 0x8A19
+#define GL_VOLATILE_APPLE 0x8A1A
+#define GL_RETAINED_APPLE 0x8A1B
+#define GL_UNDEFINED_APPLE0x8A1C
+#define GL_PURGEABLE_APPLE0x8A1D
+#define GL_BUFFER_OBJECT_APPLE0x85B3
+
+typedef GLenum (APIENTRYP PFNGLOBJECTPURGEABLEAPPLEPROC) (GLenum objectType, 
GLuint name, GLenum option);
+typedef GLenum (APIENTRYP PFNGLOBJECTUNPURGEABLEAPPLEPROC) (GLenum objectType, 
GLuint name, GLenum option);
+typedef void (APIENTRYP PFNGLGETOBJECTPARAMETERIVAPPLEPROC) (GLenum 
objectType, GLuint name, GLenum pname, GLint* params);
+
+#endif
+
+#ifndef GL_ARB_pixel_buffer_object
+#define GL_ARB_pixel_buffer_object 1
+
+#define GL_PIXEL_PACK_BUFFER_ARB  0x88EB
+#define GL_STATIC_DRAW_ARB0x88E0
+
+typedef void (APIENTRYP PFNGLBINDBUFFERARBPROC) (GLenum target, GLuint buffer);
+typedef void (APIENTRYP PFNGLDELETEBUFFERSARBPROC) (GLsizei n, const GLuint 
*buffers);
+typedef void (APIENTRYP PFNGLGENBUFFERSARBPROC) (GLsizei n, GLuint *buffers);
+typedef void (APIENTRYP PFNGLBUFFERDATAARBPROC) (GLenum target, GLsizeiptrARB 
size, const void *data, GLenum usage);
+
+#endif
+
+// GL_APPLE_object_purgeable
+static PFNGLOBJECTPURGEABLEAPPLEPROC pglObjectPurgeableAPPLE = NULL;
+static PFNGLOBJECTUNPURGEABLE

[Mesa3d-dev] [PATCH 2/2] object_purgeable-api-vbo: New testcase to simply exercise API

2010-01-19 Thread Shuang He

---
 tests/all.tests  |1 +
 tests/general/CMakeLists.txt |1 +
 tests/general/object_purgeable-api-vbo.c |  283 ++
 3 files changed, 285 insertions(+), 0 deletions(-)
 create mode 100644 tests/general/object_purgeable-api-vbo.c

diff --git a/tests/all.tests b/tests/all.tests
index 99927d1..cd1933d 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -92,6 +92,7 @@ add_plain_test(general, 'draw-elements-base-vertex')
 add_plain_test(general, 'linestipple')
 add_plain_test(general, 'occlusion_query')
 add_plain_test(general, 'object_purgeable-api-texture')
+add_plain_test(general, 'object_purgeable-api-vbo')
 add_plain_test(general, 'pbo-drawpixels')
 add_plain_test(general, 'pbo-read-argb')
 add_plain_test(general, 'pbo-teximage')
diff --git a/tests/general/CMakeLists.txt b/tests/general/CMakeLists.txt
index d010946..f2c2581 100644
--- a/tests/general/CMakeLists.txt
+++ b/tests/general/CMakeLists.txt
@@ -50,3 +50,4 @@ add_executable (vbo-subdata-sync vbo-subdata-sync.c)
 add_executable (windowoverlap windowoverlap.c)
 add_executable (occlusion_query occlusion_query.c)
 add_executable (object_purgeable-api-texture object_purgeable-api-texture.c)
+add_executable (object_purgeable-api-vbo object_purgeable-api-vbo.c)
diff --git a/tests/general/object_purgeable-api-vbo.c 
b/tests/general/object_purgeable-api-vbo.c
new file mode 100644
index 000..29d1d3d
--- /dev/null
+++ b/tests/general/object_purgeable-api-vbo.c
@@ -0,0 +1,283 @@
+
+/*
+ * Copyright Â© 2010 Intel Corporation
+ *
+ * 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 Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Shuang He 
+ */
+
+/**
+ * \file object_purgeable-api-vbo.c
+ * Simple test of the API for GL_APPLE_object_purgeable with 
GL_ARB_vertex_buffer_object.
+ */
+
+#include "piglit-util.h"
+
+#define FAIL_ON_ERROR(string)  \
+do {   \
+const GLenum err = glGetError();   \
+if (err != GL_NO_ERROR) {  \
+fprintf(stderr, "%s generated error 0x%04x\n", \
+string, err);   \
+pass = GL_FALSE;   \
+}  \
+} while (0)
+
+#ifndef APIENTRY
+#define APIENTRY
+#endif
+#ifndef APIENTRYP
+#define APIENTRYP APIENTRY *
+#endif
+
+#ifndef GL_APPLE_object_purgeable
+#define GL_APPLE_object_purgeable 1
+
+#define GL_RELEASED_APPLE 0x8A19
+#define GL_VOLATILE_APPLE 0x8A1A
+#define GL_RETAINED_APPLE 0x8A1B
+#define GL_UNDEFINED_APPLE0x8A1C
+#define GL_PURGEABLE_APPLE0x8A1D
+#define GL_BUFFER_OBJECT_APPLE0x85B3
+
+typedef GLenum (APIENTRYP PFNGLOBJECTPURGEABLEAPPLEPROC) (GLenum objectType, 
GLuint name, GLenum option);
+typedef GLenum (APIENTRYP PFNGLOBJECTUNPURGEABLEAPPLEPROC) (GLenum objectType, 
GLuint name, GLenum option);
+typedef void (APIENTRYP PFNGLGETOBJECTPARAMETERIVAPPLEPROC) (GLenum 
objectType, GLuint name, GLenum pname, GLint* params);
+
+#endif
+
+#ifndef GL_ARB_vertex_buffer_object
+#define GL_ARB_vertex_buffer_object 1
+
+#define GL_ARRAY_BUFFER_ARB   0x8892
+#define GL_STATIC_DRAW_ARB0x88E0
+
+typedef void (APIENTRYP PFNGLBINDBUFFERARBPROC) (GLenum target, GLuint buffer);
+typedef void (APIENTRYP PFNGLDELETEBUFFERSARBPROC) (GLsizei n, const GLuint 
*buffers);
+typedef void (APIENTRYP PFNGLGENBUFFERSARBPROC) (GLsizei n, GLuint *buffers);
+typedef void (APIENTRYP PFNGLBUFFERDATAARBPROC) (GLenum target, GLsizeiptrARB 
size, const void *data, GLenum usage);
+
+#endif
+
+// GL_APPLE_object_purgeable
+static PFNGLOBJECTPURGEABLEAPPLEPROC pglObjectPurgeableAPPLE = NULL;
+static PFNGLOBJECTUNPURGEABLEAPPLEPROC pg

[Mesa3d-dev] [PATCH 1/2] object_purgeable-api-texture: New testcase to simply exercise API

2010-01-19 Thread Shuang He

---
 tests/all.tests  |1 +
 tests/general/CMakeLists.txt |1 +
 tests/general/object_purgeable-api-texture.c |  250 ++
 3 files changed, 252 insertions(+), 0 deletions(-)
 create mode 100644 tests/general/object_purgeable-api-texture.c

diff --git a/tests/all.tests b/tests/all.tests
index 42f93e2..99927d1 100644
--- a/tests/all.tests
+++ b/tests/all.tests
@@ -91,6 +91,7 @@ add_plain_test(general, 'dlist-fdo3129-02')
 add_plain_test(general, 'draw-elements-base-vertex')
 add_plain_test(general, 'linestipple')
 add_plain_test(general, 'occlusion_query')
+add_plain_test(general, 'object_purgeable-api-texture')
 add_plain_test(general, 'pbo-drawpixels')
 add_plain_test(general, 'pbo-read-argb')
 add_plain_test(general, 'pbo-teximage')
diff --git a/tests/general/CMakeLists.txt b/tests/general/CMakeLists.txt
index 73305ee..d010946 100644
--- a/tests/general/CMakeLists.txt
+++ b/tests/general/CMakeLists.txt
@@ -49,3 +49,4 @@ add_executable (vbo-map-remap vbo-map-remap.c)
 add_executable (vbo-subdata-sync vbo-subdata-sync.c)
 add_executable (windowoverlap windowoverlap.c)
 add_executable (occlusion_query occlusion_query.c)
+add_executable (object_purgeable-api-texture object_purgeable-api-texture.c)
diff --git a/tests/general/object_purgeable-api-texture.c 
b/tests/general/object_purgeable-api-texture.c
new file mode 100644
index 000..ff73d3c
--- /dev/null
+++ b/tests/general/object_purgeable-api-texture.c
@@ -0,0 +1,250 @@
+/*
+ * Copyright Â© 2010 Intel Corporation
+ *
+ * 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 Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Shuang He 
+ */
+
+/**
+ * \file object_purgeable-api-texture.c
+ * Simple test of the API for GL_APPLE_object_purgeable with texture object.
+ */
+
+#include "piglit-util.h"
+
+#define FAIL_ON_ERROR(string)  \
+do {   \
+const GLenum err = glGetError();   \
+if (err != GL_NO_ERROR) {  \
+fprintf(stderr, "%s generated error 0x%04x\n", \
+string, err);   \
+pass = GL_FALSE;   \
+}  \
+} while (0)
+
+#ifndef APIENTRY
+#define APIENTRY
+#endif
+#ifndef APIENTRYP
+#define APIENTRYP APIENTRY *
+#endif
+
+#ifndef GL_APPLE_object_purgeable
+#define GL_APPLE_object_purgeable 1
+
+#define GL_RELEASED_APPLE 0x8A19
+#define GL_VOLATILE_APPLE 0x8A1A
+#define GL_RETAINED_APPLE 0x8A1B
+#define GL_UNDEFINED_APPLE0x8A1C
+#define GL_PURGEABLE_APPLE0x8A1D
+#define GL_BUFFER_OBJECT_APPLE0x85B3
+
+
+typedef GLenum (APIENTRYP PFNGLOBJECTPURGEABLEAPPLEPROC) (GLenum objectType, 
GLuint name, GLenum option);
+typedef GLenum (APIENTRYP PFNGLOBJECTUNPURGEABLEAPPLEPROC) (GLenum objectType, 
GLuint name, GLenum option);
+typedef void (APIENTRYP PFNGLGETOBJECTPARAMETERIVAPPLEPROC) (GLenum 
objectType, GLuint name, GLenum pname, GLint* params);
+
+#endif
+
+
+static PFNGLOBJECTPURGEABLEAPPLEPROC pglObjectPurgeableAPPLE = NULL;
+static PFNGLOBJECTUNPURGEABLEAPPLEPROC pglObjectUnpurgeableAPPLE = NULL;
+static PFNGLGETOBJECTPARAMETERIVAPPLEPROC pglGetObjectParameterivAPPLE = NULL;
+
+static GLboolean Automatic = GL_FALSE;
+
+static void
+init(void)
+{
+piglit_require_extension("GL_APPLE_object_purgeable");
+
+pglObjectPurgeableAPPLE = (PFNGLOBJECTPURGEABLEAPPLEPROC) 
piglit_get_proc_address("glObjectPurgeableAPPLE");
+pglObjectUnpurgeableAPPLE = (PFNGLOBJECTUNPURGEABLEAPPLEPROC) 
piglit_get_proc_address("glObjectUnpurgeableAPPLE");
+pglGetObjectParameterivAPPLE = (PFNGLGETOBJECTPARAMETERIVAPPLEPROC) 
piglit_get_proc_address("glGetObjectParameterivA

Re: [Mesa3d-dev] New state tracker API discussion

2010-01-19 Thread Chia-I Wu

On Sun, Jan 17, 2010 at 10:24 AM, Chia-I Wu  wrote:
> I myself would like to see the st_visual and st_api->make_current issues
> resolved (listed as issue 1 and 3 in DESIGN file).
The DESIGN file is available at
http://cgit.freedesktop.org/~olv/st_api/tree/DESIGN

Other than issue 1 and 3, I would like to have some feedbacks about the
simplification of the resource lookup callbacks (issue 2).  The callbacks are
designed for future extensibility without breaking the ABI.  I think that is
not a concern right now, and it may be simplified.
> I also want to use a consistent variable naming in st_api.h.  Here is my
> preference
>
> * use smapi for "struct st_manager_api"
> * use stapi for "struct st_api"
> * use stfb/stdraw/stread for "struct st_framebuffer"
> * use stctx/stshare for "strcut st_context"
> * use statt for "enum st_framebuffer_attachment"
> In the state trackers or st managers, there might already be
> structs/enums to represent things like api, fb, ctx, or att.  Prefixing
> those in st_api.h help state trackers distinguish which of them they are
> refering to.
> I now also think "struct st_manager" might be a better name than
> "struct st_manager_api".  How does it sound?
And the naming issue.

They should be the remaining issues I would like to resolve for this round of
design.  I think others can be left for next round, after we start the work and
gain more insights.

-olv

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] New state tracker API discussion

2010-01-19 Thread Chia-I Wu

On Wed, Jan 20, 2010 at 10:55 AM, Jakob Bornecrantz
 wrote:
> On Wed, Jan 20, 2010 at 1:47 AM, Chia-I Wu  wrote:
>> On Wed, Jan 20, 2010 at 3:20 AM, Jakob Bornecrantz  wrote:
>>> On 18 jan 2010, at 03.14, Chia-I Wu wrote:
 On Sun, Jan 17, 2010 at 10:24 AM, Chia-I Wu  wrote:
> I myself would like to see the st_visual and st_api->make_current issues
> resolved (listed as issue 1 and 3 in DESIGN file).
 This is proposed change for issue 1 (st_visual separation)
 http://cgit.freedesktop.org/~olv/st_api/commit/?h=issue1-proposal&id=604f4e306c81cadab19c5136842712ca9c0f4b8c
 st_visual is embedded inside both st_context_config and
 st_framebuffer_config.
>>> So all of the special variables that you have in the different configs can
>>> easily derived from what you called available_buffers.
>>> so:
>>> ctx_conf::double_buffer = (mask & BACK_RIGHT_MASK) || (mask &
>>> BACK_LEFT_MASK);
>>> ctx_conf::stereo = (mask & BACK_RIGHT_MASK) || (mask & BACK_RIGHT_MASK);
>>> And the for the buffer selection in ES and VG the semantics are very clear:
>>> desired_render_buffer = (mask & BACK_RIGHT_MASK) ? BACK_RIGHT : FRONT_RIGHT;
>>> and for GL it pick what it renders to by itself.
>> There is a subtle difference.  Even when a pixmap drawble has a back buffer,
>> EGL requires the front buffer to be used.  Unless we lie in 
>> available_buffers,
>> the st will use the wrong buffer.
>>
>> I am fine moving available_buffers to the shared st_visual, and rename it to
>> probably buffer_mask.  It will more or less make st_context_config redundant,
>> but I think there are attributes or extensions that will require more than
>> st_visual (e.g. I want a context that supports pre-multiplied alpha?).
>>
>> I believe a single st_visual is enough, if we document how a field is used
>> between st_context and st_framebuffer: field X means st_framebuffer has X' 
>> and
>> it means the user wants X'' to st_context.  But, IMHO, it gives more 
>> confusions
>> than simplifications.
> We will burn those bridges when we come to it.
> I think we should start out small and then work up to a full feature
> set. I'm also leaning against moving egl specific bits of this api
> into egl_api.h or something just like with drm_api.h vs dri_api.h.
I am against that too.  What I would like to have is a way to express the
capabilities of the context/framebuffer _and_ a way to express the user's
desire for them.  It should be a generic idea.

That said, I think I can base on your patch, and add "render_buffer" to
st_visual.  How does that sound?
> Anyways I think that we should move forwards we actually implementing
> this, especial the core bits on both egl and another manager like dri.
> And then take it from there.
Agree.  Many design defects will surface in the early stage of the
implementation.  On my side, I want to start the work early February.  I will
start with OpenVG st and egl_g3d st manager first, to verify the design.

Since st_api can be implemented parallel to st_public.h, I think a possible
path is

1. implement st_api in all state trackers, and then
2. port all st managers to st_api, and then
3. remove st_public.h from state trackers

when we are confident with the design.

-olv

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] Add -I$(TOP)/src/mesa/shader needed when building shader/lex.yy.o

2010-01-19 Thread Alan Coopersmith

Brian Paul wrote:
> Alan Coopersmith wrote:
>> Signed-off-by: Alan Coopersmith 
>> ---
>>  src/mesa/sources.mak |1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
>> index a4d09c7..70fae92 100644
>> --- a/src/mesa/sources.mak
>> +++ b/src/mesa/sources.mak
>> @@ -377,5 +377,6 @@ GLSL_LIBS = \
>>  INCLUDE_DIRS = \
>>  -I$(TOP)/include \
>>  -I$(TOP)/src/mesa \
>> +-I$(TOP)/src/mesa/shader \
>>  -I$(TOP)/src/gallium/include \
>>  -I$(TOP)/src/gallium/auxiliary
> 
> Hmmm, why hasn't this been necessary before?
> 
> Can the #include in question be something like
> 
> #include "shader/foo.h"
> 
> instead?  That would follow the existing conventions.

I can't figure out why I'm hitting it and others aren't - attached
is a patch that changes the includes needed as suggested instead of
changing the -I flags.

-- 
-Alan Coopersmith-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

>From bc660d5a24e12fa5ab5b6b00c997dc4994f83880 Mon Sep 17 00:00:00 2001
From: Alan Coopersmith 
Date: Tue, 19 Jan 2010 19:01:03 -0800
Subject: [PATCH] Add "shader/" path to #include statements in shader parser/lexer sources

Signed-off-by: Alan Coopersmith 
---
 src/mesa/shader/lex.yy.c|   10 +-
 src/mesa/shader/program_lexer.l |   10 +-
 src/mesa/shader/program_parse.tab.c |   16 
 src/mesa/shader/program_parse.y |   14 +++---
 4 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/src/mesa/shader/lex.yy.c b/src/mesa/shader/lex.yy.c
index 68543ae..d1af35f 100644
--- a/src/mesa/shader/lex.yy.c
+++ b/src/mesa/shader/lex.yy.c
@@ -1043,12 +1043,12 @@ static yyconst flex_int16_t yy_chk[1368] =
  */
 #include "main/glheader.h"
 #include "main/imports.h"
-#include "prog_instruction.h"
-#include "prog_statevars.h"
+#include "shader/prog_instruction.h"
+#include "shader/prog_statevars.h"
 
-#include "symbol_table.h"
-#include "program_parser.h"
-#include "program_parse.tab.h"
+#include "shader/symbol_table.h"
+#include "shader/program_parser.h"
+#include "shader/program_parse.tab.h"
 
 #define require_ARB_vp (yyextra->mode == ARB_vertex)
 #define require_ARB_fp (yyextra->mode == ARB_fragment)
diff --git a/src/mesa/shader/program_lexer.l b/src/mesa/shader/program_lexer.l
index e2acb3c..83bc508 100644
--- a/src/mesa/shader/program_lexer.l
+++ b/src/mesa/shader/program_lexer.l
@@ -23,12 +23,12 @@
  */
 #include "main/glheader.h"
 #include "main/imports.h"
-#include "prog_instruction.h"
-#include "prog_statevars.h"
+#include "shader/prog_instruction.h"
+#include "shader/prog_statevars.h"
 
-#include "symbol_table.h"
-#include "program_parser.h"
-#include "program_parse.tab.h"
+#include "shader/symbol_table.h"
+#include "shader/program_parser.h"
+#include "shader/program_parse.tab.h"
 
 #define require_ARB_vp (yyextra->mode == ARB_vertex)
 #define require_ARB_fp (yyextra->mode == ARB_fragment)
diff --git a/src/mesa/shader/program_parse.tab.c b/src/mesa/shader/program_parse.tab.c
index b12dcee..2adfb40 100644
--- a/src/mesa/shader/program_parse.tab.c
+++ b/src/mesa/shader/program_parse.tab.c
@@ -98,14 +98,14 @@
 
 #include "main/mtypes.h"
 #include "main/imports.h"
-#include "program.h"
-#include "prog_parameter.h"
-#include "prog_parameter_layout.h"
-#include "prog_statevars.h"
-#include "prog_instruction.h"
-
-#include "symbol_table.h"
-#include "program_parser.h"
+#include "shader/program.h"
+#include "shader/prog_parameter.h"
+#include "shader/prog_parameter_layout.h"
+#include "shader/prog_statevars.h"
+#include "shader/prog_instruction.h"
+
+#include "shader/symbol_table.h"
+#include "shader/program_parser.h"
 
 extern void *yy_scan_string(char *);
 extern void yy_delete_buffer(void *);
diff --git a/src/mesa/shader/program_parse.y b/src/mesa/shader/program_parse.y
index 5c5d8d7..3880d54 100644
--- a/src/mesa/shader/program_parse.y
+++ b/src/mesa/shader/program_parse.y
@@ -27,14 +27,14 @@
 
 #include "main/mtypes.h"
 #include "main/imports.h"
-#include "program.h"
-#include "prog_parameter.h"
-#include "prog_parameter_layout.h"
-#include "prog_statevars.h"
-#include "prog_instruction.h"
-
-#include "symbol_table.h"
-#include "program_parser.h"
+#include "shader/program.h"
+#include "shader/prog_parameter.h"
+#include "shader/prog_parameter_layout.h"
+#include "shader/prog_statevars.h"
+#include "shader/prog_instruction.h"
+
+#include "shader/symbol_table.h"
+#include "shader/program_parser.h"
 
 extern void *yy_scan_string(char *);
 extern void yy_delete_buffer(void *);
-- 
1.5.6.5

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emergi

[Mesa3d-dev] [PATCH] Copy FUNCTION portability #defines from mesa/compiler.h to eglcompiler.h

2010-01-19 Thread Alan Coopersmith

Signed-off-by: Alan Coopersmith 
---
 src/egl/main/eglcompiler.h |   18 ++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/src/egl/main/eglcompiler.h b/src/egl/main/eglcompiler.h
index 5a3fb49..d844fbb 100644
--- a/src/egl/main/eglcompiler.h
+++ b/src/egl/main/eglcompiler.h
@@ -71,5 +71,23 @@
 #  define PUBLIC
 #endif
 
+/**
+ * The __FUNCTION__ gcc variable is generally only used for debugging.
+ * If we're not using gcc, define __FUNCTION__ as a cpp symbol here.
+ * Don't define it if using a newer Windows compiler.
+ */
+#ifndef __FUNCTION__
+# if defined(__VMS)
+#  define __FUNCTION__ "VMS$NL:"
+# elif ((!defined __GNUC__) || (__GNUC__ < 2)) && (!defined __xlC__) && \
+  (!defined(_MSC_VER) || _MSC_VER < 1300)
+#  if (__STDC_VERSION__ >= 199901L) /* C99 */ || \
+(defined(__SUNPRO_C) && defined(__C99FEATURES__))
+#   define __FUNCTION__ __func__
+#  else
+#   define __FUNCTION__ ""
+#  endif
+# endif
+#endif
 
 #endif /* EGLCOMPILER_INCLUDED */
-- 
1.5.6.5


--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [PATCH] gallium/i965: Make brw_batchbuffer prototypes match in source & header

2010-01-19 Thread Alan Coopersmith

Signed-off-by: Alan Coopersmith 
---
 src/gallium/drivers/i965/brw_batchbuffer.c |2 +-
 src/gallium/drivers/i965/brw_batchbuffer.h |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/i965/brw_batchbuffer.c 
b/src/gallium/drivers/i965/brw_batchbuffer.c
index 22607dc..003b1fd 100644
--- a/src/gallium/drivers/i965/brw_batchbuffer.c
+++ b/src/gallium/drivers/i965/brw_batchbuffer.c
@@ -155,7 +155,7 @@ _brw_batchbuffer_flush(struct brw_batchbuffer *batch,
 enum pipe_error
 brw_batchbuffer_emit_reloc(struct brw_batchbuffer *batch,
   struct brw_winsys_buffer *buffer,
-  uint32_t usage,
+  enum brw_buffer_usage usage,
   uint32_t delta)
 {
int ret;
diff --git a/src/gallium/drivers/i965/brw_batchbuffer.h 
b/src/gallium/drivers/i965/brw_batchbuffer.h
index 7473f5b..6ca9f61 100644
--- a/src/gallium/drivers/i965/brw_batchbuffer.h
+++ b/src/gallium/drivers/i965/brw_batchbuffer.h
@@ -64,12 +64,12 @@ brw_batchbuffer_reset(struct brw_batchbuffer *batch);
  * Consider it a convenience function wrapping multple
  * intel_buffer_dword() calls.
  */
-int brw_batchbuffer_data(struct brw_batchbuffer *batch,
+enum pipe_error brw_batchbuffer_data(struct brw_batchbuffer *batch,
 const void *data, GLuint bytes,
enum cliprect_mode cliprect_mode);
 
 
-int brw_batchbuffer_emit_reloc(struct brw_batchbuffer *batch,
+enum pipe_error brw_batchbuffer_emit_reloc(struct brw_batchbuffer *batch,
   struct brw_winsys_buffer *buffer,
   enum brw_buffer_usage usage,
   uint32_t offset);
-- 
1.5.6.5


--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] New state tracker API discussion

2010-01-19 Thread Jakob Bornecrantz

On Wed, Jan 20, 2010 at 1:47 AM, Chia-I Wu  wrote:
> On Wed, Jan 20, 2010 at 3:20 AM, Jakob Bornecrantz  wrote:
>> On 18 jan 2010, at 03.14, Chia-I Wu wrote:
>>> On Sun, Jan 17, 2010 at 10:24 AM, Chia-I Wu  wrote:
 I myself would like to see the st_visual and st_api->make_current issues
 resolved (listed as issue 1 and 3 in DESIGN file).
>>> This is proposed change for issue 1 (st_visual separation)
>>> http://cgit.freedesktop.org/~olv/st_api/commit/?h=issue1-proposal&id=604f4e306c81cadab19c5136842712ca9c0f4b8c
>>> st_visual is embedded inside both st_context_config and
>>> st_framebuffer_config.
>> So all of the special variables that you have in the different configs can
>> easily derived from what you called available_buffers.
>> so:
>> ctx_conf::double_buffer = (mask & BACK_RIGHT_MASK) || (mask &
>> BACK_LEFT_MASK);
>> ctx_conf::stereo = (mask & BACK_RIGHT_MASK) || (mask & BACK_RIGHT_MASK);
>> And the for the buffer selection in ES and VG the semantics are very clear:
>> desired_render_buffer = (mask & BACK_RIGHT_MASK) ? BACK_RIGHT : FRONT_RIGHT;
>> and for GL it pick what it renders to by itself.
> There is a subtle difference.  Even when a pixmap drawble has a back buffer,
> EGL requires the front buffer to be used.  Unless we lie in available_buffers,
> the st will use the wrong buffer.
>
> I am fine moving available_buffers to the shared st_visual, and rename it to
> probably buffer_mask.  It will more or less make st_context_config redundant,
> but I think there are attributes or extensions that will require more than
> st_visual (e.g. I want a context that supports pre-multiplied alpha?).
>
> I believe a single st_visual is enough, if we document how a field is used
> between st_context and st_framebuffer: field X means st_framebuffer has X' and
> it means the user wants X'' to st_context.  But, IMHO, it gives more 
> confusions
> than simplifications.

We will burn those bridges when we come to it.

I think we should start out small and then work up to a full feature
set. I'm also leaning against moving egl specific bits of this api
into egl_api.h or something just like with drm_api.h vs dri_api.h.

Anyways I think that we should move forwards we actually implementing
this, especial the core bits on both egl and another manager like dri.
And then take it from there.

Cheers Jakob.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Plans for EGL

2010-01-19 Thread Chia-I Wu

On Tue, Jan 12, 2010 at 12:23 PM, Chia-I Wu  wrote:
> I just pushed a new EGL driver (egl_g3d) to master.  The new driver is located
> at src/gallium/state_trackers/egl_g3d/.  When built, it provides .a archives
> that are later linked to by src/gallium/winsys/drm//egl_g3d/ to provide 
> the
> final EGL drivers loadable by libEGL.
> This new driver supports mixed client APIs (OpenGL, OpenVG, and OpenGL ES).  
> It
> supports both HW/SW rendering on X11 and supports EGL_MESA_screen_surface on
> bare KMS.  The goal of this driver is to provide _the_ EGL driver for Gallium
> architecture.
> I am working on merging opengl-es-v2 branch.  When that is done, I plan to 
> work
> on preparing EGL for easy/wide adoption.  The specific items I have right now
> are
I just merged opengl-es-v2 to master.  I will wait for a couple days, in case
there is any build problem or regression, and move on to EGL driver removal.

I will remove src/gallium/state_trackers/egl/ and rename egl_g3d to egl.  A new
egl_x11_swrast based on egl_g3d will replace egl_softpipe.  Most of the others
will be removed as mentioned.

There were some discussions with Jakob about demodriver, egl_dri, and egl_xdri.
I prefer demodriver to be removed, but I couldn't decide for the other two.
Suggestions?

-olv

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] opengl-es-v2 status and merge plan

2010-01-19 Thread Chia-I Wu

On Tue, Jan 19, 2010 at 11:15 AM, Chia-I Wu  wrote:
> On Fri, Jan 15, 2010 at 11:25 AM, Chia-I Wu  wrote:
>> I want to talk a little about the status of opengl-es-v2 branch and how I 
>> plan
>> to merge it.  If the timing is fine for everyone, I want to merge the branch 
>> to
>> master next Tuesday or Wednesday.
> If there is no objection, I am going to merge it tomorrow.  (roughly Tuesday
> night in U.S. time)
Merged.  There is a short guide at docs/opengles.html that might help get
started with it.

If anyone encounters any build problem or regression that might due to the
merge, please let me know.  I will solve them as soon as possible.

-olv

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] New state tracker API discussion

2010-01-19 Thread Chia-I Wu

On Wed, Jan 20, 2010 at 3:20 AM, Jakob Bornecrantz  wrote:
> On 18 jan 2010, at 03.14, Chia-I Wu wrote:
>> On Sun, Jan 17, 2010 at 10:24 AM, Chia-I Wu  wrote:
>>> I myself would like to see the st_visual and st_api->make_current issues
>>> resolved (listed as issue 1 and 3 in DESIGN file).
>> This is proposed change for issue 1 (st_visual separation)
>> http://cgit.freedesktop.org/~olv/st_api/commit/?h=issue1-proposal&id=604f4e306c81cadab19c5136842712ca9c0f4b8c
>> st_visual is embedded inside both st_context_config and
>> st_framebuffer_config.
> So all of the special variables that you have in the different configs can
> easily derived from what you called available_buffers.
> so:
> ctx_conf::double_buffer = (mask & BACK_RIGHT_MASK) || (mask &
> BACK_LEFT_MASK);
> ctx_conf::stereo = (mask & BACK_RIGHT_MASK) || (mask & BACK_RIGHT_MASK);
> And the for the buffer selection in ES and VG the semantics are very clear:
> desired_render_buffer = (mask & BACK_RIGHT_MASK) ? BACK_RIGHT : FRONT_RIGHT;
> and for GL it pick what it renders to by itself.
There is a subtle difference.  Even when a pixmap drawble has a back buffer,
EGL requires the front buffer to be used.  Unless we lie in available_buffers,
the st will use the wrong buffer.

I am fine moving available_buffers to the shared st_visual, and rename it to
probably buffer_mask.  It will more or less make st_context_config redundant,
but I think there are attributes or extensions that will require more than
st_visual (e.g. I want a context that supports pre-multiplied alpha?).

I believe a single st_visual is enough, if we document how a field is used
between st_context and st_framebuffer: field X means st_framebuffer has X' and
it means the user wants X'' to st_context.  But, IMHO, it gives more confusions
than simplifications.
> And if we happen to have a drawable with both back and front that we can
> always change the st_visual that is attached to the framebuffer.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26125] rendering artefacts

2010-01-19 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26125





--- Comment #2 from burlen   2010-01-19 18:14:30 PST 
---
notes: zooming in the artefacts recede toward the edges of the tubes, but never
go away completely. the thickness of the tubes are 0.075, some but not all of
the affected tubes are overlapping or very close to their neighbors.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration

2010-01-19 Thread Marek Olšák

Yes, your patch solves my problem. Thanks.

Marek

On Wed, Jan 20, 2010 at 2:00 AM, Brian Paul  wrote:

> Marek Olšák wrote:
>
>> Hi Brian,
>>
>>
>> On Mon, Jan 18, 2010 at 6:18 PM, Brian Paul > bri...@vmware.com>> wrote:
>>
>>The second patch enables hardware-accelerated CopyTex[Sub]Image
>>in cases when the RGB and RGBA destination formats are used
>>regardless of source formats. The idea is that if the
>>colorbuffer is of RGB or RGBA format, the format conversion for
>>copying between two different surfaces is basically done in
>>texture units (using swizzles), therefore there is no reason to
>>use software fallback. Without this patch, openarena fallbacks
>>to software when bloom is enabled.
>>
>>
>>Did you read the comment at line 1498?  I remember specifically
>>adding this check to fix some issues when copying an RGBA
>>framebuffer to a RGB texture.
>>
>>
>> The behavior of copying an RGBA framebuffer to an RGB texture is not
>> changed by this patch, it is only generalized to support other formats. I
>> agree the diff file is a little bit confusing. See the code before:
>>
>>   else if (srcFormat == GL_RGBA &&
>>dstLogicalFormat == GL_RGB) {
>>  /* Add a single special case to cope with RGBA->RGB transfers,
>>   * setting A to 1.0 to cope with situations where the RGB
>>   * destination is actually stored as RGBA.
>>   */
>>  return TGSI_WRITEMASK_XYZ; /* A ==> 1.0 */
>>   }
>>   else {
>>
>> The code after:
>>
>>   else if (dstLogicalFormat == GL_RGBA) {
>>  /* In theory, any format can be converted to GL_RGBA.
>>   */
>>  return TGSI_WRITEMASK_XYZW;
>>   }
>>   else if (dstLogicalFormat == GL_RGB) {
>>  /* Add a special case to cope with transfers into RGB,
>>   * setting A to 1.0 to cope with situations where the RGB
>>   * destination is actually stored as RGBA.
>>   */
>>  return TGSI_WRITEMASK_XYZ; /* A ==> 1.0 */
>>   }
>>   else {
>>
>> Are you ok with that?
>>
>
> No.  But don't feel bad, I think my original code is broken too. :(
>
> See the attached patch.  It has a bunch of comments that explain what's
> going on.
>
> If you can test this and it seems to solve your problem, I'll commit it.
>
>
>
>  BTW could you please push the first patch (and the second one if you
>> agree)? My account hasn't been created yet. Thank you.
>>
>
> Yes, done.
>
> -Brian
>
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26125] rendering artefacts

2010-01-19 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26125





--- Comment #1 from burlen   2010-01-19 18:11:24 PST 
---
Created an attachment (id=32732)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=32732)
shows hardware rendering of the same data--no artefacts


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26125] New: rendering artefacts

2010-01-19 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26125

   Summary: rendering artefacts
   Product: Mesa
   Version: 7.5
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa3d-dev@lists.sourceforge.net
ReportedBy: burlen.lor...@gmail.com
CC: burlen.lor...@gmail.com


Created an attachment (id=32731)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=32731)
shows artifacts appearing on on rendered surfaces

When rendering a certain set of stream tubes I see artefacts on the surfaces of
the tubes. Both mesa 7.5.1 and Mesa 7.7 exhibit. It doesn't happen when using
hardware rendering.

see that attached images


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [PATCH] Fix compressed texture loads for non-minimal pitches again

2010-01-19 Thread Luca Barbieri

My commit eea6a7639f767b1d30b6ef1f91a9c49e3f3b78f0 does a memcpy of height
lines, but that's wrong because the texture has a block layout and we
must thus use the number of vertical blocks instead of the height.
---
 src/mesa/state_tracker/st_cb_texture.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/mesa/state_tracker/st_cb_texture.c 
b/src/mesa/state_tracker/st_cb_texture.c
index d57304e..d5d3711 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -687,9 +687,11 @@ st_TexImage(GLcontext * ctx,
   {
  char *dst = texImage->Data;
  const char *src = pixels;
- int i;
+ GLuint i, bw, bh, lines;
+ _mesa_get_format_block_size(texImage->TexFormat, &bw, &bh);
+ lines = (height + bh - 1) / bh;
 
- for(i = 0; i < height; ++i)
+ for(i = 0; i < lines; ++i)
  {
 memcpy(dst, src, srcImageStride);
 dst += dstRowStride;
-- 
1.6.3.3


--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] New state tracker API discussion

2010-01-19 Thread Chia-I Wu

On Wed, Jan 20, 2010 at 3:22 AM, Jakob Bornecrantz  wrote:
> Forgot attachment:
At least we agree on the name "buffer_mask" :D

-olv

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] Supporting cards with OpenGL-like WPOS in hardware?

2010-01-19 Thread Luca Barbieri

Investigating a vertical flipping problem in Doom 3, I discovered that
fragment shader wpos handling is incorrect in the nv40 driver.

The issue is that nv40 provides a "position" register with OpenGL
semantics, so if TGSI_SEMANTIC_POSITION is directly wired to it (as
the nv40 driver incorrectly does currently), then the inversion
generated by the state tracker is counterproductive and causes
misrendering.
This can be confirmed with trivial/fp-tri position.txt

I'm not sure how to fix it though.
Clearly, the driver could try to invert it again itself, but it's
stupid to invert it twice, especially considering that the viewport
would be needed as input two times.
Detecting the inversion robustly (to remove it) in the driver is also
impossible because the driver cannot know that the constant in SUB
temp, const, wpos will be set as the window height. This is always
true for TGSI programs produced by Mesa, but not in general.

It seems that a Gallium interface change is necessary for optimal
results (i.e. a fragment program that directly uses the hardware
register).

I see the following options:
1. Add a TGSI_SEMANTIC_POSITION_YINVERTED register and have mesa st
use it. This requires to change all drivers.
2. Add a TGSI_SEMANTIC_FB_HEIGHT register and use it to invert the
position. This requires to change all drivers.
3. Add an "fb height" flag to const declarations or similar TGSI token
and have mesa st set it on its window height const. This does NOT
require to change all drivers, but there will be an unused constant
slot and it's somewhat ugly.
4. Assume that if a code sequence like the one used by mesa st to
invert wpos is present, the constant is the fb height and remove the
sequence. Assert on any other use of the position semantics. This
works right now and requires no changes in Mesa, Gallium, or other
drivers, but it's clearly not a good design.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration

2010-01-19 Thread Brian Paul


Marek Olšák wrote:

Hi Brian,

On Mon, Jan 18, 2010 at 6:18 PM, Brian Paul > wrote:


The second patch enables hardware-accelerated CopyTex[Sub]Image
in cases when the RGB and RGBA destination formats are used
regardless of source formats. The idea is that if the
colorbuffer is of RGB or RGBA format, the format conversion for
copying between two different surfaces is basically done in
texture units (using swizzles), therefore there is no reason to
use software fallback. Without this patch, openarena fallbacks
to software when bloom is enabled.


Did you read the comment at line 1498?  I remember specifically
adding this check to fix some issues when copying an RGBA
framebuffer to a RGB texture.


The behavior of copying an RGBA framebuffer to an RGB texture is not 
changed by this patch, it is only generalized to support other formats. 
I agree the diff file is a little bit confusing. See the code before:


   else if (srcFormat == GL_RGBA &&
dstLogicalFormat == GL_RGB) {
  /* Add a single special case to cope with RGBA->RGB transfers,
   * setting A to 1.0 to cope with situations where the RGB
   * destination is actually stored as RGBA.
   */
  return TGSI_WRITEMASK_XYZ; /* A ==> 1.0 */
   }
   else {

The code after:

   else if (dstLogicalFormat == GL_RGBA) {
  /* In theory, any format can be converted to GL_RGBA.
   */
  return TGSI_WRITEMASK_XYZW;
   }
   else if (dstLogicalFormat == GL_RGB) {
  /* Add a special case to cope with transfers into RGB,
   * setting A to 1.0 to cope with situations where the RGB
   * destination is actually stored as RGBA.
   */
  return TGSI_WRITEMASK_XYZ; /* A ==> 1.0 */
   }
   else {

Are you ok with that?


No.  But don't feel bad, I think my original code is broken too. :(

See the attached patch.  It has a bunch of comments that explain 
what's going on.


If you can test this and it seems to solve your problem, I'll commit it.


BTW could you please push the first patch (and the second one if you 
agree)? My account hasn't been created yet. Thank you.


Yes, done.

-Brian
diff --git a/src/mesa/state_tracker/st_cb_texture.c b/src/mesa/state_tracker/st_cb_texture.c
index f01053c..3f927b6 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -31,6 +31,7 @@
 #include "main/convolve.h"
 #endif
 #include "main/enums.h"
+#include "main/fbobject.h"
 #include "main/formats.h"
 #include "main/image.h"
 #include "main/imports.h"
@@ -1368,33 +1369,64 @@ fallback_copy_texsubimage(GLcontext *ctx, GLenum target, GLint level,
 }
 
 
+
+/**
+ * If the format of the src renderbuffer and the format of the dest
+ * texture are compatible (in terms of blitting), return a TGSI writemask
+ * to be used during the blit.
+ * If the src/dest are incompatible, return 0.
+ */
 static unsigned
-compatible_src_dst_formats(const struct gl_renderbuffer *src,
+compatible_src_dst_formats(GLcontext *ctx,
+   const struct gl_renderbuffer *src,
const struct gl_texture_image *dst)
 {
-   const GLenum srcFormat = _mesa_get_format_base_format(src->Format);
-   const GLenum dstLogicalFormat = _mesa_get_format_base_format(dst->TexFormat);
+   /* Get logical base formats for the src and dest.
+* That is, use the user-requested formats and not the actual, device-
+* chosen formats.
+* For example, the user may have requested an A8 texture but the
+* driver may actually be using an RGBA texture format.  When we
+* copy/blit to that texture, we only want to copy the Alpha channel
+* and not the RGB channels.
+*
+* Similarly, when the src FBO was created an RGB format may have been
+* requested but the driver actually chose an RGBA format.  In that case,
+* we don't want to copy the undefined Alpha channel to the dest texture
+* (it should be 1.0).
+*/
+   const GLenum srcFormat = _mesa_base_fbo_format(ctx, src->InternalFormat);
+   const GLenum dstFormat = _mesa_base_tex_format(ctx, dst->InternalFormat);
 
-   if (srcFormat == dstLogicalFormat) {
+   /**
+* XXX when we have red-only and red/green renderbuffers we'll need
+* to add more cases here (or implement a general-purpose routine that
+* queries the existance of the R,G,B,A channels in the src and dest).
+*/
+   if (srcFormat == dstFormat) {
   /* This is the same as matching_base_formats, which should
* always pass, as it did previously.
*/
   return TGSI_WRITEMASK_XYZW;
}
-   else if (srcFormat == GL_RGBA &&
-dstLogicalFormat == GL_RGB) {
-  /* Add a single special case to cope with RGBA->RGB transfers,
-   * setting A to 1.0 to cope with situations where the RGB
-   * destination is actually stored as RGBA.
+   else if (srcFormat == GL_RGB && dstFormat == GL_RGBA) {
+  /*

[Mesa3d-dev] [PATCH] add dfrac, dfracexp, dldexp opcodes to gallium

2010-01-19 Thread Igor Oliveira

Hi,

These patches add support to dfrac, dldexp and fracexp opcodes.
The fracexp opcode i think it is the only opcode that use 2 DST registers.
The first one is used to store the fractional part(it store in a
double) and the second one is used to store the exponent part(it is a
int).
In the tests we can see it working.

Igor

ps.: the next patch would be adding the opcodes in documentation file.
From c7731a40ab136fd98848f9155f9ce5ae3436 Mon Sep 17 00:00:00 2001
From: Igor Oliveira 
Date: Tue, 19 Jan 2010 17:01:50 -0400
Subject: [PATCH 1/5] gallium: add dfrac and dldexp opcodes

---
 src/gallium/include/pipe/p_shader_tokens.h |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/src/gallium/include/pipe/p_shader_tokens.h b/src/gallium/include/pipe/p_shader_tokens.h
index 15f8b0d..9ab18c4 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -334,7 +334,9 @@ struct tgsi_property_data {
 #define TGSI_OPCODE_DRCP157
 #define TGSI_OPCODE_DSQRT   158
 #define TGSI_OPCODE_DMAD159
-#define TGSI_OPCODE_LAST160
+#define TGSI_OPCODE_DFRAC   160
+#define TGSI_OPCODE_DLDEXP  161
+#define TGSI_OPCODE_LAST162
 
 #define TGSI_SAT_NONE0  /* do not saturate */
 #define TGSI_SAT_ZERO_ONE1  /* clamp to [0,1] */
-- 
1.6.3.3

From b6dccfaf8ee3941c341f09c6749a398bf684f196 Mon Sep 17 00:00:00 2001
From: Igor Oliveira 
Date: Tue, 19 Jan 2010 17:02:34 -0400
Subject: [PATCH 2/5] tgsi: implement DFRAC and DLDEXP opcode

---
 src/gallium/auxiliary/tgsi/tgsi_exec.c |   28 
 src/gallium/auxiliary/tgsi/tgsi_info.c |4 +++-
 2 files changed, 31 insertions(+), 1 deletions(-)

diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index f8a4468..b6abbeb 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -290,6 +290,26 @@ micro_dmad(union tgsi_double_channel *dst,
 }
 
 static void
+micro_dfrac(union tgsi_double_channel *dst,
+const union tgsi_double_channel *src)
+{
+   dst->d[0] = src->d[0] - floor(src->d[0]);
+   dst->d[1] = src->d[1] - floor(src->d[0]);
+   dst->d[2] = src->d[2] - floor(src->d[0]);
+   dst->d[3] = src->d[3] - floor(src->d[0]);
+}
+
+static void
+micro_dldexp(union tgsi_double_channel *dst,
+ const union tgsi_double_channel *src)
+{
+   dst->d[0] = ldexp(src[0].d[0], src[1].d[0]);
+   dst->d[1] = ldexp(src[0].d[1], src[1].d[1]);
+   dst->d[2] = ldexp(src[0].d[2], src[1].d[2]);
+   dst->d[3] = ldexp(src[0].d[3], src[1].d[3]);
+}
+
+static void
 micro_exp2(union tgsi_exec_channel *dst,
const union tgsi_exec_channel *src)
 {
@@ -3907,6 +3927,14 @@ exec_instruction(
   exec_double_trinary(mach, inst, micro_dmad);
   break;
 
+   case TGSI_OPCODE_DFRAC:
+  exec_double_unary(mach, inst, micro_dfrac);
+  break;
+
+   case TGSI_OPCODE_DLDEXP:
+  exec_double_binary(mach, inst, micro_dldexp);
+  break;
+
default:
   printf("%d", inst->Instruction.Opcode);
   assert( 0 );
diff --git a/src/gallium/auxiliary/tgsi/tgsi_info.c b/src/gallium/auxiliary/tgsi/tgsi_info.c
index 269ef73..8340b07 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_info.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_info.c
@@ -190,7 +190,9 @@ static const struct tgsi_opcode_info opcode_info[TGSI_OPCODE_LAST] =
{ 1, 2, 0, 0, 0, 0, "DSEQ", TGSI_OPCODE_DSEQ },
{ 1, 1, 0, 0, 0, 0, "DRCP", TGSI_OPCODE_DRCP },
{ 1, 1, 0, 0 ,0, 0, "DSQRT", TGSI_OPCODE_DSQRT },
-   { 1, 3, 0, 0 ,0, 0, "DMAD", TGSI_OPCODE_DMAD }
+   { 1, 3, 0, 0 ,0, 0, "DMAD", TGSI_OPCODE_DMAD },
+   { 1, 1, 0, 0, 0, 0, "DFRAC", TGSI_OPCODE_DFRAC},
+   { 1, 2, 0, 0, 0, 0, "DLDEXP", TGSI_OPCODE_DLDEXP}
 };
 
 const struct tgsi_opcode_info *
-- 
1.6.3.3

From 28f586f4a525043e3496086534d3b7c2cb657b77 Mon Sep 17 00:00:00 2001
From: Igor Oliveira 
Date: Tue, 19 Jan 2010 19:20:53 -0400
Subject: [PATCH 3/5] gallium: DFRACEXP opcode to tgsi

---
 src/gallium/include/pipe/p_shader_tokens.h |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/gallium/include/pipe/p_shader_tokens.h b/src/gallium/include/pipe/p_shader_tokens.h
index 9ab18c4..e0c191c 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -336,7 +336,8 @@ struct tgsi_property_data {
 #define TGSI_OPCODE_DMAD159
 #define TGSI_OPCODE_DFRAC   160
 #define TGSI_OPCODE_DLDEXP  161
-#define TGSI_OPCODE_LAST162
+#define TGSI_OPCODE_DFRACEXP162
+#define TGSI_OPCODE_LAST163
 
 #define TGSI_SAT_NONE0  /* do not saturate */
 #define TGSI_SAT_ZERO_ONE1  /* clamp to [0,1] */
-- 
1.6.3.3

From 8b7b6484c495f4d0b0b1a51942b73ad88deecece Mon Sep 17 00:00:00 2001
From: Igor Oliveira 
Date: Tue, 19 Jan 2010 19

Re: [Mesa3d-dev] [PATCH] Implement double opcodes: ddiv, dmul, dmax, dmin, dslt, dsge, dseq, drcp, dqsrt and dmad

2010-01-19 Thread Igor Oliveira

cool!
i saw that i lost a file in commit(tgsi_info.c and p_shader_tokens.h)
. But look likes that you fix it in branch. Thanks!

Igor

On Tue, Jan 19, 2010 at 8:34 AM, michal  wrote:
> Igor Oliveira wrote on 2010-01-18 19:55:
>>
>> The patches implement gallium opcodes ddiv, dmul, dmax, dmin, dslt,
>> dsge, dseq, drcp, dqsrt and dmad and add tests to it.
>> They are applicable in gallium-double-opcode  branch.
>> The next patchs i will add documentation and missing double opcodes
>> implementation like dfrac, dldexp and dfracexp.
>>
>>
>
> Excellent, commited with cosmetic changes.
>
> Thanks!
>

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration

2010-01-19 Thread Marek Olšák

Hi Brian,

On Mon, Jan 18, 2010 at 6:18 PM, Brian Paul  wrote:

> The second patch enables hardware-accelerated CopyTex[Sub]Image in cases
>> when the RGB and RGBA destination formats are used regardless of source
>> formats. The idea is that if the colorbuffer is of RGB or RGBA format, the
>> format conversion for copying between two different surfaces is basically
>> done in texture units (using swizzles), therefore there is no reason to use
>> software fallback. Without this patch, openarena fallbacks to software when
>> bloom is enabled.
>>
>
> Did you read the comment at line 1498?  I remember specifically adding this
> check to fix some issues when copying an RGBA framebuffer to a RGB texture.
>

The behavior of copying an RGBA framebuffer to an RGB texture is not changed
by this patch, it is only generalized to support other formats. I agree the
diff file is a little bit confusing. See the code before:

   else if (srcFormat == GL_RGBA &&
dstLogicalFormat == GL_RGB) {
  /* Add a single special case to cope with RGBA->RGB transfers,
   * setting A to 1.0 to cope with situations where the RGB
   * destination is actually stored as RGBA.
   */
  return TGSI_WRITEMASK_XYZ; /* A ==> 1.0 */
   }
   else {

The code after:

   else if (dstLogicalFormat == GL_RGBA) {
  /* In theory, any format can be converted to GL_RGBA.
   */
  return TGSI_WRITEMASK_XYZW;
   }
   else if (dstLogicalFormat == GL_RGB) {
  /* Add a special case to cope with transfers into RGB,
   * setting A to 1.0 to cope with situations where the RGB
   * destination is actually stored as RGBA.
   */
  return TGSI_WRITEMASK_XYZ; /* A ==> 1.0 */
   }
   else {

Are you ok with that?

BTW could you please push the first patch (and the second one if you agree)?
My account hasn't been created yet. Thank you.

Best regards.

Marek
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] New state tracker API discussion

2010-01-19 Thread Jakob Bornecrantz


On 19 jan 2010, at 19.20, Jakob Bornecrantz wrote:

On 18 jan 2010, at 03.14, Chia-I Wu wrote:
On Sun, Jan 17, 2010 at 10:24 AM, Chia-I Wu   
wrote:
I myself would like to see the st_visual and st_api->make_current  
issues

resolved (listed as issue 1 and 3 in DESIGN file).

This is proposed change for issue 1 (st_visual separation)

http://cgit.freedesktop.org/~olv/st_api/commit/?h=issue1-proposal&id=604f4e306c81cadab19c5136842712ca9c0f4b8c

st_visual is embedded inside both st_context_config and  
st_framebuffer_config.


So all of the special variables that you have in the different  
configs can easily derived from what you called available_buffers.


so:
ctx_conf::double_buffer = (mask & BACK_RIGHT_MASK) || (mask &  
BACK_LEFT_MASK);
ctx_conf::stereo = (mask & BACK_RIGHT_MASK) || (mask &  
BACK_RIGHT_MASK);


And the for the buffer selection in ES and VG the semantics are very  
clear:
desired_render_buffer = (mask & BACK_RIGHT_MASK) ? BACK_RIGHT :  
FRONT_RIGHT;

and for GL it pick what it renders to by itself.

And if we happen to have a drawable with both back and front that we  
can always change the st_visual that is attached to the framebuffer.


Forgot attachment:

Cheers Jakob.



0001-Remove-all-state-that-can-be-derived-from-the-buffer.patch
Description: Binary data


--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] New state tracker API discussion

2010-01-19 Thread Jakob Bornecrantz

On 18 jan 2010, at 03.14, Chia-I Wu wrote:
> On Sun, Jan 17, 2010 at 10:24 AM, Chia-I Wu  wrote:
>> I myself would like to see the st_visual and st_api->make_current  
>> issues
>> resolved (listed as issue 1 and 3 in DESIGN file).
> This is proposed change for issue 1 (st_visual separation)
>
> http://cgit.freedesktop.org/~olv/st_api/commit/?h=issue1-proposal&id=604f4e306c81cadab19c5136842712ca9c0f4b8c
>
> st_visual is embedded inside both st_context_config and  
> st_framebuffer_config.

So all of the special variables that you have in the different configs  
can easily derived from what you called available_buffers.

so:
ctx_conf::double_buffer = (mask & BACK_RIGHT_MASK) || (mask &  
BACK_LEFT_MASK);
ctx_conf::stereo = (mask & BACK_RIGHT_MASK) || (mask & BACK_RIGHT_MASK);

And the for the buffer selection in ES and VG the semantics are very  
clear:
desired_render_buffer = (mask & BACK_RIGHT_MASK) ? BACK_RIGHT :  
FRONT_RIGHT;
and for GL it pick what it renders to by itself.

And if we happen to have a drawable with both back and front that we  
can always change the st_visual that is attached to the framebuffer.

Cheers Jakob.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [xserver patch 6/6 v2] dri2: Support the DRI2InvalidateBuffers event.

2010-01-19 Thread Francisco Jerez

Bumps the supported DRI2 protocol version to 1.3.

Signed-off-by: Francisco Jerez 
---
v1 was evil because the multiple clients rendering to the same
drawable case wasn't handled correctly (sometimes it crashed). Seems
to work now.

 hw/xfree86/dri2/dri2.c  |  109 +++
 hw/xfree86/dri2/dri2.h  |5 ++
 hw/xfree86/dri2/dri2ext.c   |   36 +--
 include/protocol-versions.h |2 +-
 4 files changed, 147 insertions(+), 5 deletions(-)

diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 65433e9..82ecf28 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -52,6 +52,13 @@ static DevPrivateKey dri2WindowPrivateKey = 
&dri2WindowPrivateKeyIndex;
 static int dri2PixmapPrivateKeyIndex;
 static DevPrivateKey dri2PixmapPrivateKey = &dri2PixmapPrivateKeyIndex;
 
+typedef struct _DRI2ClientRef *DRI2ClientRefPtr;
+
+struct _DRI2ClientRef {
+DRI2ClientRefPtrnext;
+XID resource;
+};
+
 typedef struct _DRI2Drawable {
 unsigned intrefCount;
 int width;
@@ -65,6 +72,8 @@ typedef struct _DRI2Drawable {
 CARD64  target_sbc; /* -1 means no SBC wait outstanding */
 CARD64  last_swap_target; /* most recently queued swap target 
*/
 int swap_limit; /* for N-buffering */
+DRI2ClientRefPtrtrack_clients; /* Clients to notify on drawable 
changes. */
+
 } DRI2DrawableRec, *DRI2DrawablePtr;
 
 typedef struct _DRI2Screen *DRI2ScreenPtr;
@@ -83,6 +92,8 @@ typedef struct _DRI2Screen {
 DRI2ScheduleWaitMSCProcPtr  ScheduleWaitMSC;
 
 HandleExposuresProcPtr   HandleExposures;
+
+PreConfigureWindowProcPtrPreConfigureWindow;
 } DRI2ScreenRec;
 
 static DRI2ScreenPtr
@@ -142,6 +153,7 @@ DRI2CreateDrawable(DrawablePtr pDraw)
 pPriv->swap_interval = 1;
 pPriv->last_swap_target = -1;
 pPriv->swap_limit = 1; /* default to double buffering */
+pPriv->track_clients = NULL;
 
 if (pDraw->type == DRAWABLE_WINDOW)
 {
@@ -379,6 +391,78 @@ DRI2BlockClient(ClientPtr client, DrawablePtr pDraw)
 }
 }
 
+extern RESTYPE dri2DrawableRes;
+
+int
+DRI2TrackClient(DrawablePtr pDraw, int id)
+{
+DRI2DrawablePtr pPriv = DRI2GetDrawable(pDraw);
+DRI2ClientRefPtr ref;
+
+if (pPriv == NULL)
+   return BadDrawable;
+
+/* Check if the client is already in. */
+for (ref = pPriv->track_clients; ref; ref = ref->next) {
+   if (CLIENT_ID(ref->resource) == id)
+   return Success;
+}
+
+/* Allocate a client ref. */
+ref = xalloc(sizeof(*ref));
+if (ref == NULL)
+   return BadAlloc;
+
+ref->next = pPriv->track_clients;
+pPriv->track_clients = ref;
+
+/* Allocate a resource for it. */
+ref->resource = FakeClientID(id);
+if (!AddResource(ref->resource, dri2DrawableRes, pDraw))
+   return BadAlloc;
+
+return Success;
+}
+
+void
+DRI2UntrackClient(DrawablePtr pDraw, int id)
+{
+DRI2DrawablePtr pPriv = DRI2GetDrawable(pDraw);
+DRI2ClientRefPtr ref, *prev;
+
+if (pPriv == NULL)
+   return;
+
+prev = &pPriv->track_clients;
+
+for (ref = *prev; ref; prev = &ref->next, ref = ref->next) {
+   if (CLIENT_ID(ref->resource) == id) {
+   *prev = ref->next;
+   xfree(ref);
+   break;
+   }
+}
+}
+
+void
+DRI2InvalidateDrawable(DrawablePtr pDraw)
+{
+DRI2DrawablePtr pPriv = DRI2GetDrawable(pDraw);
+DRI2ClientRefPtr ref;
+
+if (pPriv == NULL)
+   return;
+
+while ((ref = pPriv->track_clients)) {
+   ClientPtr client = clients[CLIENT_ID(ref->resource)];
+
+   FreeResource(ref->resource, RT_NONE);
+
+   if (client && !client->clientGone)
+   DRI2InvalidateBuffersEvent(pDraw, client);
+}
+}
+
 int
 DRI2CopyRegion(DrawablePtr pDraw, RegionPtr pRegion,
   unsigned int dest, unsigned int src)
@@ -736,6 +820,7 @@ DRI2DestroyDrawable(DrawablePtr pDraw)
 DRI2DrawablePtr pPriv;
 WindowPtr  pWin;
 PixmapPtr  pPixmap;
+DRI2ClientRefPtr ref;
 
 pPriv = DRI2GetDrawable(pDraw);
 if (pPriv == NULL)
@@ -754,6 +839,9 @@ DRI2DestroyDrawable(DrawablePtr pDraw)
xfree(pPriv->buffers);
 }
 
+while ((ref = pPriv->track_clients))
+   FreeResource(ref->resource, RT_NONE);
+
 /* If the window is destroyed while we have a swap pending, don't
  * actually free the priv yet.  We'll need it in the DRI2SwapComplete()
  * callback and we'll free it there once we're done. */
@@ -802,6 +890,24 @@ DRI2Authenticate(ScreenPtr pScreen, drm_magic_t magic)
 return TRUE;
 }
 
+static void
+DRI2PreConfigureWindow(WindowPtr pWin, int x, int y, int w, int h, int bw,
+  WindowPtr pSib)
+{
+DrawablePtr pDraw = (DrawablePtr)pWin;
+ScreenPtr pScreen = pDraw->pScreen;
+DRI2ScreenPtr ds = DRI2GetScreen(pScreen);
+DRI2DrawablePtr dd = DRI2GetDrawable(pDraw);

[Mesa3d-dev] [Bug 26121] Crash on x86-64 (but not on x86) for glLightfv w/o rendering context

2010-01-19 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26121





--- Comment #1 from Tobias Burnus   
2010-01-19 08:41:36 PST ---
Cross-ref to the application (xcrysden) bug report:
http://www.democritos.it/pipermail/xcrysden/2010-January/000732.html


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

[Mesa3d-dev] [Bug 26121] New: Crash on x86-64 (but not on x86) for glLightfv w/o rendering context

2010-01-19 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=26121

   Summary: Crash on x86-64 (but not on x86) for glLightfv w/o
rendering context
   Product: Mesa
   Version: unspecified
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Mesa core
AssignedTo: mesa3d-dev@lists.sourceforge.net
ReportedBy: tobias.bur...@physik.fu-berlin.de


The problem was encountered using XCrySDen (http://www.xcrysden.org/) and
appears with both mesa-libGL-devel-6.5.1-9.fc6 and Mesa-7.7-5.3.x86_64 on
Linux.

The problem is that calling glLightfv without a rendering context crashes in
libGL x86-64 - while libGL x86 (i686) works. There seems to be a NULL pointer
check missing.

While the application should have a rendering context (I will report a bug), it
probably makes still sense to add a NULL check in Mesa.


$ cat test.c
#include 

int main ()
{
GLfloat ambient[4] = {0.2, 0.2, 0.2, 1.0};
glLightfv(GL_LIGHT0, GL_AMBIENT, ambient);
return 0;
}

$ gcc test.c -lGL && ./a.out
Segmentation fault
$ gcc -m32 test.c -lGL && ./a.out
$

See also:
http://sourceforge.net/mailarchive/message.php?msg_name=4B559729.3000509%40net-b.de
http://sourceforge.net/mailarchive/message.php?msg_name=4B55D3B5.9010506%40vmware.com


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] Set GL context to null in __glXSetCurrentContextNull

2010-01-19 Thread Brian Paul

Luca Barbieri wrote:
> __glXSetCurrentContextNull currently does not set the GL context to null
> in the direct rendering case.
> 
> This can result in a segfault trying to flush an invalid old context
> in glXMakeCurrent.
> 
> This fixes a crash starting the Unigine demos (they still don't work due
> to missing extensions though).

Committed.  Thanks.

-Brian

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] Implement double opcodes: ddiv, dmul, dmax, dmin, dslt, dsge, dseq, drcp, dqsrt and dmad

2010-01-19 Thread michal

Igor Oliveira wrote on 2010-01-18 19:55:
> The patches implement gallium opcodes ddiv, dmul, dmax, dmin, dslt,
> dsge, dseq, drcp, dqsrt and dmad and add tests to it.
> They are applicable in gallium-double-opcode  branch.
> The next patchs i will add documentation and missing double opcodes
> implementation like dfrac, dldexp and dfracexp.
>
>   

Excellent, commited with cosmetic changes.

Thanks!

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] Is pipe transfer supposed to be temporary?

2010-01-19 Thread Michel Dänzer

On Tue, 2010-01-19 at 11:10 +0800, Chia-I Wu wrote: 
> On Tue, Jan 19, 2010 at 10:21 AM, Younes Manton  wrote:
> > On Mon, Jan 18, 2010 at 9:10 PM, Chia-I Wu  wrote:
> >> On Tue, Jan 19, 2010 at 7:58 AM, Luca Barbieri  
> >> wrote:
> >>> The XImage backend keeps a transfer permanently and map/unmaps to do
> >>> modifications.
> >>> However, Gallium transfers can be implemented by making and keeping a
> >>> copy of the surface, flushing it back on transfer destruction.
> >>> Thus, it should be fixed to create and destroy a transfer every time
> >>> it maps the surface.
> >> Thanks, that should be an easy fix.
> >> But I do wonder if a pipe transfer is always supposed to be temporary?  Its
> >> operations, transfer_map and transfer_unmap, kind of hinted me that the 
> >> pipe
> >> transfer can be used repeatedly.
> > It was my understanding that the transfer happened on destroy and that
> > was how the nouveau implementations were written. You can probably
> > find the original thread, IIRC it was Michael Danzer that did the
> > interface and softpipe.

It's true that right now transfers are only expected to read data from
the GPU at creation time and write data to the GPU at destruction time.
As you guys discussed on IRC, at this point create/map and unmap/destroy
could probably be combined into a single operation each, but there are
more invasive changes to the transfer interfaces (making transfers
context operations pipelined wrt other drawing operations, changing the
data model to minimize copies) on the horizon, so it's probably not
worth bothering without addressing those.

That said:

> The ximage backend uses only softpipe and that is why I didn't notice that.
> softpipe seems to work well with permanent pipe transfers, but I think it is
> vital to use the interface correctly.

If the ximage backend is intrinsically tied to softpipe, it's kind of
legitimiate for it to rely on softpipe specific transfer semantics if
that gives a tangible benefit, e.g. by saving transfer
creation/destruction overhead.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Re: [Mesa3d-dev] [PATCH] add dfrac, dfracexp, dldexp opcodes to gallium

Re: [Mesa3d-dev] Is pipe transfer supposed to be temporary?

[Mesa3d-dev] [PATCH] object_purgeable-api-pbo: New testcase to simply exercise API

[Mesa3d-dev] [PATCH 2/2] object_purgeable-api-vbo: New testcase to simply exercise API

[Mesa3d-dev] [PATCH 1/2] object_purgeable-api-texture: New testcase to simply exercise API

Re: [Mesa3d-dev] New state tracker API discussion

Re: [Mesa3d-dev] New state tracker API discussion

Re: [Mesa3d-dev] [PATCH] Add -I$(TOP)/src/mesa/shader needed when building shader/lex.yy.o

[Mesa3d-dev] [PATCH] Copy FUNCTION portability #defines from mesa/compiler.h to eglcompiler.h

[Mesa3d-dev] [PATCH] gallium/i965: Make brw_batchbuffer prototypes match in source & header

Re: [Mesa3d-dev] New state tracker API discussion

Re: [Mesa3d-dev] Plans for EGL

Re: [Mesa3d-dev] opengl-es-v2 status and merge plan

Re: [Mesa3d-dev] New state tracker API discussion

[Mesa3d-dev] [Bug 26125] rendering artefacts

Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration

[Mesa3d-dev] [Bug 26125] rendering artefacts

[Mesa3d-dev] [Bug 26125] New: rendering artefacts

[Mesa3d-dev] [PATCH] Fix compressed texture loads for non-minimal pitches again

Re: [Mesa3d-dev] New state tracker API discussion

[Mesa3d-dev] Supporting cards with OpenGL-like WPOS in hardware?

Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration

[Mesa3d-dev] [PATCH] add dfrac, dfracexp, dldexp opcodes to gallium

Re: [Mesa3d-dev] [PATCH] Implement double opcodes: ddiv, dmul, dmax, dmin, dslt, dsge, dseq, drcp, dqsrt and dmad

Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration

Re: [Mesa3d-dev] New state tracker API discussion

Re: [Mesa3d-dev] New state tracker API discussion

[Mesa3d-dev] [xserver patch 6/6 v2] dri2: Support the DRI2InvalidateBuffers event.

[Mesa3d-dev] [Bug 26121] Crash on x86-64 (but not on x86) for glLightfv w/o rendering context

[Mesa3d-dev] [Bug 26121] New: Crash on x86-64 (but not on x86) for glLightfv w/o rendering context

Re: [Mesa3d-dev] [PATCH] Set GL context to null in __glXSetCurrentContextNull

Re: [Mesa3d-dev] [PATCH] Implement double opcodes: ddiv, dmul, dmax, dmin, dslt, dsge, dseq, drcp, dqsrt and dmad

Re: [Mesa3d-dev] Is pipe transfer supposed to be temporary?

33 matches

Site Navigation

Mail list logo

Footer information