[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
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=314 --- Additional Comments From [EMAIL PROTECTED] 2003-23-10 11:50 --- I have done some some tests: kernel 2.6.0-test8 w/patch #703 XFree 4.3.99.14 w/patch #723 (I do not use DRM driver from X source but the patched from kernel) FujitsuSiemens Amilo A, Athlon XP +1400 - I have to clean /etc/modprobe.conf (all lines commented) It was formely generated by modutils. If I didn't do it, XFree hangs on during startup. In 2.6.0-test7 my modprobe.conf causing only KDE freezing during "initializing periphetals", Gnome went well, in 2.6.0-test8 freezes all XFree. I have full driver management in my hands, using only modprobe. - SOUND NOT WORKING if DRI is enabled modprobe snd-ali5451 (for alsa) cause system freezing immediately modprobe trident (for OSS) cause system freezing immediately If DRI is disabled the statements above work well. - network card not working if DRI is enabled (it's well known problem for Amilo A) modprobe 8139too (nothing suspicious happen, module is loaded) ifconfig eth0 up ...error message appears from kernel: disabling IRQ #11, but system goes on well, except network, but nothing freezing. - DRI works well, gives me around 400FPS in glxgears. Tuxracer have slight distortions in first screen, like big one-pixel-thin screen-wide cross, or like screen to be assembled from 4 smaller pictures. But then continues well. Quake3Arena Demo - nearly no problem, only some textures slightly flickering when I directly facing them, but it's not a big problem. - setting or unsetting in /etc/profile export RADEON_NO_IRQS=1 export RADEON_NO_USLEEPS=1 ..seems to have no efect Kerner 2.6.0-test4-patch540 DRI works still best for Amilo: no problems with sound, any screen distortions. only the network is the problem (I have to switch between two XF86Configs) It's independent on XFree version 4.3.99.14 or 4.3.99.11 or 4.3.99.12. I much prefer 2.6 kernel, for desktop/laptop users is really better, it's significant. I will give a try to DRM driver from X source in the next tests. -- 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. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
> Face it, a good graphics driver needs more than just "set up the ROM". It > needs DMA access, and the ability to use interrupts. It needs a real > driver. > > It basically needs something like what the DRI modules tend to do. > > I'd be really happy to have real graphics drivers in the kernel, but quite > frankly, so far the abstractions I've seen have sucked dead donkeys > through a straw. "fbcon" does way too much (it's not a driver, it's more a > text delivery system and a mode switcher). And DRI is too complex and > fluid to be a good low-level driver. Well... While I tend to agree, note that in 2.6 fbcon and the fbdev itself _do_ have been separated. The fbdevs are moving toward that low level driver thing. > Quite frankly, I'd much rather see a low-level graphics driver that does > _two_ things, and those things only: > > - basic hardware enumeration and setup (and no, "basic setup" does not >mean "mode switching": it literally means things like doing the >pci_enable_device() stuff. > > - serialization and arbitrary command queuing from a _trusted_ party (ie >it could take command lists from the X server, but not from untrusted >clients). This part basically boils down to "DMA and interrupts". This >is the part that allows others to wait for command completion, "enough >space in the ring buffers" etc. But it does _not_ know or care what the >commands are. IMHO, that low level driver should be ... the fbdev. The main reason for that is the necessary locking & synchronisation between the command flow and mode switching, palette control and cursor control (which aren't things doable via the normal command path on moth cases). > Then, fbcon and DRI and X could all three use these basics - and they'd be > _so_ basic that the hardware layer could be really stable (unlike the DRI > code that tends to have to upgrade for each new type of command that DRI > adds - since it has to take care of untrusted clients. So DRI would > basically use the low-level driver as a separate module, the way it > already uses AGP). I agree that fbcon itself should (and is now in 2.6) be a separate module. The interface is still scary, the locking is almost absent, which is a real problem even with current mode switching beeing racy with printk & blanking, but at least we have something that works and can evolve in the right direction. Look how the fbdev interface was simplified in the 2.4 -> 2.6 transition, it's really a lot saner now, and I hope it will continue to improve. > But I'm _not_ interested in some interfaces to let user mode just bypass > the kernel. Because they will not solve any of the other problems that > clearly _do_ need solving, and if the X server continues to believe that > it can just access the hardware directly, it will never play well together > with projects like fbcon/dri. Fully agreed. My point is that this low-level driver and the fbdev should be one thing. Ben. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
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=314 --- Additional Comments From [EMAIL PROTECTED] 2003-25-10 17:32 --- I realize this may not be the proper place to ask this, but has anybody had any luck with MergedFB http://bugs.xfree86.org/show_bug.cgi?id=276 on an igp320. I have just been making a few posts over there today. Basically my second head isn't getting a signal, even though mergedfb is enabled. I would greatly appreciate any advice you can offer. Thanks -David Smith -- 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. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
--- Linus Torvalds <[EMAIL PROTECTED]> wrote: > Quite frankly, I'd much rather see a low-level graphics driver that does > _two_ things, and those things only: > > - basic hardware enumeration and setup (and no, "basic setup" does not >mean "mode switching": it literally means things like doing the >pci_enable_device() stuff. > > - serialization and arbitrary command queuing from a _trusted_ party (ie >it could take command lists from the X server, but not from untrusted >clients). This part basically boils down to "DMA and interrupts". This >is the part that allows others to wait for command completion, "enough >space in the ring buffers" etc. But it does _not_ know or care what the >commands are. > > Then, fbcon and DRI and X could all three use these basics - and they'd be > _so_ basic that the hardware layer could be really stable (unlike the DRI > code that tends to have to upgrade for each new type of command that DRI > adds - since it has to take care of untrusted clients. So DRI would > basically use the low-level driver as a separate module, the way it > already uses AGP). > Linus, why don't you refuse updates from these projects until this is sorted out? Your proposal is exactly what it needed. For a year now I have been poking at these issues and making very little progress. I do know that all of the pieces needed already exist; but without some incentive there is very little reason to rearchitect the existing code. Personally I'm working on a standalone version of Mesa (OpenGL). This would allow us to write a 3D hardware based windowing system in response to the ones on the Mac and MS Longhorn. But instead of working on a windowing system I've spent all of my time trying to help sort out the video device drivers. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Unable to get 3d working....
I am unable to get direct 3d rendering working. Not sure what info would help but... I am running the 2.6.0-test8 kernel, and XFree86 4.3.99.14. I have tried it with both the 2.6.0-test8 drm module and the one from xfree86 4.3.99.14 System: Dual Athlon-XP 2000+ on a Tyan Tiger MPX S2466N-4M motherboard with 512 Megs of ram, and a Radeon 8500 with 128 megs of ram. When I run glxinfo it reports - Direct rendering: No lsmod reports Module Size Used by radeon119980 0 agpgart32684 0 (II) Primary Device is: PCI 01:05:0 (II) ATI: Candidate "Device" section "Card0". (--) Chipset ATI Radeon 8500 QL (AGP) found (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:5:0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe1bd8000 (II) RADEON(0): [drm] mapped SAREA 0xe1bd8000 to 0x48278000 (II) RADEON(0): [drm] framebuffer handle = 0xe000 (II) RADEON(0): [drm] added 1 reserved context for kernel (WW) RADEON(0): [agp] AGP not available (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe1bd8000 at 0x48278000 (II) RADEON(0): Memory manager initialized to (0,0) (1600,8191) (II) RADEON(0): Reserved area from (0,1200) to (1600,1202) (II) RADEON(0): Largest offscreen area available: 1600 x 6989 Thanks CuZnDragon Robin Cook --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
On Sat, 25 Oct 2003, Egbert Eich wrote: > > Speaking of XFree86: when I developed the PCI resource stuff in > XFree86 I was trying to get support from kernel folks to get the > appropriate user space interfaces into the kernel. When I got > nowhere I decided to do everything myself. There won't be any "user space interfaces". There are perfectly good in-kernel interfaces, and anybody who needs them needs to be in kernel space. Ie the kernel interfaces are for kernel modules, not for user space accesses. The kernel module can be a simple interface layer like DRI, but the thing is, it needs to be specific to some kind of hardware. I refuse to have some kind of crap "user space driver" interface - drivers in user space are a mistake. > Is there any API that allows one to do this from user space? No. And I don't really see any huge reason for it. > There are plenty of XFree86 drivers around that don't have a > DRM kernel module and it should be possible to run those which > do without DRI support, therefore it would be a good if the > XFree86 driver could do this registration itself. If you do this, do it _right_. Look at what X really needs, and make a driver for it. A _real_ driver. Not just a half-hearted "we want to do things in user space, but we can't". Face it, a good graphics driver needs more than just "set up the ROM". It needs DMA access, and the ability to use interrupts. It needs a real driver. It basically needs something like what the DRI modules tend to do. I'd be really happy to have real graphics drivers in the kernel, but quite frankly, so far the abstractions I've seen have sucked dead donkeys through a straw. "fbcon" does way too much (it's not a driver, it's more a text delivery system and a mode switcher). And DRI is too complex and fluid to be a good low-level driver. Quite frankly, I'd much rather see a low-level graphics driver that does _two_ things, and those things only: - basic hardware enumeration and setup (and no, "basic setup" does not mean "mode switching": it literally means things like doing the pci_enable_device() stuff. - serialization and arbitrary command queuing from a _trusted_ party (ie it could take command lists from the X server, but not from untrusted clients). This part basically boils down to "DMA and interrupts". This is the part that allows others to wait for command completion, "enough space in the ring buffers" etc. But it does _not_ know or care what the commands are. Then, fbcon and DRI and X could all three use these basics - and they'd be _so_ basic that the hardware layer could be really stable (unlike the DRI code that tends to have to upgrade for each new type of command that DRI adds - since it has to take care of untrusted clients. So DRI would basically use the low-level driver as a separate module, the way it already uses AGP). But I'm _not_ interested in some interfaces to let user mode just bypass the kernel. Because they will not solve any of the other problems that clearly _do_ need solving, and if the X server continues to believe that it can just access the hardware directly, it will never play well together with projects like fbcon/dri. Linus --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
Linus Torvalds writes: > > could lead to problems with hotplug. XFree is also mapping PCI ROMs in without > > informing the kernel and that can definitely cause problems. > > Absolutely. Changing PCI configurations without telling the kernel _will_ > cause problems. Especially for hotplug systems, but it's also very iffy to > do if the card is behind a PCI bridge, since you have to take bridge > resources into account (and know which bridges are transparent, which are > not, etc etc). Speaking of XFree86: when I developed the PCI resource stuff in XFree86 I was trying to get support from kernel folks to get the appropriate user space interfaces into the kernel. When I got nowhere I decided to do everything myself. XFree86 does PCI bridge tracking and one reason it does this is PCI ROM mapping. > > The kernel spends a lot of effort on getting this right, and even so it > fails every once in a while (devices that use IO or memory regions without > announcing them in the standard BAR's are quite common, and the kernel has > to have special quirk entries for things like that). Right. One reason why the PCI code in XFree86 looks so difficult is that old ATi Mach?? cards had their 8514 registers (and their mirror images) scattered all over the PIO space. > > Few enough drivers actually want to enable the roms, but the code should > look something like > > /* Assign space for ROM resource if not already assigned. Ugly. */ > if (!pci_resource_start(dev, PCI_ROM_RESOURCE)) > if (pci_assign_resource(dev, PCI_ROM_RESOURCE) < 0) > return -ENOMEM; [Stuff deleted] . Is there any API that allows one to do this from user space? There are plenty of XFree86 drivers around that don't have a DRM kernel module and it should be possible to run those which do without DRI support, therefore it would be a good if the XFree86 driver could do this registration itself. Cheers, Egbert. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: new 2048 limit code...
I'll give keith's suggestion a shot, but I don't really understand how it's supposed to work. I'm not really much of an expert when it comes to the 3D driver. If someone could give me some pointers as to where to look and maybe a 500 foot description of how it should work, I'll see what I can come up with. Also, regarding the rendering errors at 2048, I looked at the clearing code in the DRM, but nothing really seemed amiss. I don't see why it would work at resolutions up to 2047, but not at 2048. Does anyone else have thoughts on that? Alex --- Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Fri, 2003-10-24 at 23:39, Mike A. Harris wrote: > > On Fri, 24 Oct 2003, Alex Deucher wrote: > > ... > > Why doesn't somebody implement one of the discussed workarounds in > the > 3D drivers? :) > __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
On Fri, 2003-10-24 at 16:15, Alex Deucher wrote: > The question is, can we start ripping it out now, or will there be a > xfree86 4.5 and 4.6, etc. Until there's an official roadmap for 5.x, I'd assume the next release to be 4.x. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: new 2048 limit code...
On Fri, 2003-10-24 at 23:39, Mike A. Harris wrote: > On Fri, 24 Oct 2003, Alex Deucher wrote: > > >Unless anyone says otherwise, I'm going to remove this code. All it > >has done is generate complaints from MergedFB users. Apparently it > >doesn't hurt anything (ie. cause a crash) to leave direct rendering > >enabled if the virtual desktop is larger than 2048. Since MergedFB > >users seem to be the only ones running into it, I don't see this > >affecting regular DRI users. I will put a warning in the code if the > >virtual res is larger than 2048 to let them know that they may run into > >issues. > > My suggestion would be to make it a config file option defaulting > to the current behaviour. That way users who don't know any > better get 3D working full desktop, but get an error/warning to > the log file if their resolution goes beyond what is supported. > Users who know what they're doing and want 3D on part of the > desktop anyway can force enable it. I suspect they could as well just disable the check in the source... Why doesn't somebody implement one of the discussed workarounds in the 3D drivers? :) -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
On Fri, Oct 24, 2003 at 06:57:18PM +0200, Petr Vandrovec wrote: > We need something more sophisticated. Matrox's hardware has bits > 31-16 readable/writable only if bit 0 is set to 1 (ROM enabled; you can > (obviously) set bits 31-16 & 0 in one write). When ROM is disabled, > bits 31-1 are always read as 0. Hmm, I believe it's not true at least for Mystique, Millennium II and G400. Otherwise we wouldn't be able to determine ROM size/alignment as we do probe with ROM disabled (probe.c, line 125): pci_write_config_dword(dev, rom, ~PCI_ROM_ADDRESS_ENABLE); pci_read_config_dword(dev, rom, &sz); Ivan. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
On Fri, Oct 24, 2003 at 11:34:04AM -0700, Jon Smirl wrote: > PCI ROM enabale/disable has come up before on LKML. Russell made this comment > about making the code more portable. > > --- Russell King <[EMAIL PROTECTED]> wrote: > > You should use pcibios_resource_to_bus() to convert a resource to a > > representation suitable for a BAR. pci_assign_resource() does call pcibios_resource_to_bus(), so Linus' proposal will work correctly as it is. Ivan. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri-solo?
I saw a few references to "dri-solo" on the mesa list, but didnt get to read much on what it actually is. What is it supposed to be? I grepped through some of the recent dri-devel IRC logs, but didnt see anything there either. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
On Fri, Oct 24, 2003 at 09:44:38AM -0700, Linus Torvalds wrote:
>
> On Thu, 23 Oct 2003, Jeff Garzik wrote:
>
> > /* Assign space for ROM resource if not already assigned. Ugly. */
> > if (!pci_resource_start(dev, PCI_ROM_RESOURCE))
> > if (pci_assign_resource(dev, PCI_ROM_RESOURCE) < 0)
> > return -ENOMEM;
> >
> > /* Enable it. This is too ugly */
> > if (!(pci_resource_flags(dev, PCI_ROM_RESOURCE) & PCI_ROM_ADDRESS_ENABLE)) {
> > u32 val;
> > pci_read_config_dword(dev, PCI_ROM_ADDRESS, &val);
> > val |= PCI_ROM_ADDRESS_ENABLE;
> > pci_write_config_dword(dev, PCI_ROM_ADDRESS, val);
> > pci_resource_flags(dev, PCI_ROM_RESOURCE) |= PCI_ROM_ADDRESS_ENABLE;
> > }
>
> over and over again _is_ going to cause us problems later. Either we'll
> change some interface slightly (and have to fix up the drivers), or a
We need something more sophisticated. Matrox's hardware has bits
31-16 readable/writable only if bit 0 is set to 1 (ROM enabled; you can
(obviously) set bits 31-16 & 0 in one write). When ROM is disabled,
bits 31-1 are always read as 0.
> So wouldn't it be nice if we just had those ten lines as a generic
> function like
>
> int pci_enable_rom(struct pci_device *dev)
> {
> ...
>
> int pci_disable_rom(..);
It would be nice if it works... For matrox hardware I have to map ROM
over framebuffer (it is solution recommended by datasheet), as there is
no way to get memory range allocated for ROM unless ROM was left enabled
all the time.
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
---
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
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=314 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- 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. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Wrong default value for RADEON_TCL_FORCE_DISABLE
In the Radeon driver, TCL is currently enabled by default. However, it seems like there is no guarantee that the same set of vertices will be transformed equally twice, so you get Z buffer artifacts when doing multipass rendering. I am told that the DRI developers believes this is not a bug, because you should use glPolygonOffset when doing multipass rendering. This is wrong. glPolygonOffset is used when you wish to render polygons in the same plane as previously rendered polygons using _different_ vertices than those of the previously rendered polygons. However, if you render two polygons with exactly the same vertices, the pixels of both polygons should have exactly the same Z values. glDepthFunc(GL_EQUAL) becomes pointless with the current behavior. This tutorial at SGI describes multipass rendering without mentioning glPolygonOffset, but recommending the use of glDepthFunc(GL_EQUAL): http://www.sgi.com/software/opengl/advanced97/notes/node67.html This extension specification also uses glDepthFunc(GL_EQUAL) to perform multipass rendering: http://oss.sgi.com/projects/ogl-sample/registry/ARB/occlusion_query.txt Hence TCL must either be disabled by default, or it must be used consistently. -- Morten Hustveit, http://www.ping.uio.no/~mortehu/ --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon DRM memory layout transition
The question is, can we start ripping it out now, or will there be a
xfree86 4.5 and 4.6, etc.
Alex
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Jens Owen wrote:
>
> > We can definitely remove the xf86drmCompat layer for XFree86 5.0.
> I
> > believe it's well understood that major version changes will break
> > existing binary interfaces.
>
> Oh goodie! There's a whole ton of crap that will get ripped out of
> lib/GL/glx/glx{cmds,ext}.c then! All of the stuff for determining if
>
> the client-side driver supports glcontextmodes and bindContext2 /
> unbindContext2 will go bye-bye. :) This is the best news I've heard
> all
> day...
>
>
>
>
> ---
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community? Make a contribution, and help us add new
> features and functionality. Click here:
> http://sourceforge.net/donate/
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-develceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---
This SF.net email is sponsored by: The SF.net Donation Program.
Do you like what SourceForge.net is doing for the Open
Source Community? Make a contribution, and help us add new
features and functionality. Click here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
