Re: r128 driver problem
On Tuesday 14 December 2004 19:03, Bill Shannon wrote: > It's been over a month since I sent this message and I've yet to > receive a single response. If you're ignoring me on purpose, > would someone please say so? If I'm asking the wrong people, > again I'd appreciate a pointer to the right people. You're asking the right people, we're just not always perfect about responding to every message. This sounds exactly like: https://bugs.freedesktop.org/show_bug.cgi?id=1886 which is fixed in Xorg CVS, and slated for inclusion in the upcoming 6.8.2 maintenance release. - ajax pgp2PFbmKROoH.pgp Description: PGP signature
Re: [R300][PATCH] Allow use of custom compiler in drm
On Tuesday 14 December 2004 05:27, Nicolai Haehnle wrote: > Hi, > > On Monday 13 December 2004 18:29, Kronos wrote: > > In this way calling: > > CC=gcc-3.4 make > > does the Right Thing > > The base DRM Makefile doesn't pass the CC on either, and this may or may > not be with good reason. AFAIK kernel code can be rather dependant on the > exact compiler version used, so it's probably a good idea to always use the > same compiler for both the kernel itself and all modules. > > Perhaps somebody with more experience in this area wants to comment? Consider the inverse case, where you built the kernel with gcc3.3, but have mostly changed your userspace to 3.4, and don't really feel like rebuilding the whole kernel. I know that's bitten me more than once before. I don't object to the change. On 2.6 at least the kernel will refuse to load modules compiled with a different compiler version. - ajax pgpccWPyLWMK6.pgp Description: PGP signature
Re: Commit rights for Mesa?
On Wed, 15 Dec 2004 15:34:52 +0100 (CET), Thomas Hellström <[EMAIL PROTECTED]> wrote: > Hi! > > Is it possible to commit rights for the Mesa tree, or have someone commit > the work done in bug 1950 to port the unichrome driver to the new security > policy implemented in the Via DRM? > > I won't be doing much 3D development, but will focus on the 3D driver / > DRM interface; fixing bugs and improve. > > /Thomas > Eric Anholt used to be able to make these kind of changes. I'm not sure if he still can or not after the freedesktop rebuild. Daniel Stone should be able to help you out otherwise. Alex --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon: Unknown symbol i2c_bit_add_bus (was: Re: new hyperz patch)
Hi, Now, on FC3 testing lastest cvs I got: radeon: Unknown symbol i2c_bit_add_bus radeon: Unknown symbol i2c_bit_del_bus when I try to load radeon ko . thanks, On Mon, 2004-12-13 at 00:11 +0100, Roland Scheidegger wrote: > Sergio Monteiro Basto wrote: > > Hi Roland, > > So , for hyperz patch did you need modify any makefiles ? if it positive > > what makefiles did you need to patch :) ? > No makefile changes were/are needed. well, I think since 15 Nov some body did change makefiles, because I could compile radeon dri with xorg cvs and now I don't, but don't worry about that. I will try find out what happen. > > Roland -- Sérgio M.B. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300][PATCH] Allow use of custom compiler in drm
Il Tue, Dec 14, 2004 at 11:27:14AM +0100, Nicolai Haehnle ha scritto: > > --- a/drm/linux-core/Makefile 2004-10-23 14:43:44.0 +0200 > > +++ b/drm/linux-core/Makefile 2004-12-13 18:20:16.0 +0100 > > @@ -172,7 +172,7 @@ > > all: modules > > > > modules: includes > > - make -C $(LINUXDIR) $(GETCONFIG) SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules > > + make -C $(LINUXDIR) $(GETCONFIG) CC=$(CC) SUBDIRS=`pwd` DRMSRCDIR=`pwd` > modules > > > > ifeq ($(HEADERFROMBOOT),1) > > > > > > In this way calling: > > CC=gcc-3.4 make > > does the Right Thing > > The base DRM Makefile doesn't pass the CC on either, and this may or may not > be with good reason. AFAIK kernel code can be rather dependant on the exact > compiler version used, so it's probably a good idea to always use the same > compiler for both the kernel itself and all modules. The point is that my kernel is compiled with gcc-3.4 and (without patch) modules are compiled with default gcc (which on my system is gcc-3.3): modules will NOT load (with CONFIG_MODVERSIONS). Luca -- Home: http://kronoz.cjb.net Ligabue canta: "Tutti vogliono viaggiare in prim..." Io ci ho provato e dopo un chilometro ho fuso il motore e bruciato la frizione... --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI backwards compatibility problem from X.Org 6.8.0 onwards
On Mon, Dec 13, 2004 at 11:30:07AM +, Alan Cox wrote: > Does this not break compatibility with 6.8.0/6.8.1 - that seems at least > as big a problem as the breakage from 6.7 because it will prevent anyone > stuck with a 6.8.* driver from updating to get security fixes ? We discussed this issue on the release wranglers call today and decided to maintain compatibility with 6.8 for this and future 6.8-based point releases instead of restoring backwards compatibility with 6.7 since an ABI change now would cause additional problems vendors that rely on the DRI. We plan to investigate other solutions for the next major release. Kevin --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon: Unknown symbol i2c_bit_add_bus
Sergio Monteiro Basto wrote: thanks, Now I can load radeon.ko after modprobe i2c_via.ko Do you have i2c-algo-bit.ko loaded (or built into your kernel image)? That's where i2c_bit_add|del_bus are. Check this .config symbol: CONFIG_I2C_ALGOBIT=y (on my system) On Mon, 2004-12-13 at 17:27 -0500, Adam Jackson wrote: On Monday 13 December 2004 17:15, Dave Airlie wrote: radeon: Unknown symbol i2c_bit_add_bus radeon: Unknown symbol i2c_bit_del_bus you need i2c support modules loaded.. modprobe the radeon driver it should all work then... Shouldn't radeon.ko build without i2c hooks if CONFIG_I2C == NO ? - ajax -- ~Randy --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon: Unknown symbol i2c_bit_add_bus (was: Re: new hyperz patch)
> > radeon: Unknown symbol i2c_bit_add_bus > radeon: Unknown symbol i2c_bit_del_bus > you need i2c support modules loaded.. modprobe the radeon driver it should all work then... > when I try to load radeon ko . > > thanks, > > > On Mon, 2004-12-13 at 00:11 +0100, Roland Scheidegger wrote: > > Sergio Monteiro Basto wrote: > > > Hi Roland, > > > So , for hyperz patch did you need modify any makefiles ? if it positive > > > what makefiles did you need to patch :) ? > > No makefile changes were/are needed. > > well, I think since 15 Nov some body did change makefiles, because I > could compile radeon dri with xorg cvs and now I don't, but don't worry > about that. I will try find out what happen. > > > > > Roland > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Experimental options
On Sat, 11 Dec 2004, Michel [ISO-8859-1] Dänzer wrote: On Sat, 2004-12-11 at 11:19 -0500, Vladimir Dergachev wrote: The reason this is useful is that such trick greatly accelerates 3d on ^ 2? :) large resolution screens as 2d driver can also use DRM driver and this works perfectly well. This also facilitates work on 3d driver. The 2d speedup is quite considerable, however one would expect all GL apps to break because of this, as even software rendering won't work. libGL should fall back to GLX when the *_dri.so isn't around. Is it not? Even so, it would be nice to make some sort of change to make I don't think it does. At the very least this was broken for me - or maybe I screwed up something else. It should definitely fall back to indirect rendering, just like when there's a problem loading any of the existing 3D drivers. Well, I have just committed the code, protected by X_R300_DRM option - if not enabled (which is default) the DRM is not used in any way. I double-checked (removing r300_dri.so from /usr/X11/lib/modules/dri) and I still get glxgears lockup. Also, glxinfo returns info as for direct rendering driver - as, I suppose, it should. I looked around in radeon_dri.c and could not find any place to gracefully disable DRI without disabling its use by Xserver. Perhaps a better (and long-term) solution is to an early version of Nicolai Haehnle's driver that does not crash - it effectively implements all-fallback DRI driver. Suggestions (and patches:) ) are very welcome ! best Vladimir Dergachev -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
[Bug 1950] AGP Ring-buffer support for the Unichrome driver.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=1950 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #1410 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2004-12-13 06:22 --- Created an attachment (id=1538) --> (https://bugs.freedesktop.org/attachment.cgi?id=1538&action=view) New version of the patch with additional functionality. New version of the patch. This one is using the functionality just recenctly commited to DRM and since the command verifier now is implemented. This patch should be fully OK to apply. In addition to the DRM command buffer functionality, it fixes 1. A locking bug that caused the driver not to keep up with drawable changes. 2. Blitter problems caused by the blitter losing context when the command buffer is executed through AGP. 3. AGP textures are reenabled. 4. Check for texture memory allocation failure. The driver avoids filling the ring-buffer by checking the command regulator lag. Presently this is allowed to be only 50kB. This is tuneable, but larger values seem to make applications unresponsive while at the same time providing little performance gain. With Miniglx, the driver will use the PCI path until someone finds time to patch the Miniglx server to initialize the AGP ring-buffer. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1501] libGL causes double free.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=1501 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #1013|Improved fix|[FIXED_X11R68x] Improved fix description|| --- Additional Comments From [EMAIL PROTECTED] 2004-12-13 05:56 --- (From update of attachment 1013) Patch checked-in into X11R6.8.x stable branch: /cvs/xorg/xc/ChangeLog,v <-- ChangeLog new revision: 1.365.2.56; previous revision: 1.365.2.55 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. /cvs/xorg/xc/extras/Mesa/src/mesa/drivers/dri/common/dri_util.c,v <-- dri_util.c new revision: 1.1.1.3.2.1; previous revision: 1.1.1.3 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. /cvs/xorg/xc/lib/GL/glx/glxext.c,v <-- glxext.c new revision: 1.5.4.1; previous revision: 1.5 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. Mailing the commit message to [EMAIL PROTECTED] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI backwards compatibility problem from X.Org 6.8.0 onwards
Alan Hourihane wrote: There's a backwards compatibility breakage with X.Org 6.8.0 and beyond because of revision 1.3 of the file xc/include/glxint.h. So, those that provide binary drivers that were compiled against X.Org 6.7.x or XFree86 4.4.0 or earlier will break as well. So, the real answer to this problem is that the interface between libglx.a, libGLcore.a, and the DDX is horribly broken. With respect to 3D, there is no clean division between the three. Each directly allocates, rearranges, and modifies various datastructures. For the current Xorg release (6.8.x), I'm content to leave things as they were in 6.8.0. For the next major release (6.9.0) I believe that the entire existing interface on the server-side needs to be pitched in the garbage. Ideally, we want the libglx / libGLcore interface to be identical to the libGL / *_dri.so interface. On the client-side libGL *does* provide and function to allocate and initialize (with default values) __GLcontextModesRec structures. The problem stems from these additional fields in the GLXvisualConfigRec which actually are not needed. int multiSampleSize; int nMultiSampleBuffers; int visualSelectGroup; These fields are already in the new GLXFBConfigRec for the later FB visual selection code. Hmm...this is bad. Anything that makes any chages to GLXvisualConfigRec will break the hell out of a lot of things. That's why the "real" selection code in libglx abandoned that structure in favor of __GLcontextModesRec. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300][PATCH] Allow use of custom compiler in drm
Hi, On Monday 13 December 2004 18:29, Kronos wrote: > Hi, > Makefile in drm/linux-core/ doesn't pass CC to linux kernel build > system. This prevents loading the modules if kernel has been compiled > with a compiler different from the default (ie. gcc). > > The following patch add CC to kernel Makefile: > > --- a/drm/linux-core/Makefile 2004-10-23 14:43:44.0 +0200 > +++ b/drm/linux-core/Makefile 2004-12-13 18:20:16.0 +0100 > @@ -172,7 +172,7 @@ > all: modules > > modules: includes > - make -C $(LINUXDIR) $(GETCONFIG) SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules > + make -C $(LINUXDIR) $(GETCONFIG) CC=$(CC) SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules > > ifeq ($(HEADERFROMBOOT),1) > > > In this way calling: > CC=gcc-3.4 make > does the Right Thing The base DRM Makefile doesn't pass the CC on either, and this may or may not be with good reason. AFAIK kernel code can be rather dependant on the exact compiler version used, so it's probably a good idea to always use the same compiler for both the kernel itself and all modules. Perhaps somebody with more experience in this area wants to comment? cu, Nicolai pgpBEwFUW4YOm.pgp Description: PGP signature
Re: ioclts for surfaces, 2nd try
On Sun, 2004-12-12 at 22:39 +0100, Stephane Marchesin wrote:
> Michel DÃnzer wrote:
>
> >>+typedef struct drm_radeon_surface_alloc {
> >>+ int lower;
> >>+ int upper;
> >>+ int flags;
> >>+} drm_radeon_surface_alloc_t;
> >>+
> >>+typedef struct drm_radeon_surface_free {
> >>+ int lower;
> >>+} drm_radeon_surface_free_t;
> >>
> >
> >The members of these structs should be explicitly sized (and aligned?)
> >to avoid any 32/64 bit problems.
> >
> We've been discussing this on irc. I wasn't sure what to do.
> Is uint32_t ok ?
As far as I'm concerned yes, but I don't know if that'll work in all the
environments we support.
> >Also, you might allow overlapping as long as the flags are compatible?
> >I'm not sure those cases are important in practice though.
> >
> Trouble is I don't know what happens when two surfaces overlap.
>
> Also it doesn't seem make much sense to have two surfaces over the same
> area, [...]
Sure, I didn't mean that but just to extend an existing surface even if
the new one overlaps with it. But I agree that it may make sense not to
allow that because any given memory region shouldn't have more than one
owner.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Experimental options
It should definitely fall back to indirect rendering, just like when there's a problem loading any of the existing 3D drivers. Well, I have just committed the code, protected by X_R300_DRM option - if not enabled (which is default) the DRM is not used in any way. The option is superfluous IMHO, just enable it. I double-checked (removing r300_dri.so from /usr/X11/lib/modules/dri) and I still get glxgears lockup. Also, glxinfo returns info as for direct rendering driver - as, I suppose, it should. No, only the DRI driver has this information, so it can only do that if libGL can load the driver. Set LIBGL_DEBUG=verbose to find out where it's picking it up from. You were very right.. There was a stupid misprint that I overlooked and the driver name was set to r200 rather than r300. The option is now gone, and fix has been committed to CVS. best Vladimir Dergachev -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
[Bug 271] "euphoria" (really-slick screensavers) repeatably locks up system
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=271 --- Additional Comments From [EMAIL PROTECTED] 2004-12-13 05:14 --- I have experienced similar problems with a Rage128 card, running XFree86 Version 4.4.0 on Linux 2.4 Freedora core. A heavy OpenGL load hangs the X server at near 100%CPU, and the XFree86 log has repeated lines of: (EE) R128(0): Idle timed out, resetting engine (Note there are no R128WaitForIdle messages as others have reported). Solution #17 From Michel Dänzer: "Also, I'm curious: does R128CCEWaitForIdle() deal more gracefully with the timeout if you add a R128CCE_STOP(pScrn, info); before the R128EngineReset(pScrn); ?" seems to cure the problem, without any noticable performance problems I can detect. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioclts for surfaces, 2nd try
On Sun, 2004-12-12 at 14:52 +0100, Stephane Marchesin wrote:
>
> Here is my second try at the surface ioctl.
> Does everything look correct ?
Looks like you've made good progress.
> Index: shared/radeon_drm.h
> ===
> RCS file: /cvs/dri/drm/shared/radeon_drm.h,v
> retrieving revision 1.25
> diff -u -r1.25 radeon_drm.h
> --- shared/radeon_drm.h 8 Dec 2004 16:43:00 - 1.25
> +++ shared/radeon_drm.h 12 Dec 2004 13:39:16 -
> @@ -628,6 +634,20 @@
> int64_t value;
> } drm_radeon_setparam_t;
>
> +/* 1.14: Clients can allocate/free a surface
> + */
> +
> +typedef struct drm_radeon_surface_alloc {
> + int lower;
> + int upper;
> + int flags;
> +} drm_radeon_surface_alloc_t;
> +
> +typedef struct drm_radeon_surface_free {
> + int lower;
> +} drm_radeon_surface_free_t;
The members of these structs should be explicitly sized (and aligned?)
to avoid any 32/64 bit problems.
> Index: shared/radeon_state.c
> ===
> RCS file: /cvs/dri/drm/shared/radeon_state.c,v
> retrieving revision 1.40
> diff -u -r1.40 radeon_state.c
> --- shared/radeon_state.c 8 Dec 2004 16:43:00 - 1.40
> +++ shared/radeon_state.c 12 Dec 2004 13:39:18 -
> @@ -1706,11 +1706,193 @@
> ADVANCE_RING();
> }
>
> +static void radeon_apply_surface_regs(int surf_index, drm_radeon_private_t
> *dev_priv)
> +{
> + RING_LOCALS;
> +
> + BEGIN_RING( 6 );
> + OUT_RING( CP_PACKET0( RADEON_SURFACE0_INFO+16*surf_index, 0 ) );
> + OUT_RING( dev_priv->surfaces[surf_index].flags );
> + OUT_RING( CP_PACKET0( RADEON_SURFACE0_LOWER_BOUND+16*surf_index, 0 ) );
> + OUT_RING( dev_priv->surfaces[surf_index].lower );
> + OUT_RING( CP_PACKET0( RADEON_SURFACE0_UPPER_BOUND+16*surf_index, 0 ) );
> + OUT_RING( dev_priv->surfaces[surf_index].upper );
> + ADVANCE_RING();
> +}
It doesn't make sense to use the CP for these register writes because
AFAIK the surfaces only apply to CPU access, so you want them to take
effect immediately, not whenever the CP gets around to processing them.
These registers aren't FIFO'd, so it should be safe to touch them at any
time.
> + /* make sure there is no overlap with existing surfaces */
> + for(i=0;i + if ((dev_priv->surfaces[i].refcount!=0) &&
> + (( (new->lower>=dev_priv->surfaces[i].lower)&&
> (new->lowersurfaces[i].upper) ) ||
> + ( (new->upper>dev_priv->surfaces[i].lower)&&
> (new->upper<=dev_priv->surfaces[i].upper) ) ||
> + ( (new->lowersurfaces[i].lower)&&
> (new->upper>dev_priv->surfaces[i].upper) )) )
> + return -1;
> + }
This also fails if the exact same surface (range) exists already, right?
Should it? I guess allowing that would complicate the refcounting...
Also, you might allow overlapping as long as the flags are compatible?
I'm not sure those cases are important in practice though.
BTW, you should use a standard error code like EINVAL instead of an
explicit value.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon: Unknown symbol i2c_bit_add_bus (was: Re: new hyperz patch)
thanks, Now I can load radeon.ko after modprobe i2c_via.ko thanks, On Mon, 2004-12-13 at 17:27 -0500, Adam Jackson wrote: > On Monday 13 December 2004 17:15, Dave Airlie wrote: > > > radeon: Unknown symbol i2c_bit_add_bus > > > radeon: Unknown symbol i2c_bit_del_bus > > > > you need i2c support modules loaded.. modprobe the radeon driver it should > > all work then... > > Shouldn't radeon.ko build without i2c hooks if CONFIG_I2C == NO ? > > - ajax -- Sérgio M.B. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2093] Unichrome / Mesa: Drawable changes sometimes not gets through.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2093 --- Additional Comments From [EMAIL PROTECTED] 2004-12-16 17:32 --- Could this be related to #1556? My CLE266 box is now gone, so I can't do anymore testing on it. :( https://bugs.freedesktop.org/show_bug.cgi?id=1556 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Artifacts with very large texture coordinates
Felix Kühling wrote: Am Do, den 16.12.2004 schrieb Brian Paul um 16:45: Felix Kühling wrote: Hi, I noticed some strange rendering artifacts with the Savage that are caused by very large texture coordinates on GL_REPEAT'ed textures. Very large means that it gets noticeable with texture coordinates >255 or <-256. A real world example that exhibits this problem is Torcs with the "Spring" track. Right at the start the effect can be seen very nicely. The track before the start line shows artifacts, directly after the start line everything looks fine. My question is, should I consider such problems an application bug or would it be wise to implement a workaround? I was thinking of implementing a TNL pipeline stage that normalizes texture coordinates. That could be tricky. If you're thinking of doing something like t' = t MOD maxValue, that'll often cause incorrect interpolation. The trick is that you have to change (add or subtract) all texture coordinates in one primitive (e.g. triangle) in the same way, that is, the relative differences between texcoords must not be changed. That's exactly what I had in mind. I've already hacked up something and the result looks good. It computes the max and min coordinates per direction and then subtracts floor((max+min)/2 + 0.5) from all texture coordinates in the vertex buffer. This is done only for texture coordinates for which the wrapping mode is GL_REPEAT. I havn't measured the performance, but I didn't notice a major difference. I guess the Savage has other bottle-necks. ;-) A patch is attached for anyone who wants to see the gory details. Looks like you've got a good understanding of the problem. I was also wondering if other hardware has similar problems. I'm attaching a small test program that demonstrates the effect and a screenshot of what I get on my ProSavageDDR. With software rendering the output is almost correct. Compile with cc -lGL -lGLU -lglut teximage.c -o teximage If the hardware implements texcoord interpolation with fixed point you can imagine how the bits are used. If the largest texture dimension is 2048, you'd need at least 11 bits to address all texels. Then you need some sub-texel bits for accurate interpolation and for computing the weighting for linear sampling. You probably need 10 bits there. Allocate another bit for the sign. Finally, whatever bits are left in the interpolator will limit the maximum coordinate range. If the interpolator is 32 bits, then 32 - 11 - 10 - 1 = 10. So the max coordinate would be 2^10 or 1024. Maybe the savage hardware has a narrow interpolator, or allocates the bits differently. When you increase the texture coordinate offset you can see the artifacts get worse with every power of two. So you can literally take away bits available for the interpolation on the Savage by making texture coordinates bigger. :) I believe one of the differences between "pro" and "consumer" cards is the accuracy and range of interpolators. Or maybe more expensive hardware does the normalization per hardware-primitive before it starts interpolating. It might. An engineer with one of the major IHVs once told me a few things about the differences between the pro and consumer cards. -Brian --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=1220 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #980|Updated fix |[FIXED_X11R68x] Updated fix description|| --- Additional Comments From [EMAIL PROTECTED] 2004-12-16 16:14 --- (From update of attachment 980) Patch checked-in into Xorg trunk and X11R6.8.x ... /cvs/xorg/xc/ChangeLog,v <-- ChangeLog new revision: 1.365.2.101; previous revision: 1.365.2.100 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c,v <-- radeon_driver.c new revision: 1.19.2.7; previous revision: 1.19.2.6 /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h,v <-- radeon_reg.h new revision: 1.7.2.1; previous revision: 1.7 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. Mailing the commit message to [EMAIL PROTECTED] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Artifacts with very large texture coordinates
Am Do, den 16.12.2004 schrieb Brian Paul um 16:45:
> Felix Kühling wrote:
> > Hi,
> >
> > I noticed some strange rendering artifacts with the Savage that are
> > caused by very large texture coordinates on GL_REPEAT'ed textures. Very
> > large means that it gets noticeable with texture coordinates >255 or
> > <-256. A real world example that exhibits this problem is Torcs with the
> > "Spring" track. Right at the start the effect can be seen very nicely.
> > The track before the start line shows artifacts, directly after the
> > start line everything looks fine.
> >
> > My question is, should I consider such problems an application bug or
> > would it be wise to implement a workaround? I was thinking of
> > implementing a TNL pipeline stage that normalizes texture coordinates.
>
> That could be tricky. If you're thinking of doing something like t' =
> t MOD maxValue, that'll often cause incorrect interpolation.
The trick is that you have to change (add or subtract) all texture
coordinates in one primitive (e.g. triangle) in the same way, that is,
the relative differences between texcoords must not be changed.
I've already hacked up something and the result looks good. It computes
the max and min coordinates per direction and then subtracts
floor((max+min)/2 + 0.5)
from all texture coordinates in the vertex buffer. This is done only for
texture coordinates for which the wrapping mode is GL_REPEAT. I havn't
measured the performance, but I didn't notice a major difference. I
guess the Savage has other bottle-necks. ;-)
A patch is attached for anyone who wants to see the gory details.
>
>
> > I was also wondering if other hardware has similar problems. I'm
> > attaching a small test program that demonstrates the effect and a
> > screenshot of what I get on my ProSavageDDR. With software rendering the
> > output is almost correct. Compile with
> >
> > cc -lGL -lGLU -lglut teximage.c -o teximage
>
> If the hardware implements texcoord interpolation with fixed point you
> can imagine how the bits are used.
>
> If the largest texture dimension is 2048, you'd need at least 11 bits
> to address all texels.
>
> Then you need some sub-texel bits for accurate interpolation and for
> computing the weighting for linear sampling. You probably need 10
> bits there.
>
> Allocate another bit for the sign.
>
> Finally, whatever bits are left in the interpolator will limit the
> maximum coordinate range. If the interpolator is 32 bits, then 32 -
> 11 - 10 - 1 = 10. So the max coordinate would be 2^10 or 1024.
>
> Maybe the savage hardware has a narrow interpolator, or allocates the
> bits differently.
When you increase the texture coordinate offset you can see the
artifacts get worse with every power of two. So you can literally take
away bits available for the interpolation on the Savage by making
texture coordinates bigger. :)
>
> I believe one of the differences between "pro" and "consumer" cards is
> the accuracy and range of interpolators.
Or maybe more expensive hardware does the normalization per
hardware-primitive before it starts interpolating.
>
> -Brian
--
| Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
? core.2742
? core.2751
? debugfallback.diff
? depend
? diff-20041215
? savage_mesa_20041019.diff
? savage_texnorm.diff
? savagestate.diff
? savagetris.diff
? throttle_and_front.diff
Index: savage_xmesa.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savage_xmesa.c,v
retrieving revision 1.18
diff -u -r1.18 savage_xmesa.c
--- savage_xmesa.c 15 Dec 2004 17:45:23 - 1.18
+++ savage_xmesa.c 16 Dec 2004 21:16:10 -
@@ -109,6 +109,22 @@
NULL
};
+extern const struct tnl_pipeline_stage _savage_texnorm_stage;
+
+static const struct tnl_pipeline_stage *savage_pipeline[] = {
+
+ &_tnl_vertex_transform_stage,
+ &_tnl_normal_transform_stage,
+ &_tnl_lighting_stage,
+ &_tnl_fog_coordinate_stage,
+ &_tnl_texgen_stage,
+ &_tnl_texture_transform_stage,
+ &_savage_texnorm_stage,
+ &_tnl_render_stage,
+ 0,
+};
+
+
/* this is first function called in dirver*/
static GLboolean
@@ -455,7 +471,7 @@
/* Install the customized pipeline:
*/
-#if 0
+#if 1
_tnl_destroy_pipeline( ctx );
_tnl_install_pipeline( ctx, savage_pipeline );
#endif
Index: savagetris.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/savage/savagetris.c,v
retrieving revision 1.14
diff -u -r1.14 savagetris.c
--- savagetris.c 14 Dec 2004 22:37:46 - 1.14
+++ savagetris.c 16 Dec 2004 21:16:11 -
@@ -911,3 +911,189 @@
SAVAGE_CONTEXT(ctx)->verts = (char *)tnl->clipspace.vertex_buf;
}
+
+
+/***
+ * Pipeline stage for texture coordinate normalization
+ * This should probably go somewhere else.
+ ***/
+struct texnorm_stage_data {
+
[Bug 2093] New: Unichrome / Mesa: Drawable changes sometimes not gets through.
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2093 Summary: Unichrome / Mesa: Drawable changes sometimes not gets through. Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Drivers/DRI/Unichrome AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If windows with dri rendering are abruptly resized, the changes sometimes not get through to the driver as it should. Example: glxgears: If the window is resized, the contets usually follows the window but there seems to be some kind of lag in the back-buffer size as the last lines sometimes are white. Under certain conditions there can be a number of white lines, while the gears are picking up the change and drawn over the whole window. If The maximize-window is clicked, sometimes not even the back-buffer stride takes effect and a number of repetitative glxgears are drawn. The back-to-front blit seems OK, though. Mostly tested in 1280x1024x24 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI/Mesa CVS (XFree86) compilation error
On Thursday 16 December 2004 12:20, Dieter NÃtzel wrote: > make[6]: Leaving directory > `/tmp/INSTALL/SOURCE/dri-trunk/xc/xc/lib/GL/mesa/drivers/dri/common' The xc tree under /cvs/dri is archival. No new development happens there. Don't bother using it. That said, there are a few drivers languishing on branches in the old xc tree (s3virge and trident most obviously). Would anyone object to me importing them but not hooking them into the build? - ajax pgpzr56HKbUOp.pgp Description: PGP signature
Re: r128 driver problem
Adam Jackson wrote: On Tuesday 14 December 2004 19:03, Bill Shannon wrote: It's been over a month since I sent this message and I've yet to receive a single response. If you're ignoring me on purpose, would someone please say so? If I'm asking the wrong people, again I'd appreciate a pointer to the right people. You're asking the right people, we're just not always perfect about responding to every message. This sounds exactly like: https://bugs.freedesktop.org/show_bug.cgi?id=1886 which is fixed in Xorg CVS, and slated for inclusion in the upcoming 6.8.2 maintenance release. - ajax Thanks much for the pointer! I tried the workaround suggested in one of the referenced bug reports (comment out "load dri" in xorg.conf) and that solved the problem. I'll update all the bugs I filed in other places to point to the bug above. Thanks again! Bill --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI/Mesa CVS (XFree86) compilation error
On Thu, 16 Dec 2004 13:43:26 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote: > On Thursday 16 December 2004 13:06, Alex Deucher wrote: > > On Thu, 16 Dec 2004 12:35:34 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote: > > > On Thursday 16 December 2004 12:20, Dieter Nützel wrote: > > > > make[6]: Leaving directory > > > > `/tmp/INSTALL/SOURCE/dri-trunk/xc/xc/lib/GL/mesa/drivers/dri/common' > > > > > > The xc tree under /cvs/dri is archival. No new development happens > > > there. Don't bother using it. > > > > > > That said, there are a few drivers languishing on branches in the old xc > > > tree (s3virge and trident most obviously). Would anyone object to me > > > importing them but not hooking them into the build? > > > > tdlabs as well... > > The problem with the tdlabs and gamma branches is they're forked from the > existing gamma driver. I could make new driver subtrees for them though. > only if you feel motivated. I wouldn't worry too much about it. Alex > - a jax > --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI/Mesa CVS (XFree86) compilation error
On Thursday 16 December 2004 13:06, Alex Deucher wrote: > On Thu, 16 Dec 2004 12:35:34 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote: > > On Thursday 16 December 2004 12:20, Dieter Nützel wrote: > > > make[6]: Leaving directory > > > `/tmp/INSTALL/SOURCE/dri-trunk/xc/xc/lib/GL/mesa/drivers/dri/common' > > > > The xc tree under /cvs/dri is archival. No new development happens > > there. Don't bother using it. > > > > That said, there are a few drivers languishing on branches in the old xc > > tree (s3virge and trident most obviously). Would anyone object to me > > importing them but not hooking them into the build? > > tdlabs as well... The problem with the tdlabs and gamma branches is they're forked from the existing gamma driver. I could make new driver subtrees for them though. - a jax pgpmXq0ZZuxrN.pgp Description: PGP signature
Re: DRI/Mesa CVS (XFree86) compilation error
Alex Deucher wrote: On Thu, 16 Dec 2004 12:35:34 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote: On Thursday 16 December 2004 12:20, Dieter Nützel wrote: make[6]: Leaving directory `/tmp/INSTALL/SOURCE/dri-trunk/xc/xc/lib/GL/mesa/drivers/dri/common' The xc tree under /cvs/dri is archival. No new development happens there. Don't bother using it. That said, there are a few drivers languishing on branches in the old xc tree (s3virge and trident most obviously). Would anyone object to me importing them but not hooking them into the build? tdlabs as well... Sounds ok to me. Fine with me too... Keith --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI/Mesa CVS (XFree86) compilation error
On Thu, 16 Dec 2004 12:35:34 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote: > On Thursday 16 December 2004 12:20, Dieter Nützel wrote: > > make[6]: Leaving directory > > `/tmp/INSTALL/SOURCE/dri-trunk/xc/xc/lib/GL/mesa/drivers/dri/common' > > The xc tree under /cvs/dri is archival. No new development happens there. > Don't bother using it. > > That said, there are a few drivers languishing on branches in the old xc tree > (s3virge and trident most obviously). Would anyone object to me importing > them but not hooking them into the build? > tdlabs as well... Sounds ok to me. Alex > - ajax > > > --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI/Mesa CVS (XFree86) compilation error
Sounds like you are using an old CVS. Try updating. Alan. On Thu, Dec 16, 2004 at 06:20:55PM +0100, Dieter Nützel wrote: > SM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM dri_util.c > In file included from dri_util.c:52: > dri_util.h:563: Warnung: redundant redeclaration of `glXGetProcAddress' in > same scope > /opt/Mesa/include/GL/glx.h:295: Warnung: previous declaration of > `glXGetProcAddress' > dri_util.c:57: error: conflicting types for `PFNGLXGETMSCRATEOMLPROC' > /opt/Mesa/include/GL/glxext.h:617: error: previous declaration of > `PFNGLXGETMSCRATEOMLPROC' > dri_util.c:57: Warnung: redundant redeclaration of `PFNGLXGETMSCRATEOMLPROC' > in same scope > /opt/Mesa/include/GL/glxext.h:617: Warnung: previous declaration of > `PFNGLXGETMSCRATEOMLPROC' > dri_util.c: In function `glx_find_dri_screen': > dri_util.c:157: Warnung: pointer targets in passing arg 1 of > `glXGetProcAddress' differ in signedness > dri_util.c: In function `driCreateNewContext': > dri_util.c:1073: Warnung: ISO C forbids assignment between function pointer > and `void *' > dri_util.c:1074: Warnung: ISO C forbids assignment between function pointer > and `void *' > dri_util.c:1076: Warnung: ISO C forbids assignment between function pointer > and `void *' > dri_util.c:1077: Warnung: ISO C forbids assignment between function pointer > and `void *' > dri_util.c:1081: Warnung: ISO C forbids assignment between function pointer > and `void *' > dri_util.c:1082: Warnung: ISO C forbids assignment between function pointer > and `void *' > make[6]: *** [dri_util.o] Fehler 1 > make[6]: Leaving directory > `/tmp/INSTALL/SOURCE/dri-trunk/xc/xc/lib/GL/mesa/drivers/dri/common' > make[5]: *** [all] Fehler 2 > > Thanks, > Dieter > > > --- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI/Mesa CVS (XFree86) compilation error
SM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM dri_util.c In file included from dri_util.c:52: dri_util.h:563: Warnung: redundant redeclaration of `glXGetProcAddress' in same scope /opt/Mesa/include/GL/glx.h:295: Warnung: previous declaration of `glXGetProcAddress' dri_util.c:57: error: conflicting types for `PFNGLXGETMSCRATEOMLPROC' /opt/Mesa/include/GL/glxext.h:617: error: previous declaration of `PFNGLXGETMSCRATEOMLPROC' dri_util.c:57: Warnung: redundant redeclaration of `PFNGLXGETMSCRATEOMLPROC' in same scope /opt/Mesa/include/GL/glxext.h:617: Warnung: previous declaration of `PFNGLXGETMSCRATEOMLPROC' dri_util.c: In function `glx_find_dri_screen': dri_util.c:157: Warnung: pointer targets in passing arg 1 of `glXGetProcAddress' differ in signedness dri_util.c: In function `driCreateNewContext': dri_util.c:1073: Warnung: ISO C forbids assignment between function pointer and `void *' dri_util.c:1074: Warnung: ISO C forbids assignment between function pointer and `void *' dri_util.c:1076: Warnung: ISO C forbids assignment between function pointer and `void *' dri_util.c:1077: Warnung: ISO C forbids assignment between function pointer and `void *' dri_util.c:1081: Warnung: ISO C forbids assignment between function pointer and `void *' dri_util.c:1082: Warnung: ISO C forbids assignment between function pointer and `void *' make[6]: *** [dri_util.o] Fehler 1 make[6]: Leaving directory `/tmp/INSTALL/SOURCE/dri-trunk/xc/xc/lib/GL/mesa/drivers/dri/common' make[5]: *** [all] Fehler 2 Thanks, Dieter --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Artifacts with very large texture coordinates
Felix Kühling wrote: Hi, I noticed some strange rendering artifacts with the Savage that are caused by very large texture coordinates on GL_REPEAT'ed textures. Very large means that it gets noticeable with texture coordinates >255 or <-256. A real world example that exhibits this problem is Torcs with the "Spring" track. Right at the start the effect can be seen very nicely. The track before the start line shows artifacts, directly after the start line everything looks fine. My question is, should I consider such problems an application bug or would it be wise to implement a workaround? I was thinking of implementing a TNL pipeline stage that normalizes texture coordinates. That could be tricky. If you're thinking of doing something like t' = t MOD maxValue, that'll often cause incorrect interpolation. I was also wondering if other hardware has similar problems. I'm attaching a small test program that demonstrates the effect and a screenshot of what I get on my ProSavageDDR. With software rendering the output is almost correct. Compile with cc -lGL -lGLU -lglut teximage.c -o teximage If the hardware implements texcoord interpolation with fixed point you can imagine how the bits are used. If the largest texture dimension is 2048, you'd need at least 11 bits to address all texels. Then you need some sub-texel bits for accurate interpolation and for computing the weighting for linear sampling. You probably need 10 bits there. Allocate another bit for the sign. Finally, whatever bits are left in the interpolator will limit the maximum coordinate range. If the interpolator is 32 bits, then 32 - 11 - 10 - 1 = 10. So the max coordinate would be 2^10 or 1024. Maybe the savage hardware has a narrow interpolator, or allocates the bits differently. I believe one of the differences between "pro" and "consumer" cards is the accuracy and range of interpolators. -Brian --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2092] New: _radeon_texrect_stage looks broken
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2092 Summary: _radeon_texrect_stage looks broken Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Drivers/DRI/Radeon AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I just hacked up a texture normalizing pipeline stage for the savage driver. I started by copying the radeon_texrect stage. In the end I had confirmed that my stage was running but it did not take effect. When I checked t_vb_texmat.c I saw why: When the stage installs its output in the VB it needs to change VB->AttribPtr too e.g.: VB->AttribPtr[VERT_ATTRIB_TEX0+i] = VB->TexCoordPtr[i] = &store->texcoord[i]; As this is missing in the _radeon_texrect_stage I assume it must be broken right now. Can anyone confirm this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Artifacts with very large texture coordinates
> Sorry folks, I attached the wrong file. This is the second time in a > week. I have to be more careful. Now the correct program. You're simply working too hard :-) Here you go: http://kempniu.no-ip.com/files/teximage.jpg (Savage/IX 8 MB) Best regards, Michal Kepien --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Artifacts with very large texture coordinates
Felix Kühling <[EMAIL PROTECTED]> writes: > Sorry folks, I attached the wrong file. This is the second time in a > week. I have to be more careful. Now the correct program. Here's what I get with my radeon 7500 with the correct program : http://homes.kataplop.net/~dkm/texturetest2.png Hope it can help :) Marc --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Artifacts with very large texture coordinates
Sorry folks, I attached the wrong file. This is the second time in a
week. I have to be more careful. Now the correct program.
Am Do, den 16.12.2004 schrieb Felix Kühling um 1:11:
> Hi,
>
> I noticed some strange rendering artifacts with the Savage that are
> caused by very large texture coordinates on GL_REPEAT'ed textures. Very
> large means that it gets noticeable with texture coordinates >255 or
> <-256. A real world example that exhibits this problem is Torcs with the
> "Spring" track. Right at the start the effect can be seen very nicely.
> The track before the start line shows artifacts, directly after the
> start line everything looks fine.
>
> My question is, should I consider such problems an application bug or
> would it be wise to implement a workaround? I was thinking of
> implementing a TNL pipeline stage that normalizes texture coordinates.
>
> I was also wondering if other hardware has similar problems. I'm
> attaching a small test program that demonstrates the effect and a
> screenshot of what I get on my ProSavageDDR. With software rendering the
> output is almost correct. Compile with
>
> cc -lGL -lGLU -lglut teximage.c -o teximage
>
> Thanks in advance,
> Felix
--
| Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
#include
#include
#include
#include
#include
#define TEX_OFFSET_X 1024.0
#define TEX_OFFSET_Y 1024.0
#define MAX_WIDTH 128
#define MAX_HEIGHT 128
GLubyte texData[MAX_WIDTH * MAX_HEIGHT * 3];
GLuint texture;
GLuint tWidth = 0, tHeight = 0;
void init () {
GLuint x, y;
GLubyte *p;
glClearColor (0.0, 0.0, 0.0, 0.0);
glShadeModel (GL_FLAT);
p = texData;
for (y = 0; y < tHeight; ++y)
for (x = 0; x < tWidth; ++x, p += 3) {
if ((x & 7) == 4 || (y & 7) == 4) {
p[0] = 0;
p[1] = 0;
p[2] = 255;
} else {
p[0] = tWidth > 1 ? x * 255 / (tWidth-1) : 128;
p[1] = tHeight > 1 ? y * 255 / (tHeight-1) : 128;
p[2] = 0;
}
}
glGenTextures (1, &texture);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, texture);
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB8, tWidth, tHeight, 0,
GL_RGB, GL_UNSIGNED_BYTE, texData);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
}
void display () {
glClear (GL_COLOR_BUFFER_BIT);
glEnable(GL_TEXTURE_2D);
glBindTexture (GL_TEXTURE_2D, texture);
glBegin(GL_QUADS);
glColor3f(1.0, 1.0, 0.0);
glTexCoord2f(0.0+TEX_OFFSET_X, 2.0+TEX_OFFSET_Y); glVertex2f(-1.0, -1.0);
glTexCoord2f(2.0+TEX_OFFSET_X, 2.0+TEX_OFFSET_Y); glVertex2f( 1.0, -1.0);
glTexCoord2f(2.0+TEX_OFFSET_X, 0.0+TEX_OFFSET_Y); glVertex2f( 1.0, 1.0);
glTexCoord2f(0.0+TEX_OFFSET_X, 0.0+TEX_OFFSET_Y); glVertex2f(-1.0, 1.0);
glEnd();
glutSwapBuffers();
}
void reshape (int w, int h) {
glViewport (0, 0, (GLsizei) w, (GLsizei) h);
glMatrixMode (GL_PROJECTION);
glLoadIdentity ();
glOrtho (-1.0, 1.0, -1.0, 1.0, -1.0, 1.0);
glMatrixMode (GL_MODELVIEW);
}
int main (int argc, char *argv[]) {
int winId;
if (argc < 2)
tWidth = 128;
else if (sscanf (argv[1], "%u", &tWidth) != 1) {
fprintf (stderr, "Error: invalid width: %s\n", argv[1]);
return 1;
}
if (argc < 3)
tHeight = 128;
else if (sscanf (argv[2], "%u", &tHeight) != 1) {
fprintf (stderr, "Error: invalid height: %s\n", argv[2]);
return 1;
}
if (tWidth == 0 || tWidth > MAX_WIDTH) {
fprintf (stderr, "Error: width out of range [1:%u].\n", MAX_WIDTH);
return 1;
}
if (tHeight == 0 || tHeight > MAX_HEIGHT) {
fprintf (stderr, "Error: height out of range [1:%u].\n", MAX_HEIGHT);
return 1;
}
glutInit (&argc, argv);
glutInitDisplayMode (GLUT_RGBA | GLUT_DOUBLE);
glutInitWindowSize (250, 250);
glutInitWindowPosition (100, 100);
winId = glutCreateWindow ("Texture Test");
init ();
glutDisplayFunc (display);
glutReshapeFunc (reshape);
glutMainLoop ();
return 0;
}
Re: Artifacts with very large texture coordinates
Felix Kühling wrote: Hi, I noticed some strange rendering artifacts with the Savage that are caused by very large texture coordinates on GL_REPEAT'ed textures. Very large means that it gets noticeable with texture coordinates >255 or <-256. A real world example that exhibits this problem is Torcs with the "Spring" track. Right at the start the effect can be seen very nicely. The track before the start line shows artifacts, directly after the start line everything looks fine. My question is, should I consider such problems an application bug or would it be wise to implement a workaround? I was thinking of implementing a TNL pipeline stage that normalizes texture coordinates. I was also wondering if other hardware has similar problems. I'm attaching a small test program that demonstrates the effect and a screenshot of what I get on my ProSavageDDR. With software rendering the output is almost correct. Compile with The mesa software rasterizer and a number of the hardware devices start giving odd looking results for very large texture coordinates. In the past we've treated it as an application issue and fixed the demos causing the problem. If you the app takes things to extremes and start sending enormous texcoords, there's nothing we can do about it because there aren't enough bits left in a float to represent the fractional part of the coordinate. So at a certain point it has to be an application bug. Keith --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
