[Dri-devel] r200 in cvs broken?
Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything works as normal, and if I then reinstall cvs version it works until the next cold boot. I'm guessing something isn't being initialized correctly in current cvs. Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything works as normal, and if I then reinstall cvs version it works until the next cold boot. I'm guessing something isn't being initialized correctly in current cvs. Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log If you can track this down to an individual change, it will help a lot in terms of getting it resolved. Keith --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Thu, 2003-10-30 at 12:03, Keith Whitwell wrote: > Ronny V. Vindenes wrote: > > Something in the last week or two broke the r200 driver. After I cvs > > update'ed and recompiled yesterday, I get this error: > > > > (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 > > (EE) RADEON(0): GetBuffer timed out, resetting engine... > > (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 > > (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 > > > > and it gets stuck there repeating the error over and over (the first > > time it happened the log grew to almost 800mb before I noticed that > > something was wrong). > > > > > > The (cut down) log is here: > > http://www.lstud.ii.uib.no/~s864/XFree86.0.log > > If you can track this down to an individual change, it will help a lot in > terms of getting it resolved. OK, I'll take a closer look during the weekend. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: [...] Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. just wanted to let you know that current cvs works ok for me with a 8500LE. so it seems that not all r200 cards / configurations are affected. (athlon xp, 2.6.0-test8, crt connected to normal vga-port, not dvi) --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! 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...
Hopefully I'll have some time this weekend to look into this, what files in the r200 client driver should I be looking at? Having looked at the code I'm guessing r200_state. Scissor and cliprect stuff. Although thinking about it more, there are probably more changes required since I guess every part of the 3D pipeline must be updated (or at least where the commands are issued to the card) depending on which "2048 zone" the rendering falls into. Would it be better to make the solution more generic? I.e., introduce the concept of "zones" of cliprects, the extents of which would be determined based on the limitations of the hardware. the driver would then render based on zones. Maybe I'm overthinking it... Any other pointers? I'm sure I'll have more questions once I dig into it a bit more. Alex --- Keith Whitwell <[EMAIL PROTECTED]> wrote: > Michel Dänzer wrote: > > On Sat, 2003-10-25 at 17:25, Alex Deucher wrote: > > > >>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. > > > > > > AIUI (I trust in Keith correcting me if I'm clueless :), the 3D > drivers > > would divide the cliprects at multiples of 2048 and then iterate > over > > the divided zones when emitting rendering commands, adapting the > buffer > > offsets and viewport parameters for each zone (which wasn't > possible > > with my idea of doing the division in the server). > > Correct - I believe that you'd need to do this in the client. > > Keith > __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Thu, 2003-10-30 at 20:43, Ronny V. Vindenes wrote: > Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure > 32bit mode) with an lcd connected to dvi. > Just checked latest DRI CVS with my radeon 9000 PCI, no errors. I know it doesn't help but it might give you a better idea of where to look. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI sw only mode
ok, should of mentioned, its with the r200 driver, and confirmed again with the the cvs as of 30 mins ago. glXSwapBuffers segs GL applications if DRI is NOT enabled. Confirmed by recompiling glxgears with debugging and ran through gdb (see previous emails) --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI sw only mode
On Fri, 31 Oct 2003 17:42:34 +1000 Chris Ison <[EMAIL PROTECTED]> wrote: > ok, should of mentioned, its with the r200 driver, and confirmed again > with the the cvs as of 30 mins ago. > > glXSwapBuffers segs GL applications if DRI is NOT enabled. > > Confirmed by recompiling glxgears with debugging and ran through gdb > (see previous emails) Hmm, I can't reproduce this with my Radeon7500 and DRI disabled by not loading module dri in XF86Config-4. Seeing a backtrace after the segfault would be extremely helpful in locating the exact problem. Just type "bt" at the gdb prompt after the segfault. Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Combined vblank-waiting and buffer swapping
On Wed, 29 Oct 2003 10:19:20 -0800 Ian Romanick <[EMAIL PROTECTED]> wrote: > Felix Kühling wrote: > > > On Wed, 29 Oct 2003 08:56:09 -0800 > > Ian Romanick <[EMAIL PROTECTED]> wrote: > > > > > >>I also believe the #1 and #3 will require a bit of work in the > >>client-side driver. It would need to batch up commands and wait to > >>issue them. The problem is state changes. The driver usually knows the > >>current hardware state before issuing a command. Since commands are > >>just being queued, there's know way to know what the state will be when > >>they are actually issued. The queuing is done per-drawable, but state > >>is tracked per-context. I think that's solvable, but it will take some > >>work. > > > > So you want to do the queueing in user space? The scheduler that Keith > > and I were talking about would be in the kernel. I guess the user space > > approach would be easier to implement. The question is how you resume > > Buffering the commands in user space avoids having to do state switching > in the kernel, which is nice. It should also be faster in the common case. > > > submitting commands. You can't do it asynchronously while the > > application is computing physics or AI. But the next GL function call > > could trigger flushing queued commands. > > Right. That shouldn't be a problem, though. If the application is > computing physics or AI there won't be any commands to queue. :) I did > think of another "problem" case. What happens when the application > calls glXSwapBuffers while the previous swap is still pending? I'm > guessing that we'd sleep, flush out all the commands (for the whole > frame!), then issue the new swap. Queuing texture uploads would be > interesting... > > Basically, queuing commands while we wait for a swap to complete is like > building a display list. Maybe it would be easier to tackle the problem > from that point of view? When a swap is pending we'd "somehow" switch > to build-display list mode. When the swap completed we'd execute the > currently built display list and switch back to immediate mode. Dunno... Could we avoid queuing of commands with tripple buffering? Buffer 1 would be displayed. Buffer 2 has completed rendering and is waiting for its buffer swap. Now the application can continue rendering to buffer 3. When buffer 3 is finished before the swap for buffer 2 has happened then we can just throw away buffer 2 and continue rendering to buffer 2 while 3 is waiting. ... and so on. Cheers, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 704] Display freeze with Java3D and Radeon 9000
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=704 --- Additional Comments From [EMAIL PROTECTED] 2003-30-10 17:57 --- have you tried a recent DRI or xfree86 cvs snapshot? -- 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: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 704] Display freeze with Java3D and Radeon 9000
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=704 --- Additional Comments From [EMAIL PROTECTED] 2003-30-10 18:08 --- No. Sorry, I don't have the time to spend hours and hours in experiments. Using the application from http://www.3dchat.org offers a developer the possibility to reproduce this problem within minutes (comparing to hours I'd need). So I really don't know where the problem is with this REPRODUCEABLE bug. -- 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: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI sw only mode
> Hmm, I can't reproduce this with my Radeon7500 and DRI disabled by not > loading module dri in XF86Config-4. Seeing a backtrace after the > segfault would be extremely helpful in locating the exact problem. Just > type "bt" at the gdb prompt after the segfault. > > Regards, > Felix bt just returns Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 9445)] 0x in ?? () (gdb) bt #0 0x in ?? () (gdb) --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
Ronny V. Vindenes wrote: Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything works as normal, and if I then reinstall cvs version it works until the next cold boot. I'm guessing something isn't being initialized correctly in current cvs. Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log From the log, the card gets detected as a PCI card, but from the bus id I'd say it's a AGP card, is that true? In that case, it looks like the test for AGP/PCI doesn't work correctly. In radeon_driver.c, it says "Following detection method works for all cards tested so far." Guess your card is the first it doesn't :-( If that's the case, you can try to get it to work with "BusType" "AGP" in the XF86Config file. Though I'd have assumed that a AGP card detected as PCI should still work. Roland btw, the "ForcePCIMode" option (which is only there for compatibility reasons I guess) no longer works (I just tried it out to test if a AGP card forced to PCI would work). It will set the card type to pci, but that gets immediately overwritten by the agp/pci test so the log file says (**) RADEON(0): Forced into PCI mode (II) RADEON(0): AGP card detected I'd suggest just to remove that option, I guess there aren't really a lot of users using this, and those who do probably could figure out they should now use the "BusType" option instead. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI sw only mode
Chris Ison wrote: On Thu, 2003-10-30 at 17:08, Chris Ison wrote: I'm wondering what happened to the full sw mode for 3d you could use before when DRI wasn't enabled. Now GL apps just seg (including glxgears) where a few months ago you could still run them without DRI although very slow. Further investigation has shown glXSwapBuffer is the where the seg is coming from ... 164 glXSwapBuffers (x_disp, x_win); (gdb) p x_disp $1 = (Display *) 0x84514a0 (gdb) p x_win $2 = 31457282 (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) Do you get the same behavior if DRI is enabled, but you run with 'LIBGL_ALWAYS_INDIRECT=y'? Since the back trace isn't clean, it looks like there some stack corruption happening. I'll see if I can reproduce it tomorrow (I don't have access to an R200 at the moment), but I don't see this on an MGA. If DRI isn't loaded, it shouldn't matter what the hardware is. You might try stepping through glXSwapBuffers to see where it explodes. I suspect you have some thing built wrong or there's some sort of version incompatability. What's the rest of your system? There were some problems with recent libGL.so binaries and RedHat TLS enabled systems, but I *thought* those were fixed (they were all my fault anyway). --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Fri, 2003-10-31 at 00:43, Roland Scheidegger wrote: > Ronny V. Vindenes wrote: > > Something in the last week or two broke the r200 driver. After I cvs > > update'ed and recompiled yesterday, I get this error: > > > > (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 > > (EE) RADEON(0): GetBuffer timed out, resetting engine... > > (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 > > (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 > > > > and it gets stuck there repeating the error over and over (the first > > time it happened the log grew to almost 800mb before I noticed that > > something was wrong). > > > > Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything > > works as normal, and if I then reinstall cvs version it works until the > > next cold boot. I'm guessing something isn't being initialized correctly > > in current cvs. > > > > Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure > > 32bit mode) with an lcd connected to dvi. > > > > The (cut down) log is here: > > http://www.lstud.ii.uib.no/~s864/XFree86.0.log > > From the log, the card gets detected as a PCI card, but from the bus id > I'd say it's a AGP card, is that true? In that case, it looks like the > test for AGP/PCI doesn't work correctly. It is an AGP card, but the amd64-agp module in 2.6.0-test9 doesn't detect the VIA K8T800 chipset [1] (agpgart in 2.4.23-pre9 does detect it, but XFree86 still defaults to pcigart [2]). > In radeon_driver.c, it says "Following detection method works for all > cards tested so far." Guess your card is the first it doesn't :-( > If that's the case, you can try to get it to work with "BusType" "AGP" > in the XF86Config file. > Though I'd have assumed that a AGP card detected as PCI should still work. Setting "BusType" "AGP" makes no difference. Just to clarify, it is detected as PCI when using older working also. [1] I can get it to load by some hand tweaking of some of the tests in the module, but it still works no better than 2.4.23-pre9. [2] Someone with the same motherboard is seeing the same problem with agp not working: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107805 -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
I'll take a look at fixing this in the radeon driver. What needs to be done to play nice with the DRI? Alex --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote: > > Alan Hourihane ([EMAIL PROTECTED]): > > > > > Well, if someone else has a chip, or wants to update and test > other > > > drivers (but be careful with DRI enabled drivers as it needs more > work > > > in the driver). Here's a patch to the neomagic that should work, > and > > > could be used as a template for the other drivers. > > > > > > That's all. Most Xv (if not all) use linear allocation already > and will > > > take advantage of it straight away without any furthur > modifications. > > > > Alan, do you know if it would help with the Radeon driver, re bug > 830? > > > > http://bugs.xfree86.org/show_bug.cgi?id=830 > > Potentially - yes. But the DRI parts need a little more work to play > nicely with the Linear allocator. > > Alan. __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
I've actually already done it, but I'll probably leave it till after XFree86 4.4.0. Once 4.4.0 is out, I'll merge that into the DRI CVS and create a branch for this work I've been doing on the radeon with regard to dynamic allocation & the DRI. Alan. On Thu, Oct 30, 2003 at 07:36:42AM -0800, Alex Deucher wrote: > I'll take a look at fixing this in the radeon driver. What needs to be > done to play nice with the DRI? > > Alex > > --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote: > > > Alan Hourihane ([EMAIL PROTECTED]): > > > > > > > Well, if someone else has a chip, or wants to update and test > > other > > > > drivers (but be careful with DRI enabled drivers as it needs more > > work > > > > in the driver). Here's a patch to the neomagic that should work, > > and > > > > could be used as a template for the other drivers. > > > > > > > > That's all. Most Xv (if not all) use linear allocation already > > and will > > > > take advantage of it straight away without any furthur > > modifications. > > > > > > Alan, do you know if it would help with the Radeon driver, re bug > > 830? > > > > > > http://bugs.xfree86.org/show_bug.cgi?id=830 > > > > Potentially - yes. But the DRI parts need a little more work to play > > nicely with the Linear allocator. > > > > Alan. > > > __ > Do you Yahoo!? > Exclusive Video Premiere - Britney Spears > http://launch.yahoo.com/promos/britneyspears/ > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 10:59:41AM -0600, Billy Biggs wrote: > Alan Hourihane ([EMAIL PROTECTED]): > > > I've actually already done it, but I'll probably leave it till after > > XFree86 4.4.0. > > Regarding bug 830, does this mean my users can expect to sometimes hit > these situations where XVIDEO apps can't run until they shut down a > large application like their web browser? > > Don't take this the wrong way, I don't mind, I just want to understand > the situation so I can design appropriate error messages. Low memory situations should only happen when a 3D application is also running. I'm not sure why you'd be hitting it when it's not. Alan. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [XFree86] DRI weirdnesses for RADEON 9200
manu wrote:
Hi all,
before I open a bug for that I would like to sort out things a bit.
Here is the story : I installed a MDK 9.2, the agpgart module seems to
be OK with my mobo (which has a nForce2 Ultra chipset), so I went on
and try to make 3D accel work for my Radeon 9200. Whereas all logs were
OK, glxgears locks up hard (only hard reset could get me out of it). So
I asked on this list some help, and I have been advised to download
latest DRI snapshot, what I did, installed it with no problems. But
here is what I have now :
- glxgears crashes at startup here is the stacktrace (using the core
dumped) :
#0 0x in ?? ()
#1 0x4033eece in GetDRIDrawable () from /usr/X11R6/lib/libGL.so.1.2
#2 0x4033fd57 in glXSwapBuffers () from /usr/X11R6/lib/libGL.so.1.2
#3 0x4004abdf in glXSwapBuffers () from /usr/X11R6/lib/libGL.so.1
#4 0x0804a546 in XOpenDisplay ()
#5 0x401ccc57 in __libc_start_main () from /lib/i686/libc.so.6
- xawtv does not start and gives me these errors :
This is xawtv-3.88, running on Linux/i686 (2.4.22-10mdk)
Loading required GL library /usr/X11R6/lib/libGL.so.1.2
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 144 (GLX)
Minor opcode of failed request: 5 (X_GLXMakeCurrent)
Serial number of failed request: 307
Current serial number in output stream: 307
Someone on the dri-devel list reported something similar. Based on your
stacktrace, it looks like DRI is enabled on the display but not on the
screen. The crash seems to be because psc->getDrawable is NULL in
GetDRIDrawable. Do you have more than one screen on the display? The X
log doesn't seem to indicate so. It doesn't seem right that
psc->getDrawable should be NULL if DRI is enabled on a display and
there's only one screen. I'm also not sure how you get from
XOpenDisplay to glXSwapBuffers. Hmm...
So I ran glxinfo see below which told me that Direct Rendering is not
enabled! This is crazy as you can check in the XFree log (file attached).
Hope someone can tell me more about this, be it to file this directly
as a bug on bugzilla ;-)
I believe that you should file a bug against this, but also try the
attached patch. The patch should prevent calling the NULL function
pointer, but there may be other problems.
Index: lib/GL/glx/glxcmds.c
===
RCS file: /cvs/dri/xc/xc/lib/GL/glx/glxcmds.c,v
retrieving revision 1.65
diff -u -d -r1.65 glxcmds.c
--- lib/GL/glx/glxcmds.c23 Oct 2003 23:21:23 - 1.65
+++ lib/GL/glx/glxcmds.c31 Oct 2003 00:49:08 -
@@ -269,8 +269,8 @@
for ( i = 0 ; i < screen_count ; i++ ) {
__DRIscreen * const psc = &priv->screenConfigs[i].driScreen;
- __DRIdrawable * const pdraw = (*psc->getDrawable)(dpy, drawable,
- psc->private);
+ __DRIdrawable * const pdraw = (psc->private != NULL)
+ ? (*psc->getDrawable)(dpy, drawable, psc->private) : NULL;
if ( pdraw != NULL ) {
if ( scrn_num != NULL ) {
[Dri-devel] Re: [XFree86] Re: DRI weirdnesses for RADEON 9200
manu wrote: Le 30.10.2003 17:07:54, manu a écrit : So I ran glxinfo see below which told me that Direct Rendering is not enabled! This is crazy as you can check in the XFree log (file attached). Hope someone can tell me more about this, be it to file this directly as a bug on bugzilla ;-) Thanks Responding to myself : sorry it seems that the problem is because the r200_dri.so module is linked against libexpat.so.1 which is not on my system. So I just made a link to the one I had and all is working great now! glxgears gives me ~1535 FPS. Is it OK? (Radeon 9200 with 64MB). Thanks for the help, and sorry for eating the bandwidth ;-) Ah! Actually, thank you very much. :) The problem seems to be that with libexpat.so missing, there are unresolved symbols in r200_dri.so. The dlopen of r200_dri.so in OpenDriver (lib/GL/dri/dri_glx.c, line 184) fails. HOWEVER, it only logs a message if LIBGL_DEBUG is set. I removed libexpat from my system and was able to recreate the crash. With LIBGL_DEBUG set I get a nice message about not being able to open the driver. My person opinion is that the error messages in OpenDriver (but not the ones in GetDriverName) should be printed regardless of the setting of LIBGL_DEBUG. That would have helped find the source of this problem much sooner. We basically got lucky that Manu figured out that libexpat was missing for himself. :) --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
Alan Hourihane ([EMAIL PROTECTED]): > I've actually already done it, but I'll probably leave it till after > XFree86 4.4.0. Regarding bug 830, does this mean my users can expect to sometimes hit these situations where XVIDEO apps can't run until they shut down a large application like their web browser? Don't take this the wrong way, I don't mind, I just want to understand the situation so I can design appropriate error messages. -Billy > Once 4.4.0 is out, I'll merge that into the DRI CVS and create a branch > for this work I've been doing on the radeon with regard to dynamic > allocation & the DRI. > > Alan. > > On Thu, Oct 30, 2003 at 07:36:42AM -0800, Alex Deucher wrote: > > I'll take a look at fixing this in the radeon driver. What needs to be > > done to play nice with the DRI? > > > > Alex > > > > --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > > On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote: > > > > Alan Hourihane ([EMAIL PROTECTED]): > > > > > > > > > Well, if someone else has a chip, or wants to update and test > > > other > > > > > drivers (but be careful with DRI enabled drivers as it needs more > > > work > > > > > in the driver). Here's a patch to the neomagic that should work, > > > and > > > > > could be used as a template for the other drivers. > > > > > > > > > > That's all. Most Xv (if not all) use linear allocation already > > > and will > > > > > take advantage of it straight away without any furthur > > > modifications. > > > > > > > > Alan, do you know if it would help with the Radeon driver, re bug > > > 830? > > > > > > > > http://bugs.xfree86.org/show_bug.cgi?id=830 > > > > > > Potentially - yes. But the DRI parts need a little more work to play > > > nicely with the Linear allocator. > > > > > > Alan. > > > > > > __ > > Do you Yahoo!? > > Exclusive Video Premiere - Britney Spears > > http://launch.yahoo.com/promos/britneyspears/ > > ___ > > Devel mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/devel > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
