Re: [Dri-devel] trunk merge in mach64-0-0-5-branch is done
On Fri, 28 Jun 2002, José Fonseca wrote: > On Thu, Jun 27, 2002 at 04:35:16PM -0600, Brian Paul wrote: > [...] > > > >Just curious: do you guys have a plan for moving the mach64 code into the > >trunk? Are there any major issues that need to be resolved first? > > > > In my perspective the major issues missing are: > 1. Make sure the new DMA model works well in all configurations (at this > moment it seems that only PPC remains with problems) > 2. Vertex buffer template custumized to the Mach64 hardware format (this > isn't major but I wanted to work this first before addressing security, > because it can change radically how we do it, and I'm finishing it). > 3. The security - this is the real issue that must be addressed before a > merge with the trunk (and therefore, being ready for a release). I agree, and I'd add making 2D robust as another prerequisite. I'd like to squash the remaining VT switching bugs. Also, we need to implement cliprects for vertex dispatches to keep single-buffered GL windows from drawing on top of overlapping windows. Then, I think there are some remaining scissor/clipping bugs and conformance problems with glean tests that I'd like to fix. Other than that I think it'll mostly be code cleanup (remove old code paths). We can still do more optimizing, but I don't see that as a prerequisite to merging the branch into the trunk. Security and stability are the most important things. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SiS Specifications
Alex Deucher wrote: > I don't think the docs are much help with regard to 3D. there actually > is a working sis DRI driver for 300 series chips that can be found > here: > > http://www.winischhofer.net/linuxsis630.shtml > > perhaps it could be synced up to the current DRI tree. Alex, Somebody needs to step up and do the port. Nobody has been keeping the SiS 3D driver current. Are you volunteering? -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk merge in mach64-0-0-5-branch is done
On Thu, Jun 27, 2002 at 04:35:16PM -0600, Brian Paul wrote: [...] > >Just curious: do you guys have a plan for moving the mach64 code into the >trunk? Are there any major issues that need to be resolved first? > In my perspective the major issues missing are: 1. Make sure the new DMA model works well in all configurations (at this moment it seems that only PPC remains with problems) 2. Vertex buffer template custumized to the Mach64 hardware format (this isn't major but I wanted to work this first before addressing security, because it can change radically how we do it, and I'm finishing it). 3. The security - this is the real issue that must be addressed before a merge with the trunk (and therefore, being ready for a release). >BTW, I took a stab at updating the http://dri.sourceforge.net/doc/cvs.html >page which lists and describes the current CVS branches. > >The mach64 branch is described as: > > > This is the branch for the ATI Rage Pro driver development. The work is > > unfunded and is only just beginning, so a working driver is still a long >way > > off. Please do not ask when it will be complete. This branch also >contains some > > DRM architectural changes, designed to make writing new drivers easier and > > remove significant amounts of duplicated code. > >Maybe this should be updated. > Yep. This is way old (I think it refers to mach64-0-0-1-branch). José Fonseca --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: trunk merge in mach64-0-0-5-branch is done
On Thu, Jun 27, 2002 at 06:12:53PM -0400, Leif Delgass wrote: >OK, mach64-0-0-5-branch is open for your hacking and testing pleasure! Great Leif! >The trunk as of June 26 is merged in, so we now have Mesa 4.0.3 and I've >converted the mach64 driver to the drmCommand interface. The branch >compiles and works fine, and as a bonus, the bug with clears in the first >GL context seems to have vanished. :) Nice! (Less keypresses everytime I test the DRM!) >Jose, I think we can switch the binaries over to the new branch, everthing >seems to working fine. Ok. Done! José Fonseca --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Some bsd-3-0-0-branch benchmarks.
On Thu, 2002-06-27 at 15:46, Keith Whitwell wrote: > So, instead of DRM_OS_COPYFROMUSR_NC, maybe DRM_COPY_FROM_USER_UNCHECKED > might be clearer. > > Similarly, DRM_OS_KRNFROMUSR is pretty cryptic -- maybe > DRM_COPY_FROM_USER_IOCTL or something? > > Oh, and I just found DRM_OS_FETCHU_32_NC -- that's ugly... I > > How about: > > DRM_OS_COPYFROMUSR_NC > -- DRM_COPY_FROM_USER_UNCHECKED > DRM_OS_COPYFROMUSR-- DRM_COPY_FROM_USER > DRM_OS_KRNFROMUSR -- DRM_COPY_FROM_USER_IOCTL > DRM_OS_FETCHU_32_NC -- DRM_GET_USER_UNCHECKED > > and so on. Yeah, I thought the _NCs were ugly when I named them. I did that plus DRM_OS_IOCTL -> DRM_IOCTL_ARGS, DRM_OS_DELAY->DRM_OS_UDELAY, and killed DRM_OS_RETURN (not used in the os-independent code anyway). Do you know what's up with the i810 code in linux? It's complaining about not enough args to do_munmap_Rsmp_8fdbbff9. It would be nice to complete the whole drm building on Linux. -- Eric Anholt <[EMAIL PROTECTED]> http://gladstone.uoregon.edu/~eanholt/dri/ --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] trunk merge in mach64-0-0-5-branch is done
Leif Delgass wrote: > OK, mach64-0-0-5-branch is open for your hacking and testing pleasure! The > trunk as of June 26 is merged in, so we now have Mesa 4.0.3 and I've converted > the mach64 driver to the drmCommand interface. The branch compiles and works > fine, and as a bonus, the bug with clears in the first GL context seems to have > vanished. :) > > Jose, I think we can switch the binaries over to the new branch, everthing > seems to working fine. Good work, Leif. Just curious: do you guys have a plan for moving the mach64 code into the trunk? Are there any major issues that need to be resolved first? BTW, I took a stab at updating the http://dri.sourceforge.net/doc/cvs.html page which lists and describes the current CVS branches. The mach64 branch is described as: > This is the branch for the ATI Rage Pro driver development. The work is > unfunded and is only just beginning, so a working driver is still a long way > off. Please do not ask when it will be complete. This branch also contains some > DRM architectural changes, designed to make writing new drivers easier and > remove significant amounts of duplicated code. Maybe this should be updated. -Brian --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] trunk merge in mach64-0-0-5-branch is done
OK, mach64-0-0-5-branch is open for your hacking and testing pleasure! The trunk as of June 26 is merged in, so we now have Mesa 4.0.3 and I've converted the mach64 driver to the drmCommand interface. The branch compiles and works fine, and as a bonus, the bug with clears in the first GL context seems to have vanished. :) Jose, I think we can switch the binaries over to the new branch, everthing seems to working fine. -- Leif Delgass http://www.retinalburn.net --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] SiS Specifications
I don't think the docs are much help with regard to 3D. there actually is a working sis DRI driver for 300 series chips that can be found here: http://www.winischhofer.net/linuxsis630.shtml perhaps it could be synced up to the current DRI tree. Alex Might want to post this on the site somewhere - appears that utah-glx has posted specs for some SiS chipsets (300 & 630). http://prdownloads.sourceforge.net/utah-glx/300ds03.pdf?download http://prdownloads.sourceforge.net/utah-glx/630ds10a.pdf?download -Al __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Free money 7093HTiF9-810-12
Warning Unable to process data: multipart/mixed;boundary="=_NextPart_000_00E7_27E61D1D.C6224B00"
Re: [Dri-devel] Some bsd-3-0-0-branch benchmarks.
Keith Whitwell wrote: > Eric Anholt wrote: > >> Well, I've got most of the FreeBSD troubles straightened out I think. I >> went ahead and did some glxgears benchmarks, waiting for the numbers to >> stabilize, of gentoo vs freebsd-current. >> >> System is a 128MB 2xCeleron517 (BP6, OCed), diskless, booting gentoo or >> -current off of a -current system. Video at 1280x1024x60hz, 16 bit. >> >> gentoo 1.1, kernel 2.4.19-gentoo-r5 (custom, p2 opts but nothing special >> think) >> bsd-3-0-0-branch as of a few days ago >> kernel modules from bsd-3-0-0-branch from today >> twm >> >> FreeBSD-current as of a few days ago. >> WITNESS and INVARIANTS disabled. >> bsd-3-0-0-branch as of a few days ago >> kernel modules from bsd-3-0-0-branch from today. >> No wm (sshing in). >> >> Radeon 64MB VIVO, no pageflip: >> linux: 1325 fps >> bsd: 1324 >> >> Rage 128 Pro: >> linux: 581 >> bsd: 582 >> >> Matrox G400 >> linux: 923 >> bsd: 755 >> >> Only the Matrox had problems, don't know what that was.Still, I'm >> very excited about the Radeon numbers. > > > Nice. > > I'm just looking a little at the code, wonder if there can be some name > changes to simplify the macros a little. > > We're using DRM_ prefixes for os-abstractions already, like DRM_DEBUG, > so I don't think it's necessary to further specialize the namespace to > DRM_OS_ ... (doh) So, instead of DRM_OS_COPYFROMUSR_NC, maybe DRM_COPY_FROM_USER_UNCHECKED might be clearer. Similarly, DRM_OS_KRNFROMUSR is pretty cryptic -- maybe DRM_COPY_FROM_USER_IOCTL or something? Oh, and I just found DRM_OS_FETCHU_32_NC -- that's ugly... I How about: DRM_OS_COPYFROMUSR_NC -- DRM_COPY_FROM_USER_UNCHECKED DRM_OS_COPYFROMUSR -- DRM_COPY_FROM_USER DRM_OS_KRNFROMUSR -- DRM_COPY_FROM_USER_IOCTL DRM_OS_FETCHU_32_NC -- DRM_GET_USER_UNCHECKED and so on. Keith --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Some bsd-3-0-0-branch benchmarks.
Eric Anholt wrote: > Well, I've got most of the FreeBSD troubles straightened out I think. I > went ahead and did some glxgears benchmarks, waiting for the numbers to > stabilize, of gentoo vs freebsd-current. > > System is a 128MB 2xCeleron517 (BP6, OCed), diskless, booting gentoo or > -current off of a -current system. Video at 1280x1024x60hz, 16 bit. > > gentoo 1.1, kernel 2.4.19-gentoo-r5 (custom, p2 opts but nothing special > think) > bsd-3-0-0-branch as of a few days ago > kernel modules from bsd-3-0-0-branch from today > twm > > FreeBSD-current as of a few days ago. > WITNESS and INVARIANTS disabled. > bsd-3-0-0-branch as of a few days ago > kernel modules from bsd-3-0-0-branch from today. > No wm (sshing in). > > Radeon 64MB VIVO, no pageflip: > linux: 1325 fps > bsd: 1324 > > Rage 128 Pro: > linux: 581 > bsd: 582 > > Matrox G400 > linux: 923 > bsd: 755 > > Only the Matrox had problems, don't know what that was.Still, I'm > very excited about the Radeon numbers. Nice. I'm just looking a little at the code, wonder if there can be some name changes to simplify the macros a little. We're using DRM_ prefixes for os-abstractions already, like DRM_DEBUG, so I don't think it's necessary to further specialize the namespace to DRM_OS_ --- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Some bsd-3-0-0-branch benchmarks.
Well, I've got most of the FreeBSD troubles straightened out I think. I went ahead and did some glxgears benchmarks, waiting for the numbers to stabilize, of gentoo vs freebsd-current. System is a 128MB 2xCeleron517 (BP6, OCed), diskless, booting gentoo or -current off of a -current system. Video at 1280x1024x60hz, 16 bit. gentoo 1.1, kernel 2.4.19-gentoo-r5 (custom, p2 opts but nothing special think) bsd-3-0-0-branch as of a few days ago kernel modules from bsd-3-0-0-branch from today twm FreeBSD-current as of a few days ago. WITNESS and INVARIANTS disabled. bsd-3-0-0-branch as of a few days ago kernel modules from bsd-3-0-0-branch from today. No wm (sshing in). Radeon 64MB VIVO, no pageflip: linux: 1325 fps bsd: 1324 Rage 128 Pro: linux: 581 bsd: 582 Matrox G400 linux: 923 bsd: 755 Only the Matrox had problems, don't know what that was.Still, I'm very excited about the Radeon numbers. -- Eric Anholt <[EMAIL PROTECTED]> http://gladstone.uoregon.edu/~eanholt/dri/ --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] os-independence compilation
On Thu, 2002-06-27 at 13:14, Keith Whitwell wrote: > Eric, > > Just trying to compile this under linux. Does this look familiar? I couldn't > really see where it was coming from. > > I've just tried to insert the bsd-3-0-0-branch os-support directory into my > trunk tree. Maybe that's too ambitious... > > Keith Should be fixed, going to run through testing cards on linux again. BTW, I'm in #dri-devel for more real-time responses. -- Eric Anholt <[EMAIL PROTECTED]> http://gladstone.uoregon.edu/~eanholt/dri/ --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] os-independence compilation
Eric, Just trying to compile this under linux. Does this look familiar? I couldn't really see where it was coming from. I've just tried to insert the bsd-3-0-0-branch os-support directory into my trunk tree. Maybe that's too ambitious... Keith -- make[2]: Entering directory `/home/keithw/work/xc-trunk/programs/Xserver/hw/xfree86/os-support-bsd/linux/drm' rm -f xf86drm.o gcc -O2 -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -pipe -g -fno-merge-constants -I../../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../../programs/Xserver/hw/xfree86/os-support -I. -I../../../../../../../programs/Xserver/include -I../../../../../../../exports/include/X11 -I../../../../../../../include/extensions -I../.. -Ikernel -I../../../../../../.. -I../../../../../../../exports/include -I/home/XF4/xc-trunk/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -DHAS_MTRR_SUPPORT -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -c xf86drm.c In file included from xf86drm.c:84: kernel/drm.h:96: syntax error before `typedef' --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] SiS Specifications
Might want to post this on the site somewhere - appears that utah-glx has posted specs for some SiS chipsets (300 & 630). http://prdownloads.sourceforge.net/utah-glx/300ds03.pdf?download http://prdownloads.sourceforge.net/utah-glx/630ds10a.pdf?download -Al This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the Priority Health Information Services Department at (616) 942-0954. --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SIGSEGV on VT switch
On Thu, Jun 27, 2002 at 05:26:37PM +0100, Sergey V. Udaltsov wrote: > > The output went into the /var/log/XFree86.0.log (or to the console where > > you started the X server), not to the GDB screen. > Yes!!! What I got: > > 0x841eb84 ATIMach64SetDPMSMode+46a > Module "/usr/X11R6/lib/modules/drivers/atimisc_drv.o" > Section ".text" > 0x83fa220 XAA+21cf > Module "/usr/X11R6/lib/modules/libxaa.a:xaaFallback.o" > Section ".text" > 0x8593558 XAACopyArea+ab > Module "/usr/X11R6/lib/modules/libxaa.a:xaaCpyArea.o" > Section ".text" > > So the problem seems to be in ATIMach64SetDPMSMode! What about DPMS > things in DRI branch? That's not it. It's not possible for XAA to be calling DPMS functions. You could compile a static server, and debug it that way. I've found that to be much more reliable. #define DoLoadableServer NO in your host.def Alan. --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SIGSEGV on VT switch
> The output went into the /var/log/XFree86.0.log (or to the console where > you started the X server), not to the GDB screen. Yes!!! What I got: 0x841eb84 ATIMach64SetDPMSMode+46a Module "/usr/X11R6/lib/modules/drivers/atimisc_drv.o" Section ".text" 0x83fa220 XAA+21cf Module "/usr/X11R6/lib/modules/libxaa.a:xaaFallback.o" Section ".text" 0x8593558 XAACopyArea+ab Module "/usr/X11R6/lib/modules/libxaa.a:xaaCpyArea.o" Section ".text" So the problem seems to be in ATIMach64SetDPMSMode! What about DPMS things in DRI branch? Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SIGSEGV on VT switch
On Thu, Jun 27, 2002 at 11:48:40AM +0100, Sergey V. Udaltsov wrote: > > The problem is that stock gdb doesn't know about XFree86 modules. There > > are patched versions of gdb for that, but even so you can get more > > information by calling the LoaderPrintSymbol function for each of the > > addresses before a '??', i.e. at the gdb prompt: > > > > call LoaderPrintSymbol(0x0841e74e) > Really? I tried one more time. First of all, the stack trace is > different this time (which is funny itself) and this LoaderPrintSymbol > does not help much: > ** > (gdb) continue > Continuing. > > Program received signal SIGUSR1, User defined signal 1. > 0x420e198e in select () from /lib/i686/libc.so.6 > (gdb) bt > #0 0x420e198e in select () from /lib/i686/libc.so.6 > #1 0x in ?? () > #2 0x080b574a in Dispatch () > #3 0x080c808d in main () > #4 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 > (gdb) cont > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > 0x0841efee in ?? () > (gdb) bt > #0 0x0841efee in ?? () > #1 0x083fc3ef in ?? () > #2 0x08593603 in ?? () > #3 0x080fddd3 in ShmRegisterFbFuncs () > #4 0x080fedab in ShmRegisterFbFuncs () > #5 0x080b58d7 in Dispatch () > #6 0x080c808d in main () > #7 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 > > (gdb) call LoaderPrintSymbol(0x08593603) > $1 = 1 > (gdb) call LoaderPrintSymbol(0x083fc3ef) > $2 = 1 > (gdb) call LoaderPrintSymbol(0x083fc3ef) > $3 = 1 > (gdb) call LoaderPrintSymbol(0x0841efee) > $4 = 1 > (gdb) cont > Continuing. > > I dont't think this is more informative. The output went into the /var/log/XFree86.0.log (or to the console where you started the X server), not to the GDB screen. This caught me the first time I tried to use it, too. :) -andy --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parhelia vs. Radeon 8500
Hi, Just wanted to say that I got my Radeon 8500 today (off ebay), to replace a G400 (seems to be a common combination then?). > Radeon8500: > 2D is supported, including working XVideo provided by the Gatos-project, I only had to upgrade to XFree86 4.2.0 to get anything working... Haven't tried Xv, but the one in Xfree86 4.2.0 seems to be broken. > 3D is supported by the closed-source FireGL-drivers by ATi. That driver is awesome. 60fps in FlightGear (standard scene) in 1600x1200, 24bpp! BZflag is between 80 and 130fps, in a normal scenery. Maybe it is unstable, time will tell, but performance is great. I no longer have to switch to 1024x768 just to fly or to play BZflag. > The FireGL-drivers do not support XV, so you'll have to choose wether to Doesn't matter, my computer is fast enough to play most videos without Xv. (Athlon XP1800+) > bad, just a bit uncomfortable. The development of an open-source driver > for the 8500 is funded by the weather channel, and we will hopefully see > working drivers by the end of the year. Hope to see something great then. I think I've gone for the right company: they release a closed-source driver for those who want to use the card before some volunteers write a proper open-source one. This is a combination of the best things in Matrox and NVidia. > Sorry, I don't know if Matrox is planning to support the card in XF86. > Currently they don't even have a driver for win9x, so it will probably > be a while. But I may be completely wrong here. I suspect the Parhelia is very different in terms of programming from the G line, therefore it may take quite some time before they release specs. > I'd also keep in mind the costs of both cards: You can get a 8500(LE) > for less than half of what the Parhelia costs. Paid GBP100 (~$/Euro150) for my 8500... Andras === Major Andras e-mail: [EMAIL PROTECTED] www:http://andras.webhop.org/ === --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SIGSEGV on VT switch
> The problem is that stock gdb doesn't know about XFree86 modules. There > are patched versions of gdb for that, but even so you can get more > information by calling the LoaderPrintSymbol function for each of the > addresses before a '??', i.e. at the gdb prompt: > > call LoaderPrintSymbol(0x0841e74e) Really? I tried one more time. First of all, the stack trace is different this time (which is funny itself) and this LoaderPrintSymbol does not help much: ** (gdb) continue Continuing. Program received signal SIGUSR1, User defined signal 1. 0x420e198e in select () from /lib/i686/libc.so.6 (gdb) bt #0 0x420e198e in select () from /lib/i686/libc.so.6 #1 0x in ?? () #2 0x080b574a in Dispatch () #3 0x080c808d in main () #4 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0841efee in ?? () (gdb) bt #0 0x0841efee in ?? () #1 0x083fc3ef in ?? () #2 0x08593603 in ?? () #3 0x080fddd3 in ShmRegisterFbFuncs () #4 0x080fedab in ShmRegisterFbFuncs () #5 0x080b58d7 in Dispatch () #6 0x080c808d in main () #7 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) call LoaderPrintSymbol(0x08593603) $1 = 1 (gdb) call LoaderPrintSymbol(0x083fc3ef) $2 = 1 (gdb) call LoaderPrintSymbol(0x083fc3ef) $3 = 1 (gdb) call LoaderPrintSymbol(0x0841efee) $4 = 1 (gdb) cont Continuing. I dont't think this is more informative. Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: S3 VIRGE DRI in CVS now
On Thu, Jun 27, 2002 at 11:54:53AM +0200, Massimiliano Lingua wrote: [...] >3) Did you set backbuffer size and texsize in XF86Config like I >suggested in the README? Max, where can I find that README? I would like to put it in the same place as the binary snapshots. José Fonseca --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] SIGSEGV on VT switch
On Thu, 2002-06-27 at 10:30, Sergey V. Udaltsov wrote: > I've tried to use remote debugging and got the backtrace of the SIGSEVG: > > Program received signal SIGSEGV, Segmentation fault. > 0x0841e74e in ?? () > (gdb) bt > #0 0x0841e74e in ?? () > #1 0x083fbca7 in ?? () > #2 0x083198bb in ?? () > #3 0x080b7e05 in ProcCopyArea () > #4 0x080b58d7 in Dispatch () > #5 0x080c808d in main () > #6 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 > > Is it useful in any way? I'm afraid binary snapshots are stripped so I > did not expect too much info:( The problem is that stock gdb doesn't know about XFree86 modules. There are patched versions of gdb for that, but even so you can get more information by calling the LoaderPrintSymbol function for each of the addresses before a '??', i.e. at the gdb prompt: call LoaderPrintSymbol(0x0841e74e) and so on. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: S3 VIRGE DRI in CVS now
On Thu, 2002-06-27 at 03:38, John J. Tobin wrote: > No change, it still hard locks the system. I tried the binary snapshot > too and the kernel modules wouldn't build. mmm... ; ( > The windows for gears will open and then a section of the lower half of > the screen becomes corrupted at the lock up. 1) Which kernel version are you running? 2) Could you try to load module with drm_opts=debug option? 3) Did you set backbuffer size and texsize in XF86Config like I suggested in the README? Vale, - max --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] SIGSEGV on VT switch
I've tried to use remote debugging and got the backtrace of the SIGSEVG: Program received signal SIGSEGV, Segmentation fault. 0x0841e74e in ?? () (gdb) bt #0 0x0841e74e in ?? () #1 0x083fbca7 in ?? () #2 0x083198bb in ?? () #3 0x080b7e05 in ProcCopyArea () #4 0x080b58d7 in Dispatch () #5 0x080c808d in main () #6 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 Is it useful in any way? I'm afraid binary snapshots are stripped so I did not expect too much info:( Would be grateful for any clarifications/further directions Regards, Sergey --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Parhelia vs. Radeon 8500
German Gomez Garcia wrote: > Hello, I have some money to spend (finally!!!) so I'm thinking > of replacing my old G400MAX for a new card, as I prefer open source, I > have to choose between ATI and Matrox, and the optios (for me) are > the new Parhelia 512 or the AIW Radeon 8500 DV, I'll buy whatever card > works better under Linux, as far as I know somebody is working in 3D for > the 8500 even TCL!!, and the Gatos project has good quality video in/out > for the AIW DV. The parhelia is quite misterious, but I could wait two > or three months if the drivers would be good enough. > Just let me give you a short overview about the current status of the driver support: Radeon8500: 2D is supported, including working XVideo provided by the Gatos-project, 3D is supported by the closed-source FireGL-drivers by ATi. The FireGL-drivers do not support XV, so you'll have to choose wether to use 3D- or video acceleration. It's not a problem running the free/Gatos server and the FireGL server at the same time, however, so it's not too bad, just a bit uncomfortable. The development of an open-source driver for the 8500 is funded by the weather channel, and we will hopefully see working drivers by the end of the year. Parhelia: Sorry, I don't know if Matrox is planning to support the card in XF86. Currently they don't even have a driver for win9x, so it will probably be a while. But I may be completely wrong here. I'd also keep in mind the costs of both cards: You can get a 8500(LE) for less than half of what the Parhelia costs. I hope this helps a bit Stefan > I would like to know if anybody from Matrox contacted developers > here, well, in fact, I would like to know if I should wait for the > parhelia linux drivers or go for the AIW. What do you think?? > > Regards, > > - german > --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
