Re: [Dri-devel] DRI packages progress notice - what about specific options?
Quoting Jose Fonseca [EMAIL PROTECTED]: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Unfortunately, as you can notice the packages are huge. Attached is a file list of the i810 driver. libGLcore, e.g., is 18 MB..! Compressing with bzip2 does help, but I don't know if archives this big aren't a little against the whole idea of this. But having debugging information could be useful. My suggestion would be strip everything that can be stripped, except for libGL and the Mesa driver, which both run on user space and, in principle, are the only from were we could get a stack trace from a user. Regards, Jose Fonseca Some good news, just when I'm away from school! (and its great connection :) ). But just a thought: it looks like you use the standard host.def for the mach64 build. And the last time I checked out the branch, the #define MesaUse3DNow YES line wasnt in the host.def file (cant check now, since I only have windoze to surf) Since the mach64 isnt powerful, all optimisations are welcome. Are there real performance differences if one can use this option (personnally, I've got an athlon4)? Anyway, if there's an increase in fps, I'll continue to update/recompile the mach64 branch (at least at school) with all optimisations possible, so if anyone is interested in athlon-compiled binary drivers, I can help (but not before march 4th). Regards, Bernard Cafarelli - This mail sent through IMP: http://horde.org/imp/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice - what about specific options?
On 2002.02.25 10:02 [EMAIL PROTECTED] wrote: ... Some good news, just when I'm away from school! (and its great connection :) ). But just a thought: it looks like you use the standard host.def for the mach64 build. And the last time I checked out the branch, the #define MesaUse3DNow YES line wasnt in the host.def file (cant check now, since I only have windoze to surf) Since the mach64 isnt powerful, all optimisations are welcome. Are there real performance differences if one can use this option (personnally, I've got an athlon4)? Anyway, if there's an increase in fps, I'll continue to update/recompile the mach64 branch (at least at school) with all optimisations possible, so if anyone is interested in athlon-compiled binary drivers, I can help (but not before march 4th). Regards, Bernard Cafarelli I think that there is no reason for not enabling every optimization in Mesa on CVS, since the processor abilities are checked on runtime. Does anyone see a problem with this? Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice - what about specific options?
Quoting Ian Romanick [EMAIL PROTECTED]: There are two parts to this. There is the assembly coded parts of Mesa (for 3Dnow SSE) and there are compile switches for GCC. For example, we may wish to see if there are any benefits to building a version with '-mcpu=i686' or '-mcpu=k6' or ... in host.def. If the performance difference is neglegable, then we might at least consider changing the option to '-mcpu=i486 -march=i686'. Are 80386 or 80486 CPUs even supported by DRI? Heh...So I put my PCI Radeon DDR in with my 486SX 20, and RtCW wouldn't run because I only had 8MB... :) -- Tell that to the Marines! Looks like we need some benchmarking :) Also, gcc accepts many options: for example my CFLAGS is 3 lines long (thanks to a linux mag -french edition- dealing about gcc optimisation)... like ffast-math,... Can some of them be useful for gearing up the dri? Regards, Bernard Cafarelli (love this email ending thanks Jose! :) - This mail sent through IMP: http://horde.org/imp/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Unfortunately, as you can notice the packages are huge. Attached is a file list of the i810 driver. libGLcore, e.g., is 18 MB..! Compressing with bzip2 does help, but I don't know if archives this big aren't a little against the whole idea of this. But having debugging information could be useful. My suggestion would be strip everything that can be stripped, except for libGL and the Mesa driver, which both run on user space and, in principle, are the only from were we could get a stack trace from a user. Regards, Jose Fonseca On Fri, 2002-02-22 at 15:00, Jose Fonseca wrote: Hi, I'm just posting to say that I haven't forgot the promise to provide DRI binary driver snapshots. The Alan's scripts are indeed great and do most of the work. I'm just making an wrapper script to them, that synchronizes the local tree with CVS, builds it, and then call dripkg.sh to package each of the drivers. I want to make this script more or less robust so that there is no risk to release crippled drivers. Unfortunately testing it takes a long time, and since I'm not used to program complicated shell scripts, progress has been rather slow. Once this is done I'll make a similar procedure to mach64 branch. Regards, Jose' Fonseca -rw-rw-r--1 jfonseca jfonseca 372592 Feb 22 16:44 ./core/libdri.a -rw-rw-r--1 jfonseca jfonseca 1268904 Feb 22 16:44 ./core/libdrm.a -rw-rw-r--1 jfonseca jfonseca 18199320 Feb 22 16:44 ./core/libGLcore.a -rw-rw-r--1 jfonseca jfonseca 4759484 Feb 22 16:44 ./core/libglx.a -rw-rw-r--1 jfonseca jfonseca 5215 Feb 22 16:44 ./drm/ati_pcigart.h -rw-rw-r--1 jfonseca jfonseca 659 Feb 22 16:44 ./drm/Config.in -rw-rw-r--1 jfonseca jfonseca 3132 Feb 22 16:44 ./drm/CVS/Entries -rw-rw-r--1 jfonseca jfonseca 62 Feb 22 16:44 ./drm/CVS/Repository -rw-rw-r--1 jfonseca jfonseca 56 Feb 22 16:44 ./drm/CVS/Root -rw-rw-r--1 jfonseca jfonseca 8080 Feb 22 16:44 ./drm/dristat.c -rw-rw-r--1 jfonseca jfonseca11455 Feb 22 16:44 ./drm/drm_agpsupport.h -rw-rw-r--1 jfonseca jfonseca 4532 Feb 22 16:44 ./drm/drm_auth.h -rw-rw-r--1 jfonseca jfonseca29431 Feb 22 16:44 ./drm/drm_bufs.h -rw-rw-r--1 jfonseca jfonseca20097 Feb 22 16:44 ./drm/drm_context.h -rw-rw-r--1 jfonseca jfonseca14966 Feb 22 16:44 ./drm/drm_dma.h -rw-rw-r--1 jfonseca jfonseca 1930 Feb 22 16:44 ./drm/drm_drawable.h -rw-rw-r--1 jfonseca jfonseca28264 Feb 22 16:44 ./drm/drm_drv.h -rw-rw-r--1 jfonseca jfonseca 6417 Feb 22 16:44 ./drm/drm_fops.h -rw-rw-r--1 jfonseca jfonseca19806 Feb 22 16:44 ./drm/drm.h -rw-rw-r--1 jfonseca jfonseca 3733 Feb 22 16:44 ./drm/drm_init.h -rw-rw-r--1 jfonseca jfonseca 6621 Feb 22 16:44 ./drm/drm_ioctl.h -rw-rw-r--1 jfonseca jfonseca 5890 Feb 22 16:44 ./drm/drm_lists.h -rw-rw-r--1 jfonseca jfonseca 6699 Feb 22 16:44 ./drm/drm_lock.h -rw-rw-r--1 jfonseca jfonseca12396 Feb 22 16:44 ./drm/drm_memory.h -rw-rw-r--1 jfonseca jfonseca31107 Feb 22 16:44 ./drm/drmP.h -rw-rw-r--1 jfonseca jfonseca17839 Feb 22 16:44 ./drm/drm_proc.h -rw-rw-r--1 jfonseca jfonseca 6184 Feb 22 16:44 ./drm/drm_scatter.h -rw-rw-r--1 jfonseca jfonseca11808 Feb 22 16:44 ./drm/drmstat.c -rw-rw-r--1 jfonseca jfonseca 4632 Feb 22 16:44 ./drm/drm_stub.h -rw-rw-r--1 jfonseca jfonseca14369 Feb 22 16:44 ./drm/drm_vm.h -rw-rw-r--1 jfonseca jfonseca21735 Feb 22 16:44 ./drm/gamma_dma.c -rw-rw-r--1 jfonseca jfonseca 2504 Feb 22 16:44 ./drm/gamma_drm.h -rw-rw-r--1 jfonseca jfonseca 3254 Feb 22 16:44 ./drm/gamma_drv.c -rw-rw-r--1 jfonseca jfonseca 4386 Feb 22 16:44 ./drm/gamma_drv.h -rw-rw-r--1 jfonseca jfonseca 4126 Feb 22 16:44 ./drm/gamma.h -rw-rw-r--1 jfonseca jfonseca32701 Feb 22 16:44 ./drm/i810_dma.c -rw-rw-r--1 jfonseca jfonseca 7488 Feb 22 16:44 ./drm/i810_drm.h -rw-rw-r--1 jfonseca jfonseca 4272 Feb 22 16:44 ./drm/i810_drv.c -rw-rw-r--1 jfonseca jfonseca 7123 Feb 22 16:44 ./drm/i810_drv.h -rw-rw-r--1 jfonseca jfonseca 2392 Feb 22 16:44 ./drm/i810.h -rw-rw-r--1 jfonseca jfonseca37697 Feb 22 16:44 ./drm/i830_dma.c -rw-rw-r--1 jfonseca jfonseca 7772 Feb 22 16:44 ./drm/i830_drm.h -rw-rw-r--1 jfonseca jfonseca 3720 Feb 22 16:44 ./drm/i830_drv.c -rw-rw-r--1 jfonseca jfonseca 7473 Feb 22 16:44 ./drm/i830_drv.h -rw-rw-r--1 jfonseca jfonseca 3806 Feb 22 16:44 ./drm/i830.h -rw-rw-r--1 jfonseca jfonseca 593 Feb 22 16:44 ./drm/Imakefile -rw-rw-r--1 jfonseca jfonseca25588 Feb 22 16:44 ./drm/Makefile -rw-rw-r--1 jfonseca jfonseca 1400 Feb 22 16:44 ./drm/Makefile.kernel -rw-rw-r--1 jfonseca jfonseca 7832 Feb 22
Re: [Dri-devel] DRI packages progress notice
On Fri, Feb 22, 2002 at 04:56:48PM +, Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Just a comment. Why don't you put these up on the DRI pages to keep things in one place ? Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On Fri, 2002-02-22 at 17:02, Alan Hourihane wrote: On Fri, Feb 22, 2002 at 04:56:48PM +, Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Just a comment. Why don't you put these up on the DRI pages to keep things in one place ? Alan. I have no problem with that. So far I've never touched the DRI website. If there is an easy and scriptable way (which doesn't imply storing plaintext passwords somewhere) to upload to the DRI website and if it's Ok with Frank Worsley, I'll do it. Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
I've also put the my (incredible simple and featureless) script for doing this at the scripts/ subdirectory. Jose Fonseca On Fri, 2002-02-22 at 16:56, Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Unfortunately, as you can notice the packages are huge. Attached is a file list of the i810 driver. libGLcore, e.g., is 18 MB..! Compressing with bzip2 does help, but I don't know if archives this big aren't a little against the whole idea of this. But having debugging information could be useful. My suggestion would be strip everything that can be stripped, except for libGL and the Mesa driver, which both run on user space and, in principle, are the only from were we could get a stack trace from a user. Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On Fri, Feb 22, 2002 at 05:15:00PM +, Jose Fonseca wrote: On Fri, 2002-02-22 at 17:02, Alan Hourihane wrote: On Fri, Feb 22, 2002 at 04:56:48PM +, Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Just a comment. Why don't you put these up on the DRI pages to keep things in one place ? Alan. I have no problem with that. So far I've never touched the DRI website. If there is an easy and scriptable way (which doesn't imply storing plaintext passwords somewhere) to upload to the DRI website and if it's Ok with Frank Worsley, I'll do it. Please talk to Frank, I know you've got access as a developer, so it'd be good to get things updated, including your faqs. Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Unfortunately, as you can notice the packages are huge. Attached is a file list of the i810 driver. libGLcore, e.g., is 18 MB..! What is libGLcore.a? Is that actually used? Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
José Fonseca wrote: On 2002.02.22 17:28 Keith Whitwell wrote: Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Unfortunately, as you can notice the packages are huge. Attached is a file list of the i810 driver. libGLcore, e.g., is 18 MB..! What is libGLcore.a? Is that actually used? Keith Is responsible for the indirect rendering and is only used is this circumstance. The question is if there have been any changes across Xfree 4.x /| Mesa /| DRI that could lead to incompatibilities... I can't see why there would have been. This stuff doesn't really talk to the DRI or to the DDX modules in any direct way. I don't think it will need to be replaced on downloads. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On Fri, Feb 22, 2002 at 08:37:08PM +, Keith Whitwell wrote: Jos Fonseca wrote: On 2002.02.22 17:28 Keith Whitwell wrote: Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Unfortunately, as you can notice the packages are huge. Attached is a file list of the i810 driver. libGLcore, e.g., is 18 MB..! What is libGLcore.a? Is that actually used? Keith Is responsible for the indirect rendering and is only used is this circumstance. The question is if there have been any changes across Xfree 4.x /| Mesa /| DRI that could lead to incompatibilities... I can't see why there would have been. This stuff doesn't really talk to the DRI or to the DDX modules in any direct way. I don't think it will need to be replaced on downloads. Keith, libGLcore.a is the internal Mesa code that drives indirect GLX. If anything changes in Mesa, libGLcore.a changes too. Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On 2002.02.22 20:57 Alan Hourihane wrote: On Fri, Feb 22, 2002 at 08:37:08PM +, Keith Whitwell wrote: Jos Fonseca wrote: On 2002.02.22 17:28 Keith Whitwell wrote: ... What is libGLcore.a? Is that actually used? Keith Is responsible for the indirect rendering and is only used is this circumstance. The question is if there have been any changes across Xfree 4.x /| Mesa /| DRI that could lead to incompatibilities... I can't see why there would have been. This stuff doesn't really talk to the DRI or to the DDX modules in any direct way. I don't think it will need to be replaced on downloads. Keith, libGLcore.a is the internal Mesa code that drives indirect GLX. If anything changes in Mesa, libGLcore.a changes too. Alan. It changes, but it doesn't break compatibility, does it? The same thing goes for libGLX. Both these libraries have they behavior pretty standarized and are self contained so changes in their internals should not be noticed by the other components. Assuming that nobody would download a 10 MB set of experimental 3D drivers for get improvements of indirect rendering we probably should leave these out. Regards, _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On Fri, Feb 22, 2002 at 08:59:01PM +, José Fonseca wrote: On 2002.02.22 20:57 Alan Hourihane wrote: On Fri, Feb 22, 2002 at 08:37:08PM +, Keith Whitwell wrote: Jos Fonseca wrote: On 2002.02.22 17:28 Keith Whitwell wrote: ... What is libGLcore.a? Is that actually used? Keith Is responsible for the indirect rendering and is only used is this circumstance. The question is if there have been any changes across Xfree 4.x /| Mesa /| DRI that could lead to incompatibilities... I can't see why there would have been. This stuff doesn't really talk to the DRI or to the DDX modules in any direct way. I don't think it will need to be replaced on downloads. Keith, libGLcore.a is the internal Mesa code that drives indirect GLX. If anything changes in Mesa, libGLcore.a changes too. Alan. It changes, but it doesn't break compatibility, does it? The same thing goes for libGLX. Both these libraries have they behavior pretty standarized and are self contained so changes in their internals should not be noticed by the other components. Assuming that nobody would download a 10 MB set of experimental 3D drivers for get improvements of indirect rendering we probably should leave these out. What I meant is from a bug standpoint. If there's a bug in Mesa which is fixed, then libGLcore.a needs to be replaced. This is only to do with indirect rendering. A severe bug in Mesa can cause the Xserver to crash as it's loaded into the Xservers name space. We've already come across this a few times, and more recently with the NAN/INF problems. Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On Fri, Feb 22, 2002 at 09:17:28PM +, José Fonseca wrote: On 2002.02.22 21:13 Alan Hourihane wrote: On Fri, Feb 22, 2002 at 08:59:01PM +, Jos Fonseca wrote: On 2002.02.22 20:57 Alan Hourihane wrote: ... libGLcore.a is the internal Mesa code that drives indirect GLX. If anything changes in Mesa, libGLcore.a changes too. Alan. It changes, but it doesn't break compatibility, does it? The same thing goes for libGLX. Both these libraries have they behavior pretty standarized and are self contained so changes in their internals should not be noticed by the other components. Assuming that nobody would download a 10 MB set of experimental 3D drivers for get improvements of indirect rendering we probably should leave these out. What I meant is from a bug standpoint. If there's a bug in Mesa which is fixed, then libGLcore.a needs to be replaced. This is only to do with indirect rendering. A severe bug in Mesa can cause the Xserver to crash as it's loaded into the Xservers name space. We've already come across this a few times, and more recently with the NAN/INF problems. Alan. But can't we assume that the user is upgrading from a stable XFree 4.2.0 installation? No. XFree86 4.2.0 is Mesa 3.4.x based, and it seems XFree86 4.3.0 will be Mesa 4.0.x based. A MAJOR update! Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
Alan Hourihane wrote: On Fri, Feb 22, 2002 at 08:37:08PM +, Keith Whitwell wrote: Jos Fonseca wrote: On 2002.02.22 17:28 Keith Whitwell wrote: Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Unfortunately, as you can notice the packages are huge. Attached is a file list of the i810 driver. libGLcore, e.g., is 18 MB..! What is libGLcore.a? Is that actually used? Keith Is responsible for the indirect rendering and is only used is this circumstance. The question is if there have been any changes across Xfree 4.x /| Mesa /| DRI that could lead to incompatibilities... I can't see why there would have been. This stuff doesn't really talk to the DRI or to the DDX modules in any direct way. I don't think it will need to be replaced on downloads. Keith, libGLcore.a is the internal Mesa code that drives indirect GLX. If anything changes in Mesa, libGLcore.a changes too. Yes, but the interfaces to the outside world don't change - the module should be pretty much self contained... shouldn't it? Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On Fri, Feb 22, 2002 at 09:38:28PM +, José Fonseca wrote: No. XFree86 4.2.0 is Mesa 3.4.x based, and it seems XFree86 4.3.0 will be Mesa 4.0.x based. A MAJOR update! Alan. hmmm.. the only way I see to make everyone happy (I'm already seeing Sergey complaining about the size of the download! ;-) is to make two sets of drivers: - one with everything included, including debugging info - another with stripped binaries and without the libraries that do not interfere with the direct rendering (i.e., libGLcore and libGLX) If you assume a XFree86 4.2.0 base, then you put the current DRI drivers from the trunk ontop of that, you'll get Mesa 4.0.x direct rendering and Mesa 3.4.x indirect rendering if you do what your doing. That's o.k, but I'd say less than ideal. As for the size, the default DRI host.def file builds with debugging turned on '-g'. Make sure it's off, the size of the files aren't that big when compressed. Can you explain the size of the files you've currently got ? Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On Fri, Feb 22, 2002 at 09:53:50PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Fri, Feb 22, 2002 at 08:37:08PM +, Keith Whitwell wrote: Jos Fonseca wrote: On 2002.02.22 17:28 Keith Whitwell wrote: Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Unfortunately, as you can notice the packages are huge. Attached is a file list of the i810 driver. libGLcore, e.g., is 18 MB..! What is libGLcore.a? Is that actually used? Keith Is responsible for the indirect rendering and is only used is this circumstance. The question is if there have been any changes across Xfree 4.x /| Mesa /| DRI that could lead to incompatibilities... I can't see why there would have been. This stuff doesn't really talk to the DRI or to the DDX modules in any direct way. I don't think it will need to be replaced on downloads. Keith, libGLcore.a is the internal Mesa code that drives indirect GLX. If anything changes in Mesa, libGLcore.a changes too. Yes, but the interfaces to the outside world don't change - the module should be pretty much self contained... shouldn't it? True, but a less than ideal situation if you've got an indirect core at Mesa 3.4.x and a direct core at Mesa 4.0.x. Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
But can't we assume that the user is upgrading from a stable XFree 4.2.0 installation? No. XFree86 4.2.0 is Mesa 3.4.x based, and it seems XFree86 4.3.0 will be Mesa 4.0.x based. A MAJOR update! I think we have to look at the scope of what we're trying to do: provide an updated dri driver. I'd prefer to view the indirect renderer as being part of the X server, and not really an important part of the download. Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
hmmm.. the only way I see to make everyone happy (I'm already seeing Sergey complaining about the size of the download! ;-) is to make two sets of drivers: - one with everything included, including debugging info - another with stripped binaries and without the libraries that do not interfere with the direct rendering (i.e., libGLcore and libGLX) Do you think this is reasonable? Reasonable, hopefully not confusing for the users. It would be interesting to track the download frequencies of the two versions... Keith ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On 2002.02.22 22:02 Alan Hourihane wrote: On Fri, Feb 22, 2002 at 09:38:28PM +, José Fonseca wrote: No. XFree86 4.2.0 is Mesa 3.4.x based, and it seems XFree86 4.3.0 will be Mesa 4.0.x based. A MAJOR update! Alan. hmmm.. the only way I see to make everyone happy (I'm already seeing Sergey complaining about the size of the download! ;-) is to make two sets of drivers: - one with everything included, including debugging info - another with stripped binaries and without the libraries that do not interfere with the direct rendering (i.e., libGLcore and libGLX) If you assume a XFree86 4.2.0 base, then you put the current DRI drivers from the trunk ontop of that, you'll get Mesa 4.0.x direct rendering and Mesa 3.4.x indirect rendering if you do what your doing. That's o.k, but I'd say less than ideal. I don't see any problem with that. We are not trying to debug the indirect rendering. As for the size, the default DRI host.def file builds with debugging turned on '-g'. Make sure it's off, the size of the files aren't that big when compressed. Can you explain the size of the files you've currently got ? Alan. As I said before on my original posting they were built with debugging info, and I quote: But having debugging information could be useful. My suggestion would be strip everything that can be stripped, except for libGL and the Mesa driver, which both run on user space and, in principle, are the only from were we could get a stack trace from a user. So if the ideal solution is no debugging info at all, I can do this easily by always applying a patch the CVS host.def or site.def. But, IMHO, an ideal solution would be just debugging info on libGL and *_dri.so, and with no libGL and libGLX. Besides Alan and Keith what is the opinion of the others DRI developers? José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
hmmm.. the only way I see to make everyone happy (I'm already seeing Sergey complaining about the size of the download! ;-) is to make two sets :)) I do not like to complain as much as you can think:). But GATOS binary snapshots drivers are only 190K! Even if dri will be 5 times larger - it will still be OK. At least for me. of drivers: - one with everything included, including debugging info - another with stripped binaries and without the libraries that do not interfere with the direct rendering (i.e., libGLcore and libGLX) Just one question: which, if any, of these sets is going it be compatible with XFree 4.2.0? Or Mesa 4.0-compatibility makes this impossible? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On Fri, Feb 22, 2002 at 09:59:01PM +, Keith Whitwell wrote: But can't we assume that the user is upgrading from a stable XFree 4.2.0 installation? No. XFree86 4.2.0 is Mesa 3.4.x based, and it seems XFree86 4.3.0 will be Mesa 4.0.x based. A MAJOR update! I think we have to look at the scope of what we're trying to do: provide an updated dri driver. I'd prefer to view the indirect renderer as being part of the X server, and not really an important part of the download. This seems reasonable to me. If the libGLcore.a is device independent, then why not distribute it by itself? That way, people that want / need it can have it, and people that don't, don't have to bother. -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Unfortunately, as you can notice the packages are huge. Attached is a file list of the i810 driver. libGLcore, e.g., is 18 MB..! 18MB for libGLcore.a seems really large. If I run strip on it then it's only 1.7MB. But evidently that removes some essential XFree86 loader symbols. What about 'strip --strip-debug'? That reduces the module to 2.2MB and it seems to retain the GLcoreSetup and VersRec symbols. I can't test this right now but maybe somebody else can. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On 2002.02.22 22:12 Sergey V. Udaltsov wrote: hmmm.. the only way I see to make everyone happy (I'm already seeing Sergey complaining about the size of the download! ;-) is to make two sets :)) I do not like to complain as much as you can think:). But GATOS binary snapshots drivers are only 190K! Even if dri will be 5 times larger - it will still be OK. At least for me. Yes, but as you can see on http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ the (just uploaded) mach64 driver is more like 50x... ...so I remembered of poor Sergey, with is tiny disk and slow internect connection... ;o) of drivers: - one with everything included, including debugging info - another with stripped binaries and without the libraries that do not interfere with the direct rendering (i.e., libGLcore and libGLX) Just one question: which, if any, of these sets is going it be compatible with XFree 4.2.0? Or Mesa 4.0-compatibility makes this impossible? Cheers, Sergey They will be compatible because they overwrite libGL. Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On 2002.02.22 22:00 Keith Whitwell wrote: hmmm.. the only way I see to make everyone happy (I'm already seeing Sergey complaining about the size of the download! ;-) is to make two sets of drivers: - one with everything included, including debugging info - another with stripped binaries and without the libraries that do not interfere with the direct rendering (i.e., libGLcore and libGLX) Do you think this is reasonable? Reasonable, hopefully not confusing for the users. It would be interesting to track the download frequencies of the two versions... Keith I have a web statistics package on my webserver http://mefriss1.swan.ac.uk/cgi-bin/awstats.pl were one could get that information. This doesn't mean that I won't put my stuff on DRI website: I've sent an email to Frank and I'm waiting for his reply. José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On 2002.02.22 22:27 Brian Paul wrote: Jose Fonseca wrote: Luckily, after sending the previous email the script completed sucessfully. The generated packages are available at: http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/ Unfortunately, as you can notice the packages are huge. Attached is a file list of the i810 driver. libGLcore, e.g., is 18 MB..! 18MB for libGLcore.a seems really large. If I run strip on it then it's only 1.7MB. But evidently that removes some essential XFree86 loader symbols. What about 'strip --strip-debug'? That reduces the module to 2.2MB and it seems to retain the GLcoreSetup and VersRec symbols. I can't test this right now but maybe somebody else can. -Brian Doesn't work. This was the option I first tried at that time. I even tried some wierd configurations that I saw in some SRPMS that eliminated only some sections but 'strip' always removed crucial symbols, no matter what. Only if I have two build trees: with and without debugging info. José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On 2002.02.22 22:49 Daryll Strauss wrote: On Fri, Feb 22, 2002 at 10:24:49PM +, José Fonseca wrote: I have a web statistics package on my webserver http://mefriss1.swan.ac.uk/cgi-bin/awstats.pl were one could get that information. This doesn't mean that I won't put my stuff on DRI website: I've sent an email to Frank and I'm waiting for his reply. I think they should be actual SourceForge releases. That puts a version number on them and keeps them forever. Then you get all statistics automatically. - |Daryll But on a daily basis!? At least this was the initial plan.. I was thinking in using a script that made some kind of rotation eliminating old releases, only adding a snapshot when there were differences, etc... This can be done on the DRI website, but not on SF release system. Although I knew that Alan's scripts were intended for making full releases I always assumed that the point on making these binary snapshots to have a wider test range. We must decide whether we want target frequent testing or stable releases or both, but *not* at the same time! I propose then again 2 separate releases: - a full stable release on SourceForge (scheduled manualy) - an automated cut-down but with debugging info in client libs on DRI website (or in my server until then) I think this suits everyone purposes. Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
Is the idea here to have daily/weekly (or whatever) CVS snapshots or to start an incremental release process seperate from XFree86 releases (i.e., with release tags)? On Fri, 22 Feb 2002, Daryll Strauss wrote: On Fri, Feb 22, 2002 at 10:24:49PM +, José Fonseca wrote: I have a web statistics package on my webserver http://mefriss1.swan.ac.uk/cgi-bin/awstats.pl were one could get that information. This doesn't mean that I won't put my stuff on DRI website: I've sent an email to Frank and I'm waiting for his reply. I think they should be actual SourceForge releases. That puts a version number on them and keeps them forever. Then you get all statistics automatically. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
On Fri, Feb 22, 2002 at 10:54:22PM +, José Fonseca wrote: But on a daily basis!? At least this was the initial plan.. I was thinking in using a script that made some kind of rotation eliminating old releases, only adding a snapshot when there were differences, etc... This can be done on the DRI website, but not on SF release system. Although I knew that Alan's scripts were intended for making full releases I always assumed that the point on making these binary snapshots to have a wider test range. We must decide whether we want target frequent testing or stable releases or both, but *not* at the same time! I propose then again 2 separate releases: - a full stable release on SourceForge (scheduled manualy) - an automated cut-down but with debugging info in client libs on DRI website (or in my server until then) I think this suits everyone purposes. That's a reasonable plan. I didn't mean daily snapshots, but I would like see it updated frequently. We never got to that before and I think that was a mistake. - |Daryll ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI packages progress notice
Ian Romanick wrote: On Fri, Feb 22, 2002 at 09:59:01PM +, Keith Whitwell wrote: But can't we assume that the user is upgrading from a stable XFree 4.2.0 installation? No. XFree86 4.2.0 is Mesa 3.4.x based, and it seems XFree86 4.3.0 will be Mesa 4.0.x based. A MAJOR update! I think we have to look at the scope of what we're trying to do: provide an updated dri driver. I'd prefer to view the indirect renderer as being part of the X server, and not really an important part of the download. This seems reasonable to me. If the libGLcore.a is device independent, then why not distribute it by itself? That way, people that want / need it can have it, and people that don't, don't have to bother. I have to agree with Keith and Ian on this one. I would like to see this packaging pave the way for independent driver suite releases, and avoiding replacing device independent libraries is a big step in the right direction. If we have to replace a device independent file for a driver suite release, then we should look at fixing the interface. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
