Re: [Dri-devel] Radeon scratch register writeback patch
On Mon, 2002-07-15 at 05:21, Jens Owen wrote: Michel Dänzer wrote: On Sun, 2002-07-14 at 15:36, Keith Whitwell wrote: Michel Dänzer wrote: On Fri, 2002-07-12 at 14:56, Keith Whitwell wrote: Looks good, but I think I've got an even better patch: http://www.penguinppc.org/~daenzer/DRI/radeon-nommio.diff I've moved the initialization and put the scratch registers right behind the ring read pointer, this should work with PCI GART and all kinds of AGP GART. I'll commit this now. This looks ok. The one thing I'd say is that we've added functionality to the kernel module, so we should bump the minor version number (ie 1.4.0) -- this means that you can test rmesa-drm.minor (or whatever) instead of firing off the ioctl checking for EINVAL. Bumping the minor strikes me as overkill for this. It's not a new ioctl or something. What about the attached patch? It's a change to the interface -- an extension. It doesn't matter that it's not a new ioctl, this is exactly what bumping the minor number is supposed to do. Bumping the minor number is free - it doesn't cost anything or break anything. One thing that we haven't really made clear is when a 'release' is. However, given that 1.3 is in the 2.5 kernel sources, I'd say wherever the line is, we've crossed it. So - bump the minor don't worry too much. You're the boss. :) Changed and committed. Michel, Please don't think of Keith as being heavy handed. I don't, I was just joking. His suggestion is exactly what we need to do in order to preserve compatability. I understand that. Thanks for working with us on this issue. Thanks for guiding me. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Secrets of the professionals.
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00D1_78C51E0B.A0068B70
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
Hi José, I got a similar error with your patch applied. On stdout I get the usual Error flushing vertex buffer: return = -11 but the log looks different: Jul 15 13:01:11 viking kernel: [drm] AGP 0.99 on VIA Apollo KT133 @ 0xd000 64MB Jul 15 13:01:11 viking kernel: [drm] Initialized mach64 1.0.0 20020417 on minor 0 Jul 15 13:01:12 viking kernel: [drm] Creating pci pool Jul 15 13:01:12 viking kernel: [drm] Allocating descriptor table memory Jul 15 13:01:12 viking kernel: [drm] descriptor ring: cpu addr 0xc051c000, bus addr: 0x0051c000 Jul 15 13:01:12 viking kernel: [drm] Starting DMA test... Jul 15 13:01:12 viking kernel: [drm] starting DMA transfer... Jul 15 13:01:12 viking kernel: [drm] waiting for idle... Jul 15 13:01:12 viking kernel: [drm] waiting for idle...done Jul 15 13:01:12 viking kernel: [drm] DMA test succeeded, using asynchronous DMA mode Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] ring contents: Jul 15 13:04:02 viking kernel: [drm] head_addr: 0x0051d650 head: 1428 tail: 1944 Jul 15 13:04:02 viking kernel: Jul 15 13:04:02 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd001c000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] 0x0051d620: 0x007ffe48 0xd0098000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d630: 0x007ffe48 0xd018 0x40d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d640: 0x007ffe48 0xd013 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d650: 0x007ffe48 0xd01b4000 0x4dd0 0x (head) Jul 15 13:04:02 viking kernel: [drm] 0x0051d660: 0x007ffe48 0xd0054000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d670: 0x007ffe48 0xd00bc000 0x40d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051d680: 0x007ffe48 0xd0084000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] 0x0051de30: 0x007ffe48 0xd008c000 0x40d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de40: 0x007ffe48 0xd018 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de50: 0x007ffe48 0xd0098000 0xc0d0 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de60: 0x007ffe48 0xd00dc000 0x4068 0x (tail) Jul 15 13:04:02 viking kernel: [drm] 0x0051de70: 0x007ffe48 0xd00d4000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de80: 0x007ffe48 0xd01ec000 0x4270 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051de90: 0x007ffe48 0xd001c000 0x4048 0x Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:04:02 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] buffer contents: Jul 15 13:04:02 viking kernel: [drm] d01b4000: 0x00060190 Jul 15 13:04:02 viking kernel: [drm] d01b4004:0x0240 = 0x3d806d0d Jul 15 13:04:02 viking kernel: [drm] d01b4008:0x0244 = 0xbcc71574 Jul 15 13:04:02 viking kernel: [drm] d01b400c:0x0248 = 0x3b9f445d Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4454:0x0840 = 0x3d9f677c Jul 15 13:04:02 viking kernel: [drm] d01b4458:0x0844 = 0xbc78d3d8 Jul 15 13:04:02 viking kernel: [drm] d01b445c:0x0848 = 0x3bc179a8 Jul 15 13:04:02 viking kernel: [drm] d01b4460:0x084c = 0xff10 Jul 15 13:04:02 viking kernel: [drm] d01b4464:0x0850 = 0xfee88000 Jul 15 13:04:02 viking kernel: [drm] d01b4468:0x0854 = 0xffcc Jul 15 13:04:02 viking kernel: [drm] d01b446c:0x0858 = 0x07a203ff Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4dc4:0x11b0 = 0x053d03df Jul 15 13:04:02 viking kernel: [drm] d01b4dc8:0x11b4 = 0x01c0 Jul 15 13:04:02 viking kernel: [drm] d01b4dcc:0x11b8 = 0xbb9a4b09 Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm]BM_GUI_TABLE = 0x0051d660 Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ffe48 Jul 15 13:04:02 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0xd01b4460 Jul 15 13:04:02 viking kernel: [drm] BM_COMMAND = 0x4970 Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] BM_STATUS = 0x130060ca Jul 15 13:04:02 viking kernel: [drm]BUS_CNTL = 0x7b3fa011 Jul 15 13:04:02 viking
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
I tried restarting torcs after the last problem and it locked up the Xserver. I got something in the log before I rebooted: Jul 15 13:16:48 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] ring contents: Jul 15 13:16:48 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:48 viking kernel: Jul 15 13:16:48 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:48 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:48 viking kernel: [drm] ... Jul 15 13:16:48 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x (head) Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm]BM_GUI_TABLE = 0x0051c000 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 15 13:16:48 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051c000 Jul 15 13:16:48 viking kernel: [drm] BM_COMMAND = 0x4000 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] BM_STATUS = 0x930860ca Jul 15 13:16:48 viking kernel: [drm]BUS_CNTL = 0x7b3fa011 Jul 15 13:16:48 viking kernel: [drm] FIFO_STAT = 0x Jul 15 13:16:48 viking kernel: [drm]GUI_STAT = 0x0181 Jul 15 13:16:48 viking kernel: [drm]SRC_CNTL = 0x0f00 Jul 15 13:16:48 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle failed BM_GUI_TABLE=0x0051c000 tail: 4 Jul 15 13:16:50 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] ring contents: Jul 15 13:16:50 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:50 viking kernel: Jul 15 13:16:50 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:50 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:50 viking kernel: [drm] ... Jul 15 13:16:50 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:16:50 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x (head) Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm]BM_GUI_TABLE = 0x0051c000 Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 15 13:16:50 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051c000 Jul 15 13:16:50 viking kernel: [drm] BM_COMMAND = 0x4000 Jul 15 13:16:50 viking kernel: [drm] Jul 15 13:16:50 viking kernel: [drm] BM_STATUS = 0x930860ca Jul 15 13:16:50 viking kernel: [drm]BUS_CNTL = 0x7b3fa011 Jul 15 13:16:50 viking kernel: [drm] FIFO_STAT = 0x Jul 15 13:16:50 viking kernel: [drm]GUI_STAT = 0x0181 Jul 15 13:16:50 viking kernel: [drm]SRC_CNTL = 0x0f00 Jul 15 13:16:50 viking kernel: [drm:mach64_do_dma_idle] *ERROR* mach64_do_dma_idle failed BM_GUI_TABLE=0x0051c000 tail: 4 Jul 15 13:16:52 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:52 viking kernel: [drm] Jul 15 13:16:52 viking kernel: [drm] ring contents: Jul 15 13:16:52 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:52 viking kernel: Jul 15 13:16:52 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x Jul 15 13:16:52 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:52 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:52 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:52 viking kernel: [drm] ... Jul 15 13:16:52 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Mon, Jul 15, 2002 at 01:16:37PM +0200, Felix Kühling wrote: Hi José, I got a similar error with your patch applied. On stdout I get the usual Error flushing vertex buffer: return = -11 but the log looks different: Yes, it's a different problem this time - the engine locked hard. [...] Jul 15 13:04:02 viking kernel: [drm] Jul 15 13:04:02 viking kernel: [drm] buffer contents: Jul 15 13:04:02 viking kernel: [drm] d01b4000: 0x00060190 Jul 15 13:04:02 viking kernel: [drm] d01b4004:0x0240 = 0x3d806d0d Jul 15 13:04:02 viking kernel: [drm] d01b4008:0x0244 = 0xbcc71574 Jul 15 13:04:02 viking kernel: [drm] d01b400c:0x0248 = 0x3b9f445d Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4454:0x0840 = 0x3d9f677c Jul 15 13:04:02 viking kernel: [drm] d01b4458:0x0844 = 0xbc78d3d8 Jul 15 13:04:02 viking kernel: [drm] d01b445c:0x0848 = 0x3bc179a8 Jul 15 13:04:02 viking kernel: [drm] d01b4460:0x084c = 0xff10 Jul 15 13:04:02 viking kernel: [drm] d01b4464:0x0850 = 0xfee88000 Jul 15 13:04:02 viking kernel: [drm] d01b4468:0x0854 = 0xffcc Jul 15 13:04:02 viking kernel: [drm] d01b446c:0x0858 = 0x07a203ff Jul 15 13:04:02 viking kernel: [drm] ... Jul 15 13:04:02 viking kernel: [drm] d01b4dc4:0x11b0 = 0x053d03df Jul 15 13:04:02 viking kernel: [drm] d01b4dc8:0x11b4 = 0x01c0 Jul 15 13:04:02 viking kernel: [drm] d01b4dcc:0x11b8 = 0xbb9a4b09 These values on the left side are absurd - the DMA buffer is busted. This means that either invalid data was generated or it was overwritten. I vote for the former (attending the new vertex template code may be buggy somewhere). [...] I think its just a coincident that it happend so soon after the server start, since I tested it a lot last night and nothing happened. Yes. It's most definetly an unrelated problem. [...] One more thing, I'm going home for at least four weeks on wednesday, so I won't be able to do any more testing then. And when I get back I will most probably upgrade to a Xpert 2000 Pro. So if there is any other patch you want me to test, there is not much time left. Ok, I'll contact you if make any advances here. hmm.. ATI Xpert 2000 Pro? That's an R128... I'm sad we won't be able to count with you anymore for the Mach64 development, but I hope you still keep your insterest on the DRI development. Thanks for all the help you've given, Felix! José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
On Mon, Jul 15, 2002 at 01:26:58PM +0200, Felix Kühling wrote: I tried restarting torcs after the last problem and it locked up the Xserver. I got something in the log before I rebooted: Jul 15 13:16:48 viking kernel: [drm] mach64_ring_idle failed! GUI_STAT=0x0181 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] ring contents: Jul 15 13:16:48 viking kernel: [drm] head_addr: 0x0051fff0 head: 4092 tail: 4 Jul 15 13:16:48 viking kernel: Jul 15 13:16:48 viking kernel: [drm] 0x0051c000: 0x007ffe48 0xd01b4000 0xc070 0x ^^ Jul 15 13:16:48 viking kernel: [drm] 0x0051c010: 0x007ffe48 0xd0118000 0x4770 0x (tail) Jul 15 13:16:48 viking kernel: [drm] 0x0051c020: 0x007ffe48 0xd0028000 0x4048 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051c030: 0x007ffe48 0xd01e 0x47f8 0x Jul 15 13:16:48 viking kernel: [drm] ... Jul 15 13:16:48 viking kernel: [drm] 0x0051ffc0: 0x007ffe48 0xd016c000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffd0: 0x007ffe48 0xd00dc000 0x4c30 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051ffe0: 0x007ffe48 0xd00d4000 0x4068 0x Jul 15 13:16:48 viking kernel: [drm] 0x0051fff0: 0x007ffe48 0xd01ec000 0x43fc 0x (head) Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm]BM_GUI_TABLE = 0x0051c000 Jul 15 13:16:48 viking kernel: [drm] Jul 15 13:16:48 viking kernel: [drm] BM_FRAME_BUF_OFFSET = 0x007ff980 Jul 15 13:16:48 viking kernel: [drm] BM_SYSTEM_MEM_ADDR = 0x0051c000 The engine locked while looping around the ring, reading the first entry. My guess is that the engine was already busted somehow... Jul 15 13:16:48 viking kernel: [drm] BM_COMMAND = 0x4000 Jul 15 13:16:48 viking kernel: [drm] [...] José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Fw: Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11
Oops, forgot to copy this one to the list... Begin forwarded message: Date: Mon, 15 Jul 2002 15:09:17 +0200 From: Felix Kühling [EMAIL PROTECTED] To: José Fonseca [EMAIL PROTECTED] Subject: Re: [Dri-devel] Mach64: Error flushing vertex buffer: return = -11 On Mon, 15 Jul 2002 12:56:33 +0100 José Fonseca [EMAIL PROTECTED] wrote: On Mon, Jul 15, 2002 at 01:16:37PM +0200, Felix Kühling wrote: [...] One more thing, I'm going home for at least four weeks on wednesday, so I won't be able to do any more testing then. And when I get back I will most probably upgrade to a Xpert 2000 Pro. So if there is any other patch you want me to test, there is not much time left. Ok, I'll contact you if make any advances here. hmm.. ATI Xpert 2000 Pro? That's an R128... I'm sad we won't be able to count with you anymore for the Mach64 development, but I hope you still keep your insterest on the DRI development. Thanks for all the help you've given, Felix! I will definitely keep my interest in DRI development. And I have to thank you and Leif. José Fonseca Bye, Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Microsoft IP claims over OpenGL
José Fonseca wrote: Microsoft has been progressively claiming IP ownership of parts of the OpenGL API. (See http://news.zdnet.co.uk/story/0,,t269-s2118968,00.html) Although the parts they claim are things like vertex programming - features that aren't present in older cards such as Mach64 -, it seems obvious that these are features very important in the current and next generation of graphics cards. Vertex programming is in the latest Mesa code (I implemented GL_NV_vertex program over the winter/spring). It'll be available to all DRI drivers when the DRI gets Mesa 4.1. NVIDIA gave me permission to implement the extension in software only. But since that time, NVIDIA has announced basically unrestricted permission to implement GL_NV_vertex_program. I'll have to talk to them again someday regarding future DRI hardware implementations. I would like to know your opinion about the influence this may have for the DRI and Mesa3D projects in particular, and for the OpenGL API in general. I consider myself a programmer and not a spokesperson for open-source, intellectual property, patent issues, or anything else. It's something I'd rather just avoid. But I guess it's something that I have to deal with to some extent. I don't have any deep insight into what Microsoft's actions will mean for OpenGL or Mesa. Other people are much better at analyzing the situation and deducing the potential impact. My time is best spent writing code. But like everyone else, I'm worried about Microsoft's recent actions. I love working with OpenGL and don't want to see it strangled by anyone or anything. OpenGL still has a HUGE user base spanning everyone from ISVs, to researchers, to educators, to hobbyists. If Microsoft really takes action to kill OpenGL I'd hope that the uproar and ill-will generated by such a move would convince them to back off. -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Microsoft IP claims over OpenGL
[resending with corrected email address typo] José Fonseca wrote: Microsoft has been progressively claiming IP ownership of parts of the OpenGL API. (See http://news.zdnet.co.uk/story/0,,t269-s2118968,00.html) Although the parts they claim are things like vertex programming - features that aren't present in older cards such as Mach64 -, it seems obvious that these are features very important in the current and next generation of graphics cards. Vertex programming is in the latest Mesa code (I implemented GL_NV_vertex program over the winter/spring). It'll be available to all DRI drivers when the DRI gets Mesa 4.1. NVIDIA gave me permission to implement the extension in software only. But since that time, NVIDIA has announced basically unrestricted permission to implement GL_NV_vertex_program. I'll have to talk to them again someday regarding future DRI hardware implementations. I would like to know your opinion about the influence this may have for the DRI and Mesa3D projects in particular, and for the OpenGL API in general. I consider myself a programmer and not a spokesperson for open-source, intellectual property, patent issues, or anything else. It's something I'd rather just avoid. But I guess it's something that I have to deal with to some extent. I don't have any deep insight into what Microsoft's actions will mean for OpenGL or Mesa. Other people are much better at analyzing the situation and deducing the potential impact. My time is best spent writing code. But like everyone else, I'm worried about Microsoft's recent actions. I love working with OpenGL and don't want to see it strangled by anyone or anything. OpenGL still has a HUGE user base spanning everyone from ISVs, to researchers, to educators, to hobbyists. If Microsoft really takes action to kill OpenGL I'd hope that the uproar and ill-will generated by such a move would convince them to back off. -Brian --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Learn the secrets how wealthy people make money and get a FREE EURO. 6424ZTfI5-499ocTc691-19
Warning Unable to process data: multipart/mixed;boundary==_NextPart_000_00C6_02A34B6A.B1708C70
Re: [Dri-devel] Radeon scratch register writeback patch
On Thursday 11 Jul 2002 9:25 pm, Michel Dänzer scribed numinously: PS: Sorry if you wasted time on this. I worked on it on Monday but haven't gotten around to finish it until now, and I thought you didn't have time to work on it this week. I was mucking around moving things over to the new os-independent stuff anyway, so no more than 10 minutes wasted :-) I'm back to probing at the lockup now that I have my hacking space back. I'll post the WAIT_UNTIL_3D_IDLE version in a minute so there's a fix while I try to understand the true problem more. Heh. My boss is in the country tomorrow. Maybe I can convince him to let me spend time on this at work dreams... -- Tim Smith ([EMAIL PROTECTED]) SMALL ADS: WANTED for treason, arson and insurrection. Reasonable rates. Apply within. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Merged trunk into r200 branch
I've merged the trunk into the r200 branch. It seems to work fine, but I've changed test machines so I can't compare performance -- so yell if there's a big change. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Mon, Jul 15, 2002 at 09:25:18PM +0100, Tim Smith wrote: I'm back to probing at the lockup now that I have my hacking space back. I'll post the WAIT_UNTIL_3D_IDLE version in a minute so there's a fix while I try to understand the true problem more. Heh. My boss is in the Which lockup is this? Which files in CVS should I watch for your commit? I've been scratching at the switch-to-vt-and-back freeze for a few days, but am a bit out of my depth with this source. Thanks for any information, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Binary packages (Was: Re: [Dri-devel] R200 testing)
On Sunday 14 July 2002 16:15, José Fonseca wrote: On Sun, Jul 14, 2002 at 07:42:36AM -0600, Keith Whitwell wrote: Next, tuxracer ran, but the menus were basically unusable. Sounds like he hit a whack of software fallbacks - frame rate on menus must have been less than 1fps. He didn't have the patience to get into the game. this happens to me as well, but only if i restart the system after installing the beta r200 driver. Re-running the install.sh script solves the problem and the tuxracer menusystem is as fast as expected. I suspect this is a problem of default dri kernel modules not being overwritten (?), but the install reloads them properly. It's not a big issue though. Interesting. Jose, Alan, have you seen similar problems with the install scripts for other hardware? It sounds like the old radeon.o isn't getting overwritten/overridden. I guess the install script insmod's it explicitly? No. The install script loads the module with `modprobe radeon`, i.e., without the .o, so it should pick the installed one. What the install scripts additionally does is `modprobe agpgart`. Could it be that agpgart was forgotten to be added to /etc/modules.conf? It should read this way correctly: # agpgart is i386 only right now--- not true anylonger? pre-install mga /sbin/modprobe -k agpgart pre-install r128 /sbin/modprobe -k agpgart pre-install radeon /sbin/modprobe -k agpgart options agpgart agp_try_unsupported=1 -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science @home: [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: [Dri-devel] Microsoft IP claims over OpenGL
On Mon, Jul 15, 2002 at 02:10:06PM -0500, Stephen J Baker wrote: | The deal though is that (presuming MS really do own these rights) | they are talking in terms of LICENSING this IP to allow OpenGL | to continue to exist. Who would pay them to license it for | Linux? There may be ways to finesse this. People are talking about the possibilities, but I haven't seen a conclusion yet. Allen --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Radeon 7500 lockup workaround
Here's the workaround for the Radeon 7500 lockup. I won't dignify it by
calling it a fix until I've investigated the actual commands being sent and
determined whether there's a better way of fixing it.
--
Tim Smith ([EMAIL PROTECTED])
Imperial Royal Guard foils attempted theft of Palpatine's left leg. I'm
hopping mad! says Emperor.
Index: xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c
===
RCS file: /cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c,v
retrieving revision 1.3
diff -u -3 -p -r1.3 radeon_state.c
--- xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c 11 Jul 2002 20:31:12 - 1.3
+++ xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c 15 Jul 2002 20:40:07 -
@@ -1692,6 +1692,19 @@ static int radeon_emit_packet3_cliprect(
if ( i cmdbuf-nbox ) {
if (DRM_COPY_FROM_USER_UNCHECKED( box, boxes[i], sizeof(box) ))
return DRM_ERR(EFAULT);
+ /* FIXME The second and subsequent times round this loop, send a
+ * WAIT_UNTIL_3D_IDLE before calling emit_clip_rect(). This
+ * fixes a lockup on fast machines when sending several
+ * cliprects with a cmdbuf, as when waving a 2D window over
+ * a 3D window. Something in the commands from user space
+ * seems to hang the card when they're sent several times
+ * in a row. That would be the correct place to fix it but
+ * this works around it until I can figure that out - Tim Smith */
+ if ( i ) {
+BEGIN_RING( 2 );
+RADEON_WAIT_UNTIL_3D_IDLE();
+ADVANCE_RING();
+ }
radeon_emit_clip_rect( dev_priv, box );
}
@@ -1700,7 +1713,6 @@ static int radeon_emit_packet3_cliprect(
ADVANCE_RING();
} while ( ++i cmdbuf-nbox );
-
if (cmdbuf-nbox == 1)
cmdbuf-nbox = 0;
Re: Binary packages (Was: Re: [Dri-devel] R200 testing)
On Mon, Jul 15, 2002 at 10:35:46PM +0200, Dieter Nützel wrote: On Sunday 14 July 2002 16:15, José Fonseca wrote: [...] What the install scripts additionally does is `modprobe agpgart`. Could it be that agpgart was forgotten to be added to /etc/modules.conf? It should read this way correctly: # agpgart is i386 only right now --- not true anylonger? pre-install mga /sbin/modprobe -k agpgart pre-install r128 /sbin/modprobe -k agpgart pre-install radeon /sbin/modprobe -k agpgart options agpgart agp_try_unsupported=1 I really don't know much about modules.conf. Usually I just add lines like the ones below: below mach64 agpgart below radeon agpgart José Fonseca --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] IRC meeting reminder
The weekly DRI meeting is scheduled to start now. Anyone interested? -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon scratch register writeback patch
On Monday 15 Jul 2002 9:33 pm, Charl P. Botha scribed numinously: On Mon, Jul 15, 2002 at 09:25:18PM +0100, Tim Smith wrote: I'm back to probing at the lockup now that I have my hacking space back. I'll post the WAIT_UNTIL_3D_IDLE version in a minute so there's a fix while I try to understand the true problem more. Heh. My boss is in the Which lockup is this? Which files in CVS should I watch for your commit? I've been scratching at the switch-to-vt-and-back freeze for a few days, but am a bit out of my depth with this source. I'm almost certain they're unrelated - this is to say, I've not been able to provoke the switch-to-vt-and-back freeze on my system. The file is radeon_state.c; the lockup occurs when waving a 2D window over a very active 3D window, causing the redraw of the 3D window to occur in several smaller clipping rectangles rather than one big one. You need a quick(ish, by todays standards) system (e.g. Athlon 1200) and a heavy 3D app (e.g. the NeverWinter Nights toolset) to make it happen, though I did manage to make glxgears do it once. I'm pretty new at the source myself, so I post (small) patches here rather than apply them directly, so that wiser heads can hopefully stop me before I break anything... -- Tim Smith ([EMAIL PROTECTED]) Daleks are now an endangered species, and it is actually illegal not to let one exterminate you if it wants to. -- Dave's Web of Lies --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Segmentation fault with Radeon 7500 QW
I recently bought a Radeon 7500 64MB DDR (lovingly called a QW), and have had no luck with the DRI cvs trunk. 3D acceleration /does/ work, however, with xfree86 4.2 The problem is, whenever I run a 3d app, I get a segmentation fault. Running strace on said apps reveals that the segfault right after: old_mmap(NULL, 499712, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x44dcf000 Neither RADEON_NO_VTXFMT nor RADEON_NO_TCL fix the problem. Running with LIBGL_ALWAYS_INDIRECT, however, does. This is kernel 2.4.19-rc1, using the DRI cvs drm. I'm using the ATI framebuffer for console. Any ideas what the problem might be? -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell This concept of wuv confuses and infuriates us! -- Lur of Omicron Persei VIII --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Tribes 2 Lockups: Help me pinpoint the problem...
On Friday 12 Jul 2002 2:03 am, Daniel Kasak scribed numinously: Marc Poulhiès wrote: I know that closed source drivers from ati are not discussed here, but with my radeon 8500 and tribes2 i have exactly the same probleme. Maybe this is a probleme from tribes2 and not the dri :) Maybe. But it _used_ to work fine under xfree86 4.1.0 4.2.0. Has anyone had any success with Tribes 2 and the Radeon TCL drivers? Try the workaround patch I just posted. The initial symptoms I started chasing when I got my lockup were the same as yours (freelist_get returning NULL - not that that particular error message turned out to have much to do with the real problem, as was pointed out to me when I started wondering aloud about it). Possibly you're running into the same problem? -- Tim Smith ([EMAIL PROTECTED]) A fray -- Groo the Wanderer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64 multitexture bug
Here's a couple screenshots of the multitexture bug in quake3 lightmap mode (two slightly different angles): http://retinalburn.net/linux/q3a-bug1.jpg http://retinalburn.net/linux/q3a-bug2.jpg -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: mach64 multitexture bug
I saw a similar problem in torcs. First I thought it was just a problem with too little z-buffer accuracy. But when you look closely you see that the polygon is too bright. http://www.dd.chalmers.se/~kuhlfeli/torcsbug.jpg On Mon, 15 Jul 2002 19:08:29 -0400 (EDT) Leif Delgass [EMAIL PROTECTED] wrote: I forgot to mention that commenting out the fallback primitive functions didn't have an effect. On Mon, 15 Jul 2002, Leif Delgass wrote: Here's a couple screenshots of the multitexture bug in quake3 lightmap mode (two slightly different angles): http://retinalburn.net/linux/q3a-bug1.jpg http://retinalburn.net/linux/q3a-bug2.jpg -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]o__/ \___/ \___/at the same time! --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Mach64 : texture bug
Hi all, First of all, thank you to all the people involved in DRI project. I have an ATI Rage Mobility and I am very impressed by the result. I write to signal a bug. It's with the game 'Emilia pinball' http://pinball.sourceforge.net since the version 20020713 of the snapshot. It seems that some textures (circles) aren't drawn correctly. Here 2 screen captures, one in indirect mode (export LIBGL_ALWAYS_INDIRECT=1) and the other in mode DRI: http://people.easter-eggs.org/~valos/pinball_indirect.png http://people.easter-eggs.org/~valos/pinball_dri.png Bye, Valos msg06028/pgp0.pgp Description: PGP signature
Re: [Dri-devel] R200-0-1-branch devfs patch.
On Mon, 2002-07-15 at 23:15, Mike Mestnik wrote:
It was a copy/past job. I'm working on rewriting a lot of it, the main point of the
patch is to
get devfs working. The pci ids are only needed if there is more than one card(under
linux) and
the code was copied from BSD so I just assumed that things would work there also.
I'm going to rewrite the device struct to match the one expected by linux...
struct pci_device_id {
unsigned int vendor, device;/* Vendor and device ID or
PCI_ANY_ID */
unsigned int subvendor, subdevice; /* Subsystem ID's or PCI_ANY_ID */
unsigned int class, class_mask; /* (class,subclass,prog-if) triplet
*/
unsigned long driver_data; /* Data private to the driver */
};
1. There is no name feild.
The name field is nice on FreeBSD so people can see what actual device
it's attaching to, and so that when I get a (limited) bug report with a
dmesg I can see it easily. It might fit into driver_data, unless that's
reserved for something else in your scheme.
2. There is no suported flag, so DRM_SUP can go.
Well, it removes the ability for a platform to simply not have
__REALLY_HAVE_SG (for example, this was the case on FreeBSD for quite a
while, and might be the case on a new OS, too) and by doing that not
support the PCI versions of the cards. When we support alpha on
FreeBSD, we won't have AGP for it, so it would be nice to disable
support for the AGP cards from the PCI ids (so they don't get probed as
supported cards and then attach the DRM uselessly).
What does using that linux version of the struct do to improve Linux
support? (your other mail about it confused me).
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/dri/
---
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
