Re: r300 - alpha test
I just realized something - isn't the application supposed to change Z test for that ? I don't know, but all application I tested and which uses alpha test - has z test enabled and all displays errors (tuxracer, enemy territory, fire - from mesa/demos) Maybe what really happens is that disabling Z test is broken. Z test is not disabled - it is enabled. Problem is - even alpha test fails (and fragment is discarded) z value is still written (and this looks wrong). On the other hand, as Nicolai points out it would be nice to know what that register does and whether other bits have any function. AFAIK: fglrx initialize 0x4f14 register to 0x0001, but when alpha test is enabled it sets it to 0x. I have to do more tests to see if fglrx sets this register back to 0x0001 (for now looks, like it is not set back, but I need to make test program for it). Peter Zubaj Vsetko o SuperStar http://superstar.atlas.sk --- 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://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 - alpha test
On Mon, 21 Mar 2005, Peter Zubaj wrote: I just realized something - isn't the application supposed to change Z test for that ? I don't know, but all application I tested and which uses alpha test - has z test enabled and all displays errors (tuxracer, enemy territory, fire - from mesa/demos) Maybe what really happens is that disabling Z test is broken. Z test is not disabled - it is enabled. Problem is - even alpha test fails (and fragment is discarded) z value is still written (and this looks wrong). So you are saying that this bit is don't write Z when alpha test fails ? I would suggest trying to find a similar bit in R200 hardware, it might shed light on what the entire register does. best Vladimir Dergachev On the other hand, as Nicolai points out it would be nice to know what that register does and whether other bits have any function. AFAIK: fglrx initialize 0x4f14 register to 0x0001, but when alpha test is enabled it sets it to 0x. I have to do more tests to see if fglrx sets this register back to 0x0001 (for now looks, like it is not set back, but I need to make test program for it). Peter Zubaj Vsetko o SuperStar http://superstar.atlas.sk --- 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://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 - alpha test
Meh, I originally sent this from the wrong email address, sorry... On Monday 21 March 2005 12:50, Peter Zubaj wrote: I just realized something - isn't the application supposed to change Z test for that ? I don't know, but all application I tested and which uses alpha test - has z test enabled and all displays errors (tuxracer, enemy territory, fire - from mesa/demos) Maybe what really happens is that disabling Z test is broken. Z test is not disabled - it is enabled. Problem is - even alpha test fails (and fragment is discarded) z value is still written (and this looks wrong). Bingo. If setting 0x4F14 to 1 does indeed enable early Z testing, this is easily explained: For every fragment, the card *first* does the Z test. The Z test passes, so the new depth is written out. The fragment program is probably run after the Z test, but this detail doesn't matter. What matters is that the alpha test discards the fragment, but only after Z has already been written. If, on the other hand, 0x4F14 is set to 0, Z testing happens *after* the alpha test and everything's fine. On the other hand, as Nicolai points out it would be nice to know what that register does and whether other bits have any function. AFAIK: fglrx initialize 0x4f14 register to 0x0001, but when alpha test is enabled it sets it to 0x. I have to do more tests to see if fglrx sets this register back to 0x0001 (for now looks, like it is not set back, but I need to make test program for it). Yes, that would need further testing. If fglrx does not set the register back to 1, that would indicate that there's more to this bit than just early Z. Possible explanations could be (a) a relation to other Z acceleration tricks, (b) fglrx is just being stupid or (c) switching between early and late Z testing is very slow or broken in hardware. But if fglrx *does* reset the register to 1 when alpha test is disabled, we can pretty much say with certainty that it enables early Z testing. cu, Nicolai pgp5ZzfXpDQXP.pgp Description: PGP signature
Re: Problems with DRI on FreeBSD 6.8.2
On Sunday 20 March 2005 10:29 am, Adam K Kirchhoff wrote: So I can't seem to get direct rendering enabled with 6.8.2 on my freebsd installation at the moment. This is what I'm seeing in the Xorg log file: (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (EE) RADEON(0): [drm] Failed to map vertex/indirect buffers list (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc57fe000 at 0x283c7000 (II) RADEON(0): Render acceleration disabled (II) RADEON(0): Direct rendering disabled Any ideas? We need to know kernel version and chipset info. Jung-uk Kim --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problems with DRI on FreeBSD 6.8.2
Jung-uk Kim wrote: On Sunday 20 March 2005 10:29 am, Adam K Kirchhoff wrote: So I can't seem to get direct rendering enabled with 6.8.2 on my freebsd installation at the moment. This is what I'm seeing in the Xorg log file: (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (EE) RADEON(0): [drm] Failed to map vertex/indirect buffers list (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xc57fe000 at 0x283c7000 (II) RADEON(0): Render acceleration disabled (II) RADEON(0): Direct rendering disabled Any ideas? We need to know kernel version and chipset info. Jung-uk Kim Actually, I tracked down Eric on IRC and he informed me that PHK broke the DRM on FreeBSD -CURRENT. Eric pointed me in the direction of a patch that got it working again. Thanks, though! Adam --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] 32-bit ioctl compatibility for CVS DRM
On Wed, 9 Mar 2005 22:55:04 +1100, Paul Mackerras [EMAIL PROTECTED] wrote: Here is a patch that adds 32-bit ioctl compatibility code to the CVS DRM (i.e. the drm CVS module at dri.freedesktop.org). I have taken a different approach to the problem of 32-bit map handles this time. I only generate a fake 32-bit handle for _DRM_SHM mappings as before, but now I put the 32-bit handle in map-offset for those mappings (previously map-offset and map-handle were the same for _DRM_SHM mappings). This simplifies the code quite a bit. I built this against CVS DRM and a recent -bk kernel (just prior to 2.6.12-rc1) on amd64. I had to merge support for the recent agp bridge changes into the CVS DRM, but I don't think that should have affected the ioctl32 bits. Setup: Distro: Debian unstable pure64 Graphics card: radeon9200 Kernel: -bk snapshot from just before 2.6.12-rc1 (plus cvs drm, plus the above patch) X server used in tests: Xorg 6.8.2 Results: 64-bit direct rendering clients are still quite happy with this patch. I've tested this with the libGL.so and r200_dri.so from Xorg 6.8.2 and with those from the debian XFree86 4.3 package. At some point soon, I'll make sure to actually run the XFree86 4.3 server and test that too. 32-bit direct rendering clients are also happy when run under a 32-bit X server. I've only tested the Xorg 6.8.2 server in 32-bit mode, however. I'll try and test the old 4.3 server sometime this week. -- Will Dyson --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 - alpha test
On Monday 21 March 2005 12:50, Peter Zubaj wrote: I just realized something - isn't the application supposed to change Z test for that ? I don't know, but all application I tested and which uses alpha test - has z test enabled and all displays errors (tuxracer, enemy territory, fire - from mesa/demos) Maybe what really happens is that disabling Z test is broken. Z test is not disabled - it is enabled. Problem is - even alpha test fails (and fragment is discarded) z value is still written (and this looks wrong). Bingo. If setting 0x4F14 to 1 does indeed enable early Z testing, this is easily explained: For every fragment, the card *first* does the Z test. The Z test passes, so the new depth is written out. The fragment program is probably run after the Z test, but this detail doesn't matter. What matters is that the alpha test discards the fragment, but only after Z has already been written. If, on the other hand, 0x4F14 is set to 0, Z testing happens *after* the alpha test and everything's fine. On the other hand, as Nicolai points out it would be nice to know what that register does and whether other bits have any function. AFAIK: fglrx initialize 0x4f14 register to 0x0001, but when alpha test is enabled it sets it to 0x. I have to do more tests to see if fglrx sets this register back to 0x0001 (for now looks, like it is not set back, but I need to make test program for it). Yes, that would need further testing. If fglrx does not set the register back to 1, that would indicate that there's more to this bit than just early Z. Possible explanations could be (a) a relation to other Z acceleration tricks, (b) fglrx is just being stupid or (c) switching between early and late Z testing is very slow or broken in hardware. But if fglrx *does* reset the register to 1 when alpha test is disabled, we can pretty much say with certainty that it enables early Z testing. cu, Nicolai pgp21RdGhCMMO.pgp Description: PGP signature
[Bug 2596] Disabling DRI. [drm] failed to load kernel module i915 (EE) I810(0): [dri] DRIScreenInit failed.
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=2596 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Disabling DRI. [drm] failed |Disabling DRI. [drm] failed |to load kernel module i915|to load kernel module i915 |(EE) I810(0): [dri] |(EE) I810(0): [dri] |DRIScreenInit failed. |DRIScreenInit failed. --- Additional Comments From [EMAIL PROTECTED] 2005-03-21 10:23 --- I'm not sure if it applies to freebsd, but do you have the i915 kernel module installed? -- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] 3dfx DRM depends on PCI
3dfx DRM depends on PCI
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
--- linux-2.6.12-rc1/drivers/char/drm/Kconfig 2005-01-22 09:28:00.0
+0100
+++ linux-m68k-2.6.12-rc1/drivers/char/drm/Kconfig 2005-01-17
22:51:02.0 +0100
@@ -18,7 +18,7 @@ config DRM
config DRM_TDFX
tristate 3dfx Banshee/Voodoo3+
- depends on DRM
+ depends on DRM PCI
help
Choose this option if you have a 3dfx Banshee or Voodoo3 (or later),
graphics card. If M is selected, the module will be called tdfx.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Savage40] Re: Savage dri does not resume from disk
Hi Dario, With the help of Sergey Zharkov I narrowed down the problem. I'm CCing this to the dri-devel and savage40 lists as a summary. The problem seems to be in the AGP GART driver which is in the Linux kernel. A new snapshot won't help you, I can't fix the problem there. I haven't had the time to prepare a good bug-report for the kernel developers yet. I would have to upgrade the kernel and get swsusp to work with it first (last time I tried this was several months ago). I think I won't have time for this in the next two weeks. :( See my comment below for a good workaround. Am Montag, den 21.03.2005, 21:11 +0100 schrieb Dario Saccavino: I am experiencing the same problem with swsusp2 (version 2.1.8, kernel 2.6.11): after resuming from suspend to disk, if I launch a 3D application the computer hangs. I can avoid the problem completely by specifying DmaMode none in xorg.conf or by shutting down X before suspending. In order to make swsusp work reliably you should set BusType to PCI. This will disable any use of AGP memory, both for textures and for DMA. With BusType PCI you do not need to set DmaMode to None, but you may get slightly better performance. Your mileage may vary. I'm using a CVS snapshot dating about 2 weeks ago; is this fixed now, or going to be? I can supply logs and testing, if you need some help. Dario Regards, Felix On Wed, 16 Mar 2005 14:47:01 +0300, Sergey Zharkov [EMAIL PROTECTED] wrote: Felix, I've tried some coding to make savage resume looking at radeon resume code but failed completely :(( Unfortunately I'am ABAP/4 developer - not a C guru. The only thing that may help real dri developers to suggest how to resume - when I switched DMA mode from command or vertex to None i've lost about 5 % of speed but the dri system was able to resume from disk if no glx apps were running. And even with glx apps running it was resuming, but the glx apps were resuming with black window. Anyway after resume I was able to start glx apps and they worked, with dma enebled I had to pull a power cord and battery out to restart. And the bug is not in the kernel I guess - restarting X after resume with enabled dma works fine. --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 segfaults in t_vtx_generic.c running legends
Philipp Klaus Krause wrote: Well I just tried legends on my system (Debian DRI packages from nixnuts). I have hardware TCL disabled. legends runs without crashes, but enabling bumpmapping causes graphics errors on the ground. Can confirm that. However, with tcl enabled, it neither crashes nor are there the graphical glitches on the ground with bump mapping enabled here (Mesa CVS). That said, I got a gpu lockup after some minutes wandering around :-(, though I was not able to reproduce that. Roland --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4337] ATI Rage 128: messed up X
http://bugme.osdl.org/show_bug.cgi?id=4337 --- Additional Comments From [EMAIL PROTECTED] 2005-03-21 17:56 --- I'm assuming that we still have a bug here, although it's not obvious what it is. Markus, it might be useful to test 2.6.12-rc1-mm1, which has an AGP/DRI fix. Although we're not getting 100% success reports from that. --- 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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
