Re: mesa 7.7.1 and 7.8.1 fails to compile under uclibc
Piotr Gluszenia Slawinski wrote: hello. problem as in topic. http://83.18.299.190/uclibc/ contain files which might add some light to subject :) it seems that problem is that _GNU_SOURCE is passed on (i know it from irc chat with someone bit more skilled) previous mesa versions compiled fine with uclibc http://pastebin.com/g20gCNxe following modification seems to fix the problem Did you forget an attachment? I don't see a difference in the code at the given URL. -Brian -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mesa 7.7.1 and 7.8.1 fails to compile under uclibc
On Thu, 27 May 2010, Brian Paul wrote: Piotr Gluszenia Slawinski wrote: hello. problem as in topic. http://83.18.299.190/uclibc/ contain files which might add some light to subject :) it seems that problem is that _GNU_SOURCE is passed on (i know it from irc chat with someone bit more skilled) previous mesa versions compiled fine with uclibc http://pastebin.com/g20gCNxe following modification seems to fix the problem Did you forget an attachment? I don't see a difference in the code at the given URL. -Brian basically 'fix' (or rather quick hack) goes down to line : #if defined(_GNU_SOURCE) !defined(__UCLIBC_MAJOR__) it should be ~801 line of original main/imports.c . while discussing it on #uclibc, conclusion was drawn that this is not very ellegant solution - program should check if locale are available, they can be both existant in uclibc, or missing in glibc (or elibc, libc5 , etc. implementation) - it is not considered 'given' part of libc. current 'fix' works for me though and allows at least uclibc users enjoy mesa :) Can you send a regular patch? I still don't understand what needs to be changed. -Brian -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Move lists to freedesktop.org?
Unless there's some objection I'm going to subscribe everyone to the new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list. Probably in the next 24 hours. Then, some of you may have to log into the mailman interface (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest mode, etc. -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.
Looks OK, but have you tested with Glean's clipFlat test? If it passes go ahead and commit. -Brian Marek Olšák wrote: The attached patches change softpipe and llvmpipe so that they never provoke the first vertex for quads. Please review. I think that these and the Corbin's one could be pushed by now, couldn't they? -Marek On Thu, Feb 11, 2010 at 4:03 PM, Brian Paul bri...@vmware.com mailto:bri...@vmware.com wrote: Corbin Simpson wrote: From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001 From: Corbin Simpson mostawesomed...@gmail.com mailto:mostawesomed...@gmail.com Date: Wed, 10 Feb 2010 10:39:18 -0800 Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex. Fixes glean/clipFlat. Softpipe might be broken; I haven't figured out how to test it in this new API world. :T --- src/mesa/state_tracker/st_extensions.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index d5f5854..e2d871b 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -137,6 +137,9 @@ void st_init_limits(struct st_context *st) /* XXX separate query for early function return? */ st-ctx-Shader.EmitContReturn = screen-get_param(screen, PIPE_CAP_TGSI_CONT_SUPPORTED); + + /* Quads always follow GL provoking rules. */ + c-QuadsFollowProvokingVertexConvention = GL_FALSE; } This causes the glean clipFlat test to fail with softpipe. The gallium softpipe driver _does_ implement the quad follows provoking vertex convention. I don't have time right now to update the softpipe driver so this patch will have to wait a while. Maybe someone else can look at it sooner. -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Mesa3d-dev mailing list mesa3d-...@lists.sourceforge.net mailto:mesa3d-...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
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. 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? -Brian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.
Corbin Simpson wrote: From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001 From: Corbin Simpson mostawesomed...@gmail.com Date: Wed, 10 Feb 2010 10:39:18 -0800 Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex. Fixes glean/clipFlat. Softpipe might be broken; I haven't figured out how to test it in this new API world. :T --- src/mesa/state_tracker/st_extensions.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index d5f5854..e2d871b 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -137,6 +137,9 @@ void st_init_limits(struct st_context *st) /* XXX separate query for early function return? */ st-ctx-Shader.EmitContReturn = screen-get_param(screen, PIPE_CAP_TGSI_CONT_SUPPORTED); + + /* Quads always follow GL provoking rules. */ + c-QuadsFollowProvokingVertexConvention = GL_FALSE; } This causes the glean clipFlat test to fail with softpipe. The gallium softpipe driver _does_ implement the quad follows provoking vertex convention. I don't have time right now to update the softpipe driver so this patch will have to wait a while. Maybe someone else can look at it sooner. -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] glean: Disable dithering for clipFlat.
Corbin Simpson wrote: From fe9c18cb5f4417558d40be7372c8bb74b613d470 Mon Sep 17 00:00:00 2001 From: Corbin Simpson mostawesomed...@gmail.com Date: Wed, 10 Feb 2010 10:56:56 -0800 Subject: [PATCH] glean: Disable dithering for clipFlat. Allows r300g to handily pass. Applied upstream to Glean. Thanks. -Brian -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Sedat Dilek wrote: Hi, this patch fixes a build-error in mesa GIT master after... commit251363e8f1287b54dc7734e690daf2ae96728faf (patch) configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster From my build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 Might be introduced in... commit955f51270bb60ad77dba049799587dc7c0fb4dda Make sure we use only signed/unsigned ints with bitfields. Kind Regars, - Sedat - I just fixed that. -Brian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
r300_translate_tex_filters() was missing the is_anisotropic parameter. I fixed that, but there may be other issues. Looks like some of the r300 code isn't c99. -Brian Sedat Dilek wrote: OK. That's the next one :-) ... In file included from r300_emit.c:36: r300_state_inlines.h: In function ‘r300_translate_tex_filters’: r300_state_inlines.h:263: error: ‘is_anisotropic’ undeclared (first use in this function) r300_state_inlines.h:263: error: (Each undeclared identifier is reported only once r300_state_inlines.h:263: error: for each function it appears in.) make: *** [r300_emit.o] Error 1 ... I am having dinner, now - Sedat - On Wed, Jan 6, 2010 at 6:07 PM, Brian Paul bri...@vmware.com wrote: Sedat Dilek wrote: Hi, this patch fixes a build-error in mesa GIT master after... commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster From my build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 Might be introduced in... commit 955f51270bb60ad77dba049799587dc7c0fb4dda Make sure we use only signed/unsigned ints with bitfields. Kind Regars, - Sedat - I just fixed that. -Brian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] Fixes after Merge branch 'glsl-pp-rework-2'
Sedat Dilek wrote: Patches already sent to dri-devel ML [1]. Forgot to CC to mesa3d-dev. - Sedat - [1] http://marc.info/?l=dri-develm=126107525213315w=2 -- Forwarded message -- From: Sedat Dilek sedat.di...@googlemail.com Date: Thu, Dec 17, 2009 at 7:21 PM Subject: [mesa] Fixes after Merge branch 'glsl-pp-rework-2' To: DRI dri-devel@lists.sourceforge.net Here two patches fixing mesa GIT master after: commit e195eab9093d2a6cf55a42b2e7789c9a381b7782 Merge branch 'glsl-pp-rework-2' (Thanks to Ghworg on IRC) - Sedat - Committed. Thanks. -Brian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 3/4] APPLE_object_purgeable: core
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Wilson wrote:
diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
index 52c4995..08633a9 100644
--- a/src/mesa/main/bufferobj.c
+++ b/src/mesa/main/bufferobj.c
@@ -37,6 +37,8 @@
#include image.h
#include context.h
#include bufferobj.h
+#include fbobject.h
+#include texobj.h
/* Debug flags */
@@ -1655,3 +1657,351 @@ _mesa_FlushMappedBufferRange(GLenum target, GLintptr
offset, GLsizeiptr length)
if (ctx-Driver.FlushMappedBufferRange)
ctx-Driver.FlushMappedBufferRange(ctx, target, offset, length,
bufObj);
}
+
+#if FEATURE_APPLE_object_purgeable
+static GLenum
+_mesa_RenderObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
+{
+ struct gl_renderbuffer *bufObj;
+ GLenum retval;
+
+ bufObj = _mesa_lookup_renderbuffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glObjectUnpurgeable(name = 0x%x), name);
+ return 0;
+ }
+
+ if (bufObj-Purgeable) {
+ _mesa_error(ctx, GL_INVALID_OPERATION,
+ glObjectPurgeable(name = 0x%x) is already purgeable,
name);
+ return GL_VOLATILE_APPLE;
+ }
+
+ bufObj-Purgeable = GL_TRUE;
+
+ retval = GL_VOLATILE_APPLE;
+ if (ctx-Driver.ObjectPurgeable_RenderObject)
+ retval = ctx-Driver.ObjectPurgeable_RenderObject(ctx, bufObj,
option);
+
+ return retval;
+}
+
+static GLenum
+_mesa_TextureObjectPurgeable(GLcontext *ctx, GLuint name, GLenum option)
Usually, only functions that are connected directly to the dispatch
table get camel case. Functions that are only used internally are
usually named _mesa_texture_object_purgeable.
I don't know if it's worth changing these. Brian may have an opinion
about this.
Yes, that's what I'd prefer.
The idea is if you're looking for code related to glBindTexture() you
can grep for BindTexture, for example.
When I see _mesa_TextureObjectPurgeable() I'm thinking is there an
API entrypoint named glTextureObjectPurgeable()? (there isn't)
-Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: APPLE_object_purgeable [v2]
Chris, It looks like this extension depends on the drm_intel_bo_madvise() function which isn't in a released version of libdrm yet. Correct? If so, I'd like to hold off on applying this patch to Mesa until there's a new libdrm. -Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [PATCH 3/4] APPLE_object_purgeable: core
One minor thing here:
+void GLAPIENTRY
+_mesa_GetObjectParameterivAPPLE(GLenum objectType, GLuint name, GLenum pname,
GLint* params)
+{
+ GET_CURRENT_CONTEXT(ctx);
+ struct gl_buffer_object *bufObj;
+
+ switch (objectType) {
+ case GL_TEXTURE:
+ case GL_BUFFER_OBJECT_APPLE:
+ case GL_RENDERBUFFER_EXT:
+ break;
+
+ default:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ glGetObjectParameteriv(name = 0x%x) invalid type: %d,
name, objectType);
+ return;
+ }
+
+ if (name == 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glGetObjectParameteriv(name = 0x%x), name);
+ return;
+ }
+
+ bufObj = get_buffer(ctx, name);
+ if (!bufObj) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glGetObjectParameteriv(name = 0x%x) invalid object, name);
+ return;
+ }
+
+ switch (pname) {
+ case GL_PURGEABLE_APPLE:
+ *params = !! bufObj-Purgeable;
Remove the double-not !!
-Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [PATCH 1/2] APPLE_object_purgeable
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h index 94d29a7..82d6e30 100644 --- a/src/mesa/main/mtypes.h +++ b/src/mesa/main/mtypes.h @@ -1410,6 +1410,7 @@ struct gl_buffer_object GLsizeiptr Length; /** Mapped length */ /*...@}*/ GLboolean Written; /** Ever written to? (for debugging) */ + GLenum purgeable;/** Purgeable status of the buffer */ Again, this should be a boolean. The enum is only used by the driver. And please capitalize Purgeable to be consistent with the other fields. -Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)
Robert Noland wrote:
Build was broken by commit 9666529b5a5be1fcde82caadc2fe2efa5ea81e49
I'm not certain that this is entirely the correct fix since the demo
from bug #23774 seemed to work before the commit that broke the build.
Signed-off-by: Robert Noland rnol...@2hip.net
---
src/glx/x11/glxhash.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/glx/x11/glxhash.c b/src/glx/x11/glxhash.c
index 7d28ada..dcf8c98 100644
--- a/src/glx/x11/glxhash.c
+++ b/src/glx/x11/glxhash.c
@@ -87,6 +87,12 @@
#define HASH_ALLOC malloc
#define HASH_FREE free
+#ifndef __GLIBC__
+#define HASH_RANDOM_DECL char *ps, rs[256]
+#define HASH_RANDOM_INIT(seed) ps = initstate(seed, rs, sizeof(rs))
+#define HASH_RANDOM random()
+#define HASH_RANDOM_DESTROY setstate(ps)
+#else
#define HASH_RANDOM_DECL struct random_data rd; int32_t rv; char rs[256]
#define HASH_RANDOM_INIT(seed) \
do { \
@@ -95,6 +101,7 @@
} while(0)
#define HASH_RANDOM ((void) random_r(rd, rv), rv)
#define HASH_RANDOM_DESTROY
+#endif
typedef struct __glxHashBucket
{
I was just looking at this after my coworker found the build failure
on MacOS.
Would nrand48() be a more portable option? Ian?
See http://evanjones.ca/random-thread-safe.html
-Brian
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: bisected engine demo
Robert Noland wrote: The following commit causes texture issues on r600 at least, I haven't tried other hardware currently. Running engine demo starts out correctly, but when cycling 'm' the issue appears. bcb62ae78a9d2f4d08001e9f207b6f1291443968 is first bad commit commit bcb62ae78a9d2f4d08001e9f207b6f1291443968 Author: Brian Paul bri...@vmware.com Date: Thu Sep 3 21:27:06 2009 -0600 mesa: _mesa_meta_bitmap() function :04 04 59187a621eb3c63005926ba958fa0ad610ddbb88 eb4da44a186e7f90c07b64a0abf7e1307e015c25 M src This can't possibly be the right commit since at that point in the history, nobody calls that function yet. That said, I found a bug in the code which probably causes the textured bitmap bug. I've committed it to master. -Brian -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [PATCH] mesa/st: Initialize format bits of framebuffer renderbuffers
Nicolai Hähnle wrote:
From 471cf346d0e9bf0bd97f2e652fd3052ba8f7a0c7 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Nicolai=20H=C3=A4hnle?= nhaeh...@gmail.com
Date: Sat, 12 Sep 2009 12:13:35 +0200
Subject: [PATCH] mesa/st: Initialize format bits of framebuffer renderbuffers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Nicolai Hähnle nhaeh...@gmail.com
---
src/mesa/state_tracker/st_cb_fbo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index a966028..aad8493 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -258,8 +258,9 @@ st_new_renderbuffer_fb(enum pipe_format format, int
samples, boolean sw)
strb-Base.ClassID = 0x4242; /* just a unique value */
strb-Base.NumSamples = samples;
strb-format = format;
+ init_renderbuffer_bits(strb, format);
strb-software = sw;
switch (format) {
case PIPE_FORMAT_A8R8G8B8_UNORM:
case PIPE_FORMAT_B8G8R8A8_UNORM:
Looks good. This should probably go on the 7.5 branch.
-Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] mesa/st: Create front renderbuffer on the fly when supplied
Nicolai Hähnle wrote:
From f08d6efbc85609d1384006b773ea0a3276eb1e67 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Nicolai=20H=C3=A4hnle?= nhaeh...@gmail.com
Date: Sat, 12 Sep 2009 16:49:31 +0200
Subject: [PATCH] mesa/st: Create front renderbuffer on the fly when supplied
with a surface
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Normally, the mesa/st would create a fake front buffer out of a
client-allocated surface.
In the DRI setting, however, st/dri provides a front buffer surface which is
created and maintained by the X server. Prefer to use this surface instead,
so that front buffer rendering and reading works correctly.
Signed-off-by: Nicolai Hähnle nhaeh...@gmail.com
---
src/mesa/state_tracker/st_framebuffer.c | 18 +++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_framebuffer.c
b/src/mesa/state_tracker/st_framebuffer.c
index ca32b2e..5c0d335 100644
--- a/src/mesa/state_tracker/st_framebuffer.c
+++ b/src/mesa/state_tracker/st_framebuffer.c
@@ -66,7 +66,7 @@ st_create_framebuffer( const __GLcontextModes *visual,
else {
/* Only allocate front buffer right now if we're single buffered.
* If double-buffered, allocate front buffer on demand later.
- * See check_create_front_buffers().
+ * See check_create_front_buffers() and
st_set_framebuffer_surface().
*/
struct gl_renderbuffer *rb
= st_new_renderbuffer_fb(colorFormat, samples, FALSE);
@@ -170,8 +170,20 @@ st_set_framebuffer_surface(struct st_framebuffer *stfb,
strb = st_renderbuffer(stfb-Base.Attachment[surfIndex].Renderbuffer);
- /* fail */
- if (!strb) return;
+ if (!strb) {
+ if (surfIndex == ST_SURFACE_FRONT_LEFT) {
+ /* Delayed creation when the window system supplies a fake front
buffer */
+ struct st_renderbuffer *strb_back
+= st_renderbuffer(stfb-
Base.Attachment[ST_SURFACE_BACK_LEFT].Renderbuffer);
+ struct gl_renderbuffer *rb
+= st_new_renderbuffer_fb(surf-format, strb_back-
Base.NumSamples, FALSE);
+ _mesa_add_renderbuffer(stfb-Base, BUFFER_FRONT_LEFT, rb);
+ strb = st_renderbuffer(rb);
+ } else {
+ /* fail */
+ return;
+ }
+ }
/* replace the renderbuffer's surface/texture pointers */
pipe_surface_reference( strb-surface, surf );
I think this looks good too. It should probaby go on the 7.6 branch.
-Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Partial updates with glX/DRI
Roland Scheidegger wrote: On 21.08.2009 11:45, Tom Cooksey wrote: Hello, I'm a Qt developer. We want all Qt rendering to be done using OpenGL 2. We have this working pretty well (a few artifacts still here and there). However, we've found some fundamental problems using GL for regular widget rendering. Normally I wouldn't bother this list, but I've recently seen that someone's writing a new GL back end to Cairo, so I guess those guys are going to hit the exact same issues. The problem is partial updates. From what we've seen it's typical for applications to only update a small region of their top-level-widget at a time (E.g. a flashing cursor in a text edit). As Qt only creates a single X window per top-level widget, this means a sub-region of a single X window. When using glX, we have no guarantee over what state the back buffer will be in after swap buffers. So, whenever an application needs to update, it must re- render the entire window. This makes things slow (we have to invoke every child widget's paint event). To overcome this, we try to use a 3rd buffer as a back buffer, usually a multi-sampled FBO or PBuffer. We direct rendering to the FBO/PBuffer, bind it as a texture (after blitting it to a non multi-sampled FBO if needed), draw the whole buffer to the window's back buffer then call swap buffers. Eughhh! But at least the PBuffer/FBO contents aren't destroyed. What would be really nice is to be able to have an EGL_SWAP_BEHAVIOR == EGL_BUFFER_PRESERVED equivalent on glX. I notice there's an EGL implementation being worked on in Mesa trunk so perhaps we should switch to EGL rather than glX? Anyway, lets assume that swap buffers keeps the contents of the back buffer. There's another issue, although not as detrimental as the first. When we issue swap buffers, glX/EGL has to assume the entire window's contents has changed. That has 2 effects: 1) XDamage regions are generated for the whole window: When a composition manager is running, this means it has to re-compose the entire window, even though only a few pixels may have changed (which it might have to do anyway, see above :-)). 2) I'm led to believe that DRI2 implements swap buffers as a blit and so must blit the entire back buffer to the front. I think I can work around this by making a glx context current on a GLXPixamp (from a XPixmap). Pixmaps are single buffered and so don't get destroyed on swap buffers (in fact I don't even call swap buffers). I can then post updates using XCopyArea which will also cause the Xserver to generate an appropriate XDamage region for the compositor. The only down side is that I have to glFinish before calling XCopyArea. While I have this working, it seems a little hacky and isn't widely supported (I have it working on 1 driver build for 1 bit of hardware). It seems like a glXSwapPartialBuffers which takes an array of dirty rects would be preferable. The implementation could ignore the rects completely if it so chooses or only use them to generate the damage region. Or, if it's on DRI2, it can choose to only copy the sub-region from the back to the front. Eventually it could also use the rects as a metric to figure out if it should flip or blit (flip if there's 30% region changed, blit otherwise). Would glx_mesa_copy_sub_buffer help? It only takes one rect though, not a list. BTW, a region of the back buffer can be copied to the front buffer with glCopyPixels() or glBlitFramebuffer() too. -Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] fix not including r300 compiler in tarballs
Thierry Vignaud wrote: Thierry Vignaud tvign...@mandriva.com writes: Thierry Vignaud tvign...@mandriva.com writes: The following patch fixes missing r300 compiler in generated tarballs: diff --git a/src/mesa/drivers/dri/r300/Makefile b/src/mesa/drivers/dri/r300/Makefile index 95c6765..3bce7d2 100644 --- a/src/mesa/drivers/dri/r300/Makefile +++ b/src/mesa/drivers/dri/r300/Makefile @@ -40,6 +40,7 @@ RADEON_COMMON_SOURCES = \ DRIVER_SOURCES = \ radeon_screen.c \ +compiler \ r300_context.c \ r300_draw.c \ r300_ioctl.c \ oops, looks like I send the wrong patch: diff --git a/Makefile b/Makefile index 220676f..bd45c01 100644 --- a/Makefile +++ b/Makefile @@ -345,6 +345,7 @@ DRI_FILES = \ $(DIRECTORY)/src/mesa/drivers/dri/common/xmlpool/*.[ch] \ $(DIRECTORY)/src/mesa/drivers/dri/common/xmlpool/*.po \ $(DIRECTORY)/src/mesa/drivers/dri/*/*.[chS] \ +$(DIRECTORY)/src/mesa/drivers/dri/*/*/*.[chS] \ $(DIRECTORY)/src/mesa/drivers/dri/*/Makefile\ $(DIRECTORY)/src/mesa/drivers/dri/*/Doxyfile\ $(DIRECTORY)/src/mesa/drivers/dri/*/server/*.[ch] as weel as the bs bits: Committed. Thanks. -Brian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: About Gallium3D Co.
Beyond the wiki info, you'll just have to read the code. If you have specific questions, ask them on the mesa3d-dev list. -Brian Uros Nedic wrote: Thank you for the link. I do not want to diminish your effort for helping me, but it is not documentation. It is just collection of some notes and links (some of them are even empty). Presentation file is from 2007 and it is just 'presentation file'. I would like to read more deep dive stuffs. Plan to spend all august learning all those stuffs to be able to write high quality drivers for Gallium3D architecture. Best, Uros Nedic Belgrade, Serbia Date: Mon, 27 Jul 2009 15:53:57 -0600 From: bri...@vmware.com To: ur...@live.com CC: dri-devel@lists.sourceforge.net Subject: Re: About Gallium3D Co. Uros Nedic wrote: I would like to ask you for documentation about Gallium3D and DRI architectures. Some documentation with detailed description of TGSI and LLVM is also welcome. http://wiki.freedesktop.org/wiki/Software/gallium -Brian _ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] r128: handle two-sided lighting correctly
Péteri András wrote: The olight application from the OpenGL GLUT examples [1] crashes with a segmentation fault straight after turning off two-sided ligthing. A backtrace from a debug build shows that function pointers still point to the [line|triangle|quadr]_twoside routines after switching to one-sided mode, and, most likely, the backside color pointer is invalid by then: Thanks for the patch. I don't think too many people are using the r128 driver anymore but I'm committing your fix. -Brian -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GLX makeCurrent in glean vs broken X server glxAllContexts linked list
Allen Akin wrote: On Fri, Jun 12, 2009 at 10:25:42AM +1000, Dave Airlie wrote: | On Fri, Jun 12, 2009 at 10:01 AM, Allen Akina...@pobox.com wrote: | On the other hand, if there's no mechanism for implicitly flushing the | GL command stream on window teardown, then whatever problems this error | is designed to address can happen every time a window is closed. I | would expect to find something in the spec that says You must execute | (SwapBuffers|Flush|Finish...) before destroying a bound window or | such-and-such bad things can happen. Trivial test programs would have | been failing since day one. | | Well usually when the window is torndown, we exit straight away afterwards, | normally you don't keep going... I don't think you have to keep going -- all you have to do is destroy the window when there are still GL commands that haven't been flushed. It looks like the same (or very similar) problem to me; what do you do with those commands that have been queued up for a now-nonexistent window? |... however the glean test case does another | test which opens a new window and rendering context and calls MakeCurrent | on it, thereby triggering the above failure case. esp after it has | done rendering | on the previous context and then blown away the window without flushing or | swapbuffers. I didn't trace the test, so I'm not fully confident about this, but it looks to me like this is the sequence of commands: Create window. Create rendering contexts. Make an RC current. Clear the buffer. Query the clear color. ReadPixels() to get the contents of the buffer. repeat Destroy rendering contexts. (one RC is still current, so its destruction is postponed) Destroy window. ... A subsequent test does a MakeCurrent, which triggers the error. The ReadPixels() does an implicit flush. Since it's the last operation before the MakeCurrent, and it's synchronous, there should be no other commands remaining in the GL stream at the time of the MakeCurrent. If that's correct, it explains why this problem has never been detected before, and it suggests that there might still be an implementation bug to be tracked down. What's left in the queue, or is it marked nonempty even though it's really empty? I'm persuaded that the test should be changed, though. It's not reasonable to depend on the flushing behavior of ReadPixels to meet the requirements of the spec, since a minor modification of the test could cause things to start failing mysteriously. | What happens when one X client destroys a window that another one is | using for GL rendering? The destruction of the window has to be | postponed until it's no longer bound to an RC, or the GL command queue | has to be redirected to a black hole, or GL rendering has to be | terminated by error somehow. Or something else. | | If the window is destroyed the app normally gets a SIGPIPE and dies soon | after. Really? That surprises me. For normal X apps, I would think it would just get an error delivered via the X protocol the next time it attempts to use the window ID. The GL case seems messier. I hacked mesa/progs/xdemos/glxglears.c to destroy its window after 200 frames are rendered. 1. With sw rendering, we exit with an X protocol error inside glXSwapBuffers when we call XPutImage(): X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 72 (X_PutImage) Resource id in failed request: 0x482 Serial number of failed request: 824 Current serial number in output stream: 826 2. With the i965 DRI driver we again exit from an X protocol error when trying to get the drawable info: X Error of failed request: BadDrawable (invalid Pixmap or Window parameter) Major opcode of failed request: 135 (XFree86-DRI) Minor opcode of failed request: 9 () Resource id in failed request: 0x382 Serial number of failed request: 644 Current serial number in output stream: 644 #0 _XError (dpy=0x22cd010, rep=0x7fff38bf88a0) at XlibInt.c:2895 #1 0x7fe33062cf30 in _XReply (dpy=0x22cd010, rep=0x7fff38bf88a0, extra=1, discard=0) at XlibInt.c:1857 #2 0x7fe330996e80 in XF86DRIGetDrawableInfo (dpy=0x22cd010, screen=0, drawable=58720258, index=0x22d453c, stamp=0x22d4548, X=0x22d454c, Y=0x22d4550, W=0x22d4554, H=0x22d4558, numClipRects=0x22d455c, pClipRects=0x22d4560, backX=0x22d4568, backY=0x22d456c, numBackClipRects=0x22d4574, pBackClipRects=0x22d4578) at XF86dri.c:495 #3 0x7fe3309949db in __glXDRIGetDrawableInfo (drawable=0x22d4520, index=0x22d453c, stamp=0x22d4548, X=0x22d454c, Y=0x22d4550, W=0x22d4554, H=0x22d4558, numClipRects=0x22d455c, pClipRects=0x22d4560, backX=0x22d4568, backY=0x22d456c, numBackClipRects=0x22d4574, pBackClipRects=0x22d4578,
Re: GLX makeCurrent in glean vs broken X server glxAllContexts linked list
Dave Airlie wrote: So glXMakeCurrent says GLXBadCurrentWindow is generated if there are pending GL commands for the previous context and the current drawable is a window that is no longer valid. This appears to be true, we don't seem to have cleared all the pending GL commands before, so we get this error. Adding a glFinish into the glean test exit path, gets it past this, but I've no idea if this is correct. I then hit a GLXBadContext soon afterwards which suggest something more is going wrong. Probably need someone with some knowledge of GLX to tell me more. Okay attached two patches (one is a resend of some previous work - its in radeon-rewrite). With these in mesa and a glFinish in the tbinding.cpp glean no longer dies in the makeCurrent test case. However Brian you had a comment in dri_util.c about not unbinding things properly due to swapbuffers on an unbound window, can you put a glean test together for that? Hmmm, that comment is from a long time ago and I don't remember the details. I'm not sure glean's infrastructure will support testing swapbuffers on an unbound window. I don't have time right now to dig into it. One of the mesa/progs/xdemos/* examples might be hacked to test that. so we can test it properly, as the hack that was in place seems to not be the best idea. Holding a pointer to a drawable object with no reference on it is definitely a path to accessing freed memory. The other open question is whether the glFinish in the glean test case is actually necessary, from reading the glXMakeCurrent manpage is appears it might be, or something else needs to make sure outstanding GL commands on the context are flushed before the window is destroyed. Do you have a patch for glean? Off-hand, I don't think adding a glFinish() would contradict the intention of the makeCurrent test - so the change sounds OK to me. Otherwise, your patches look OK to me. Thanks! -Brian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] mklib: cosmetic: use case instead of expr match
Thanks. I'll commit this and your prev patch after a bit more testing...
-Brian
Tormod Volden wrote:
From: Tormod Volden debian.tor...@gmail.com
Saves forking an expr for every object.
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
On Thu, Apr 30, 2009 at 8:37 AM, Tormod Volden wrote:
Dan Nicholson wrote:
Is there any reason not to just use a case statement instead of forking
expr?
No, that was just copied from another part of the script.
And to save the trees, here is an additional patch to fix the part I had
copied from.
Cheers,
Tormod
--
bin/mklib | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/bin/mklib b/bin/mklib
index 86aa80f..6331f5a 100755
--- a/bin/mklib
+++ b/bin/mklib
@@ -279,18 +279,21 @@ case $ARCH in
# expand any .a objects into constituent .o files.
NEWOBJECTS=
DELETIA=
- for OBJ in ${OBJECTS} ; do
- if [ `expr match $OBJ '.*\.a'` -gt 0 ] ; then
- # extract the .o files from this .a archive
- FILES=`ar t $OBJ`
- ar x $OBJ
- NEWOBJECTS=$NEWOBJECTS $FILES
- # keep track of temporary .o files and delete them below
- DELETIA=$DELETIA $FILES
- else
- # ordinary .o file
- NEWOBJECTS=$NEWOBJECTS $OBJ
- fi
+ for OBJ in $OBJECTS ; do
+ case $OBJ in
+ *.a)
+ # extract the .o files from this .a archive
+ FILES=`ar t $OBJ`
+ ar x $OBJ
+ NEWOBJECTS=$NEWOBJECTS $FILES
+ # keep track of temporary .o files and delete them below
+ DELETIA=$DELETIA $FILES
+ ;;
+ *)
+ # ordinary .o file
+ NEWOBJECTS=$NEWOBJECTS $OBJ
+ ;;
+ esac
done
# make lib
--
Register Now Save for Velocity, the Web Performance Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] mklib: cosmetic: use case instead of expr match
Dan Nicholson wrote: On Thu, Apr 30, 2009 at 3:57 PM, Brian Paul bri...@vmware.com wrote: Thanks. I'll commit this and your prev patch after a bit more testing... I have the other one queued up, I just didn't have time to give it a spin yet. If you can wait until tomorrow (later tonight actually), I'll push them. But if you're in a rush, I think they're safe to commit. I found a few glitches with the static linux build but everything else seems OK. -Brian -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxgears crash with latest mesa swrast module
Marco wrote: I don't see how that change could be related to a SwapBuffers crash Sorry I was misunderstod: that is latest commit I have. Last mesa sources I had was from 20/08/2008, and glxgears was running fine, then I upgraded till the commit of Fri Sep 5 08:06:59 2008 -0600 and glxgears now crashes. I don't see any problem here and nobody else has reported it. Did you try a clean rebuild? -Brian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxgears crash with latest mesa swrast module
I don't see how that change could be related to a SwapBuffers crash. Maybe try recompile everything from scratch. -Brian Marco wrote: I tried latest git from mesa master (latest commit is): commit 11d694b1bb0cb384d802d7e0e252cf5119febb98 Author: Brian Paul [EMAIL PROTECTED] Date: Fri Sep 5 08:06:59 2008 -0600 mesa: replace MALLOC w/ CALLOC to fix memory error in glPushClientAttrib() Glxgears crash as soon as it starts. This is gdb trace: [EMAIL PROTECTED]:~$ gdb glxgears GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu... Using host libthread_db library /lib/libthread_db.so.1. (gdb) run Starting program: /usr/bin/glxgears [Thread debugging using libthread_db enabled] [New process 11011] [New Thread -1211914576 (LWP 11011)] libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211914576 (LWP 11011)] 0x47206769 in ?? () (gdb) bt #0 0x47206769 in ?? () #1 0xb7f09deb in glXSwapBuffers (dpy=0x804c008, drawable=35651586) at glxcmds.c:859 #2 0x0804a69b in main (argc=1, argv=0xbfc857b4) at glxgears.c:338 (gdb) Bye Marco - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: driDestroyDrawable is never called
Nicolai Hähnle wrote: Hi, testing the r300-bufmgr has revealed that the driDestroyDrawable is never called in very simple applications such as glxinfo or glxgears. This obviously causes a number of memory leaks. Unfortunately, I don't really understand that part of the code yet, but I have confirmed that the problem also exists in git master. This is with the r300 driver, if it makes a difference. I believe this problem has existed since day one. The problem is the client-side driver would need to get some sort of message from the X server when a window is destroyed. Otherwise, it's not clear when a window's DRI info can go away. I think there may be some garbage collection code that periodically checks if any of the window IDs previously passed to glXMakeCurrent() have gone away (by installing an X error hander and trying to touch the window ID). If a known window ID no longer exists on the server, the DRI info can be freed. I haven't looked at that stuff in quite a while so I'm not sure of the status of it. -Brian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri2-without-sarea branches for review
Michel Dänzer wrote: On Mon, 2008-08-18 at 15:30 -0400, Kristian Høgsberg wrote: I have pushed the DRI2 update to the dri2proto, mesa, xserver, and xf86-video-intel trees in ~krh. It's on the master branch in those repos. I don't see anything younger than 5 months in your xf86-video-intel repo. The way this works now, is that when ctx-Driver.Viewport is called (and thus at least when binding a drawable to a context), the DRI driver calls back to the loader, which then calls into the DRI2 module to get the buffers associated with the drawable. The DRI2 module in turns calls into the DDX driver to allocate these and sends them back to the DRI driver, which updates the renderbuffers to use the given buffers. So after binding a drawable to a context, the buffer information will only be updated when the app calls glViewport()? Any idea if this scheme will be suitable for other APIs like GLES or OpenVG? Khristian, are you depending on glViewport being called whenever the window/framebuffer is resized? That's usually the case, but not always. Maybe we should have a new Mesa device driver callback that's invoked when a window size changes or first time use is detected? -Brian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Please HELP!!! accumulation buffers support FC9
Svilen wrote: Nicolai Hähnle wrote: Am Donnerstag 07 August 2008 01:48:07 schrieb Svilen: I'm having troubles obtaining GLX visual with accumulation buffers. It happens only on Fedora 9. Attached is glxinfo log. Problem never appears with fglrx drivers, but as you know it's not available for FC9. I'm really looking forward for your comments. Here is my platform: X1600 Mobility Radeon Linux, Fedora 9 Xorg 7.4 (unofficial) Mesa 7.1 (unofficial) xorg.conf ... Section Device Identifier Videocard0 Driver radeon EndSection ... Regards I don't think we have acceleration for accumulation buffers. You may still be able to obtain a GLX visual with accum buffers by what Michel said, but don't expect too great results. To be honest, you're the first person I've ever seen complaining about missing accumulation buffers, so I have no idea whether that will change any time soon. I'm certainly not a great expert in OpenGL, but accumulation buffers can be quite handy. It seems highly unlikely that I'm the only one using them. Besides you can find a simple tricks with the accumulation buffers in every openGL book. It is certainly a surprise that I'm the first complaining about it. It certainly took me some time until I found the right place to ask the question. Maybe this is one of the reasons? I agree that a GLX visual with an accum buffer should be present. Accum is always implemented in software with Mesa, but it's trivial to support. -Brian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Please HELP!!! accumulation buffers support FC9
Svilen wrote: Hi, This is second time I'm trying to get your attention guys. Shall I flag it as a bug? Or it is not a DRI problem. I know at least a couple of similar platforms with the same trouble. If this is not a right place to ask the question, I'll appreciate if you point me another mailing list. I've already discussed this in [EMAIL PROTECTED] but they claim it's not a driver problem. Regards Svilen Svilen Krustev wrote: Hi, I'm having troubles obtaining GLX visual with accumulation buffers. It happens only on Fedora 9. Attached is glxinfo log. Problem never appears with fglrx drivers, but as you know it's not available for FC9. I'm really looking forward for your comments. Here is my platform: X1600 Mobility Radeon Linux, Fedora 9 Xorg 7.4 (unofficial) Mesa 7.1 (unofficial) xorg.conf ... Section Device Identifier Videocard0 Driver radeon EndSection ... Regards name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: DRI R300 Project OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL OpenGL version string: 1.3 Mesa 7.1 rc1 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_fragment_program, GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_MESAX_texture_float, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_gpu_program_parameters, GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SUN_multi_draw_arrays 3 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x22 24 dc 0 32 0 r
Re: [announce] libdrm 2.3.1
Paul Bender wrote: Fatih Aşıcı wrote: 01 Tem 2008 Sal tarihinde, Dave Airlie şunları yazmıştı: Update libdrm to 2.3.1. These archives do not include xf86mm.h ? I noticed that is well, but it appears to be correct. I found that I needed to patch Mesa 7.1.0 with two commits from trunk: 0b734bd7cf921592eee441f759687e10f48a2cbc and d3f7b463c3975c070503053e4ad70af99016a756. In addition, I needed to patch xf86-video-intel 2.3.2 with one commit from trunk: 55678c64bc6e3ed613ea6db14c105c18a0cf28ce. After that, everything was able to build. I'm planning on making a 7.1 release candidate #2 pretty soon. That'll have the latest bits from git. -Brian - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Combining Mesa3D and DRI mailing lists and/or sites?
Timo Jyrinki wrote: 2008/6/12 Keith Whitwell [EMAIL PROTECTED]: In reality, what has happened is that most of this has already occurred -- whatever 3d driver-related traffic that hasn't been sucked into IRC is now occurring on the Mesa lists. Right. I now rearranged DRI wiki's mailing list page http://dri.freedesktop.org/wiki/MailingLists by stating that fact. I also commented out the dri-announce mailing list which hadn't been used for 5+ years. I actually think the current structure makes a lot of sense - if we wanted a change, we could rename dri-devel to drm-devel, but it hardly seems worthwhile. It'd be nice, but only if somehow automagic enough. Just documentation is mostly enough, too. What about the dri-users mailing list? From users point of view DRI/Mesa/DRM are mostly all the same (users want them all), and any users of DRM are likely to be halfway developers anyway. While DRI discussion has successfully migrated to mesa3d-dev list, users are currently randomly posting either mesa3d-users or dri-users and the discussion is not coherent. Could those two mailing lists be merged into mesa3d-users, or do you think that mentioning dri-users is (nowadays) for DRM discussion is enough to fix the problem from now on? Regarding wikis, I also started reorganizing the front page http://dri.freedesktop.org/ a bit, including changing title to include Mesa, too. I still think that it could be the wiki for both Mesa and DRI, and that mesa3d.org could include a link to the wiki (or DRI wiki because of the current status) under eg. the Resources title instead of having the link to DRI website only in the bottom of the navigation. What do you think? Sounds good. Send me a patch to the html file... -Brian - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon r6xx DRM...
Corbin Simpson wrote: Matthias Hopf wrote: I'm in the process of skimming through the 3D programming documentation of the r6xx chips. AMD announced on XDC 2008 to make it public, so it will show up pretty soon. It's one massive beast, more than 650 pages... Obviously, the first step to get 3D working on r6xx is to update the radeon DRM to support these chips, and I think I've understood enough now to start working on this thing. I assume working in a public user repro is the best way to collaborate, but I'd be fine working in a branch on the main repro or just sending patches, just what fits best. r6xx looks substantially different than previous chipsets, but I think it still fits into the radeon driver. If it turns out that for exposing additional features and using DRI2 it's better to split out parts, that can be decided later on. Any comments on advancing here, or pitfalls to avoid? Has anybody already some ideas how to restructure things if necessary? So long Matthias Mm, can't wait for delicious documentation. I was envisioning a completely separate r600 DRI driver for r6xx+, since, if I understand correctly, the r6xx 3D engine is a completely new chip with nothing in common with the older Radeons. On the other hand, though, I haven't seen the actual documentation, so I have no idea exactly how different this new chipset actually is. On the DRM side, Alex has added the r6xx microcode to the DRM, and it doesn't seem like it should be too much work to get it going, but again I have no idea what I'm talking about. Overall though, I think that building on the previous Radeon DRI is probably going to be necessary, at least in the short run. If the new driver won't be an incremental change to the existing radeon drivers, I'd recommend basing it on Gallium. -Brian - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
gallium (was Re: radeon r6xx DRM...)
Dave Airlie wrote: Stephane wrote: Hi Brian, It seems like people are mostly concerned about gallium stability right now. How stable wioll the interfaces be in the future ? Maybe if you could tell us, that'd help others jump in. The gallium interfaces won't change radically, but we are looking at some changes. In particular, the winsys stuff is kind of complicated and we're hoping to simplify and re-organize it somewhat. Winsys basically includes all the stuff needed to interface a portable gallium driver into the non-portable window system and OS which hosts it. The dividing lines, modularity and terminology(!) can be improved in that area. Jakob Bornecrantz may be commiting some changes soon. Beyond that, there'll probably always be some evolutionary changes to the gallium interfaces. It'll have to evolve just has Mesa has had to evolve since we can't predict future needs. None of this should stop anyone from digging into gallium though. Even when it might make it to master, is it planned to land in master.. I would assume Mesa 8.0 or something. Gallium might ultimately wind up in its own repository as a stand-alone project. Afterall, Gallium drivers could be used by APIs other than OpenGL. Before then though, the gallium branch could be merged into Mesa master (if not git-merged, simply copied over). There's been a bit of code divergence in core Mesa between master and gallium-0.1 which will need attention (nothing too serious though). When either of those things happens a Mesa 8.0 release would probably be appropriate. I haven't thought about a time frame yet, but the end of the year might be a good goal. -Brian - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glGenerateMipmapEXT and DRI drivers.
On Thu, May 8, 2008 at 9:06 PM, Dave Airlie [EMAIL PROTECTED] wrote: So compiz calls glGenerateMipmapEXT to generate mipmaps for some icons on its switcher, this fails with a NULL src data ptr when running under TTM+DRI2, my initial feeling is that we don't have the miptrees mapped and from looking the texture data ptr is set to NULL. I'm just wondering how best to hook this into the drivers? a new entry point? or maybe I'm just missing something. And I was and I fixed this in the tree and it looks fairly obvious. Since I'm talking to myself (damn timezones...) Okay I added a hook to Map/Unmap texture around the mipmap generate function, however I'm wonder should I just have added a new dd hook, for this whole GenerateMipmapEXT call and punt it into the drivers.. Intel code has a intel_generate_mipmap function which wraps the mesa one so I'm wondering if I really need to be calling this, even though it appears to work.. On the gallium-0.1 branch I added a device driver hook for GenerateMipmap. I think you could cherry-pick that into master. I don't recall if it was one or two commits. -Brian - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: UT2004 and AIGLX crashes with current mesa
Adam K Kirchhoff wrote: So I've been following the development of Xorg and mesa to track all the wonderful changes going into the radeon and radeonhd drivers. I updated today, for the first time in about a week or two, and I'm suddenly getting some crashes. When I go to close out ut2004, I get: [...] It was reported earlier on mesa3d-dev. I'm looking into it. -Brian - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Proposal for a few minor internal API changes.
Keith Whitwell wrote:
Keith Packard wrote:
I'm writing up some documentation for internal DRM interfaces and came
across a couple of interface inconsistencies that seem like they should
get fixed before they start getting used a lot more. If these look like
good changes, I'll continue to search out other similar issues. I'll
just include the header changes in this message.
Make ttm create/destroy APIs consistent. Pass page_flags in create.
Creating a ttm was done with drm_ttm_init while destruction was done with
drm_destroy_ttm. Renaming these to drm_ttm_create and drm_ttm_destroy
makes
their use clearer. Passing page_flags to the create function will allow
that
to know whether user or kernel pages are needed, with the goal of
allowing
kernel ttms to be saved for later reuse.
--- linux-core/drm_objects.h
---
index 1dc61fd..66611f6 100644
@@ -297,7 +297,7 @@ struct drm_ttm {
};
-extern struct drm_ttm *drm_ttm_init(struct drm_device *dev, unsigned long
size);
+extern struct drm_ttm *drm_ttm_create(struct drm_device *dev, unsigned long
size, uint32_t page_flags);
extern int drm_bind_ttm(struct drm_ttm *ttm, struct drm_bo_mem_reg *bo_mem);
extern void drm_ttm_unbind(struct drm_ttm *ttm);
extern void drm_ttm_evict(struct drm_ttm *ttm);
@@ -318,7 +318,7 @@ extern int drm_ttm_set_user(struct drm_ttm *ttm,
* Otherwise it is called when the last vma exits.
*/
-extern int drm_destroy_ttm(struct drm_ttm *ttm);
+extern int drm_ttm_destroy(struct drm_ttm *ttm);
#define DRM_FLAG_MASKED(_old, _new, _mask) {\
(_old) ^= (((_old) ^ (_new)) (_mask)); \
Document drm_bo_do_validate. Remove spurious 'do_wait' parameter.
Add comments about the parameters to drm_bo_do_validate, along
with comments for the DRM_BO_HINT options. Remove the 'do_wait'
parameter as it is duplicated by DRM_BO_HINT_DONT_BLOCK.
--- linux-core/drm_objects.h
---
index 66611f6..1c6ca79 100644
@@ -546,7 +546,6 @@ extern struct drm_buffer_object
*drm_lookup_buffer_object(struct drm_file *file_
extern int drm_bo_do_validate(struct drm_buffer_object *bo,
uint64_t flags, uint64_t mask, uint32_t hint,
uint32_t fence_class,
- int no_wait,
struct drm_bo_info_rep *rep);
/*
Document drm_bo_handle_validate. Match drm_bo_do_validate parameter
order.
Document parameters and usage for drm_bo_handle_validate. Change
parameter
order to match drm_bo_do_validate (fence_class has been moved to after
flags, hint and mask values). Existing users of this function have been
changed, but out-of-tree users must be modified separately.
--- linux-core/drm_objects.h
---
index 1c6ca79..0926b47 100644
@@ -535,9 +535,8 @@ extern int drm_bo_clean_mm(struct drm_device *dev,
unsigned mem_type);
extern int drm_bo_init_mm(struct drm_device *dev, unsigned type,
unsigned long p_offset, unsigned long p_size);
extern int drm_bo_handle_validate(struct drm_file *file_priv, uint32_t
handle,
- uint32_t fence_class, uint64_t flags,
- uint64_t mask, uint32_t hint,
- int use_old_fence_class,
+ uint64_t flags, uint64_t mask, uint32_t hint,
+ uint32_t fence_class, int use_old_fence_class,
struct drm_bo_info_rep *rep,
struct drm_buffer_object **bo_rep);
These all look sensible.
It's a pity that the change above looks like it will allow users of the
old argument order to continue to compile without error despite the
change. It's a bit hard to know how to achieve that though.
Could a temporary/dummy parameter be added for a while? Callers that
weren't updated would get an error/warning about too few arguments.
Then remove the dummy at some point in the future.
-Brian
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch] to fix libGL error: dlopen /usr/lib/dri/i915_dri.so failed (/usr/lib/dri/i915_dri.so: undefined symbol: _glthread_GetID
Sergio Monteiro Basto wrote: Hi, since is for i915_dri.so , seems to me that is the best Malling list to post it. Simply clean _glthread_GetID from DBG macros. To be honest I had clean all lines with DBG and _glthread_GetID , to be more fast. I had try Mesa from git sources master. What exactly is the issue here? A compiler warning? Linker problem? -Brian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Gtkradiant not working with radeon driver
Roland Scheidegger wrote: Jose Rodriguez wrote: On 30/10/2007, *Roland Scheidegger* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hmm, so max_index is -1. Apparently gtkradiant has called drawArrays with a count of 0 (which is legal though pretty much a no-op), it seems we don't handle that correctly. (calculating start + count - 1 is a problem there...). I'd guess the solution for that is checking for count == 0 and returning early in vbo_exec_DrawArrays in this case. Maybe the same problem can be found in other places, haven't really looked at it (e.g. the drawelements functions). Roland Should I open a bug report about this? Would building DRI from git make any difference? Is there anything else I could do in terms of a) providing information and b) solving my inability to run this software? git master still would have the same problem as far as I can see. The attached simple patch might fix the problem, if it really is what I think it is :-). I'm a bit unsure if DrawElements might have a similar problem, the same problem shouldn't happen but maybe others later... Roland diff --git a/configs/linux-debug b/configs/linux-debug diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c index 1e4c310..abe5741 100644 --- a/src/mesa/vbo/vbo_exec_array.c +++ b/src/mesa/vbo/vbo_exec_array.c @@ -240,6 +240,9 @@ vbo_exec_DrawArrays(GLenum mode, GLint s if (!_mesa_validate_DrawArrays( ctx, mode, start, count )) return; + if (!count) + return; + FLUSH_CURRENT( ctx, 0 ); if (ctx-NewState) The proper fix is to do the check in _mesa_validate_DrawArrays() as is done for DrawElements and DrawRangeElements. I'll take care of it. -Brian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRI interface changes
Keith Whitwell wrote: Brian Paul wrote: Kristian Høgsberg wrote: Hi, I have this branch with DRI interface changes that I've been threatening to merge on several occasions: http://cgit.freedesktop.org/~krh/mesa/log/?h=dri2 I've just rebased to todays mesa and it's ready to merge. Ian reviewed the changes a while back gave his ok, and from what we discussed at XDS2007, I believe the changes there are compatible with the Gallium plans. What's been keeping me from merging this is that it breaks the DRI interface. I wanted to make sure that the new interface will work for redirected direct rendering and GLXPixmaps and GLXPbuffers, which I now know that it does. The branch above doesn't included these changes yet, it still uses the sarea and the old shared, static back buffer setup. This is all isolated to the createNewScreen entry point, though, and my plan is to introduce a new createNewScreen entry point that enables all the TTM features. This new entry point can co-exist with the old entry point, and a driver should be able to support one or the other and probably also both at the same time. The AIGLX and libGL loaders will look for the new entry point when initializing the driver, if they have a new enough DRI/DRM available. If the loader has an old style DRI/DRM available, it will look for the old entry point. I'll wait a day or so to let people chime in, but if I don't hear any stop the press type of comments, I'll merge it tomorrow. This is basically what's decsribed in the DRI2 wiki at http://wiki.x.org/wiki/DRI2, right? The first thing that grabs my attention is the fact that front color buffers are allocated by the X server but back/depth/stencil/etc buffers are allocated by the app/DRI client. If two GLX clients render to the same double-buffered GLX window, each is going to have a different/private back color buffer, right? That doesn't really obey the GLX spec. The renderbuffers which compose a GLX drawable should be accessible/shared by any number of separate GLX clients (like an X window is shared by multiple X clients). I guess I want to know what this really means in practice. Suppose 2 clients render to the same backbuffer in a race starting at time=0, doing something straightforward like (clear, draw, swapbuffers) there's nothing in the spec that says to me that they actually have to have been rendering to the same surface in memory, because the serialization could just be (clear-a, draw-a, swap-a, clear-b, draw-b, swap-b) so that potentially only one client's rendering ends up visible. So I would say that at least between a fullscreen clear and either swap-buffers or some appropriate flush (glXWaitGL ??), we can treat the rendering operations as atomic and have a lot of flexibility in terms of how we schedule actual rendering and whether we actually share a buffer or not.Note that swapbuffers is as good as a clear from this perspective as it can leave the backbuffer in an undefined state. On the other hand, a pair of purposely-written programs could clear-a, draw-a, draw-b, swap-b and the results should be coherent. That's how I read the spec. I'm not just splitting hairs for no good reason - the ability for the 3d driver to know the size of the window it is rendering to while it is emitting commands, and to know that it won't change size until it is ready for it to is really crucial to building a solid driver. Agreed. The trouble with sharing a backbuffer is what to do about the situation where two clients end up with different ideas about what size the buffer should be. So, if it is necessary to share backbuffers, then what I'm saying is that it's also necessary to dig into the real details of the spec and figure out how to avoid having the drivers being forced to change the size of their backbuffer halfway through rendering a frame. I see a few options: 0) The old DRI semantics - buffers change shape whenever they feel like it, drivers are buggy, window resizes cause mis-rendered frames. 1) The current truly private backbuffer semantics - clean drivers but some deviation from GLX specs - maybe less deviation than we actually think. 2) Alternate semantics where the X server allocates the buffers but drivers just throw away frames when they find the buffer has changed shape at the end of rendering. I'm sure this would be nonconformant, at any rate it seems nasty. (i915 swz driver is forced to do this). 3) Share buffers with a reference counting scheme. When a client notices the buffer needs a resize, do the resize and adjust refcounts - other clients continue with the older buffer. What happens when a client on the older buffer calls swapbuffers -- I'm sure we can figure out what the correct behaviour should be. I don't know the answers to this either. There's probably very few, if any, GLX programs in existance
cooperative rendering
I've checked in a new GLX test for rendering into one GLX window by two processes. See comments in progs/xdemos/corender.c for instructions. Two interlocking tori are drawn. The first process draws a red one, the second process draws a blue one. I'm getting mixed results. With an old GeForce3 series card it seems to work perfectly. With a GeForce 7300 card there's rendering glitches. The blue torus isn't depth-buffered correctly. But if I insert an extra glClear(GL_DEPTH_BUFFER_BIT) it works except for an occasional glitch. Pretty weird - the second clear shouldn't do what it does. See attached image. In both cases, rapid window resizes causes lots of window flickering but no noticable distortion of the rendering otherwise. -Brian inline: corender.png- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i945 GM performance question
Jonathan Bastien-Filiatrault wrote: Michel Dänzer wrote: On Mon, 2007-09-24 at 21:51 -0400, Jonathan Bastien-Filiatrault wrote: I have made a program that draws zfail/zpass shadows. I draw three models with ~120 tris each and one light source and a simple floor, with zpass. I can get a full 60fps until the window size reaches about 780x580 which drops to around ~30 fps in a maximized window (1342x820). The application is far from cpu-bound and vsync is disabled. I was wondering if I am really hitting the 945GM fill rate limit, or I am doing something terribly costly someway along the way (this should not be the case, it is somewhat too simple). I have tried with the latest i915 in Debian and the latest i915tex from git (right after it got renamed to i915). The newer driver gives a steady ~20 fps, any window size, for my program and ~60 fps for glxgears. The render is divided into three passes: ambient, shadow volumes(front and back), illuminate, nothing remarkable. I use VBOs, the performance is about the same as vertex arrays (added vbo support for the heck of it today). I'm not sure, but it sounds like this is something the software zone rendering on the i915tex-zone-rendering branch might help for. You'll need to set the environment variable INTEL_SWZ=1 to make it use software zone rendering. Thanks for the tip. I used the zone rendering branch, with the latest DRM (pipes/planes patch applied) and it gives me a boost of around 10 FPS. Disabling lighting and blending during the shadow volume gave me another 10 FPS boost. The biggest optimization was putting the shadow volume geometry and using glDrawArrays. I now run fullscreen (1440x900) at around 45-50 fps with a 960 face model in zpass mode. PS: Have you noticed that some versions of the newer mesa does not seem to like mixing plain old vertex arrays with VBOs ? The mesa in Debian unstable(7.0.1) does not segfault on me with direct rendering with mixed code. Are you saying 7.0.1 works as expected but Mesa from git (or the swz branch) doesn't work? I don't quite follow what you're saying. Is it even worth it putting shadow edge geometry in a VBO ? For the light cap, I use glDrawElements with the main vertex VBO, avoiding copies of vertex data. Sometimes, determining the best storage/rendering method depends on the hardware or other factors so it's best to do actual measurements to answer the question. -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] fix drm_i915_flip_t breakage
Jesse Barnes wrote: On Thursday, September 27, 2007 3:35:22 pm Jesse Barnes wrote: In one of my overzealous pipe/plane mapping patches, I renamed the pipes field in drm_i915_flip_t to planes, since it's really dealing with planes and so seemed to make sense. However, drm_i915_flip_t has different compatibility requirements than the i915 sarea private. The sarea private is duplicated in the Mesa and DDX trees and used under a different name, so changes to it, as long as they're binary compatible, are fine. drm_i915_flip_t, on the other hand, is used under the same name by both the Mesa and DDX trees. So if you build an old DDX or Mesa against a new DRM, they'll pick up the new drm_i915_flip_t definition (since HAVE_I915_FLIP will be defined) and promptly break. This patch reverts the DRM to the old name and adds comments describing the actual field usage. Sorry for the trouble. Oh, and for similar reasons, building a new Mesa or DDX against an old DRM will break, but keithp is making everything use the installed DRM headers all the time, so we can go back to the old drm_i915_flip_t field name then. I've got a few issues using the git heads of Mesa, DRM and xf86-video-intel: 1. The Mesa 7.0.2 branch doesn't build with drm/master. Compiling dri_bufmgr.c: ../common/dri_bufmgr.c: In function ‘driFenceBuffers’: ../common/dri_bufmgr.c:102: warning: passing argument 3 of ‘drmFenceBuffers’ makes integer from pointer without a cast ../common/dri_bufmgr.c:102: error: too few arguments to function ‘drmFenceBuffers’ Compiling i915tex/intel_buffers.c: intel_buffers.c: In function ‘intelWindowMoved’: intel_buffers.c:290: error: ‘drm_i915_flip_t’ has no member named ‘pipes’ intel_buffers.c:298: error: ‘drm_i915_flip_t’ has no member named ‘pipes’ intel_buffers.c: In function ‘intelPageFlip’: intel_buffers.c:764: error: ‘drm_i915_flip_t’ has no member named ‘pipes’ Is this supposed to work? If so, please fix it. If Mesa 7.0.2 is not intended to work with drm/master, what revision of drm should work? 2. Mesa/master builds and runs but gears, for example, is limping along at 83 fps (using 90% CPU). Can you test and see what you get? Other demos are exhibiting rendering errors that I don't recall seeing before (such as demos/gloss and demos/fogcoord). Also, I had a total system lock-up when I exited gears at one point. There's been a lot of changes lately and I don't know who's responsible for the regressions but they need to be addressed. -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] fix drm_i915_flip_t breakage
Jesse Barnes wrote: On Friday, September 28, 2007 9:27 am Brian Paul wrote: 1. The Mesa 7.0.2 branch doesn't build with drm/master. Compiling dri_bufmgr.c: ../common/dri_bufmgr.c: In function ‘driFenceBuffers’: ../common/dri_bufmgr.c:102: warning: passing argument 3 of ‘drmFenceBuffers’ makes integer from pointer without a cast ../common/dri_bufmgr.c:102: error: too few arguments to function ‘drmFenceBuffers’ I'm not sure about this one... Compiling i915tex/intel_buffers.c: intel_buffers.c: In function ‘intelWindowMoved’: intel_buffers.c:290: error: ‘drm_i915_flip_t’ has no member named ‘pipes’ intel_buffers.c:298: error: ‘drm_i915_flip_t’ has no member named ‘pipes’ intel_buffers.c: In function ‘intelPageFlip’: intel_buffers.c:764: error: ‘drm_i915_flip_t’ has no member named ‘pipes’ Is this supposed to work? If so, please fix it. Yes this should work but I broke it. I've checked in fixes to drm/master, mesa/master, and xf86-video-intel/master that should make things forward backward compatible again. Again, sorry for the trouble. I suck. Thanks, I'll re-test later. 2. Mesa/master builds and runs but gears, for example, is limping along at 83 fps (using 90% CPU). Can you test and see what you get? Other demos are exhibiting rendering errors that I don't recall seeing before (such as demos/gloss and demos/fogcoord). Also, I had a total system lock-up when I exited gears at one point. I haven't seen this, but I haven't tried master since Eric checked in his TTM stuff... I'm hoping Eric can do a few quick tests... I could certainly have something wrong on my end so I'd like to get another datapoint one way or another. There's been a lot of changes lately and I don't know who's responsible for the regressions but they need to be addressed. Are you planning to do a release soon? Yes, I announced plans for a 7.0.2 release on the Mesa3d-dev list a couple days ago. -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i945 GM performance question
Jonathan Bastien-Filiatrault wrote: Brian Paul wrote: Jonathan Bastien-Filiatrault wrote: [snip] at around 45-50 fps with a 960 face model in zpass mode. PS: Have you noticed that some versions of the newer mesa does not seem to like mixing plain old vertex arrays with VBOs ? The mesa in Debian unstable(7.0.1) does not segfault on me with direct rendering with mixed code. Are you saying 7.0.1 works as expected but Mesa from git (or the swz branch) doesn't work? I don't quite follow what you're saying. Sorry for the non-sequitur. The latest git and the swz branch tend to segfault when mixing VBOs with plain old vertex arrays with DRI. This problem is not present with the mesa in Debian. Disabling hardware acceleration prevents the segfault. I am using the latest DDX and DRM code. The kernel is 2.6.22.9 vanilla. The machine is a Dell D620, AMD64. Here are the few last lines from valgrind: ==21659== Invalid read of size 8 ==21659==at 0x806F3C9: _tnl_draw_prims (t_draw.c:131) ==21659==by 0x8067E83: vbo_exec_DrawArrays (vbo_exec_array.c:259) ==21659==by 0x805C413: neutral_DrawArrays (vtxfmt_tmp.h:328) ==21659==by 0x41E9D3: OglGeometry::drawShadowVolume(RenderPass const) (geometry.cpp:315) ^^ vertex array draw ==21659==by 0x41EBE8: OglGeometry::render(RenderPass const) (geometry.cpp:357) ==21659==by 0x41697F: Drawable::draw(RenderPass const) (drawable.h:32) ==21659==by 0x4169AF: DrawableObject::draw(RenderPass const) (drawableobject.h:14) ==21659==by 0x416DC3: Node::draw(RenderPass const) (node.cpp:24) ==21659==by 0x417BBA: Scene::render() (scene.cpp:111) ==21659==by 0x4138FE: Window::draw() (window.cpp:242) ==21659==by 0x41393D: Window::draw_cb() (window.cpp:36) ==21659==by 0x4C4639A: processWindowWorkList (glut_event.c:1306) ==21659== Address 0x1C5D7558 is not stack'd, malloc'd or (recently) free'd I am pretty sure I am not passing invalid pointers to mesa. Shall I write a test case ? Do you want to have a look at the code ? It would be ideal if you could provide a small test program and file a bug report. I'm working on tracking down a couple other VBO bugs in between other things... -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] fix drm_i915_flip_t breakage
Dave Airlie wrote: I've got a few issues using the git heads of Mesa, DRM and xf86-video-intel: 1. The Mesa 7.0.2 branch doesn't build with drm/master. Compiling dri_bufmgr.c: ../common/dri_bufmgr.c: In function 'driFenceBuffers': ../common/dri_bufmgr.c:102: warning: passing argument 3 of 'drmFenceBuffers' makes integer from pointer without a cast ../common/dri_bufmgr.c:102: error: too few arguments to function 'drmFenceBuffers' Compiling i915tex/intel_buffers.c: intel_buffers.c: In function 'intelWindowMoved': intel_buffers.c:290: error: 'drm_i915_flip_t' has no member named 'pipes' intel_buffers.c:298: error: 'drm_i915_flip_t' has no member named 'pipes' intel_buffers.c: In function 'intelPageFlip': intel_buffers.c:764: error: 'drm_i915_flip_t' has no member named 'pipes' Is this supposed to work? If so, please fix it. If Mesa 7.0.2 is not intended to work with drm/master, what revision of drm should work? It should build against the last release of libdrm, not master, master isn't released and when it gets released it'll be libdrm3 due to the ttm api... if it can't build against that due to the missing TTM then disable i915tex builds by default... Now if there isn't a current release we can build Mesa 7.0.2 against that is an issue, I also think we shouldn't be building i915tex by default in Mesa 7.0.2 until we can get the API issues all sorted out otherwise we'll just get pain in the future.. Does the version of xf86-video-intel factor into this too? I'm presently using: Mesa from mesa_7_0_branch DRM from drm-2.3.0 tag xf86-video-intel from head/master When I run glxinfo I get: [...] libGL: XF86DRIGetClientDriverName: 1.9.0 i915 (screen 0) libGL: OpenDriver: trying /home/brian/m7/lib/i915_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::00:02.0 ERROR! mapping regions libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed [...] -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] fix drm_i915_flip_t breakage
Lukas Hejtmanek wrote: On Fri, Sep 28, 2007 at 06:19:48PM -0600, Brian Paul wrote: I'm presently using: Mesa from mesa_7_0_branch DRM from drm-2.3.0 tag xf86-video-intel from head/master When I run glxinfo I get: [...] libGL: XF86DRIGetClientDriverName: 1.9.0 i915 (screen 0) libGL: OpenDriver: trying /home/brian/m7/lib/i915_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::00:02.0 ERROR! mapping regions libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed [...] you need to use drm head/master and mesa head/master. It works for me in such a case. The whole point of this is to get a working Mesa 7.0.2 environment (which requires drm 2.3 or thereabouts, per Dave's message). I'm trying to wrap-up a Mesa 7.0.2 release and I thought it would be nice to do a little testing first... -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GLX software indirect rendering broken when used by more than one client
Keith Packard wrote: Debugging a kernel scheduling issue, I tried running two glxgears at once without dri (option NoDRI) and the X server neatly crashed on me. in xm_dd.c:xmesa_update_state, ctx-DrawBuffer is NULL for the second GLX client. That certainly doesn't sound right. I probably won't get back to looking at this for several days, so anyone should feel free to try and find the cause of this problem; it should be possible to use git-bisect to locate the patch causing the problem, but I have no idea how far back to start looking. I've found/fixed the problem in Mesa. -Brian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-users] mesa/linux-agp-compat/README Re: i915tex prerequisites
On 8/7/07, Sergio Monteiro Basto [EMAIL PROTECTED] wrote: On Fri, 2007-07-27 at 08:16 -0600, Brian Paul wrote: Michel suggest when install linux-agp-compat instead of delete Module.symvers I append the Module(s).symvers file generated by linux-agp-compat to the kernel's file of the same name with cat before building the DRM. And works quite well. So this could be add mesa/linux-agp-compat/README Done. has Dave wrote: It's in 2.6.21 (kernel) and later, it is just a part of agp, nothing special about compat or otherwise, I haven't used linux-agp-compat in a while. a030ce4477baa06dd9c037ccd3c8d171aac9ed44 is the kernel git commitid So , this information should also enter in mesa/linux-agp-compat/README , that this is just for kernel 2.6.21 And to install linux-agp-compat in kernel 2.6.21 we should, overwrite .ko modules kernel like this: cp agpgart.ko intel-agp.ko /lib/modules/`uname -a`/kernel/drivers/char/agp/ instead install in other location. And we should swap, not append the symbols. I done a little script which do that, replace all agp_symblos generated by this new modules on old one. Just to be more precisely ... The script is a little raw, but the 2 temporary files, tmp1 and cm, could explain the script itself. I not sure that works in all platforms. OK, I've checked in some updates to the README file. Please review. BTW, I think you meant to use `uname -r` above, not `uname -a`. -Brian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-users] i915tex prerequisites
Sergio Monteiro Basto wrote: Since last email about this subject (3 of July) , I had installed i915tex on my laptop , and I had working without problems . Michel suggest when install linux-agp-compat instead of delete Module.symvers I append the Module(s).symvers file generated by linux-agp-compat to the kernel's file of the same name with cat before building the DRM. And works quite well. So this could be add mesa/linux-agp-compat/README Done. 2nd - will linux-agp-compat enter in kernel main stream ? I'm not too familiar with this stuff but that sounds like a good idea. -Brian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 11283] blender menus don't show up with r300 driver from git
Adam K Kirchhoff wrote: On Wednesday 20 June 2007 13:02:47 Brian Paul wrote: Eric Anholt wrote: On Tue, 2007-06-19 at 12:20 -0400, Adam K Kirchhoff wrote: On Sat, 2007-06-16 at 09:44 -0700, [EMAIL PROTECTED] wrote: http://bugs.freedesktop.org/show_bug.cgi?id=11283 --- Comment #4 from [EMAIL PROTECTED] 2007-06-16 09:44 PST --- Finished with git-bisect: 9e8a961dd7d7b717a9fb4ecdea1c1b60ea355efe is first bad commit commit 9e8a961dd7d7b717a9fb4ecdea1c1b60ea355efe Author: Brian [EMAIL PROTECTED] Date: Sun May 20 12:27:39 2007 -0600 Overhaul/simplify SWvertex and SWspan attribute handling. Instead of separate fog/specular/texcoord/varying code, just treat all of them as generic attributes. Simplifies the point/line/triangle functions. :04 04 9f70804d38a62512f185453df294c7e1df8e44e0 3ef1f5e6a5ae338ef5ccce99bc62cfbaf7f8987c M src Brian, Can you shed some light onto what this commit did to blender? :-) I was just looking into this commit. It broke the software drawpixels path with the drawpix demo, at least. Yeah, try my latest commits and see what happens with Blender (and drawpix). -Brian Sorry, but blender is still broken :-( Does anyone know how blender draws its menus (glDrawPixels, glBitmap, textured polygons, etc)? -Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 11283] blender menus don't show up with r300 driver from git
Adam K Kirchhoff wrote: On Sat, 2007-06-16 at 09:44 -0700, [EMAIL PROTECTED] wrote: http://bugs.freedesktop.org/show_bug.cgi?id=11283 --- Comment #4 from [EMAIL PROTECTED] 2007-06-16 09:44 PST --- Finished with git-bisect: 9e8a961dd7d7b717a9fb4ecdea1c1b60ea355efe is first bad commit commit 9e8a961dd7d7b717a9fb4ecdea1c1b60ea355efe Author: Brian [EMAIL PROTECTED] Date: Sun May 20 12:27:39 2007 -0600 Overhaul/simplify SWvertex and SWspan attribute handling. Instead of separate fog/specular/texcoord/varying code, just treat all of them as generic attributes. Simplifies the point/line/triangle functions. :04 04 9f70804d38a62512f185453df294c7e1df8e44e0 3ef1f5e6a5ae338ef5ccce99bc62cfbaf7f8987c M src Brian, Can you shed some light onto what this commit did to blender? :-) My guess is when we're hitting the fallback path, the SWvertex-color values aren't getting populated. In most of the DRI drivers, there's a XXX_translate_vertex() function that converts HW vertices to SWvertex format. I don't see that in the R300 driver though. I'm not sure how fallbacks work in that driver. -Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [texture_from_pixmap.c] glXBindTexImageEXT undefined
Dieter Nützel wrote: Am Montag, 28. Mai 2007 schrieb Brian Paul: Dieter Nützel wrote: progs/xdemos time nice +19 make gcc -I../../include -Wall -Wmissing-prototypes -std=c99 -ffast-math -O -march=athlon-mp -fomit-frame-pointer -m3dnow -msse -mmmx -mfpmath=sse,387 -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM texture_from_pixmap.c -L../../lib -lglut -lGLU -lGL -lm -o texture_from_pixmap /tmp/cc089W35.o: In function `main': texture_from_pixmap.c:(.text+0x811): undefined reference to `glXBindTexImageEXT' collect2: ld returned 1 exit status make: *** [texture_from_pixmap] Fehler 1 My glx.h has it. Latest glxproto.h CVS not. As long as you've got the latest Mesa sources, I have. Latest Mesa git 7.1, DRM git (installed). OpenGL vendor string: DRI R300 Project OpenGL renderer string: Mesa DRI R300 20060815 AGP 4x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 7.1 and everything compiled OK, It does and works, so far. this shouldn't be happening. But...;-) You could run 'nm' on libGL.so and see that glXBindTexImageEXT is defined. progs/xdemos time nice +19 make -j10 gcc -I../../include -Wall -Wmissing-prototypes -std=c99 -ffast-math -O -march=athlon-mp -fomit-frame-pointer -m3dnow -msse -mmmx -mfpmath=sse,387 -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM texture_from_pixmap.c -L../../lib -lglut -lGLU -lGL -lm -o texture_from_pixmap /tmp/ccA6P9wF.o: In function `main': texture_from_pixmap.c:(.text+0x811): undefined reference to `glXBindTexImageEXT' collect2: ld returned 1 exit status make: *** [texture_from_pixmap] Fehler 1 0.376u 0.048s 0:00.43 95.3% 0+0k 0+0io 0pf+0w progs/xdemos nm /opt/mesa/lib/libGL.so.1.2 | grep glXBindTexImageEXT 0001b0a4 t __glXBindTexImageEXT progs/xdemos nm /usr/lib/libGL.so.1.2 | grep glXBindTexImageEXT 0001b0a4 t __glXBindTexImageEXT I only added GLX_EXT_texture_from_pixmap to the xlib driver, as someone requested. I didn't do anything on the DRI side. I'll update the test program to check for the extension like it should. But what is this? If I set 'setenv LIBGL_ALWAYS_INDIRECT' (tcsh) I get: OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R300 20060815 AGP 4x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.5.1 Shouldn't it OpenGL 2.1 like ~mesa/docs/relnotes-7.1.html stated? The OpenGL version depends on the driver. Core Mesa and the Xlib driver support 2.1, but the DRI drivers don't yet. -Brina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [texture_from_pixmap.c] glXBindTexImageEXT undefined
Dieter Nützel wrote: progs/xdemos time nice +19 make gcc -I../../include -Wall -Wmissing-prototypes -std=c99 -ffast-math -O -march=athlon-mp -fomit-frame-pointer -m3dnow -msse -mmmx -mfpmath=sse,387 -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM texture_from_pixmap.c -L../../lib -lglut -lGLU -lGL -lm -o texture_from_pixmap /tmp/cc089W35.o: In function `main': texture_from_pixmap.c:(.text+0x811): undefined reference to `glXBindTexImageEXT' collect2: ld returned 1 exit status make: *** [texture_from_pixmap] Fehler 1 My glx.h has it. Latest glxproto.h CVS not. As long as you've got the latest Mesa sources, and everything compiled OK, this shouldn't be happening. You could run 'nm' on libGL.so and see that glXBindTexImageEXT is defined. -Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] minor minor minor cleanups
Christoph Brill wrote: Hi list, attached are few fixes for issues I found while browsing through the r200 DRI code. I checked in your patches. -Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 cleanup questions
Jerome Glisse wrote:
On 5/8/07, Christoph Brill [EMAIL PROTECTED] wrote:
I reviewed the cleanup done by Olliver McFadden and had the following
questions:
-int r300_get_num_verts(r300ContextPtr rmesa, int num_verts, int prim)
+static int r300NumVerts(r300ContextPtr rmesa, int num_verts, int prim)
Is it necessary/usefull that the function is static?
I think it's better to have static function, i am thinking of symbol export
and
other things like that.
Yes, make functions static whenever possible.
-/* Immediate implementation has been removed from CVS. */
-
-/* vertex buffer implementation */
-
-static void inline fire_EB(r300ContextPtr rmesa, unsigned long addr
+static void inline r300FireEB(r300ContextPtr rmesa, unsigned long addr
Why move all the comments to the head of the file. IMO the method should
have a doxygen comment that states it is the vertex buffer
implementation of fire_EB, right?
-if (num_verts 65535) { /* not implemented yet */
+if (num_verts 65535) {
Comments like this should be kept. Otherwise it looks like a hardware
limitation while the limitation can be worked around or the limitation
does not exist.
Last but not least is
r300_foo_bar
preferred or
r300FooBar
Which is the one mesa uses?
We can use the one we like, i prefer r300_foo_bar over r300FooBar which
i dislike but the choice is up to the first person who do big cleanup :) and
we do not have to conform to mesa coding style for driver but use the one
we like the more.
Yes, core Mesa has a fairly consistant naming scheme but it's the
prerogative of the driver writers to choose their style. That said,
naming within each driver should be consistant.
-Brian
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 cleanup questions
Oliver McFadden wrote: I'd like some input on the VBO stuff in r300. In r300_context.h we have the following. /* KW: Disable this code. Driver should hook into vbo module * directly, see i965 driver for example. */ /* #define RADEON_VTXFMT_A */ #ifdef RADEON_VTXFMT_A #define HW_VBOS #endif So the VTXFMT (radeon_vtxfmt_a.c) code is disabled anyway. This also disables hardware VBOs. I guess this has been done since the new VBO branch was merged. So, the question is, should this dead code be removed? I think all drivers are (or should be) moving to the new VBO code anyway. I've already made a patch for this, but I'm not committing until I get the okay from a few people. I'm no expert on the R300 code so I'll defer. Keith might have some comments but he's very busy with another project ATM. On thing: I'd like to keep the trunk/master code stable for the upcoming 7.0 release. If you think there's some risk, let me first make the 7.0/stable branch in git. -Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 cleanup questions
Oliver McFadden wrote: I also think we might need to add _dri_warning/_dri_error because the _mesa versions output Mesa warning: %s which implies to the user this is a Mesa problem, not a DRI driver problem. I could add r300Warning and r300Error, but probably all DRI drivers need warning and error functions... So maybe adding them to the common DRI code? You could just stick with _mesa_warning() and prefix the messages with R300. -Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 cleanup questions
If it's just dead code removal, go ahead. -Brian Oliver McFadden wrote: Well both Keith and Jerome are okay with me removing the VTXFMT code, so I'll go ahead and do that. I don't think there is any serious risk as I'm only removing code that is already disabled. :) Brian, let me know if you want to make a branch so I know when I can push. On 5/9/07, Brian Paul [EMAIL PROTECTED] wrote: Oliver McFadden wrote: I also think we might need to add _dri_warning/_dri_error because the _mesa versions output Mesa warning: %s which implies to the user this is a Mesa problem, not a DRI driver problem. I could add r300Warning and r300Error, but probably all DRI drivers need warning and error functions... So maybe adding them to the common DRI code? You could just stick with _mesa_warning() and prefix the messages with R300. -Brian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Support for stereoscopic output in DRI?
David Oftedal wrote: Hello! According to one or more sources on Google, Linux now makes it possible to use LCD shutter to get stereoscopic graphics in certain games and with certain graphics cards. However, there are certainly other interesting methods of outputting stereoscopic graphics, such as outputting to two different outputs (such as two different projectors with different polarising filters), combining the red channel of the left frame and the green and blue channels of the right frame to create an anaglyphic image that can be viewed with 3D glasses and so on, and it would be really interesting to see if these methods could be used to output OpenGL graphics. Even more so with the arrival of 3D TVs and monitors, it would be interesting to be able to use their stereoscopic capabilities with existing games and applications. I've seen two pieces of software, one for Linux and one for Windows, and it seemed like what they did was intercept OpenGL commands and render two separate images at slightly shifted (user-specified?) angles or viewpoints, one for the left eye and one for the right eye. If the effect could be achieved more or less reliably in all applications, stereoscopic output could be achieved in a wide range of games even today. I have some experience with automatic stereo from the Chromium project. Chromium has an option which basically intercepts OpenGL matrix changes, computes modified matrices for the left and right views and renders the scene twice into different buffers. It works in simple cases, but falls apart in others. The problem is there's not enough information in the OpenGL command stream to determine the right parameters in all cases. I remember having a lot of difficulty with programs that setup more than one projection transformation per frame too. On the other hand, I believe there's some OpenGL games that can take advantage of true stereo when it's supported. That is, there are quad-buffered colorbuffers for storing separate left/right, front/back images. At any rate, I was wondering if something like this has ever been attempted, or implemented, in DRI? Off hand, I don't recall which DRI-supported cards/chips have stereo ability. Stereo has traditionally been a professional card feature for sci-vis apps. In any case, none of the DRI drivers support quad-buffer stereo at this time. -Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Announcing Piglit, an automated testing framework
All the Glean tests that check for specific rendering results already have an error margin. Can you be more specific about which tests are failing and how the error margin might need to be changed? -Brian Oliver McFadden wrote: I notice some failures with the example tests (R300) that seem to just be slight precision errors; I think you should add a margin for error because usually the hardware will implement things in a faster, perhaps less precise way. This lower precision is still good enough, though. On 3/17/07, Brian Paul [EMAIL PROTECTED] wrote: Nicolai Haehnle wrote: Hello, back when I was actively working on DRI drivers almost three years ago, I always felt uneasy about the fact that I didn't have an extensive array of tests that I could rely on to test for regressions. Now I've decided to do something about it. I've taken Glean and some code from Mesa and wrapped it with Python and cmake glue to - execute OpenGL tests without user interaction and - neatly format the results in HTML You can find the current version (and a sample HTML summary, to get an idea of what they look like at the moment) at http://homepages.upb.de/prefect/piglit/ The idea is to make testing dead simple for driver developers. I believe that Piglit already makes it quite simple, but I'm sure there's still room for improvement. My current plans are: - Hunt some bugs in R300, to get a better feeling for how the tool fares in practice - Integrate tests from Mesa; unfortunately, this needs manual work because those tests are mainly interactive, but it's definitely necessary to make this useful I'm also considering setting up a public repository somewhere, perhaps on Sourceforge. Please give it a try when you have a little time to spare and tell me if you find it useful (or more importantly, why you don't find it useful), and where it could be improved. I'll try to give it a try when I have some time. For now though I've added a link to Piglit from the Glean home page. -Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Announcing Piglit, an automated testing framework
Nicolai Haehnle wrote: Hello, back when I was actively working on DRI drivers almost three years ago, I always felt uneasy about the fact that I didn't have an extensive array of tests that I could rely on to test for regressions. Now I've decided to do something about it. I've taken Glean and some code from Mesa and wrapped it with Python and cmake glue to - execute OpenGL tests without user interaction and - neatly format the results in HTML You can find the current version (and a sample HTML summary, to get an idea of what they look like at the moment) at http://homepages.upb.de/prefect/piglit/ The idea is to make testing dead simple for driver developers. I believe that Piglit already makes it quite simple, but I'm sure there's still room for improvement. My current plans are: - Hunt some bugs in R300, to get a better feeling for how the tool fares in practice - Integrate tests from Mesa; unfortunately, this needs manual work because those tests are mainly interactive, but it's definitely necessary to make this useful I'm also considering setting up a public repository somewhere, perhaps on Sourceforge. Please give it a try when you have a little time to spare and tell me if you find it useful (or more importantly, why you don't find it useful), and where it could be improved. I'll try to give it a try when I have some time. For now though I've added a link to Piglit from the Glean home page. -Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Fwd: compiling savage-20060403-linux.i386
Can someone take a quick look at this patch? -Brian ---BeginMessage--- Message body follows: Hi My name's Roberto. I don't know if you're the right person to send this message, but I prefer telling it. Compiling savage-20060403-linux.i386 driver (http://dri.freedesktop.org/snapshots/), on Linux kernel 2.6.18.2-34-default, I got this error: savage-20060403-linux.i386/drm/linux-core/ati_pcigart.c:87: error: ‘struct page’ has no member named ‘count’ To pass it, I changed these two files: savage-20060403-linux.i386\drm\linux\drm_compat.h savage-20060403-linux.i386\drm\linux-core\drm_compat.h replacing from: #define __put_page(p) atomic_dec((p)-count) to: #define __put_page(p) atomic_dec((p)-_count) Regards Roberto Mannai -- This message has been sent to you, a registered SourceForge.net user, by another site user, through the SourceForge.net site. This message has been delivered to your SourceForge.net mail alias. You may reply to this message using the Reply feature of your email client, or using the messaging facility of SourceForge.net at: https://sourceforge.net/sendmessage.php?touser=1496799 ---End Message--- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-users] mesa fbcon/dri
I'm just cc'ing your message to the DRI list so someone more involved in the DRI/kernel code can take a look at this. -Brian Robert Carter wrote: I saw the post from Lukas S about hardware GL without X11. My problem is similar but using a different method to solve, so i'll begin a new thread. I've read the document about fbdev/dri here: http://www.mesa3d.org/fbdev-dri.html I'm following the instructions to build kernel modules. I am designing for an embedded system, so the kernel is not the same as the currently running kernel. I use make like this to specify the kernel tree: [EMAIL PROTECTED]:~/drm/drm/linux# make LINUXDIR=~/kernel/linux-2.6.18/ make -C /home/rob/kernel/linux-2.6.18/ SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules make[1]: Entering directory `/home/rob/kernel/linux-2.6.18' CC [M] /home/rob/drm/drm/linux/i810_drv.o In file included from /home/rob/drm/drm/linux/drm_core.h:27, from /home/rob/drm/drm/linux/i810_drv.c:40: /home/rob/drm/drm/linux/drm_agpsupport.h:45: error: syntax error before ‘*’ token /home/rob/drm/drm/linux/drm_agpsupport.h:45: warning: type defaults to ‘int’ in declaration of ‘drm_agp’ ... It looks like i'm missing some headers or an environment path is missing. Do I need a kernel headers tarball in addition to the headers already included in the source tree? Thanks for any help Rob - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Mesa3d-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mesa3d-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] fragment.position patch (RFC)
Rune Petersen wrote: Hi, I finally managed to iron out the last issue with getting a fully working fragment.position for the r300 driver. This should really require the big discussion if it wasn't for the fact that it depends on functional changes in r300_vertexprog.c (r300_select_vertex_shader4). The patches: r300_select_vertex_shader4: The patch makes the vertex program output from the fragment input. It makes the driver capable of catching output-input mismatches. primarily based on some of Aapo Tahkola's code. mesa-support_internal_driver_state_vars: Makes it possible for driver to define its own internal state parameters. Checked in. r300_fragment_wpos5: Adds fragment.position support, depends on the above patches. This patch doesn't apply cleanly to Mesa CVS head. r300_select_vertex_shader4.patch applies OK, but I'll hold off it until until the first one is resolved. -Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Rune Petersen wrote: Brian Paul wrote: It seems to me that in ctx-Driver.ProgramStringNotify() you can add any extra parameters you need to the program's parameters list. I would prefer to make driver specific version of _mesa_add_state_reference() for internal state vars. No matter how this is done, the driver needs to call add_parameter() to safely add to the parameter list. Would it be all right if I made add_parameter non static? You can't use _mesa_add_state_reference()? Perhaps a new _mesa_add_driver_state() function otherwise? Then, during state validation in the driver you can load/update any parameters you might have added. I think it is a good idea. In _mesa_fetch_state() we could change the default case for switch (state[i]) to be silent when it sees any state tokens it doesn't understand (rather than call _mesa_problem()). Provided it is only done for STATE_INTERNAL, it should be pretty safe. Also I was thinking adding something like STATE_INTERNAL_DRIVER or some such so the drivers have a safe place to start adding there own vars. Does that sound feasible? yes, and it would be less intrusive. OK. I think the next step would be for you to post a patch with whatever you need changed. Then we'll understand the details better. -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Rune Petersen wrote:
Keith Whitwell wrote:
Rune Petersen wrote:
Keith Whitwell wrote:
Roland Scheidegger wrote:
Keith Whitwell wrote:
I think Rune is rather refering to the fact that you can't change (not
with legal means at least) the constant you got with
_mesa_add_unnamed_constant.
Ah right. I missed that.
I think there exist at least 2 solutions for that. The clean way would
probably be to add some more INTERNAL_STATE (like i965 driver uses) so
you use _mesa_add_state_reference instead, in this case mesa's shader
code would need to update program parameter based on the drawable
information - I'm not sure if accessing a driver's drawable
information there would get messy). The easier solution would probably
be to just directly manipulate the ParameterValues entry associated
with the constant you added, easy though it might be considered
somewhat hackish. Just don't forget you not only have to update the
constant within r300UpdateWindow (if the currently bound fp requires
it), but also when the active fp is switched to another one (and make
sure that a parameter upload is actually triggered if it not already
is upon drawable changes).
I think the parameter approach is probably the right one. This would
require that there be a callback into the driver to get this state, and
more importantly, the driver would have to set a bit in ctx-NewState
(perhaps _NEW_BUFFERS) to indicate that a statechange has occurred which
would affect that internal state atom.
Thank you.
I've hit a bit of a problem:
I was planning to have state flags returned from a callback
make_state_flags().
something like:
ctx-Driver.GetGenericStateFlags(state);
The problem being that the context ctx is not a parameter in
make_state_flags().
Is there smart way of solving this?
Rune,
I don't quite understand what you want to do here. Can you show me the
code you'd like to have (ignoring the ctx argument issue)? I would have
thought that we could determine the state statically and just rely on
the driver to set that state in ctx-NewState when necessary.
I am trying to make generic state vars that the drivers can use.
the way I read these functions:
make_state_flags() - returns the state flags should trigger an update
of the state var.
_mesa_fetch_state() - fetches the state var.
In order to make generic state vars.
- I need to get the flags via a callback to the driver from
make_state_flags().
I need to fetch the vars via a callback to the driver from
_mesa_fetch_state().
make_state_flags()
{
.
case STATE_INTERNAL:
{
switch (state[1]) {
case STATE_NORMAL_SCALE:
.
break;
case STATE_TEXRECT_SCALE:
.
break;
case STATE_GENERIC1:
assert(ctx-Driver.FetchGenericState);
ctx-Driver.FetchGenericState(ctx, state, value);
break;
}
}
}
_mesa_fetch_state()
{
.
case STATE_INTERNAL:
switch (state[1]) {
case STATE_NORMAL_SCALE:
return _NEW_MODELVIEW;
case STATE_TEXRECT_SCALE:
return _NEW_TEXTURE;
case STATE_GENERIC1:
assert(ctx-Driver.GetGenericStateFlags);
return ctx-Driver.GetGenericStateFlags(state);
}
}
It seems to me that in ctx-Driver.ProgramStringNotify() you can add
any extra parameters you need to the program's parameters list.
Then, during state validation in the driver you can load/update any
parameters you might have added.
In _mesa_fetch_state() we could change the default case for switch
(state[i]) to be silent when it sees any state tokens it doesn't
understand (rather than call _mesa_problem()).
Does that sound feasible?
-Brian
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Texture function opengl specification
Roland Scheidegger wrote: Jerome Glisse wrote: According to fragment program extension, TEX, TXP, ... should give you the right A value (Ap depending on which texture unit you are using). That's not how I read that. TEX,TXP,... refer to texture sampling only, there is no thing as previous unit there. Thus, for an RGB texture, A should be always 1. What induced me to this , is that in fragment program extension description they say to look at table 3.21 and in this one there is reference to Ap for A in RGB. Anyway i think you are right here. What version of the spec are you using? Table 3.21 only lists the component mapping here. Well, if my theory is sound, then the glean pixelFormats test is wrong. I don't think the test is wrong as-is. It's just that GL_COMBINE mode exercises things in a different way. A better way, in fact. I'll clean up your patch, Roland, and check it in. I'll check if GL_ARB_texture_env_combine is supported at run time. -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Texture function opengl specification
Roland Scheidegger wrote: Brian Paul wrote: Well, if my theory is sound, then the glean pixelFormats test is wrong. I don't think the test is wrong as-is. It's just that GL_COMBINE mode exercises things in a different way. A better way, in fact. I'll clean up your patch, Roland, and check it in. I'll check if GL_ARB_texture_env_combine is supported at run time. Sorry I didn't express that clearly. The test was ok, but not if you use USE_FRAG_PROG (which is what caused the errors on r300), which should behave the same as when using GL_COMBINE mode unless I'm missing something. This still appears to be wrong (when the GL_REPLACE path is executed with USE_FRAG_PROG set), maybe the test should just be run 3 times instead (fixed function GL_REPLACE, GL_COMBINE and fragment prog, if the extensions are supported). OK, I'll look at the frag prog path. I really just threw that in for a quick test, not thinking it would actually be used thereafter... -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 official releases
Jacek Poplawski wrote: Is it possible to release r300 driver more often to the public? Last version of Mesa has been released 15th September, this version does not contain fix for Blender, so everyone with this version of Mesa will notice broken rendering and people will say to such a person: r300 is broken, but nVidia instead. But truth is that Blender works correctly with current Mesa CVS. Previous version of Mesa has been released in March. Distributions are using official releases, not CVS/git. Is it bad idea to release new version after each important fix, when driver is stable and everything works? This way more people would use the driver. FWIW, I'm hoping to release 6.5.2 next week after we merge in the texmem_0_3 branch. -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Recent CVS commit broke some apps (GLX)
Elie Morisse wrote: Hi, About a week ago you(?) seems to have broken some apps such as wine and ut2004 ( no problem with glxgears, blender, googleearth.. ). wine doesn't work at all, ut2004 doesn't restore resolution at exit, and both output something like this : X Error of failed request: GLXBadContextTag Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 25 Current serial number in output stream: 25 I have a Radeon 9250 and till-arched Xorg 7.1 from Gentoo, and LIBGL_ALWAYS_INDIRECT=1 makes them work. I'm not all sure, but i think the rest of my system is ok, so Mesa is likely guilty BTW current CVS cannot compile :../../../src/mesa/glapi/glapi.c: In function ‘get_static_proc_address’:../../../src/mesa/glapi/glapi.c:436: erreur: expected ‘:’ before ‘;’ token Are you sure you have the latest Mesa code? Line 436 of glapi.c is a #else line. -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tnl trouble, how can you do hw state changes depending on the primitive being rendered
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger wrote: Roland Scheidegger wrote: I thought there was a mechanism that allowed the driver to be notified at glBegin (or similar) time. It seems like you ought to be able to emit some extra state at that time to change to / from point-sprite mode. Ah, sounds like a plan. I thought the NotifyBegin would only be useful for vtxfmt-replace like things. I'll look into that. That was too fast. The NotifyBegin will only be called if there is actually new state, otherwise the tnl module will simply keep adding new primitives. I think the core should be modified to call NotifyBegin if there is new state *or* the primitive type changes. Perhaps there should be a flag to request it being called in that case. Brian, do you have an opinion on this? The tnl module is pretty much Keith's domain. One thing to keep in mind is glPolygonMode. Depending on whether a triangle is front or back-facing, it may either be rendered as a filled triangle, lines, or the vertices rendered as GL_POINTS (which may be sprites!). I think cases like that might be a fallback. Anyway, even if glBegin(GL_TRIANGLES) is called, you may wind up rendering lines, points or sprites instead of triangles. Off-hand I don't know how this is currently handled in the DRI drivers. Keith would know. -Brian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] TCL fallback with Quake3
Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: Hi, Quake3 causes fallback because r300_translate_vertex_shader() returns early and doesn't translate the shader. The culprit: if (!mesa_vp-Base.String) return; To me it looks suspect because checking a pointer to the shader string to verify that the parsed shader is valid doesn't make sense to me. And this check i omitted for fragment translation which uses the same structure. Anything obvious I missed? That check is there to check if a shader string was even specified in the first place (see the thread about Radeon 9200 GetProgramiv(GL_VERTEX_PROGRAM_ARB,... at the mesa3d-dev list). Maybe there is some trouble with that, in the case of quake3 and r300 I'd suspect it's because no string exists for the shader at all, because quake3 obviously doesn't use vertex shaders and it's internally generated by fixed function to shader conversion code. That is what I suspected. The way I see it Base.String is always set along side the Base.Instructions pointer. Since the the code actual depends on Base.Instructions it makes more sense to check it. The only problem is I am unable to test if it failes as intended. If you remove the test for mesa_vp-Base.String does Quake3 work? -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] TCL fallback with Quake3
Rune Petersen wrote: Brian Paul wrote: Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: Hi, Quake3 causes fallback because r300_translate_vertex_shader() returns early and doesn't translate the shader. The culprit: if (!mesa_vp-Base.String) return; To me it looks suspect because checking a pointer to the shader string to verify that the parsed shader is valid doesn't make sense to me. And this check i omitted for fragment translation which uses the same structure. Anything obvious I missed? That check is there to check if a shader string was even specified in the first place (see the thread about Radeon 9200 GetProgramiv(GL_VERTEX_PROGRAM_ARB,... at the mesa3d-dev list). Maybe there is some trouble with that, in the case of quake3 and r300 I'd suspect it's because no string exists for the shader at all, because quake3 obviously doesn't use vertex shaders and it's internally generated by fixed function to shader conversion code. That is what I suspected. The way I see it Base.String is always set along side the Base.Instructions pointer. Since the the code actual depends on Base.Instructions it makes more sense to check it. The only problem is I am unable to test if it failes as intended. If you remove the test for mesa_vp-Base.String does Quake3 work? It does. The Mesa generated shaders doesn't set Base.String making Base.String a bad choice for checking the validity of the Base struct. I am just trying to find a check that is valid in all cases and can be used by r300 r200. Does replacing the above test with this work? if (mesa_vp-Base.NumInstructions == 0) return GL_FALSE; -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] TCL fallback with Quake3
Rune Petersen wrote: Brian Paul wrote: Rune Petersen wrote: Brian Paul wrote: Rune Petersen wrote: Roland Scheidegger wrote: Rune Petersen wrote: Hi, Quake3 causes fallback because r300_translate_vertex_shader() returns early and doesn't translate the shader. The culprit: if (!mesa_vp-Base.String) return; To me it looks suspect because checking a pointer to the shader string to verify that the parsed shader is valid doesn't make sense to me. And this check i omitted for fragment translation which uses the same structure. Anything obvious I missed? That check is there to check if a shader string was even specified in the first place (see the thread about Radeon 9200 GetProgramiv(GL_VERTEX_PROGRAM_ARB,... at the mesa3d-dev list). Maybe there is some trouble with that, in the case of quake3 and r300 I'd suspect it's because no string exists for the shader at all, because quake3 obviously doesn't use vertex shaders and it's internally generated by fixed function to shader conversion code. That is what I suspected. The way I see it Base.String is always set along side the Base.Instructions pointer. Since the the code actual depends on Base.Instructions it makes more sense to check it. The only problem is I am unable to test if it failes as intended. If you remove the test for mesa_vp-Base.String does Quake3 work? It does. The Mesa generated shaders doesn't set Base.String making Base.String a bad choice for checking the validity of the Base struct. I am just trying to find a check that is valid in all cases and can be used by r300 r200. Does replacing the above test with this work? if (mesa_vp-Base.NumInstructions == 0) return GL_FALSE; yes (remove GL_FALSE, void function) OK, I checked in this change. The r200 version needs the return value. -Brian - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 code cleanup
Tilman Sauerbeck wrote: Jerome Glisse [2006-07-03 23:49]: I want to cleanup a bit the r300 code, there is a lot of dead code. I also would like to use unified indenting rules and function naming rules. Good idea :) For indenting rules i personnaly use the linux kernel ones, iirc this was the original indenting choosed by Nicolai. Anyway, we can use another if people prefer another one (as long as the indenting you propose is not severly broken). Shouldn't we stick to the Mesa indentation rules? My feeling is that code in core Mesa should follow the established indentation/brace/etc style but driver writers are free to use their own style (within reason). I figure if you're putting a lot of work into a driver and you're most productive with your own style, it's your prerogative to do as you see fit. For function name i think that r300DoSomething is for function called by mesa and r300_do_otherthings is for internal driver function at leat this is my guess from looking at i915 driver :) I'd prefer not to mix up CamelCase and snake_case. Do you think the benefit it provides is good enough to make up for the inconsistency? We haven't been totally consistant with that, unfortunately. My general style is when a function directly corresponds to an OpenGL entrypoint, it gets named _prefix_FunctionName(). I.e. _mesa_TexImage2D(). That way you can easily search for the functions which implement a particular OpenGL function. Functions which are non-static and do not correspond to an API function are _prefix_function_name(). I.e. _mesa_initialize_texture_object(). Functions which are static are function_name(). I.e. is_depth_format() That's core Mesa anyway, I realize the DRI drivers have followed a somewhat different style. -Brian Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Why DRI/Mesa turns off hardware acceleration instead disabling features?
Jacek Poplawski wrote: Hardware acceleration is always on assuming your system is set up properly. If an application uses a feature that is not supported by hardware, you have to fall back to software if you want the application to run. But in that case many applications won't run correctly, because they are tested with propertary nVidia/ATI drivers, and their authors don't know / don't care about open source drivers. And it is not possible to fix closed source application. Sometimes particular graphics hardware isn't even fast enough to give decent performance, nevermind hardware vs. software paths. Ideally, an application should either measure its own performance and automatically scale back rendering or give the user the option to do so manually. To address this thread's subject, I don't think a driver should just ignore particular OpenGL features when they may be slow. I'd rather have a slow OpenGL driver than one that just drops features/rendering on the floor. Is there any layer between application and OpenGL implementation which may process OpenGL calls and emulate some of them (i.e. draw normal lines instead smooth ones)? Maybe a wrapper - /usr/lib/libGL.so library which will use /usr/lib/libGL- original.so library? Chromium (http://sourceforge.net/projects/chromium) can be used to intercept/change OpenGL calls. Or is it completly wrong idea? I don't think it's something most people want to mess with. -Brian Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Doom3 causes VBO leak
Tilman Sauerbeck wrote: Tilman Sauerbeck [2006-06-11 12:35]: Tilman Sauerbeck [2006-05-22 19:42]: [...] I found out that the buffer in question was allocated by r300BufferData(). Now, the proper call to radeon_mm_free() would have been made by r300DeleteBuffer(), but that function was never called. From looking at the code I think this means that it's an application error. Now the question is, should Mesa call the DeleteBuffer callback for all buffers that are still alive when the context is destroyed or should r300 be able to cope with it the way it currently is? Here's a patch that deletes all VBOs that are still alive when the context is destroyed. Because r300DeleteBuffer() calls radeon_mm_free(), which depends on ctx-DriverCtx, we now cannot set DriverCtx to NULL before destroying the Mesa context however. Is this a problem? There's lots of driver calls in free_share_state() that might depend on DriverCtx not being NULL, so I don't think I'm adding new evil code here. Can anyone please comment on that patch? Looks OK to me. I think you can check it in. -Brian Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][PATCH] minor patches
Rune Petersen wrote: Hi, Thought I'd share some of my patches. Change vp max instructions: The current state op the vp code is capable of executing 255 instructions not 255*4. Disable unused routes (speedup): When trying to get fragment.position to work I found the routes were only set for the used routes and disabling it gives a few fps in some games. I have found no regressions... Rune, would you like CVS-write access so you can check in your own changes? You seem to be getting pretty familiar with the code. I'll check in these two if no-one has any concerns, or if nobody beats me to it. -Brian Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][PATCH] fix vertex attribs - try 2 - Re: [r300] ARB vp attribs broken?
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tilman Sauerbeck wrote:
Index: r300_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v
retrieving revision 1.98
diff -u -p -r1.98 r300_context.h
--- r300_context.h27 Jun 2006 01:26:47 - 1.98
+++ r300_context.h27 Jun 2006 16:30:09 -
@@ -544,7 +544,7 @@ struct r300_vap_reg_state {
int i_color[2];
int i_fog;
int i_tex[R300_MAX_TEXTURE_UNITS];
-int i_attrib[_TNL_LAST_GENERIC-_TNL_FIRST_GENERIC];
+int i_attrib[_TNL_LAST_GENERIC - _TNL_FIRST_GENERIC + 1];
int i_index;
int i_pointsize;
};
I think we should add a define _TNL_NUM_GENERIC for this. This will
likely happen in other drivers in the future, and I'd hate to see these
off-by-one errors come back.
Yes, please do so. Put it in tnl/t_context.h
-Brian
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] ARB vp attribs broken?
Rune Petersen wrote: Tilman Sauerbeck wrote: Rune Petersen [2006-06-25 16:31]: I've been looking at vertex shaders this weekend. It would appear that attribs are broken. The most straight forward way to test this it to compare progs/tests/arbvptest3 to progs/tests/vptest3 On my system I get different colors when I resize the window. Can someone confirm this? (it would explain why Doom 3 is broken) Yes, I have reported this some weeks ago: http://marc.theaimsgroup.com/?l=dri-develm=114855685402158w=2 Don't know how I fixed that... It would appear to be caused bu the reshuffling of the attribs. Any idea where the attribs are passed to the driver? and how to read the data in the attribs... I can't comment on the r300 driver, but the change in vertex aliasing in core Mesa is pretty simple. It's really just a change of which index into the VB-Attribs[] array corresponds to glVertexAttribARB(index, ...). -Brian Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300: GL_INVALID_ENUM in glStencilFunc.
Mike Mestnik wrote: I keep trying to send this :( http://www.transgaming.com/showthread.php?forum=1262thread=61671msg=61671 LIBGL_ALWAYS_INDIRECT works. Grand Theft Auto III, in game black screen. - Request for support (open) more help needed by cheako on Tuesday June 13, 2006 @ 10:20PM. Cedega Version: 5.1.4 Distribution: Debian Video Card: ATI X600. Driver: DRI r300 Sound Card: Black Sheep - onboard. Driver: ALSA Game Title: Grand Theft Auto III 3 three Using LIBGL_ALWAYS_INDIRECT fixes this problem. If any one else reports it this could be a bug in the r300 driver. I was playing GTA3 and then I don't know what I did, but now after the intro movies(hit space twice!!) all I get is a black screen. I'm able to start the game and even drive around blindly with the cops after me. The speed is fast and I'm sure I get hardware rendering... libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so drmOpenByBusid: Searching for BusID pci::02:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: drmOpenMinor returns 14 drmOpenByBusid: drmGetBusid reports pci::02:00.0 EOF Re: Grand Theft Auto III, in game black screen. by cheako on Tuesday June 13, 2006 @ 10:48PM. Ohh, wait... This is with MESA_DEBUG. Mesa: User error: GL_INVALID_ENUM in glStencilFunc I don't get this with LIBGL_ALWAYS_INDIRECT, a goggle says that this is for not drawing things. How do I know if this is emitted by the app, cedega, or mesa? It's emitted by Mesa when the application makes an invalid API call. -Brian -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300: GL_INVALID_ENUM in glStencilFunc.
Mike Mestnik wrote: On Mon, Jun 19, 2006 at 08:01:09AM -0600, Brian Paul wrote: Mike Mestnik wrote: I keep trying to send this :( http://www.transgaming.com/showthread.php?forum=1262thread=61671msg=61671 LIBGL_ALWAYS_INDIRECT works. Grand Theft Auto III, in game black screen. - Request for support (open) more help needed by cheako on Tuesday June 13, 2006 @ 10:20PM. Cedega Version: 5.1.4 Distribution: Debian Video Card: ATI X600. Driver: DRI r300 Sound Card: Black Sheep - onboard. Driver: ALSA Game Title: Grand Theft Auto III 3 three Using LIBGL_ALWAYS_INDIRECT fixes this problem. If any one else reports it this could be a bug in the r300 driver. I was playing GTA3 and then I don't know what I did, but now after the intro movies(hit space twice!!) all I get is a black screen. I'm able to start the game and even drive around blindly with the cops after me. The speed is fast and I'm sure I get hardware rendering... libGL: XF86DRIGetClientDriverName: 4.0.3 r300 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r300_dri.so drmOpenByBusid: Searching for BusID pci::02:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 14, (OK) drmOpenByBusid: drmOpenMinor returns 14 drmOpenByBusid: drmGetBusid reports pci::02:00.0 EOF Re: Grand Theft Auto III, in game black screen. by cheako on Tuesday June 13, 2006 @ 10:48PM. Ohh, wait... This is with MESA_DEBUG. Mesa: User error: GL_INVALID_ENUM in glStencilFunc I don't get this with LIBGL_ALWAYS_INDIRECT, a goggle says that this is for not drawing things. How do I know if this is emitted by the app, cedega, or mesa? It's emitted by Mesa when the application makes an invalid API call. -Brian How do I prove that? I'm thinking they might try and say that a software mesa path is calling this, I'd assume that internally you would call something like _glStencilFunc. The internal function is called _mesa_StencilFunc. It's called directly by glStencilFunc, or via executing a display list. In either case, the only way that error will be reported is if the application provides an invalid value. My other problem is that if the error is caught, why is the screen all black? I can't say. Maybe correct stencil operation is required for anything to appear. Or, it may be a totally unrelated issue. What would be the next step in tracking this down be? One of the r300 driver developers will probably have to look into it. -Brian -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: _glapi_add_dispatch
Alan Hourihane wrote: On Thu, 2006-06-01 at 17:07 +0100, Alan Hourihane wrote: On Thu, 2006-06-01 at 08:53 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jacek Poplawski wrote: On 5/30/06, Pedro Maia [EMAIL PROTECTED] wrote: To run quake2 please use, LD_PRELOAD=path/to/libGL.so quake2 In my case it works fine, with that trick , without it didn't work. But why it didn't work? It opens /usr/lib/libGL.so for sure, because without it even software accelerated OpenGL doesn't work in the game. Quake2 is the only application I tried which loads libGL with dlopen. I think the way that Quake2 dlopens libGL prevents some symbols in libGL from being exposed to the driver. I seem to remember alanh mentioning something about this, but I don't recall the details. My dlopen-fu is lacking, so I'm not sure what the problem or the solution might be. Basically, what happens is this A game may try to dlopen libGL itself at runtime rather than linking at build time. So, the linux dllinker does not bother to search for symbols to resolve that exist in the DRI driver. I'm not sure exactly why it doesn't though. Actually I do remember my theory When a program is linked at build time, libGL is the one responsible for dlload'ing the DRI driver and resolves symbols perfectly well with the current RTLD flags. But when the program dlopen's libGL itself, it resolves what it currently has access to which the DRI driver isn't actually loaded. I suspect for this to work the libGL's dlinit() routine (that's called when dlopen'ed) would need to someone link in the correct DRI driver at that time - but I'm pretty sure all the available details to do that wouldn't be available. I don't think there's any easy fix, which is why I resorted to the LD_PRELOAD approach. This may all be bogus though. This sounds related to the -Bsymbolic linker option. When you build a shared library, the -Bsymbolic option tells the linker to resolve references in the shared library to symbols defined within the library, in preference to other locations. For example, if libGL had a function called init_driver(), -Bsymbolic would ensure that references to init_driver() were resolved to that function, and not another init_driver() function that might be defined in the application itself. The lack of -Bsymbolic in some libraries has caused me grief in the past. I've also raised this issue with some commercial OpenGL vendors. -Brian -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] per-component negation for SWZ
Tilman Sauerbeck wrote: Roland Scheidegger [2006-05-30 22:33]: Tilman Sauerbeck wrote: I finally ran glean today, and noticed that SWZ wasn't implemented properly for r300 ARB vertex programs. So far I didn't handle per-component negation flags, the attached patch adds that. Question: is it okay to assume that NegateBase in struct prog_src_register will always be filled the way it's filled currently? ie that the sign for the x component is at bit 0 etc. I'd guess that's ok. Whoever wants to change it needs to make sure that the code wherever it's used still works. Such things can get forgotten though, but in that case someone will notice and fix it up then :-). Mmh, alright :) If it doesn't, the patch I attached obviously wouldn't work... If there are no objections, I'll commit this in a few days. Wouldn't it be simpler to just change t_src to always apply src-NegateBase? I can't see a need for that src-NegateBase ? VSF_FLAG_ALL : VSF_FLAG_NONE, as the mesa parser sets all 4 bits anyway when normal instructions are parsed. The code would both be smaller and faster :-). (t_src_scalar OTOH cannot be changed.) That won't work for NV vertex programs. nvvertparse.c sets NegateBase to either GL_TRUE or GL_FALSE. If they'd use 0xf (== VSF_FLAG_ALL) and 0x0 as NV fp and ARB vp/fp do, it would work indeed :) Maybe nvvertparse.c should be changed? Setting a GLuint bitfield to GL_TRUE seems a bit weird :) Good catch. The NegateBase field is meant to per-component. I'll fix the nvverparse.c code. The only instruction which can arbitrarily set individual bits of NegateBase is SWZ. For all other instructions, all four bits will either be set or cleared. -Brian -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] vertex attribute changes broke Doom3?
Tilman Sauerbeck wrote: Hi, I suspect that the vertex attribute changes from 2006-04-26 broke Doom3 on r300. Symptoms: The rendering of Mars in the main menu screen is broken, see the attached screenshot (the planet is supposed to look reddish, not white). It's also flickering a lot. Similar problems exist in game, but they aren't very well visible on screenshots... Anyway, CVS from 2006-04-25 works, but the code from the 26th (including the _TNL_ATTRIB_INDEX - _TNL_ATTRIB_LAST_MAT fix) doesn't. Any ideas? I just checked in a patch to Mesa that _might_ help with this. -Brian --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] texture corruption with copypixrate subtexrate
Rune Petersen wrote: Hi, I get texture corruption if copypixrate or subtexrate is run without being the top most window. This is not a new problem, I just just happened to discover recently. When a window is partially covered by another window, or off the edge of the screen, reading pixels from those areas gives undefined results (because there's no backing store). That's within the OpenGL spec. -Brian --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] problems leaving the game (Quake 3 + Doom 3)
Rune Petersen wrote: I found the problem: In Mesa MAX_TEXTURE_UNITS, MAX_TEXTURE_COORD_UNITS, and MAX_TEXTURE_IMAGE_UNITS are all set to 8. (src/mesa/main/config.h) And there are no sanity-checks done on the values returned by the drivers. Changing the defines to 16 makes everything work. Changing only MAX_TEXTURE_IMAGE_UNITS should be valid according to src/mesa/main/config.h but a sanity-check fails (if commented out it lockups like before). In the future it would be nice to have bounds checks on the Const.* values. I've added a new function that does some sanity checks on the ctx-Const.* values the first time a context is bound. As discussed a few days ago, we're presently limited to 8 texture image and coordinate units in core Mesa. -Brian --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New video card
Alvaro Kuolas wrote: Hello to everyone! Currently I'm searching for a good video card, but I'm not interested in performance: I wan't it to be well documented. I now that 3dfx ones are well documented, I need something new, but no new new. What is the best video card for using it on DRI? How good is a r200 or a r300 based video card in terms of well documented by ATI? In my inventory i have: 3D Blaster Banshee 16MiB SGRAM (3Dfx Voodoo Banshee) Diamond Stealth III S540 32MiB SDRAM (S3 Graphics Savage4 Pro+) Unknown Brand S3 Trio64V+ 1MiB Power3D TNT2 M64 32MiB SDRAM If it counts: CirrusLogic CL-GD5424 512KiB CirrusLogic CL-GD5428 1MiB I've always complaint on ATI, about not releasing good documents and/or good drivers (and still is the case). But now the TNT2 (TNT, TNT2, GeForce 256, GeForce2) since ForceWare 75 (Linux Driver 71.74 is the last) ins not supported. They dropped support for it. Anybody knows if nvidia is dropping docs too? What will be to these unsupported video cards? You might also consider getting a motherboard with an Intel graphics chip. They're pretty well covered by the DRI drivers and may be the first to expose advanced GL features like framebuffer objects. -Brian --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] problems leaving the game (Quake 3 + Doom 3)
Rune Petersen wrote: Adam Jackson wrote: On Wednesday 26 April 2006 10:14, Rune Petersen wrote: Hi, Since the 12 of April there has been a change that causes Quake 3 and Doom 3 (demo)not to exit properly. Quake 3 locks up the system, and Doom 3 does a double fault. The suspect as I see it is: Ensure all GART allocations are freed on context destruction But I have yet to confirm it. If you are unable to confirm it, I'll try to track it down myself. That patch was admittedly rather brute-force, but I've not had any issues with it locally. Turns out you're off the hook :) (for now) The Quake 3 lockup is caused/triggered by a change done to Mesa (not r300) between 14 and 15 of April. patch: Replace ctx-Const.MaxTextureUnits w/ ctx-Const.MaxTexture[Coord/Image]Units in various places. looks like I need to join the Mesa mailing-list... Do you have the MESA_DEBUG env var set? That might give a hint. I think the r300 driver is the only one that can have different values for GL_MAX_TEXTURE_IMAGE_UNITS and GL_MAX_TEXTURE_COORD_UNITS. That might have something to do with it. Looks like those values can be set in your .driconf file (though I'm not sure why that's a config option!). Otherwise, here's the CVS check-in log. You could try undoing the changes in one file at a time until you find the trouble: Revision ChangesPath 1.64 +4 -0 Mesa/src/mesa/main/matrix.c http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/main/matrix.c 1.265 +3 -3 Mesa/src/mesa/main/mtypes.h http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/main/mtypes.h 1.138 +114 -29 Mesa/src/mesa/main/texstate.c http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/main/texstate.c 1.92 +4 -7 Mesa/src/mesa/swrast/s_context.c http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/swrast/s_context.c 1.113 +2 -1 Mesa/src/mesa/swrast/s_span.c http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/swrast/s_span.c 1.54 +3 -3 Mesa/src/mesa/tnl/t_array_api.c http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_array_api.c 1.48 +1 -1 Mesa/src/mesa/tnl/t_vb_arbprogram.c http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_vb_arbprogram.c 1.9 +2 -2 Mesa/src/mesa/tnl/t_vb_arbshader.c http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_vb_arbshader.c 1.38 +1 -1 Mesa/src/mesa/tnl/t_vb_program.c http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_vb_program.c -Brian --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300]Crash, and backtrace!
Pedro Maia wrote:
I'm using R300 CVS from today (24-04-2006). During my test sessions i found
some problems.
Tests:
ARBWARPMESH
Starting program: /home/pedro_maia/CVS/Mesa/progs/tests/arbvpwarpmesh
[Thread debugging using libthread_db enabled]
[New Thread -1213638976 (LWP 27240)]
Mesa: CPU vendor: AuthenticAMD
Mesa: CPU name: AMD Athlon(tm) XP 2800+
Mesa: MMX cpu detected.
Mesa: 3DNow! cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
glGetError = 0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213638976 (LWP 27240)]
0x in ?? ()
(gdb) bt full
#0 0x in ?? ()
No symbol table info available.
#1 0x080490e5 in Display () at arbvpwarpmesh.c:50
No locals.
#2 0xb7f20ae1 in processWindowWorkList (window=0x80536f0) at
glut_event.c:1297
changes = {x = -1211930352, y = -1208603141, width = -1208545324,
height = -1208544024, border_width = 134513940, sibling = 3213289040,
stack_mode = -1208589632}
workMask = 4
__PRETTY_FUNCTION__ = processWindowWorkList
#3 0xb7f20dcf in glutMainLoop () at glut_event.c:1344
remainder = (GLUTwindow *) 0x0
#4 0x080495b2 in main (argc=1, argv=0x0) at arbvpwarpmesh.c:244
No locals.
You'll need to recompile the driver with -g to get a meaningful stack
trace.
ARBVPTEST3
Starting program: /home/pedro_maia/CVS/Mesa/progs/tests/arbvptest3
[Thread debugging using libthread_db enabled]
[New Thread -1213233472 (LWP 28004)]
Mesa: CPU vendor: AuthenticAMD
Mesa: CPU name: AMD Athlon(tm) XP 2800+
Mesa: MMX cpu detected.
Mesa: 3DNow! cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
glGetError = 0
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213233472 (LWP 28004)]
0x in ?? ()
(gdb) bt full
#0 0x in ?? ()
No symbol table info available.
#1 0xb79e225a in _tnl_VertexAttrib3fARB (index=137004200, x=-1.10118103,
y=-1.10118103, z=-1.10118103) at t_vtx_generic.c:467
ctx = (GLcontext *) 0xbf8cf380
#2 0x08048e0d in Display () at arbvptest3.c:25
No locals.
#3 0xb7f83ae1 in processWindowWorkList (window=0x80536f0) at
glut_event.c:1297
changes = {x = 12, y = 41, width = 0, height = 134525008,
border_width = 33554433, sibling = 0, stack_mode = 0}
workMask = 2052
__PRETTY_FUNCTION__ = processWindowWorkList
#4 0xb7f83dcf in glutMainLoop () at glut_event.c:1344
remainder = (GLUTwindow *) 0xb79e2210
#5 0x080490a0 in main (argc=1, argv=0x0) at arbvptest3.c:125
No locals.
I may be fixing this soon with an upcoming check-in. See my posting
to mesa3d-dev from last week if interested.
ARBVPTEST1
Althought no errors appear, i don't see nothing in the window!
FPTEST1
Mesa: CPU vendor: AuthenticAMD
Mesa: CPU name: AMD Athlon(tm) XP 2800+
Mesa: MMX cpu detected.
Mesa: 3DNow! cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
Mesa 6.5.1 implementation error: User called no-op dispatch function (an
unsupported extension function?)
Please report at bugzilla.freedesktop.org
glGetError = 1280
TEXOBJSHARE
Mesa: CPU vendor: AuthenticAMD
Mesa: CPU name: AMD Athlon(tm) XP 2800+
Mesa: MMX cpu detected.
Mesa: 3DNow! cpu detected.
Mesa: SSE cpu detected.
Mesa: Not testing OS support for SSE, leaving enabled.
GL_RENDERER = Mesa DRI R300 20040924 AGP 4x x86/MMX+/3DNow!+/SSE TCL
Generated texture ID 1
After delete, binding = 0
In second context, binding = 1
X Error of failed request: BadValue (integer parameter out of range for
operation)
Major opcode of failed request: 143 (XFree86-DRI)
Minor opcode of failed request: 9 ()
Value in failed request: 0x282
Serial number of failed request: 33
Current serial number in output stream: 33
If you need any more info please say. Do you want me to open a bug, in
bugzilla database?
If you don't see any progress on these within a couple days, file a
bug report.
-Brian
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Insane build system (Was: glxinfo segfaults with r300)
Tilman Sauerbeck wrote:
Benjamin Herrenschmidt [2006-04-14 16:40]:
On Fri, 2006-04-14 at 15:31 +1000, Benjamin Herrenschmidt wrote:
On Fri, 2006-04-14 at 15:15 +1000, Benjamin Herrenschmidt wrote:
Not sure at this point, but the problem ends up being ctx-DriverCtx at
a different offset
within GLcontext between mesa context.c and r300_tex.c.
Looks like to get the stuff built properly, one has to build first, make
install, make clean and rebuild, and finally re-make install
Oh, and I'm not even sure where the installed versions came from...
looks like it could have been from an X.org install (does it install
GL/internal/* stuff too ?)
Hrm... did make install which updated headers, rebuilt all and still
crash... so something else is causing r300_tex.c to be built with a
different idea of what GLcontext is than the rest of mesa, maybe some
#define related to an EXTension or something like that...
Ok, finally... stale {prefix}/include/GL/internal/glcore.h
No idea who installed this file, it wasn't updated by a make install of
Mesa/DRI, could have been put there by the server, not sure.
{prefix}/include/GL/internal/glcore.h is installed by xorg's glproto.
Why is that? I don't think that's a good idea. {prefix}/include/GL
should only have the public OpenGL headers needed to compile apps, no
internal headers.
-Brian
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][PATCH] compile error fix
Fixed. -Brian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: driver level sub-pixel rendering?
John Kheit wrote: Sorry Brian, I should have been more specific. I mean more as a final output onto a screen. Using an LCD/CRT's individual RGB subpixels to antialiasing (or some form of screen output enhancement). It seems a lot of the 3D stuff in the GPU is already employing sub-pixel coordinates, so it would be nice if the actual output to the screen would take advantage of that. AFAIK, nobody's hardware does that. When that kind of antialiasing is done for text, I think it's the job of the font rendering code to do so. -Brian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: driver level sub-pixel rendering?
John Kheit wrote: Do these drivers do anything to support subpixel rendering of the text or screen images? Is any of that built in to the hardware acceleration, or is that done only at the operating system level? I think on the Windows side, some of the Nvidia drivers do subpixel work on the driver level. Can you be more specific? If you're asking about line/triangle rasterization, I believe vertex coordinates are snapped/truncated to some sub-pixel fraction (rather than whole pixel coords) in all hardware. For text, are you asking about some form of antialiasing? Or, do you have multisampling in mind? -Brian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: xorg HEAD + Mesa HEAD = boom
Kristian Høgsberg wrote: Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kristian Høgsberg wrote: Benjamin Herrenschmidt wrote: Haven't had time to investigate much yet (and probably won't for a couple of weeks) but with a build of today's CVS Mesa, r300 DRI, and X against that Mesa version (the whole lot), the server blows up right away when launching glxinfo or glxgears. The latest log I got (with glxgears) shows this backtrace: It isn't clear from the stack trace what went wrong, but I've just checked in a patch which fixes a few issues: GLcore needs to build with TLS settings matching glx, the ARGB visual is now marked as non-conformant, and there was a problem with freeing a mesa buffer even if it never got allocated. What is non-conformant about those visuals? Maybe it's not non-conformance, but a driver bug instead. The radeon driver panics and calls exit() if it sees a visual with no depth buffer (see the switch on line 175 in radeon_state_init.c). Yikes! That should be fixed. The default case should probably be: rmesa-state.depth.clear = 0; rmesa-state.depth.scale = 0.0; /* or 1.0? */ rmesa-staet.stencil.clear = 0; Can someone try that? -Brian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: xorg HEAD + Mesa HEAD = boom
Benjamin Herrenschmidt wrote: Haven't had time to investigate much yet (and probably won't for a couple of weeks) but with a build of today's CVS Mesa, r300 DRI, and X against that Mesa version (the whole lot), the server blows up right away when launching glxinfo or glxgears. The latest log I got (with glxgears) shows this backtrace: Backtrace: 0: /usr/local/xorg/bin/X(xf86SigHandler+0xa4) [0x10082344] 1: [0x100374] 2: [0x10c5b548] 3: [0x10c5b548] 4: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so(xmesa_resize_buffers+0x54) [0xf61c004] 5: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so(XMesaResizeBuffers+0x60) [0xf61ac54] 6: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so [0xf616f04] 7: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so(DoMakeCurrent+0x5d8) [0xf98e06c] 8: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so(__glXMakeCurrent+0x24) [0xf98e164] 9: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so [0xf993d94] 10: /usr/local/xorg/bin/X(Dispatch+0x21c) [0x10043c40] 11: /usr/local/xorg/bin/X(main+0x47c) [0x10025170] 12: /lib/libc.so.6 [0xfc558ec] 13: /lib/libc.so.6 [0xfc55a34] Update your Mesa CVS and try again. I checked in some changes a few hours ago. -Brian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Xorg-HEAD with XGL branch with Mesa 6.5 issues
Shawn Starr wrote: Mesa 6.5 implementation error: Unexpected format 0xa77f4625 in _mesa_source_buffer_exists Please report at bugzilla.freedesktop.org Could you set a breakpoint in _mesa_problem() and get a stack trace? The value 0xa77f4625 looks like garbage. Xgl: tnl/t_vb_arbprogram.c:1279: run_arb_vertex_program: Assertion `p' failed. Stack trace? If I build the Xgl branch install it _then_ install Xorg-HEAD. Xgl works rather well, except if I start certain applications: firefox or konsole it crashes out and dumps this to log. -Brian --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
