Re: [PATCH] DRM depends on ???
The whole dependancy seems like nonsense to me. I think depends on PCI is a lot more sensible. I think the original reasoning was something like this: If DRM is built-in, then AGP _must_ be built-in or not included at all, modular won't work. If DRM is modular or not built, then AGP may be built-in, modular, or not built at all. The depends on AGP || AGP=n means that if DRM=y, then AGP=y or AGP=n, and if DRM=m or DRM=n, then AGP=y or AGP=m or AGP=n. Yes it's unclear and yes it should probably be documented in a comment somewhere. What Kyle said is the correct answer... we either keep this lovely construct (I'll add a comment for 2.6.13) or we go back to the old intermodule or module_get stuff... DRM built-in with modular AGP is always wrong... or at least I'll get a hundred e-mails less every month if I say it is .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
Hi, First patch helped lot (but there are still lockups). Second - no diffrence with or without. Peter Zubaj Nicolai Haehnle wrote: Hi everybody, I once again tripped upon an R300 lockup (possibly the same one that everybody's been talking about) and spent the last one and half days chasing it down. It turns out that writing the vertex buffer age to scratch registers (the ones that are written back to main memory) during a 3D sequence is a bad idea. Apparently, this confuses the memory controller so much that some part of the engine locks up hard. The attached patch.out-of-loop-dispatch-age fixes this, at least for me. The attached patch.remove-userspace-pacifiers removes additional unnecessary emission of the pacifier sequence from the userspace driver. Userspace isn't supposed to emit this sequence anyway. Could everybody please test whether a) the first patch really does fix the lockups people are seeing and b) whether combining both the first and the second patch causes any regressions. If everything's fine with these patches, I'm going to commit them in a few days or so. cu, Nicolai --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM depends on ???
On Sun, May 29, 2005 at 12:25:10AM -0400, Kyle Moffett wrote: If DRM is built-in, then AGP _must_ be built-in or not included at all, modular won't work. If DRM is modular or not built, then AGP may be built- in, modular, or not built at all. The depends on AGP || AGP=n means that if DRM=y, then AGP=y or AGP=n, and if DRM=m or DRM=n, then AGP=y or AGP=m or AGP=n. Yes it's unclear and yes it should probably be documented in a comment somewhere. could be written easier as depends on AGP if AGP --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
Peter Zubaj wrote: Hi, First patch helped lot (but there are still lockups). Second - no diffrence with or without. Peter Zubaj Nicolai Haehnle wrote: Same here. All the lockups happen, it just takes them longer. Boris Peterbarg Hi everybody, I once again tripped upon an R300 lockup (possibly the same one that everybody's been talking about) and spent the last one and half days chasing it down. It turns out that writing the vertex buffer age to scratch registers (the ones that are written back to main memory) during a 3D sequence is a bad idea. Apparently, this confuses the memory controller so much that some part of the engine locks up hard. The attached patch.out-of-loop-dispatch-age fixes this, at least for me. The attached patch.remove-userspace-pacifiers removes additional unnecessary emission of the pacifier sequence from the userspace driver. Userspace isn't supposed to emit this sequence anyway. Could everybody please test whether a) the first patch really does fix the lockups people are seeing and b) whether combining both the first and the second patch causes any regressions. If everything's fine with these patches, I'm going to commit them in a few days or so. cu, Nicolai --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
On Sunday 29 May 2005 02:31, Ben Skeggs wrote:
Morning,
After playing UT2004 for 10 or so minutes, and then quickly checking
some other
apps known to worn, I see no regressions with either patch.
I'll be putting it through some more rigorous testing as the day
progresses, will
report back if I find anything.
Also, out of interest, what triggered the lockup you saw?
Pretty much anything could trigger it, from glxgears (unlikely lockup) over
glean (regular lockups) to cube (almost instant lockup).
Unfortunately, just like others are reporting, I'm still getting lockups,
too. This time, however, they are more elusive as the lockups disappear as
soon as I start looking for them:
I used the attached patch (in variations) to hunt for the previous lockup.
What this patch does is that it basically commits the ring buffer after
every ADVANCE_RING and waits for the read ptr to catch up with the write
ptr. Feel free to try this patch if you're seeing lockups, perhaps you can
find something out that way. However, as soon as I enable the call to
commit_and_wait, the lockups disappear for me.
I'm still going to try to find this thing, but it looks like it's going to
be difficult.
cu,
Nicolai
Index: drm/shared-core/radeon_cp.c
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/radeon_cp.c,v
retrieving revision 1.7
diff -u -3 -p -r1.7 radeon_cp.c
--- drm/shared-core/radeon_cp.c 19 Apr 2005 21:05:18 - 1.7
+++ drm/shared-core/radeon_cp.c 28 May 2005 20:34:04 -
@@ -923,6 +923,56 @@ static int radeon_do_wait_for_idle(drm_r
return DRM_ERR(EBUSY);
}
+
+/* Debugging function:
+ *
+ * Commit the ring immediately and verify that the hardware is making
+ * progress on the ring.
+ */
+static int failed_once = 0;
+static const char* prev_inflight_caller = 0;
+static const char* prev2_inflight_caller = 0;
+static const char* prev3_inflight_caller = 0;
+
+void radeon_do_inflight_commit_and_wait(drm_radeon_private_t * dev_priv, const char* caller)
+{
+ const char* prev3_caller = prev3_inflight_caller;
+ const char* prev2_caller = prev2_inflight_caller;
+ const char* prev_caller = prev_inflight_caller;
+ const char* cur_caller = caller;
+ u32 old_tail = RADEON_READ(RADEON_CP_RB_WPTR);
+ u32 new_tail = dev_priv-ring.tail;
+ int i;
+
+ prev3_inflight_caller = prev2_caller;
+ prev2_inflight_caller = prev_caller;
+ prev_inflight_caller = caller;
+
+ if (failed_once)
+ return;
+
+ COMMIT_RING();
+
+ for(i = 0; i dev_priv-usec_timeout; i++) {
+ u32 head = GET_RING_HEAD(dev_priv);
+
+ if (new_tail old_tail) {
+ if (head old_tail head = new_tail)
+return;
+ } else {
+ if (head = new_tail || head old_tail)
+return;
+ }
+
+ DRM_UDELAY(1);
+ }
+
+ DRM_ERROR(failed! (caller = %s, prev = %s - %s - %s)\n, cur_caller, prev_caller, prev2_caller, prev3_caller);
+ radeon_status(dev_priv);
+ failed_once = 1;
+}
+
+
/*
* CP control, initialization
*/
Index: drm/shared-core/radeon_drv.h
===
RCS file: /cvsroot/r300/r300_driver/drm/shared-core/radeon_drv.h,v
retrieving revision 1.12
diff -u -3 -p -r1.12 radeon_drv.h
--- drm/shared-core/radeon_drv.h 3 Mar 2005 04:40:21 - 1.12
+++ drm/shared-core/radeon_drv.h 28 May 2005 20:34:05 -
@@ -985,14 +985,39 @@ do { \
#define RING_LOCALS int write, _nr; unsigned int mask; u32 *ring;
+#define ALIGN_RING() do { \
+ int _nr = 32 - (dev_priv-ring.tail 31); \
+ int _write; \
+ if (dev_priv-ring.space = (_nr+1) * sizeof(u32)) { \
+ COMMIT_RING(); \
+ radeon_wait_ring( dev_priv, (_nr+1) * sizeof(u32) ); \
+ }\
+ _write = dev_priv-ring.tail; \
+ if (_write 1) { \
+ dev_priv-ring.start[_write++] = RADEON_CP_PACKET2; \
+ _write = _write % dev_priv-ring.tail_mask; \
+ _nr--; \
+ }\
+ while( _nr = 2 ) { \
+ /*dev_priv-ring.start[_write++] = CP_PACKET3( RADEON_CP_NOP, 0 );*/ \
+ /*dev_priv-ring.start[_write++] = CP_PACKET0( 0x1438, 0 );*/ \
+ dev_priv-ring.start[_write++] = RADEON_CP_PACKET2; \
+ dev_priv-ring.start[_write++] = RADEON_CP_PACKET2; \
+ _write = _write % dev_priv-ring.tail_mask; \
+ _nr -= 2; \
+ }\
+ dev_priv-ring.tail = _write; \
+} while (0)
+
#define BEGIN_RING( n ) do { \
+ ALIGN_RING(); /* TEST TEST */ \
if ( RADEON_VERBOSE ) { \
DRM_INFO( BEGIN_RING( %d ) in %s\n, \
n, __FUNCTION__ );\
}\
- if ( dev_priv-ring.space = (n) * sizeof(u32) ) { \
+ if ( dev_priv-ring.space = dev_priv-ring.size/2 /*(n+1) * sizeof(u32)*/ ) { \
COMMIT_RING(); \
- radeon_wait_ring( dev_priv, (n) * sizeof(u32) ); \
+ radeon_wait_ring( dev_priv, dev_priv-ring.size/2/*(n+1) * sizeof(u32)*/ ); \
}\
_nr = n; dev_priv-ring.space -= (n) * sizeof(u32); \
ring = dev_priv-ring.start; \
@@
r300 and pcie card...
Okay I've a Dell Inspiron 6000 with a X300 (1002:5460) on a PCI-Express bus.. I've installed Xorg CVS and the latest r300 drm and with the drm loaded, X hangs the card (usual 99% X server can't kill it ...) turning on debug just gives the usual deadlock ioctl, the end of the log is May 29 20:15:51 localhost kernel: [drm:drm_ioctl] pid=8432, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 May 29 20:15:51 localhost kernel: [drm:radeon_cp_indirect] indirect: idx=1 s=0 e=112 d=0 May 29 20:15:51 localhost kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=1 s=0x0 e=0x70 May 29 20:15:52 localhost kernel: [drm:drm_ioctl] pid=8432, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 May 29 20:15:52 localhost kernel: [drm:radeon_cp_idle] May 29 20:15:52 localhost kernel: [drm:radeon_do_cp_idle] May 29 20:15:52 localhost kernel: [drm:drm_ioctl] ret = fff0 Anyone got r300 working on any pci express yet or am I going to have to be the one to try and get it working? Regards, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patches] Re: r300 radeon 9800 lockup
Nicolai Haehnle wrote: Hi everybody, I once again tripped upon an R300 lockup (possibly the same one that everybody's been talking about) and spent the last one and half days chasing it down. It turns out that writing the vertex buffer age to scratch registers (the ones that are written back to main memory) during a 3D sequence is a bad idea. Apparently, this confuses the memory controller so much that some part of the engine locks up hard. The attached patch.out-of-loop-dispatch-age fixes this, at least for me. The attached patch.remove-userspace-pacifiers removes additional unnecessary emission of the pacifier sequence from the userspace driver. Userspace isn't supposed to emit this sequence anyway. Could everybody please test whether a) the first patch really does fix the lockups people are seeing and b) whether combining both the first and the second patch causes any regressions. If everything's fine with these patches, I'm going to commit them in a few days or so. cu, Nicolai A) The first patch may help a little, but definitely doesn't eliminate the lockups. B) Huge regression. With both patches I get an immediate lockup when launching glxgears (before the window is even drawn). Adam --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon 9600se?
I have xorg.conf set up to use radeon driver with big desktop mode and xinerama. It works fine, but I want acceleration. So am I correct in saying all I need to do is # Load dri Load glx uncomment the dri load, and make install your modules? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon 9600se?
Hi, No, you are not correct. You need cvs version of xorg, cvs version of mesa and cvs version of r300 driver from r300.sf.net. r300 driver is still in alpha stage (it can lock or crash your computer). Peter Zubaj Najdi svojich spoluziakov! http://www.spoluziak.sk --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 and pcie card...
On 5/29/05, Dave Airlie [EMAIL PROTECTED] wrote: Okay I've a Dell Inspiron 6000 with a X300 (1002:5460) on a PCI-Express bus.. I've installed Xorg CVS and the latest r300 drm and with the drm loaded, X hangs the card (usual 99% X server can't kill it ...) turning on debug just gives the usual deadlock ioctl, the end of the log is May 29 20:15:51 localhost kernel: [drm:drm_ioctl] pid=8432, cmd=0xc010644d, nr=0x4d, dev 0xe200, auth=1 May 29 20:15:51 localhost kernel: [drm:radeon_cp_indirect] indirect: idx=1 s=0 e=112 d=0 May 29 20:15:51 localhost kernel: [drm:radeon_cp_dispatch_indirect] indirect: buf=1 s=0x0 e=0x70 May 29 20:15:52 localhost kernel: [drm:drm_ioctl] pid=8432, cmd=0x6444, nr=0x44, dev 0xe200, auth=1 May 29 20:15:52 localhost kernel: [drm:radeon_cp_idle] May 29 20:15:52 localhost kernel: [drm:radeon_do_cp_idle] May 29 20:15:52 localhost kernel: [drm:drm_ioctl] ret = fff0 Anyone got r300 working on any pci express yet or am I going to have to be the one to try and get it working? You're the first! I've got one too (pcie x800), and I've been meaning to try it, I just haven't gotten a chance yet. Alex Regards, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 bugs
Hi, I've just tried out the r300 driver - works remarkably well for untested and broken code. I've run into 2 bugs though: It doesn't work well if the display uses 16 bpp (24 bpp works perfectly) -- 3D in 16 bpp is pretty badly misrendered (sample attached; 2D works well w/ r300 DRI even at 16 bpp) -- mixed with a random section of the rest of the screen, wrong colors, and drawn way too large (but close enough to the expected output to recognize it). The 2nd bug is that tuxkart (http://tuxkart.sf.net/) segfaults when starting a game -- apparently the driver is returning a wrong value (or NULL pointer?) somewhere. The game works on r200 and i855; didn't have the time to do a lot of debugging yet. Any ideas? Thanks, bero attachment: glxgears.png
Re: [PATCH] DRM depends on ???
On May 29, 2005, at 15:58:10, Geert Uytterhoeven wrote: What Kyle said is the correct answer... we either keep this lovely construct (I'll add a comment for 2.6.13) or we go back to the old intermodule or module_get stuff... DRM built-in with modular AGP is always wrong... or at least I'll get a hundred e-mails less every month if I say it is .. And what if we don't have AGP at all? Or no PCI? Then DRM detects that at configure time and excludes the code that requires AGP. Basically, the following are valid configurations: DRM=y AGP=y # DRM will use AGP DRM=y AGP=n # DRM will not use AGP DRM=m AGP=y # DRM will use AGP DRM=m AGP=m # DRM will use AGP (DRM module depends on AGP module) DRM=m AGP=n # DRM will not use AGP DRM=n AGP=* # DRM isn't compiled and therefore doesn't care about AGP The only invalid configuration is DRM=y AGP=m, which seems silly, although theoretically in that case DRM should exclude AGP support. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C$ UB/L/X/*(+)$ P+++()$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e-$ h!*()++$ r !y?(-) --END GEEK CODE BLOCK-- --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL
Ok, with help so far from a number of people on this list (thank you), I have built and installed Mesa and drm. However, I am getting symbol errors (listed below) when I try to load the new radeon module. I presume that the problem is caused by differences between the new modules and the libraries/modules in my distro. 1. I note that libdri.a and libdrm.a in /usr/X11R6/lib/modules/extensions haven't been updated. Is this a possible cause of the problem? 2. In checking that the AGP modules are being loaded before the radeon driver, it seems that there are no loadable AGP modules with the kernel (2.6.11-1.14_FC3). In fact, there is no /lib/modules/2.6.11-1.14_FC3/kernel/drivers/char/agp directory. Am I correct in interpreting this as meaning the Fedora Core has these modules built into the kernel as non-loadable modules? (I do recall something about this being a solution to get rhgb working??) Looking at the source, most of these symbols seem to be defined in the drm modules I have just compiled and installed, so I still haven't worked out where the conflicts are, and what I need to rebuild to fix them. Looking at this mailing list, I see that there are certain combinations of static vs dynamic modules that just don't work. Am I correct in presuming that this is what I'm encountering? If so, what is the recommended solution? 1. Move the newer DRM and MESA source into my existing kernel source tree, and rebuild the kernel from the same config (ie, with static AGP etc modules) 2. Change the kernel config to make DRM, MESA, AGP, DRI (and any others??) to be dynamically loadable modules, rebuild the kernel, and then install my newly compiled modules? I would expect that for future upgradability and debugging, this second option is the better, but are there any particular downsides that I should be aware of? And if I'm on the wrong track entirely, could someone please give me a pointer as to how to find and fix the symbol errors? Cheers! Nik. radeon: disagrees about version of symbol drm_open radeon: Unknown symbol drm_open radeon: disagrees about version of symbol drm_fasync radeon: Unknown symbol drm_fasync radeon: disagrees about version of symbol drm_poll radeon: Unknown symbol drm_poll radeon: Unknown symbol drm_get_resource_len radeon: disagrees about version of symbol drm_core_get_reg_ofs radeon: Unknown symbol drm_core_get_reg_ofs radeon: disagrees about version of symbol drm_irq_uninstall radeon: Unknown symbol drm_irq_uninstall radeon: Unknown symbol drm_get_dev radeon: disagrees about version of symbol drm_ioctl radeon: Unknown symbol drm_ioctl radeon: disagrees about version of symbol drm_exit radeon: Unknown symbol drm_exit radeon: disagrees about version of symbol drm_core_get_map_ofs radeon: Unknown symbol drm_core_get_map_ofs radeon: disagrees about version of symbol drm_init radeon: Unknown symbol drm_init radeon: Unknown symbol drm_get_resource_start radeon: disagrees about version of symbol drm_vbl_send_signals radeon: Unknown symbol drm_vbl_send_signals radeon: Unknown symbol drm_cleanup_pci radeon: disagrees about version of symbol drm_ati_pcigart_init radeon: Unknown symbol drm_ati_pcigart_init radeon: disagrees about version of symbol drm_mmap radeon: Unknown symbol drm_mmap radeon: disagrees about version of symbol drm_ati_pcigart_cleanup radeon: Unknown symbol drm_ati_pcigart_cleanup radeon: Unknown symbol drm_initmap radeon: disagrees about version of symbol drm_core_reclaim_buffers radeon: Unknown symbol drm_core_reclaim_buffers radeon: disagrees about version of symbol drm_release radeon: Unknown symbol drm_release --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1615] R128 Software fallbacks 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=1615 --- Additional Comments From [EMAIL PROTECTED] 2005-05-29 19:18 --- No longer appears to cause hangs, but rendering is still wrong. -- 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. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2195] switch radeon driver to t_vertex interface
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=2195 --- Additional Comments From [EMAIL PROTECTED] 2005-05-29 18:53 --- I've tested this on ut2004, ut, q3, and tcl_mode=0 projtex, and it seemed to be fine. There's a 25k reduction in the stripped binary size. However performance is also reduced somewhat (tcl_mode=0 quake3, 800x600 demofours on 1ghz p3 and rv200 card): x pre-tvertex + post-tvertex +--+ |+x| |+ + + + x x| ||___A| |AM| +--+ N Min MaxMedian AvgStddev x 579 79.1 79.1 79.080.04472136 + 5 75.476 75.6 75.620.22803509 Difference at 95.0% confidence -3.46 +/- 0.239647 -4.37532% +/- 0.303043% (Student's t, pooled s = 0.164317) Do we want to apply the patch in this case? It would increase maintainability, definitely. -- 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. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 bugs
Hi, 16 bpp is not supported in r300 driver. It will be probably supported if fglrx will support 16 bpp (I think, this will never hapend. Peter Zubaj ___ Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete. http://www.wanda.sk/ --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
