[Mesa3d-dev] [Bug 24425] rv770 hangs when trying to play nexuiz (mesa bisected)
http://bugs.freedesktop.org/show_bug.cgi?id=24425 --- Comment #5 from Asbjørn Sannes a...@sannes.org 2009-10-13 01:21:58 PST --- Hm, well nexuiz definitly makes it hang within 20 minutes, but it seems it is not connected to that commit at all now, atleast when it hangs I do not get any off the output I put in there.. only thing is that it seems to happen more often with that commit, but that could be a coincident .. drmRadeonCmdBuffer: -16. Kernel failed to parse or rejected command stream. See dmesg for more info. And in dmesg: [ 330.458381] [drm:radeon_ib_get] *ERROR* radeon: IB(2:0x10121000:15872) [ 330.458384] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB [ 330.458386] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! So since it hangs, sometimes quicker than other times, and the correlation does not seem strong enough, maybe this bug should just be closed? I actually spent a lot of time to make sure that it was that commit that caused the difference before reporting a bug, and now I can't reproduce it. Sorry to waste your time like this.. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24425] rv770 hangs when trying to play nexuiz (mesa bisected)
http://bugs.freedesktop.org/show_bug.cgi?id=24425 --- Comment #6 from Marcin Baczyński marb...@gmail.com 2009-10-13 01:37:43 PST --- I get the same dmesg messages on my mobility 2400 (m72/rv610). See bug #24218 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300g: Fallback on surfaces we can't render to or from.
On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: Module: Mesa Branch: master Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 Author: Corbin Simpson mostawesomed...@gmail.com Date: Mon Oct 12 20:47:00 2009 -0700 r300g: Fallback on surfaces we can't render to or from. Still not sure why st keeps handing down things we can't render to. Corbin, This is a problem of the Mesa state tracker and most co-statetrackers that sit on top of it. It's better than it was before but there are still a few places where it uses formats without querying the driver. A typical problem are PIPE_FORMAT_x - Mesa visual translation. I had to solve this in the WGL state tracker, but it would be nice if we had shared code for that in src/mesa/state_tracker . Jose -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300g: Fallback on surfaces we can't render to or from.
José Fonseca wrote: On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: Module: Mesa Branch: master Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 Author: Corbin Simpson mostawesomed...@gmail.com Date: Mon Oct 12 20:47:00 2009 -0700 r300g: Fallback on surfaces we can't render to or from. Still not sure why st keeps handing down things we can't render to. Corbin, This is a problem of the Mesa state tracker and most co-statetrackers that sit on top of it. It's better than it was before but there are still a few places where it uses formats without querying the driver. A typical problem are PIPE_FORMAT_x - Mesa visual translation. I had to solve this in the WGL state tracker, but it would be nice if we had shared code for that in src/mesa/state_tracker . This is just happening with surface_copy() and surface_fill(), right? I think the assumption was that if the driver can create a surface in format X, then it can copy and fill regions in format X by one means or another (and not necessarily by 3D rendering). Corbin, it looks like you're using quads/points to do the copy/fill. Can't some sort of blit be used instead? -Brian -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Store clipping distance for user clip planes as part of vertex processing
Looks good to me.
-Brian
Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Once the clipping distance is calculated and stored per vertex, the
distances can be re-used when clipping is actually performed. This
doesn't have any immediate benefit, but it paves the way for
implementing gl_ClipDistance in vertex shaders and result.clip[] in
vertex programs.
This has not produces any oglconform regressions on my G31 system
which uses software TNL.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/tnl/t_context.h|1 +
src/mesa/tnl/t_vb_cliptmp.h | 103 --
src/mesa/tnl/t_vb_program.c | 15 ++
src/mesa/tnl/t_vb_vertex.c | 31 -
4 files changed, 132 insertions(+), 18 deletions(-)
diff --git a/src/mesa/tnl/t_context.h b/src/mesa/tnl/t_context.h
index 6137c2d..ca4edcf 100644
--- a/src/mesa/tnl/t_context.h
+++ b/src/mesa/tnl/t_context.h
@@ -207,6 +207,7 @@ struct vertex_buffer
GLvector4f *EyePtr;/* _TNL_BIT_POS */
GLvector4f *ClipPtr; /* _TNL_BIT_POS */
GLvector4f *NdcPtr; /* _TNL_BIT_POS */
+ GLfloat *ClipDistancePtr[MAX_CLIP_PLANES]; /* _TNL_BIT_POS */
GLubyte ClipOrMask; /* _TNL_BIT_POS */
GLubyte ClipAndMask;/* _TNL_BIT_POS */
GLubyte *ClipMask; /* _TNL_BIT_POS */
diff --git a/src/mesa/tnl/t_vb_cliptmp.h b/src/mesa/tnl/t_vb_cliptmp.h
index 618b8b3..0d2183a 100644
--- a/src/mesa/tnl/t_vb_cliptmp.h
+++ b/src/mesa/tnl/t_vb_cliptmp.h
@@ -80,6 +80,58 @@ do {
\
} while (0)
+#define POLY_USERCLIP(PLANE) \
+do { \
+ if (mask CLIP_USER_BIT) { \
+ GLuint idxPrev = inlist[0]; \
+ GLfloat dpPrev = VB-ClipDistancePtr[PLANE][idxPrev];\
+ GLuint outcount = 0; \
+ GLuint i;
\
+ \
+ inlist[n] = inlist[0]; /* prevent rotation of vertices */
\
+ for (i = 1; i = n; i++) { \
+GLuint idx = inlist[i];\
+GLfloat dp = VB-ClipDistancePtr[PLANE][idx]; \
+ \
+if (!IS_NEGATIVE(dpPrev)) {\
+ outlist[outcount++] = idxPrev; \
+} \
+ \
+if (DIFFERENT_SIGNS(dp, dpPrev)) { \
+ if (IS_NEGATIVE(dp)) { \
+ /* Going out of bounds. Avoid division by zero as we\
+ * know dp != dpPrev from DIFFERENT_SIGNS, above.\
+ */ \
+ GLfloat t = dp / (dp - dpPrev); \
+ INTERP_4F( t, coord[newvert], coord[idx], coord[idxPrev]); \
+ interp( ctx, t, newvert, idx, idxPrev, GL_TRUE );\
+ } else {\
+ /* Coming back in. \
+ */ \
+ GLfloat t = dpPrev / (dpPrev - dp); \
+ INTERP_4F( t, coord[newvert], coord[idxPrev], coord[idx]); \
+ interp( ctx, t, newvert, idxPrev, idx, GL_FALSE ); \
+ } \
+outlist[outcount++] = newvert++; \
+} \
+ \
+idxPrev = idx; \
+dpPrev = dp; \
+ }
\
+ \
+ if (outcount 3)
\
+return;\
+ \
+ {
[Mesa3d-dev] [PATCH 2/2] Fix build when PROGRAM_DIRS is empty.
SUBDIRS just takes PROGRAM_DIRS value. If PROGRAM_DIRS gets set to the empty string (as can happen when building only OSMesa), a 'for' loop will lack anything to iterate over, causing a parse error. This fixes the issue by making sure SUBDIRS is the null string when PROGRAM_DIRS is, and wrapping the for loops in if's, causing them only to execute if there are directories to iterate over. --- progs/Makefile | 26 +++--- 1 files changed, 15 insertions(+), 11 deletions(-) diff --git a/progs/Makefile b/progs/Makefile index c99f4ee..064e5a2 100644 --- a/progs/Makefile +++ b/progs/Makefile @@ -4,7 +4,7 @@ TOP = .. include $(TOP)/configs/current -SUBDIRS = $(PROGRAM_DIRS) +SUBDIRS =$(PROGRAM_DIRS) default: message subdirs @@ -15,18 +15,22 @@ message: subdirs: - @for dir in $(SUBDIRS) ; do \ - if [ -d $$dir ] ; then \ - (cd $$dir $(MAKE)) || exit 1 ; \ - fi \ - done + @if test -n $(SUBDIRS) ; then \ + for dir in $(SUBDIRS) ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir $(MAKE)) || exit 1 ; \ + fi \ + done \ + fi # Dummy install target install: clean: - -...@for dir in $(SUBDIRS) tests ; do \ - if [ -d $$dir ] ; then \ - (cd $$dir $(MAKE) clean) ; \ - fi \ - done + -...@if test -n $(SUBDIRS) ; then \ + for dir in $(SUBDIRS) tests ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir $(MAKE) clean) ; \ + fi \ + done \ + fi -- 1.6.3.3 -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 1/2] ac: Fix AIX shared library builds.
AIX uses .a for both static and shared library extensions. --- configure.ac |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 7518976..44fb779 100644 --- a/configure.ac +++ b/configure.ac @@ -230,6 +230,8 @@ else LIB_EXTENSION='dylib' ;; cygwin* ) LIB_EXTENSION='dll' ;; +aix* ) +LIB_EXTENSION='a' ;; * ) LIB_EXTENSION='so' ;; esac -- 1.6.3.3 -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/5] egl: core updates
Chia-I Wu wrote: Hi, This patch series introduces two features to EGL core and fixes some conformance issues. The first feature is support for built-in driver. The other one is to allow driver to install a customized logger for _eglLog(). The first patch adds built-in driver support. It is adapted from WINDOWS_STATIC_LINK, with better error reporting and integrate better with current driver model. It is a matter of changing the Makefile to build a libEGL.so with the driver built-in. The second patch removes core EGL functions from eglGetProcAddress, as required by the spec. The third patch tries to fix an issue that eglGetProcAddress is called really early (before any EGLDisplay is created). The best shot is to try to preload a driver, and get proc address from the preloaded driver. The fourth patch allows any client api to be bound. This simplifies the code a bit, and it makes more sense. Config attribute EGL_RENDERABLE_TYPE is supposed to be used to choose a config that support certain apis. The apis supported by a display can also be queried through EGL_CLIENT_APIS. The last patch allows the log level and the logger to be changed by a driver. This is helpful on systems with an alternative logging facility. Committed. Sorry for the slow follow-up. -Brian -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] ac: Fix AIX shared library builds.
Sorry, should have used an intro comment mail. (Assuming all's well,) It would be great if these two could make it onto a branch (e.g. 7.6) in addition to master. -tom Tom Fogal tfo...@alumni.unh.edu writes: AIX uses .a for both static and shared library extensions. --- configure.ac |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Initial version of GL_MESA_gpu_program3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the initial version of the assembly extension that was discussed at XDC. This is a very early alpha version, and some parts are not yet complete. At this point, I am mainly looking for two things in a review: - - Are there any issues marked RESOLVED where you disagree with the resolution? I'm especially interested in issues 2, 4, and 19. - - Are there any issues marked UNRESOLVED that you have an opinion on or data to support a resolution? I'm especially interested in issues 7, 11, 15, and 34 (resolution may be related to 4). - - Are there any instructions listed that cannot be trivially supported on some relevant hardware? Some instructions expand to multiple real instructions (e.g., NRM). As long as the expansion is trivial and only adds one or two extra instructions, this is okay. - - Is there some important SM3 feature that's missing? I plan to circulate this around the Wine community after the next revision. There is some goofy formatting and issue numbering. This is done to minimize the diffs with GL_NV_gpu_program4. The output of 'diff -d - --side-by-side -W 165 MESA_gpu_program3 NV_gpu_program4' is pretty readable and useful. http://people.freedesktop.org/~idr/MESA_gpu_program3.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrU0wUACgkQX1gOwKyEAw+lxQCgi+hjDeERsB163Ljyv+iyPz7W z98AnRleHrs1R9Hb1wlk6qLk45gFXfVf =fggv -END PGP SIGNATURE- -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300g: Fallback on surfaces we can't render to or from.
On 10/13/2009 03:28 AM, José Fonseca wrote: On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: Module: Mesa Branch: master Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 Author: Corbin Simpson mostawesomed...@gmail.com Date: Mon Oct 12 20:47:00 2009 -0700 r300g: Fallback on surfaces we can't render to or from. Still not sure why st keeps handing down things we can't render to. Corbin, This is a problem of the Mesa state tracker and most co-statetrackers that sit on top of it. It's better than it was before but there are still a few places where it uses formats without querying the driver. A typical problem are PIPE_FORMAT_x - Mesa visual translation. I had to solve this in the WGL state tracker, but it would be nice if we had shared code for that in src/mesa/state_tracker . On one hand, it's my opinion that if I say no to is_format_supported for RENDER_TARGETs (or SAMPLERs, for copying), then the state tracker is misbehaving if it proceeds to request surface_fill or surface_copy with those. On the other hand, this fallback is kind of okay with me because it goes right next to the fallbacks for overlapping blits, which aren't okay on the 3D engine. On the *other* other hand, it'd be really nice if we had PIPE_CAP_BLITTER, which encapsulated all of this. ~ C. -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300g: Fallback on surfaces we can't render to or from.
On 10/13/2009 08:34 AM, Brian Paul wrote: José Fonseca wrote: On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: Module: Mesa Branch: master Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 Author: Corbin Simpson mostawesomed...@gmail.com Date: Mon Oct 12 20:47:00 2009 -0700 r300g: Fallback on surfaces we can't render to or from. Still not sure why st keeps handing down things we can't render to. Corbin, This is a problem of the Mesa state tracker and most co-statetrackers that sit on top of it. It's better than it was before but there are still a few places where it uses formats without querying the driver. A typical problem are PIPE_FORMAT_x - Mesa visual translation. I had to solve this in the WGL state tracker, but it would be nice if we had shared code for that in src/mesa/state_tracker . This is just happening with surface_copy() and surface_fill(), right? I think the assumption was that if the driver can create a surface in format X, then it can copy and fill regions in format X by one means or another (and not necessarily by 3D rendering). Well, yes and no. Byte-for-byte copies are pretty easy with a fallback, and I could probably get those to be pretty speedy with BO moves and a custom libdrm hook. Shifting formats is iffy though, and at that point we're talking about turning on the blitter. Corbin, it looks like you're using quads/points to do the copy/fill. Can't some sort of blit be used instead? And here's where we get fun. Turning on the blitter is non-trivial in r300/r500. We have to flush, send a 2D-only command packet with the fill/copy, and then flush again when we go back to 3D. This is messy and painful. Kernel-side, the kernel actually has to idle most of the card to do the switch. If we're doing any serious 3D work, anybody doing glClear() at the beginning of their frame is incurring a massive penalty. We could turn on the blitter, but I'd rather see this handled with PIPE_CAP_BLITTER or something similar, because r600g will be blitter-less and completely dependent on its 3D engine, and I'd like to be prepared sooner rather than later. Aside: We use points for fills because fglrx uses points for clears/fills, and we seem to be getting really good speeds that way. Silly, but effective. ~ C. -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): r300g: Fallback on surfaces we can't render to or from.
Corbin Simpson wrote: On 10/13/2009 08:34 AM, Brian Paul wrote: José Fonseca wrote: On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: Module: Mesa Branch: master Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 Author: Corbin Simpson mostawesomed...@gmail.com Date: Mon Oct 12 20:47:00 2009 -0700 r300g: Fallback on surfaces we can't render to or from. Still not sure why st keeps handing down things we can't render to. Corbin, This is a problem of the Mesa state tracker and most co-statetrackers that sit on top of it. It's better than it was before but there are still a few places where it uses formats without querying the driver. A typical problem are PIPE_FORMAT_x - Mesa visual translation. I had to solve this in the WGL state tracker, but it would be nice if we had shared code for that in src/mesa/state_tracker . This is just happening with surface_copy() and surface_fill(), right? I think the assumption was that if the driver can create a surface in format X, then it can copy and fill regions in format X by one means or another (and not necessarily by 3D rendering). Well, yes and no. Byte-for-byte copies are pretty easy with a fallback, and I could probably get those to be pretty speedy with BO moves and a custom libdrm hook. Shifting formats is iffy though, and at that point we're talking about turning on the blitter. For surface_copy() the src and dst surfaces will always be of the same format. Corbin, it looks like you're using quads/points to do the copy/fill. Can't some sort of blit be used instead? And here's where we get fun. Turning on the blitter is non-trivial in r300/r500. We have to flush, send a 2D-only command packet with the fill/copy, and then flush again when we go back to 3D. This is messy and painful. Kernel-side, the kernel actually has to idle most of the card to do the switch. If we're doing any serious 3D work, anybody doing glClear() at the beginning of their frame is incurring a massive penalty. It's important to understand when/where surface_copy() and surface_fill() are used: Currently, surface_fill() is only used for the util_clear() utility/fallback function. Most drivers should do something smarter for clear(), I think. surface_copy() is mainly used to copy mipmap levels from one texture to another, glCopyTex[Sub]Image() and glCopyPixels(). I believe we'll often be flushing the 3D pipe before doing these things anyway. We could turn on the blitter, but I'd rather see this handled with PIPE_CAP_BLITTER or something similar, because r600g will be blitter-less and completely dependent on its 3D engine, and I'd like to be prepared sooner rather than later. Sure. I totally understand the desire to avoid using the blitter. I'm just trying to clarify those two functions. If surface_copy() is always done with 3D rendering, it has to be able to cope with any src texture format as a possible destination (ex: for mipmap level copying). In the state tracker we could avoid calling surface_copy() when the driver doesn't support rendering to the dest format. We'd probably fall back to map/memcpy/unmap but that's what util_surface_copy() does already. So it's just a matter of who calls it. Aside: We use points for fills because fglrx uses points for clears/fills, and we seem to be getting really good speeds that way. Silly, but effective. -Brian -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Bug 24207] Extension for S3TC decompression only
That solution might work for linux usersbut anyone have a solution for windows users? Believe it or not, but I'm using this project for windows in a VM environment for some autoplay testing. S3TC would be very valuable for that effort. I just need a DLL and a patch for mesa to use the dll correctly. On Fri, Oct 2, 2009 at 11:15 PM, bugzilla-dae...@freedesktop.org wrote: http://bugs.freedesktop.org/show_bug.cgi?id=24207 --- Comment #6 from Ian Romanick i...@freedesktop.org 2009-10-02 23:15:12 PST --- (In reply to comment #5) Anyway, we're wasting time while the solution is pretty simple: we should just ignore patents (in particular, they don't apply in my country, so I can't feel sad). You and me both. If the powers that be don't want it in mesa git, maybe someone should just fork mesa, add the patended bits and let distros pick their choice. While we're trying to actually fix this issue with the help of OIN, the plan that came out of XDC is to take the freetype approach: have configure-time options to enable certain bits of code. These options would be, by default, disabled. I believe S3TC should stay in an external library. It works that way, and is easier for users: just drop the library into your system and be happy. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- My Website http://www.codelandia.com Jennys Website http://www.dontbflat.com -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24207] Extension for S3TC decompression only
http://bugs.freedesktop.org/show_bug.cgi?id=24207 --- Comment #8 from JasonErickson viperja...@gmail.com 2009-10-13 14:31:27 PST --- That solution might work for linux usersbut anyone have a solution for windows users? Believe it or not, but I'm using this project for windows in a VM environment for some autoplay testing. S3TC would be very valuable for that effort. I just need a DLL and a patch for mesa to use the dll correctly. On Fri, Oct 2, 2009 at 11:15 PM, bugzilla-dae...@freedesktop.org wrote: http://bugs.freedesktop.org/show_bug.cgi?id=24207 --- Comment #6 from Ian Romanick i...@freedesktop.org 2009-10-02 23:15:12 PST --- (In reply to comment #5) Anyway, we're wasting time while the solution is pretty simple: we should just ignore patents (in particular, they don't apply in my country, so I can't feel sad). You and me both. If the powers that be don't want it in mesa git, maybe someone should just fork mesa, add the patended bits and let distros pick their choice. While we're trying to actually fix this issue with the help of OIN, the plan that came out of XDC is to take the freetype approach: have configure-time options to enable certain bits of code. These options would be, by default, disabled. I believe S3TC should stay in an external library. It works that way, and is easier for users: just drop the library into your system and be happy. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] ac: Fix AIX shared library builds.
tom fogal wrote: Sorry, should have used an intro comment mail. (Assuming all's well,) It would be great if these two could make it onto a branch (e.g. 7.6) in addition to master. Both look good to me. You can commit, right? -Brian -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] ac: Fix AIX shared library builds.
Brian Paul bri...@vmware.com writes: tom fogal wrote: Sorry, should have used an intro comment mail. (Assuming all's well,) It would be great if these two could make it onto a branch (e.g. 7.6) in addition to master. Both look good to me. You can commit, right? In theory, but it hasn't gone through yet: https://bugs.freedesktop.org/show_bug.cgi?id=23311 -tom -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 1/2] ac: Fix AIX shared library builds.
tom fogal wrote: Brian Paul bri...@vmware.com writes: tom fogal wrote: Sorry, should have used an intro comment mail. (Assuming all's well,) It would be great if these two could make it onto a branch (e.g. 7.6) in addition to master. Both look good to me. You can commit, right? In theory, but it hasn't gone through yet: https://bugs.freedesktop.org/show_bug.cgi?id=23311 OK, I've committed them to the 7.6 branch. -Brian -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Initial version of GL_MESA_gpu_program3
Am Tuesday 13 October 2009 21:20:40 schrieb Ian Romanick: Here is the initial version of the assembly extension that was discussed at XDC. This is a very early alpha version, and some parts are not yet complete. At this point, I am mainly looking for two things in a review: Looks good from a very cursory look. - Are there any issues marked RESOLVED where you disagree with the resolution? I'm especially interested in issues 2, 4, and 19. Note: The following replies are based on my understanding of the hardware. There may still be some missing or unclear information in the docs by AMD. If this is the case, then it can hopefully be clarified in the course of this thread. Issue 2: 1) R500 supports unstructured branching in fragment programs but not in vertex programs, so I'm happy about leaving it out. 2) R500 supports address registers as described in vertex programs (including input/output offsets), but has no address registers at all in fragment programs. A loop address register can be used as offsets in loops, but the values loaded into this register must be determined at compile time. Issue 4: Agreed. R500 does not support address register math. Issue 6 (predicate registers): Is it correct that there is only a PSEQ instruction and not the full orthogonal set? The grammar includes the full orthogonal set, but the instruction list seems to be missing something. I assume predicate registers can be used to mask writes of ordinary ALU instructions. Can they also mask TEX instructions? (R500 supports both, and it's easy to emulate, but see caveat). I think we can do everything you throw at us on R500. The only difficulty is that R500 is a bit schizophrenic in that vertex programs are very different from fragment programs, but we can emulate things. The only stupid weakness is that swizzling predicates in fragment programs is essentially impossible (the only natively supported swizzles are .rgba and the smears ., ., ., .). Obviously we can emulate this. Issue 11: R500 supposedly supports relative addressing of temporary registers in vertex programs, and also in fragment programs (but only using loop indices). I have never tested whether it actually works, though. Issue 13: Similar to issue 2, R500 fragment programs support unstructured everything but vertex programs don't, so not overlapping sounds good to me. Issue 15: I know R500 fragment programs can support a CONT, but I'm not so familiar with the R500 vertex programs, and they seem generally less flexible. Issue 17: I would *expect* negative addressing offsets to work on R500, but somehow I haven't been able to get them to work. I'll see if I can look into it again. Issue 34: I don't see any support for an address register stack on R500, or anything else to provide for a subroutine stack. Thanks for working on this! cu, Nicolai - Are there any issues marked UNRESOLVED that you have an opinion on or data to support a resolution? I'm especially interested in issues 7, 11, 15, and 34 (resolution may be related to 4). - Are there any instructions listed that cannot be trivially supported on some relevant hardware? Some instructions expand to multiple real instructions (e.g., NRM). As long as the expansion is trivial and only adds one or two extra instructions, this is okay. - Is there some important SM3 feature that's missing? I plan to circulate this around the Wine community after the next revision. There is some goofy formatting and issue numbering. This is done to minimize the diffs with GL_NV_gpu_program4. The output of 'diff -d --side-by-side -W 165 MESA_gpu_program3 NV_gpu_program4' is pretty readable and useful. http://people.freedesktop.org/~idr/MESA_gpu_program3.txt --- --- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Come build with us! The BlackBerry(R) 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 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
