Re: [Dri-devel] driver comparison
Roland Scheidegger wrote: Keith Whitwell wrote: And to get this fully on-topic, is there a specific reason why the dri driver is quite a bit slower (up to 50% in some subtests) in SpecViewPerf compared to the cvs version of july? Could this be related to the changes with GLX_NV_vertex_array_range, GLX_MESA_agp_offset, GLX_MESA_allocate_memory (the only extensions which changed in that timeframe) or must this be something else? Roland, if you're interested in tracking this down, doing a binary search with cvs to find the point at which things slowed down would be hugely helpful. Ok, I've tried to narrow it down. It happened between 2003-07-25 and 2003-08-01. (For testing, I've only exchanged r200_dri.so and libGL.so, I didn't install a different 2d driver, drm etc. - mostly because I couldn't get everything to compile - guess cvs update -dP -D date doesn't do the trick). btw why exactly isn't it possible to hot-swap (when xfree86 is running) the dri driver (r200_dri.so)? This kinda works, but kwm, kicker kwhatever insists on crashing shortly afterwards :-( Oprofile output (see below) shows that r200_emit_state_list together with some check_tcl_xx functions gets called approximately 40 times as much. Maybe dmatmp2 changes related? Yes, it looks like it. I think it's probably related to changes to the ALLOC_ELTS() macro - previously I could add more elts to an existing allocation with little effort. Maybe I can ressurect that code. Keith --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] weird corruption with r200
Alex Deucher wrote: Before I go grepping through the tree, where would I find this code (in the DRM, DRI, or 2D)? Also is it for r100 or r200 or both? is there a r200_cp_dispatch_clear()? It's in the drm module. The r200 shares the radeon kernel code. Keith --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 2003-10-17 at 04:41, Alex Deucher wrote: Log message: *Re-wrote MergedFB validate mode function from scratch based on crt1 validation rather than the old clone validation code. So does it work more or less like the old clone mode by default now? :) *Fixed mode validation on systems without libint10.a; MergedFB should work on Freebsd, however, I don't have such a system to test on. It works fine on linux without libint10.a. Note that AIUI, the problem was never a missing libint10.a, but the generic one vs. the Linux specific one. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] compilation failure in sis_alloc.c
Anyone seeing this? I'm pretty sure this isn't just something local to my environment. I'll probably take 'sis' out of the build in the meantime. Keith gcc -c -O2 -fno-strength-reduce -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -pipe -g -I../../../../../../exports/include/X11 -I../../../../../../include/extensions -I../../../../../../extras/Mesa/src -I../../../../../../extras/Mesa/include -I../../../../../../lib/GL/mesa/src/drv/common -I../../../../../../lib/GL/mesa/src/drv/sis -I../../../../../../lib/GL/dri -I../../../../../../lib/GL/glx -I../../../../../../exports/include -I../../../../../../exports/include/GL -I../../../../../../programs/Xserver/GL/dri -I../../../../../../programs/Xserver/hw/xfree86/os-support -I../../../../../../programs/Xserver/hw/xfree86/drivers/sis -I../../../../../../programs/Xserver/hw/xfree86/common -I../../../../../../lib/GL/dri/drm -I../../../../../../lib/GL/include -I../../../../../.. -I../../../../../../exports/include -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM sis_alloc.c In file included from sis_common2.h:49, from sis_context.h:42, from sis_alloc.c:37: /usr/include/unistd.h:966: warning: redundant redeclaration of `ctermid' in same scope /usr/include/stdio.h:585: warning: previous declaration of `ctermid' /usr/include/unistd.h:985: warning: redundant redeclaration of `pthread_atfork' in same scope /usr/include/pthread.h:673: warning: previous declaration of `pthread_atfork' sis_alloc.c: In function `sisAllocFB': sis_alloc.c:65: `drm_sis_mem_t' undeclared (first use in this function) sis_alloc.c:65: (Each undeclared identifier is reported only once sis_alloc.c:65: for each function it appears in.) sis_alloc.c:65: parse error before `fb' sis_alloc.c:69: `fb' undeclared (first use in this function) sis_alloc.c:71: `DRM_SIS_FB_ALLOC' undeclared (first use in this function) sis_alloc.c: In function `sisFreeFB': sis_alloc.c:90: `drm_sis_mem_t' undeclared (first use in this function) sis_alloc.c:90: parse error before `fb' sis_alloc.c:97: `fb' undeclared (first use in this function) sis_alloc.c:99: `DRM_SIS_FB_FREE' undeclared (first use in this function) sis_alloc.c: In function `sisAllocAGP': sis_alloc.c:105: `drm_sis_mem_t' undeclared (first use in this function) sis_alloc.c:105: parse error before `agp' sis_alloc.c:110: `agp' undeclared (first use in this function) sis_alloc.c:112: `DRM_SIS_AGP_ALLOC' undeclared (first use in this function) sis_alloc.c: In function `sisFreeAGP': sis_alloc.c:131: `drm_sis_mem_t' undeclared (first use in this function) sis_alloc.c:131: parse error before `agp' sis_alloc.c:138: `agp' undeclared (first use in this function) sis_alloc.c:140: `DRM_SIS_AGP_FREE' undeclared (first use in this function) make: *** [sis_alloc.o] Error 1 --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Fri, 2003-10-17 at 04:41, Alex Deucher wrote: Log message: *Re-wrote MergedFB validate mode function from scratch based on crt1 validation rather than the old clone validation code. So does it work more or less like the old clone mode by default now? :) Should work more like it :) *Fixed mode validation on systems without libint10.a; MergedFB should work on Freebsd, however, I don't have such a system to test on. It works fine on linux without libint10.a. Note that AIUI, the problem was never a missing libint10.a, but the generic one vs. the Linux specific one. That's what I meant, sorry for any confusion. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 2003-10-17 at 05:14, Eric Anholt wrote: Log message: - Converted Linux drivers to initialize DRM instances based on PCI IDs, not just a single instance. Moved the PCI ID lists from card_drv.c in BSD to card.h. The PCI ID lists include a driver private field, which may be used by drivers for chip family or other information. Based on work by jonsmirl. - Make tdfx_drv.c and tdfx.h match other drivers. - Fixed up linking of sis shared files. Tested with Radeon and SiS on Linux and FreeBSD, including a Linux setup with 2 SiS cards in a machine, but only one head being used (with DRI) The case I was concerned about was multiple Radeon cards, that used to fail rather spectacularly. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 17 Oct 2003, Michel [ISO-8859-1] Dänzer wrote: On Fri, 2003-10-17 at 04:41, Alex Deucher wrote: Log message: *Re-wrote MergedFB validate mode function from scratch based on crt1 validation rather than the old clone validation code. So does it work more or less like the old clone mode by default now? :) *Fixed mode validation on systems without libint10.a; MergedFB should work on Freebsd, however, I don't have such a system to test on. It works fine on linux without libint10.a. Well, I updated, recompiled, and installed under FreeBSD. I launched X and it didn't crash. I'm not actually in front of the machine, so I can't confirm that it hasn't destroyed my monitors, but it looks like it's running fine :-) Adam --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
--- Michel D�nzer [EMAIL PROTECTED] wrote: On Fri, 2003-10-17 at 05:14, Eric Anholt wrote: Log message: - Converted Linux drivers to initialize DRM instances based on PCI IDs, not just a single instance. Moved the PCI ID lists from card_drv.c in BSD to card.h. The PCI ID lists include a driver private field, which may be used by drivers for chip family or other information. Based on work by jonsmirl. - Make tdfx_drv.c and tdfx.h match other drivers. - Fixed up linking of sis shared files. Tested with Radeon and SiS on Linux and FreeBSD, including a Linux setup with 2 SiS cards in a machine, but only one head being used (with DRI) The case I was concerned about was multiple Radeon cards, that used to fail rather spectacularly. I thought that had something to do with rom loading on secondary cards, although you may be speaking of a different issue. Alex __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
On Fri, 2003-10-17 at 17:41, Alex Deucher wrote: --- Michel Dnzer [EMAIL PROTECTED] wrote: The case I was concerned about was multiple Radeon cards, that used to fail rather spectacularly. I thought that had something to do with rom loading on secondary cards, although you may be speaking of a different issue. I am, at least one instance would get confused in the ring or even MMIO handling. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI + Radeon + LCD has framerate cap
you need to change the DRI config settings: http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure perhaps we shouldn't make sync to refresh the default. Alex --- Paul Zaremba [EMAIL PROTECTED] wrote: Hello, I have a Radeon 8500 LE with an LCD attached to the CRT output. I've been compiling the DRI to test against NwN, glxgears, and bzflag. So first of all, great work! However, as of last week when I downloaded and compiled the DRI it appears that my glxgears framerate is capping at the vSync rate (70fps) and the hardware NwN fps is a little over half what it used to be, lighting/texture glitches and all. I suspect that it's idling the CPU waiting for vSync in both. I re-tested by using the latest trunk as of this morning and it's still capped. It also appears that R200_NO_TCL no longer functions. It was the only thing that allowed me to play NwN at all with the DRI since I prefer not to use the ATI binary drivers. I haven't learned how to use what appears to be the DRI config file yet, but that's on my list of things to do this weekend. In the source it looks like I can set TCL_mode to 0 in the config file to achieve the same effect that R200_NO_TCL used to give me. Is my deduction correct about the config file? If you want, when I get the time (read: tomorrow) I will use cvs update -D to binary search through the tree of the last 45 days and find when it changed. I'm willing to dig into the code and find out what's wrong. I design and implement software for a living and as my second favorite hobby. So, while I'm not familiar with the code I believe I can be of more use than the usual it's broken, help? statements. Just in case they may be useful I have logs available at: http://treeofice.net/~pez/logs/ XFree86.0.log (50K) glxinfo.log (4.1K) I figure I'll sacrifice some outgoing bandwidth to keep from spamming the list with files unnecessarily. System info; Athlon 1800+, 512MB RAM, Radeon 8500LE, gentoo linux (ACCEPT_KEYWORDS=~x86), 2.4.20-gentoo-r7 with kernel module not built in kernel. Using the DRI CVS kernel module. The LCD monitor has a CRT connector and is connect to the CRT output. I have a DVI to CRT convertor somewhere if testing through the DVI port is desired. Note: I used to get ~1450 out of glxgears, 36 fps out of NwN with the ugly hardware acceleration. Now it's 70/19. The cap happens with or without page flipping (makes sense). The logs are without page flipping. Thanks, Paul --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver comparison, cp vs rm; cp.
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2003-10-17 at 02:36, Roland Scheidegger wrote: Keith Whitwell wrote: Alex Deucher wrote: As I recall KDE preloads libGL for some reason. that might have something to do with it. If you make sure that the old driver.so file is removed, not overwritten, there shouldn't be any problem, as existing open filehandles won't then see any changes. Yes! That did it. [...] Well, I've never tried to install the whole XFree86 when it's running, but I'm often lazy and just compile the mesa/src/drv/r200 if only small changes happen and copy the r200_dri.so manually. But as you suggested, if I'll delete the installed r200_dri.so before copying the new one, then no crashes happen - the running kde happily keeps its references to the old deleted dri driver and new apps will use the new dri driver. cp --remove-destination will do that. I'm a bit surprised cp doesn't always unlink the destination before replacing it though; is there any reason why this shouldn't be considered a bug? (Seems to me the only difference should be whether it follows symlinks or not) I can't think of an example where overwriting the existing file would be useful, but that may well be just me, any clues appreciated. :) When you do it this way the inode(number) and it's meta data are lost. cp would have to know about the filesystem and what meta data needs to be saved/restored. As this results in the loss of permitions it is not the default. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI + Radeon + LCD has framerate cap
On Friday 17 October 2003 03:10 pm, Alex Deucher wrote: you need to change the DRI config settings: http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure perhaps we shouldn't make sync to refresh the default. Alex Thank you Alex, I'll download driconf and give it a shot. I need to become more familiar with the Wiki. Note that it was a little confusing that the word Download was highlighted in the Driconf document but it went to the DRI download page instead of the 'download section below' like I was expecting. You could also leave sync as the default and add driconf to the FAQ. The closest FAQ I saw was Installation Configuration Questions: How Many FPS does my Ati Radeon should work on a glxgears test? http://dri.sourceforge.net/faq/faq_display.phtml?id=56 Or even a new FAQ (I can see my question popping up frequently when the new DRI is released). Of course, it all comes down to performance vs. appearance as the default. Also how many people post to the list about it. :-) I didn't mention it before but I'm on the list so no need to CC me. Thanks though :-) Paul --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI + Radeon + LCD has framerate cap
On Fri, 17 Oct 2003 12:10:05 -0700 (PDT) Alex Deucher [EMAIL PROTECTED] wrote: you need to change the DRI config settings: http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure perhaps we shouldn't make sync to refresh the default. IIRC there was a similar discussion after the texmem-0-0-1 merge. I was hoping that a well defined configuration system would finally allow us to make the default comply with the spec. The default setting should not affect the frame rate if it was below the vertical refresh rate without vsyncing. Only for benchmarks it is useful to disable vsync. For everyday work/game play you never need more than 75 or 80 Hz, do you? Alex Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI + Radeon + LCD has framerate cap
--- Felix Kühling [EMAIL PROTECTED] wrote: On Fri, 17 Oct 2003 12:10:05 -0700 (PDT) Alex Deucher [EMAIL PROTECTED] wrote: you need to change the DRI config settings: http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure perhaps we shouldn't make sync to refresh the default. IIRC there was a similar discussion after the texmem-0-0-1 merge. I was hoping that a well defined configuration system would finally allow us to make the default comply with the spec. The default setting should not affect the frame rate if it was below the vertical refresh rate without vsyncing. Only for benchmarks it is useful to disable vsync. For everyday work/game play you never need more than 75 or 80 Hz, do you? Alex Regards, Felix There may be allot I don't know about OpenGL, but I do know video games. In games you want to hear/see the latesed info about game state that exists, this adds(subtracts) to your hand eye cordination(Things like network anticipation are great). You also want what you hear to be synched with what you see. It's important for these 2 reasons that OpenGL allways present the user with the most current data. The way things should work is... The card tells the game when the NEXT vsync should happen, deduced by Current + RefreshRate. Then the game should predict what things will look like and send that to the card to be rendered. However things AFAICG work... The game renderes as many FPS as the card can and the card draws the last one to the sceen. Maby not the best way but the most feasable with what(drivers) we have today. Thus synch to vblank ?may? make frames appere 1/RefreshRate of a seconds too late. Thought for most gamers this may be fine, I think my eyes are faster. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI + Radeon + LCD has framerate cap
plus there is a certain machismo element to the number of FPS your card can render... --- Mike Mestnik [EMAIL PROTECTED] wrote: --- Felix Kühling [EMAIL PROTECTED] wrote: On Fri, 17 Oct 2003 12:10:05 -0700 (PDT) Alex Deucher [EMAIL PROTECTED] wrote: you need to change the DRI config settings: http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure perhaps we shouldn't make sync to refresh the default. IIRC there was a similar discussion after the texmem-0-0-1 merge. I was hoping that a well defined configuration system would finally allow us to make the default comply with the spec. The default setting should not affect the frame rate if it was below the vertical refresh rate without vsyncing. Only for benchmarks it is useful to disable vsync. For everyday work/game play you never need more than 75 or 80 Hz, do you? Alex Regards, Felix There may be allot I don't know about OpenGL, but I do know video games. In games you want to hear/see the latesed info about game state that exists, this adds(subtracts) to your hand eye cordination(Things like network anticipation are great). You also want what you hear to be synched with what you see. It's important for these 2 reasons that OpenGL allways present the user with the most current data. The way things should work is... The card tells the game when the NEXT vsync should happen, deduced by Current + RefreshRate. Then the game should predict what things will look like and send that to the card to be rendered. However things AFAICG work... The game renderes as many FPS as the card can and the card draws the last one to the sceen. Maby not the best way but the most feasable with what(drivers) we have today. Thus synch to vblank ?may? make frames appere 1/RefreshRate of a seconds too late. Thought for most gamers this may be fine, I think my eyes are faster. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] new 2048 limit code...
I've had several mergedfb users complain about the 2048 DRI limit
put in yesterday:
else if ( pScrn-virtualX 2048 || pScrn-virtualY 2048 ) {
info-directRenderingEnabled = FALSE;
xf86DrvMsg(scrnIndex, X_WARNING,
Direct Rendering Disabled --
Virtual resolution exceeds 2048
(hardware limitation)\n);
}
I'm not sure what the best way around this is...
While that is the limit, you can have a desktop larger than 2048 in
either dimension and 3D will work as long as the 3D windows are within
those limits. Often times users have a desktop larger than 2048 and
then when they use 3D (game, etc. using xvidmode), they switch to a
clone mode of less then 2048 and everything works fine. people rarely
run any apps larger than 2048 (other than screen savers maybe...).
I don't really care which way we go on this issue, I'm just pointing
out that's it's there...
perhaps we can not disable the DRI if mergedfb is active and the viral
is larger than 2048?
Anyone have any thoughts?
Alex
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---
This SF.net email sponsored by: Enterprise Linux Forum Conference Expo
The Event For Linux Datacenter Solutions Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; in the Server Room
http://www.enterpriselinuxforum.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: trunk)
Felix Kuehling wrote: CVSROOT:/cvs/dri Module name:xc Repository: xc/xc/lib/GL/mesa/src/drv/sis/ Changes by: [EMAIL PROTECTED] 03/10/17 06:26:08 Log message: Fixed linking of DRI drivers with common object files. Now each driver only links with those common objects that it really needs. hwlog.o is not used anymore. Removed a last left-over include hwlog.h from common/mm.c. Lets remove hwlog.[ch] then. Keith --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] new 2048 limit code...
On Fri, 2003-10-17 at 17:27, Alex Deucher wrote:
I've had several mergedfb users complain about the 2048 DRI limit
put in yesterday:
else if ( pScrn-virtualX 2048 || pScrn-virtualY 2048 ) {
info-directRenderingEnabled = FALSE;
xf86DrvMsg(scrnIndex, X_WARNING,
Direct Rendering Disabled --
Virtual resolution exceeds 2048
(hardware limitation)\n);
}
I'm not sure what the best way around this is...
While that is the limit, you can have a desktop larger than 2048 in
either dimension and 3D will work as long as the 3D windows are within
those limits. Often times users have a desktop larger than 2048 and
then when they use 3D (game, etc. using xvidmode), they switch to a
clone mode of less then 2048 and everything works fine. people rarely
run any apps larger than 2048 (other than screen savers maybe...).
I don't really care which way we go on this issue, I'm just pointing
out that's it's there...
perhaps we can not disable the DRI if mergedfb is active and the viral
is larger than 2048?
Anyone have any thoughts?
Maybe in the 3d driver you could fall back to software on grabbing the
lock if the width is too large?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email sponsored by: Enterprise Linux Forum Conference Expo
The Event For Linux Datacenter Solutions Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; in the Server Room
http://www.enterpriselinuxforum.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] driver comparison, cp vs rm; cp.
--- Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2003-10-17 at 02:36, Roland Scheidegger wrote: Keith Whitwell wrote: Well, I've never tried to install the whole XFree86 when it's running, but I'm often lazy and just compile the mesa/src/drv/r200 if only small changes happen and copy the r200_dri.so manually. But as you suggested, if I'll delete the installed r200_dri.so before copying the new one, then no crashes happen - the running kde happily keeps its references to the old deleted dri driver and new apps will use the new dri driver. cp --remove-destination will do that. I'm a bit surprised cp doesn't always unlink the destination before replacing it though; is there any reason why this shouldn't be considered a bug? (Seems to me the only difference should be whether it follows symlinks or not) I can't think of an example where overwriting the existing file would be useful, but that may well be just me, any clues appreciated. :) When you do it this way the inode(number) and it's meta data are lost. cp would have to know about the filesystem and what meta data needs to be saved/restored. As this results in the loss of permitions it is not the default. __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-17-10 22:37 --- I've been having a problem with XFree86 Randomly locking up. I'm running kernel 2.6.0-test7 with XFree86 4.3.99.14. It seems to happen when I'm running xscreensaver with an opengl screensaver, and at times running 3D games. Could this be related to the patch? HP ZE4145 ATI Radeon IGP320 AMD Athlong XP 1800+ / 512m ddr sdram. -- 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 sponsored by: Enterprise Linux Forum Conference Expo The Event For Linux Datacenter Solutions Strategies in The Enterprise Linux in the Boardroom; in the Front Office; in the Server Room http://www.enterpriselinuxforum.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
