Re: [Announce] DRIconf 0.2.5
RPMS are now available as well. I do have a suggestion/issue. I notice that one of the tabs is labeled Features that are not hardware-accelerated and you can really read text on the tab unless you mouse over it. We should probably look at a different wording for that. Non-accelerated Features? Software GL extensions? Non-accelerated Extensions? I imagine you should be able to set a tool tip that will explain it further on mouse over. It is something to think about. On Sun, 27 Mar 2005, Felix [ISO-8859-1] Kühling wrote: Hello DRI users, I'm happy to announce a new DRIconf release 0.2.5. It is now available for download from http://dri.freedesktop.org/wiki/DriConf. Short summary of new features: * I18N (InternationlizatioN), only a German translation so far, more translations are very welcome * More attractive look with icons in the configuration tree * Full editing of unknown options and unknown drivers (though type and range checking is not possible) * Less popup messages The tarball includes a Makefile, which is supposed to make life easier for translators. If you're interested in translating DRIconf to your native language see the start of the Makefile for instructions. Happy Easter, Felix -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396opÌk -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel //\\ || D. Hagemandhageman@dracken.com || \\//
Re: [Announce] New DRIconf version 0.2.3
I have made a RPM, SRPM and SPEC file of driconf available. The RPM was made under Fedora Core 3. The link is in the Download section on this page: http://dri.freedesktop.org/wiki/DriConf I will do my best to track releases to keep them updated, but if you can't wait it should be easy to modify the SPEC file to make it work for you. //\\ || D. Hagemandhageman@dracken.com || \\// --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] New DRIconf version 0.2.3
I added to the Installation instructions: Packages are available for Linux distributions utilizing RPM package management in the Download section. We currently do not have Debian packages available. If you are interested in the role of Debian package manager for this project please send an e-mail to the dri-devel mailing list. On Tue, 15 Mar 2005, Felix [ISO-8859-1] Kühling wrote: Am Dienstag, den 15.03.2005, 10:36 -0600 schrieb D. Hageman: I have made a RPM, SRPM and SPEC file of driconf available. The RPM was made under Fedora Core 3. The link is in the Download section on this page: http://dri.freedesktop.org/wiki/DriConf Could you also add a note near the top of the page, under Installation Instructions? This way people who can use your RPMs can skip the part about manual installation. I will do my best to track releases to keep them updated, but if you can't wait it should be easy to modify the SPEC file to make it work for you. //\\ || D. Hagemandhageman@dracken.com || \\// Thanks, Felix P.S.: Anyone interested in making a Debian package? I have no experience in making Debian packages, so I'd prefer to leave this to someone who has. -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | //\\ || D. Hagemandhageman@dracken.com || \\//
Re: [r300] Results from the weekend.
My tree that I built with was updated and built shortly before I sent out the e-mail. I realize that the ati shader is part of the Mesa code (and it is new), but the thing that weirded me out about it is that technically ... it was never really used. I mean - lesson01 just generates an opengl context and basically waits for the user to shut it down. It is even more interesting when I found the next few lessons after 01 worked fine for me. I will update the tree again, but since I am updating from anonymous it might be an issue that some updates are not getting to me very fast. On Mon, 31 Jan 2005, Vladimir Dergachev wrote: On Mon, 31 Jan 2005, D. Hageman wrote: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] The speed reported by glxgears has improved by about a 100 frames a second over what it was last weekend. I have started to go through the lessons at nehe for testing and I was unable to get past lesson 1. Output: r300NewProgram, target=34336, id=0 vertex prog r300NewProgram, target=34820, id=0 fragment prog r300NewProgram, target=35104, id=0 ati fragment prog Using 8 maximum texture units.. At which point X would freeze. I was still able to log in remotely and shutdown the system. It could be the issue is due to the Mesa tree rather than the driver - the fragment support is very new. Could you try updating to the latest Mesa tree and newest r300_driver code ? I updated this Sunday and it works fine for me.. Quick test of commenting out the calling of the ati fragment program stopped the lockup. I am going to continue on this path of testing and will let you know what I find. Thank you ! Vladimir Dergachev //\\ || D. Hagemandhageman@dracken.com || \\// --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel //\\ || D. Hagemandhageman@dracken.com || \\// --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Results from the weekend.
I just finished updating my CVS tree and rebuilding ... No updates for Mesa showed up, but several for the r300 driver did. I no longer experience the lockups I was having with lesson01. I will continue to test ... On Mon, 31 Jan 2005, D. Hageman wrote: My tree that I built with was updated and built shortly before I sent out the e-mail. I realize that the ati shader is part of the Mesa code (and it is new), but the thing that weirded me out about it is that technically ... it was never really used. I mean - lesson01 just generates an opengl context and basically waits for the user to shut it down. It is even more interesting when I found the next few lessons after 01 worked fine for me. I will update the tree again, but since I am updating from anonymous it might be an issue that some updates are not getting to me very fast. On Mon, 31 Jan 2005, Vladimir Dergachev wrote: On Mon, 31 Jan 2005, D. Hageman wrote: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] The speed reported by glxgears has improved by about a 100 frames a second over what it was last weekend. I have started to go through the lessons at nehe for testing and I was unable to get past lesson 1. Output: r300NewProgram, target=34336, id=0 vertex prog r300NewProgram, target=34820, id=0 fragment prog r300NewProgram, target=35104, id=0 ati fragment prog Using 8 maximum texture units.. At which point X would freeze. I was still able to log in remotely and shutdown the system. It could be the issue is due to the Mesa tree rather than the driver - the fragment support is very new. Could you try updating to the latest Mesa tree and newest r300_driver code ? I updated this Sunday and it works fine for me.. Quick test of commenting out the calling of the ati fragment program stopped the lockup. I am going to continue on this path of testing and will let you know what I find. Thank you ! Vladimir Dergachev //\\ || D. Hagemandhageman@dracken.com || \\// --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel //\\ || D. Hagemandhageman@dracken.com || \\// --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel //\\ || D. Hagemandhageman@dracken.com || \\// --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Results from the weekend.
ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] The speed reported by glxgears has improved by about a 100 frames a second over what it was last weekend. I have started to go through the lessons at nehe for testing and I was unable to get past lesson 1. Output: r300NewProgram, target=34336, id=0 vertex prog r300NewProgram, target=34820, id=0 fragment prog r300NewProgram, target=35104, id=0 ati fragment prog Using 8 maximum texture units.. At which point X would freeze. I was still able to log in remotely and shutdown the system. Quick test of commenting out the calling of the ati fragment program stopped the lockup. I am going to continue on this path of testing and will let you know what I find. //\\ || D. Hagemandhageman@dracken.com || \\// --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] testing results
On Fri, 14 Jan 2005, Vladimir Dergachev wrote: On Fri, 14 Jan 2005, D. Hageman wrote: I took the time to compile the r300 driver and give it a whirl. The machine is a Dell Laptop (Inspiron 9100) with a ATI Radeon Mobility 9600 M10. It has a device ID of 0x4e50. glxgears runs with a 370-380 FPS. Hmm.. There are two possibilities: 1. I have been somewhat careless to commit code with debugging fprintf's - these could be interfering with framerates. The motivation was that part of code (textures) need figuring out and fprintfs are convenient to track things down.. It is all cleaned up by now, so try again - or just hunt down and delete fprintf's by hand. 2. You might be using software rendering and your CPU is quite a bit faster than mine (I get somewhat above 200 on 1.6ghz Pentium-M). Use export LIBGL_DEBUG=verbose to see what happend to glxgears during startup. r300_demo --triangles and --tex-triangles does not give me the same view as the screenshot on the r300 webpage. The tex-triangles is closest to the screenshot on the webpage, but the triangles one is no where close. This is normal - there had been some changes :) I just got done with the second try at this. I pulled the Mesa and r300_driver cvs trees this morning and recompiled. The only hitch was that apparently some changes have happened to the radeon and r200 driver in the Mesa tree that doesn't allow it to compile. Looks like someone added some code with some defines that didn't get into the header. At any rate, still the same situation with the glxgears. It works, but it works slow. I don't get any lockups. I think the r300_demo is working fine. Enabling the LIBGL_DEBUG doesn't show that it isn't finding anything like r300_dri.so or something. Here is the output from glxgears -info GL_MAX_VIEWPORT_DIMS=4096/4096 GL_RENDERER = Mesa X11 GL_VERSION= 1.5 Mesa 6.3 GL_VENDOR = Brian Paul GL_EXTENSIONS = GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_depth_bounds_test GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_shared_texture_palette GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_ATI_fragment_shader GL_HP_occlusion_test GL_IBM_multimode_draw_arrays GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_program_debug GL_MESA_resize_buffers GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_fragment_program GL_NV_light_max_exponent GL_NV_point_sprite GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_NV_vertex_program1_1 GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGI_texture_color_table GL_SGIS_generate_mipmap GL_SGIS_pixel_texture GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_pixel_texture GL_SGIX_shadow GL_SGIX_shadow_ambient GL_SUN_multi_draw_arrays 1858 frames in 5.0 seconds = 371.430 FPS 1863 frames in 5.0 seconds = 372.415 FPS 1871 frames in 5.0 seconds = 374.167 FPS //\\ || D. Hagemandhageman@dracken.com || \\// --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp
Re: [r300] testing results
I was finally able to coerce it into working. I am not sure what I did different to make it work. Getting it to work doubled the FPS from glxgears. At any rate, the results from glxgears are below: Using 8 maximum texture units.. GL_MAX_VIEWPORT_DIMS=4096/4096 GL_RENDERER = Mesa DRI R300 20040924 AGP 1x NO-TCL GL_VERSION= 1.3 Mesa 6.3 GL_VENDOR = Tungsten Graphics, Inc. GL_EXTENSIONS = GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_blend_equation_separate GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_NV_vertex_program GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod r300_render.c:r300_get_primitive_type Not enough vertices to draw primitive 08 - help me ! 4311 frames in 5.0 seconds = 862.151 FPS 4356 frames in 5.0 seconds = 871.109 FPS 4210 frames in 5.0 seconds = 841.978 FPS 4333 frames in 5.0 seconds = 866.465 FPS //\\ || D. Hagemandhageman@dracken.com || \\// --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] testing results
I took the time to compile the r300 driver and give it a whirl. The machine is a Dell Laptop (Inspiron 9100) with a ATI Radeon Mobility 9600 M10. It has a device ID of 0x4e50. glxgears runs with a 370-380 FPS. r300_demo --triangles and --tex-triangles does not give me the same view as the screenshot on the r300 webpage. The tex-triangles is closest to the screenshot on the webpage, but the triangles one is no where close. I am wondering if I compiled something wrong since I don't have high framerates on the glxgears like others are seeing and my r300_demo doesn't match the screenshots. I see that some changes have went into CVS today so I will take the time to compile those tonight. If you have something specific you want me to try with this hardware let me know. //\\ || D. Hagemandhageman@dracken.com || \\// --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Design draft of a new Configuration Infrastructure
On Wed, 19 Feb 2003, Brian Paul wrote: Felix Kühling wrote: Hello list, D. Hageman and I have been bouncing a design document for the new configuration infrastructure back and forth in private mail for the past week. Now we think it's ready for public discussion. You may notice that the structure is quite similar to Ians texmem design. This is the first time I'm writing such a document so I took Ian's work as a good example. The document is attached in plain text format. Nice work! I think you've covered all the issues I'm aware of. Sweet! I have one idea to bring up though. As it is now, you have a 'driConfigurationOptions' symbol in each *_dri.so driver file which would be accessed via dlopen/dlsym. It's up to the configuration tool to determine which driver file to open for a particular screen (using the XF86DRI extension). What if libGL did that for you? That is, we'd add a new internal function to libGL like this: const char *libglGetConfiguratinOptions(Display *dpy, int screen); So, you'd use dlopen() to open libGL.so, then call that function for whichever display/screen you're interested in. libglGetConfiguratinOptions(), in turn, would dlopen the appropriate DRI driver and fetch the options associated with 'driConfigurationOptions'. Then, we'd actually have a DRI-independant mechanism that could potentially be picked up by NVIDIA and ATI for their binary drivers. All they'd have to do is implement the libglGetConfiguratinOptions() function in their libGL.so libs. I am not opposed to this idea. I know originally we were planning on staying away from Mesa if we could just to keep things simple and hopefully have a faster implementation time. However - anything that we can do to make it easier and potentially be better for the end user - I support fully. Felix - see any problems with this? Thanks for the feedback Brian! -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration
On Sun, 16 Feb 2003, Philip Brown wrote: On Sun, Feb 16, 2003 at 05:55:55PM -0600, D. Hageman wrote: So, why not do it by PCI vendor/devid ? That sort of information is visible from the DRI level, I believe. I think its just another Xserver internal call, isnt it? I thought about PCI vendors/devid ... problem with that is that we would like to have a sane configuration for a normal user. I think using that would be too confusing for the user. If we use the identifier that is specified in the XF86Config I think it would be the most logical route - don't you think? What's your definition of sane configuration ? Nothing is stopping you from using the PCI ids as the *actual* tagging mechanism, but perhaps using the xfree86 card name as a comment to help the user out a bit. IMO, that extra config comment stuff should be handled at user-level. Keep that sort of stuff out of the kernel. This won't go into the kernel. This will go into the driver that gets loaded by Mesa that communicates to the module that gets loaded up into the kernel. You can find the source for these drivers in: xc/lib/GL/mesa/src/drv/ You can see what current config options exist by doing: grep -r getenv * I really do appreciate your comments and feedback, but please ask questions if you are unsure of certain aspects of the problem. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Re: DRI Mailing list maintanence / maintaner
On Mon, 17 Feb 2003, Mike A. Harris wrote: On Sat, 15 Feb 2003, D. Hageman wrote: I think spam filtering for dri-devel and dri-users would be a good solution -- IMO, that would be better than moderation. For dri-patches, the Reply-To is dri-devel. I'd rather have just commit messages and nothing else on dri-patches. Any comments/replies to specific patches, or posts dealing with CVS should go to dri-devel anyway. That's why I suggested limiting just dri-patches to sourceforge addresses. I have only been glancing at this thread, but basically it comes down to this - If the spam bothers you that much setup spam filtering on your personal machine and be done with it. We waste more time and bandwidth talking about what should be done (with the list) then actually doing what really should be done (with dri). Just my thoughts ... As stated in my previous mail, I do use spamassassin, and as such I do not have a problem with spam. If you're not interested in the discussion on despamming, then simply hit DEL on the messages that do not interest you, and you'll lose no time at all. If other people wish to discuss it, they can, and will. Freedom of speech. Please - what one minute here! I hold the freedom of speech very close to my heart for specific reasons I won't go into. What I wrote above in no way indicates that I want such a freedom restricted or otherwise removed. What I did write above is an indication of my insight into the problem: 1) Moderating a list restricts the flow of information (thus in some way can be viewed as a restriction of speech ... see above). 2) Limiting the mailing list interaction via mail addresses limits the flow of information (thus in some way can be viewed as a restriction of speech ... see above). 3) Implementing a mailing list wide spam filter can remove potentially beneficial e-mails (thus in some way can be viewed as a restriction of speech ... see above Besides I know it will never happen unless we take the lists off of sourceforge and host them else where ... or so the little birds tell me). Stating that ... too much energy has already been wasted ... on spinning wheels. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration
On Sat, 15 Feb 2003, Philip Brown wrote: On Sat, Feb 15, 2003 at 01:24:26PM -0600, D. Hageman wrote: ... We played around with using Screens and driver names, but in the end we were looking at keying off the device identifier. At this time I still believe that is the best thing to use, but we have no way at this time of grabbing such information from inside a DRI driver. What I would like to do is add a field to the DRIInfoRec struct: char* cardIdentifier or char* configIdentifier ... This option would set in the DRIScreenInit much like the busIdString is set during initialization. Does anyone see any issues with this or does anyone have any technical objections on why this shouldn't be done? I'm coming from a solaris driver background (and am actively working on a drm port to solaris) In solaris, it is much more common (practically required, really) that driver instances are bound to a particular piece of hardware, by the OS level driver loading proceedures. [This is because the OS is very rigid about deciding where to send interrupt notifications to] As such, instances of drm in solaris already come associated with a particular video card. I would like to see a model where, instead of the X server telling /dev/drm/card0, You are bound to this card, the **drm** driver tells the X server, I am associated with this card . (here is the base address, here is the PCI id, etc, etc) I think this is a much cleaner overall design. After all, you dont open /dev/fbX and tell it, I want you to be associated with this video card now... The stuff that I talk about above was regarding individual driver configuration items that are currently being set by using environment variables. It has no bearing on the logic or instrumentation used to bind a particular device to an OS interface. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: DRI Mailing list maintanence / maintaner
On Sat, 15 Feb 2003, Leif Delgass wrote: What about people getting the list as a digest? Also, the spam ends up in the mail archives. I think a person would have to take responsibility for the choices they make. If you so choose to get the list in a digest then you will have to accept that spam happens. I think the digest format is just for people who can't setup mail rules anyway. :-) A nice sourceforge option would be to be able to purge unwanted e-mails out of the archives. On Sat, 15 Feb 2003, D. Hageman wrote: I have only been glancing at this thread, but basically it comes down to this - If the spam bothers you that much setup spam filtering on your personal machine and be done with it. We waste more time and bandwidth talking about what should be done (with the list) then actually doing what really should be done (with dri). Just my thoughts ... On Sat, 15 Feb 2003, Leif Delgass wrote: On Sat, 15 Feb 2003, Mike A. Harris wrote: On Fri, 14 Feb 2003, Leif Delgass wrote: I could do it, but I don't think it's a good idea to restrict those who are non-members of the list. Cross postings from the xfree86 lists are sometimes useful. Alan. What about dri-patches? It gets all the same spam that -devel and -users do. I don't see any reason not to restrict posting to that list to project members. Of course, there may be people with commit access that aren't subscribed. Is there a way to restrict it to sourceforge accounts rather than the subscriber list? Why not just have posts from non-members moderated? They would get held long enough for someone to look at them and go ah, this is not spam, then accept the message for posting. Of course, that would mean a message would get held until a moderator could look at it. I do this on our xfree86-list, and it works well. I dunno if that would be something one of the list maintainers would want to do or not though. Just a suggestion nonetheless. On the other side of things, spamassassin rocks. It nails almost all of my spam. A good 93% to date anyway. I think spam filtering for dri-devel and dri-users would be a good solution -- IMO, that would be better than moderation. For dri-patches, the Reply-To is dri-devel. I'd rather have just commit messages and nothing else on dri-patches. Any comments/replies to specific patches, or posts dealing with CVS should go to dri-devel anyway. That's why I suggested limiting just dri-patches to sourceforge addresses. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRIInfoRec, Identifiers and DRI Configuration
On Sun, 16 Feb 2003, Philip Brown wrote: On Sun, Feb 16, 2003 at 02:00:01PM -0600, D. Hageman wrote: On Sat, 15 Feb 2003, Philip Brown wrote: I think this is a much cleaner overall design. After all, you dont open /dev/fbX and tell it, I want you to be associated with this video card now... The stuff that I talk about above was regarding individual driver configuration items that are currently being set by using environment variables. It has no bearing on the logic or instrumentation used to bind a particular device to an OS interface. Ah. You're just looking for a way to tag a particular video card for user/program configuration option purposes. Re-reading your original email, it looks like you already rejected do it by screen number, and seem to be looking for a more hardware-level identifier. The reason why the screen number is rejected is that we are looking for a method that might be able to follow the device (since this is device level configuration) when DRI matures and can handle things like multi-head, etc. a little more cleanly. Screens are a nice abstraction for a X application developer, but not if you are working with the drivers themselves. So, why not do it by PCI vendor/devid ? That sort of information is visible from the DRI level, I believe. I think its just another Xserver internal call, isnt it? I thought about PCI vendors/devid ... problem with that is that we would like to have a sane configuration for a normal user. I think using that would be too confusing for the user. If we use the identifier that is specified in the XF86Config I think it would be the most logical route - don't you think? -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRIInfoRec, Identifiers and DRI Configuration
Felix and I have been slowing working on a more solidified design of the DRI configuration idea that has been discussed on this list a couple of times. During our last public discussion in which we were talking about configuration file formats we attempted to find a item in which to key everything else from. We played around with using Screens and driver names, but in the end we were looking at keying off the device identifier. At this time I still believe that is the best thing to use, but we have no way at this time of grabbing such information from inside a DRI driver. What I would like to do is add a field to the DRIInfoRec struct: char* cardIdentifier or char* configIdentifier It seems to be the most logical route since most of these type of options already exist there: /* device info */ char* drmDriverName; char* clientDriverName; char* busIdString; This option would set in the DRIScreenInit much like the busIdString is set during initialization. Does anyone see any issues with this or does anyone have any technical objections on why this shouldn't be done? -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Some DRM related changes for running multiple i810/830M X servers
Since the changes touch the general DRM code I would say hold off on making the changes. I think it might be a good idea to push the 4.3.0 out the door and let the vendors pick up that for release since quite a few improvements already exist in the code base. At that point we can focus on a release that has some of the improvements that have been working their way into the DRI CVS tree, but haven't been accepted in the main XFree86 tree since they were too drastic for the 4.3.0 release. Just my thoughts ... On Fri, 14 Feb 2003, David Dawes wrote: Egbert and I have been looking into the issues that are preventing a second X server to be started for i810/830M platforms when DRI is enabled. Several issues were found: 1. The i810 support doesn't unbind/release the agpgart module when VT switching away, and this prevents a second X server from acquiring it. Since the i810 driver requires agpgart access even for 2D operation, this is prevents a second X server from running. A fix for this is to add the unbind/release calls at LeaveVT, and acquire/rebind at EnterVT. The attached patch does this. It also makes a small change to the unbind code in the DRM kernel modules to handle this. 2. The 830M support does unbind/release the agpgart module, but code in DRM(release) called when closing a /dev/dri/* device blocks until it can obtain the lock. Since the first server holds the lock while switched away, the second one can never get it, so it ends up blocking in close(). The second server opens/closes the devices to find out whether DRI can be enabled. DRI can't be enabled on the second server (which isn't a problem), but this blocking behaviour is preventing it from starting up at all. I've found that this can be solved by keeping track of whether the opener has ever tried to acquire the lock, and not try to acquire it at close/release when it had never previously been acquired. The patch below implements this. 3. The drm module AGP support code keeps track of a handle for allocated AGP regions. It uses the memory address returned from the allocation for this purpose. This would normally be unique, but for the i810 driver case where DCACHE memory is allocated. In the DCACHE case, the allocated memory is freed immediately (since DCACHE doesn't come from the system memory pool), and the next allocation often ends up getting the same memory address, and thus the same handle. This showed up as a problem when the unbind/rebind code was added. The user-level agpgart interfaces use a key value to uniquely identify allocated AGP regions. I don't know why the DRM module doesn't do the same, since the key is guaranteed to be unique. The patch below changes the handle to be the key value. I'm wary of making changes like this so close to the 4.3 release, but I would like to see this problem fixed in 4.3. Does anyone see any potential problems with the attached patch? David -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, 28 Jan 2003, Dieter Nützel wrote: Am Dienstag, 28. Januar 2003 08:22 schrieb D. Hageman: On Mon, 27 Jan 2003, Philip Brown wrote: I am trying to point out that none of [-] On the other hand, DRI is meant to integrate with XFree86. XFree86 has a standard configuration file format. We should follow the 'principle of least surprise', and use the same format they are used to for X11 configuration DOES seem to make a good deal of sense, when considering the needs of users as more important than the needs of developers. Two things: 1) Don't kick a gift horse in the mouth. If the users really want something in a certain way are more the happy to do it. 2) The XF86Config file format does what it does very well. It isn't necessarily what we are looking for. It also isn't exactly a library that one can just use. It is a very custom built parser for a very specific purpose. We don't need to re-invent the wheel here. Make the file format as simple as possible. Absolutely. The XML format is already well known and very straight forward. A million and one tools exists for manipulation of these files. Not only for the users but think about remote editing/managing even if it is meant as a local config file. This was good Unix thinking for ages. Absolutely. XML is text based so any text editor can modify it. Assuming we can stick to your first request, then it only follows that it would be easy to do remotely with a simple vi session or ... X11 remote running of applications could do it graphically as well. So what are the technical advantages of XML in this case? Quick List -- *) Text Based - easy to edit. *) Well known basic format (think each tag must be ended, etc.) *) Million and one tools already exist that handle XML if you didn't want to edit by hand. *) Every major programming language has some library to handle XML (say if you hacked togther a library that does the XF86Config file format ... this wouldn't be the case). *) Extensible, no painting ourselves into a corner. One can easily extend the spec without having to rewrite the entire parser. *) Assume that we have to in the future change the format specification: A simple XSLT file could transform the current into the other format without issues or having to write a bunch of C/perl/python code. 'nuff said? In some ways it is over kill. I have this philosophy though: If you do it right the first time and maybe go that extra mile you don't have to worry about it later. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration File Format Example
On Tue, 28 Jan 2003, Ian Romanick wrote: How do we want to handle the case where a user changes video cards? Some of the parameters are likely to be generic, but a lot will be very device specific. The issue here is that the set of available parameters will change. A releated issue is when the set of availble parameters change from one driver release to another. So, do we want to key options on hardware device, screen (in the X sense), or something else? The answer to this question will likely dictate how we handle multi-head. The more I play around with this in my head the more I lean towards keying to the device. The screen is a very generic term and it is supposed to be that way for the abstraction of X11 to work. It however does not lend itself to specific driver tweaking ... hence why the option parameters go in the Device section. I think we're going to end up with two keys. One is the application (with a default available) and the other will be something to identify the device and/or screen. How do we want to specify them? By this I mean, do we want to select the application then the screen (like you suggest above) or the other way around? In all honesty I threw out my example to start some discussion. Not too much thought had went into it. I saw a couple let us see a schema posts so I thought I would see what happen if I posted one. I think the real way it should be done is device, then application. device id=0 application name=... ... /application application name=... ... /application /device One nice side-effect of this is that it becomes very easy to move, delete, or import profile sections. If you want to import a set of application preferences for a specific screen (perhaps from a file that shipped with the application), you just insert its tree in the correct place. If you un-install an application and want to remove its profile, you just delete its subtree. This works with the nesting in either order, as far as I can tell. I'm pretty sure both expat and libxml have the ability to do this easilly. Absolutely. Then there's the issue of how to specify the preferences. How does the driver communicate the set of available options to the various utilities (GUI or otherwise)? This issue is a bit more complicated than it seems. There needs to be a way to specify dependencies (i.e., this option is only available is some other option is set / not set). If we settle on a small set of option types, things are simplified a bit. I'm thinking something similar to the set of available form input types HTML. I think boolean, enum, float, and perhaps string should cover everything we would need. A multi-select enum might also be needed. Sounds reasonable. In the config file, I think the options could be specified as simple name / value pairs. Something like 'option name=tcl_enabled value=true/'. For multiselect enums, the value would be a comma separated list of the selected options. I don't fully understand the nesting in your example. Ah, let me toss out what I was thinking by using the debug node. debug type=verbose Essentially set all debuging to be verbose. texture enable=yes/ Enable texture debugging. ioctl enable=yes/ Disable ioctl debuging /debug It can just as easily been done with option name= value=/ as well. I went with the name of the option in the tag to be more explicit in each scenerio. As an aside, I believe that all of this so far would work with an XF86Config style file format as well. Sometimes you can fit a square peg in a round hole ... I agree. Another thing to consider is internationalization. We should make it possible to specify different translations of text with in the driver's list of options. A utility could read the list of options from the driver and present the user's prefered langauge, if available. As we shift to a Joe User mindset, internationalization will become more and more important. Good call! -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration File Format Example
On Tue, 28 Jan 2003, Ian Romanick wrote: D. Hageman wrote: On Tue, 28 Jan 2003, Ian Romanick wrote: How do we want to handle the case where a user changes video cards? Some of the parameters are likely to be generic, but a lot will be very device specific. The issue here is that the set of available parameters will change. A releated issue is when the set of availble parameters change from one driver release to another. So, do we want to key options on hardware device, screen (in the X sense), or something else? The answer to this question will likely dictate how we handle multi-head. The more I play around with this in my head the more I lean towards keying to the device. The screen is a very generic term and it is supposed to be that way for the abstraction of X11 to work. It however does not lend itself to specific driver tweaking ... hence why the option parameters go in the Device section. What would we use as the device key, then? Would this match the device's name from the XF86Config file? It would have to as no other keying would be reasonable or at least none that I can think of at the momment. There are a few odd corner cases that we need to make sure and get right the first time. User's changing cards and multi-head cards (even though we don't support direct rendering on them now) are the two big ones that I can think of. The way I see some of this is that we just don't have the capability of being super smart about some of this. If a person changes a card then it would indeed invalidate the DRI configuration if it isn't the same variety of card. I don't think that in and of itself is an unreasonable expection. It would be nice to be able to provide some feedback to the user and claim that they have done something screwy. Part of this endeavor should standardize at least the basic configuration options so at least the configuration should be ... reasonably unusable if a card was switched. On a multi-head box the device names should be different so we should be convered there, right? I'm coming to conclusion more the more I think about it. I really can't come up with a good, real-world case to argue for application-then-device. Most of the cases where you'd want the application at the top level could be handled by putting a 'device id=*' around it. Sounds good - I think I am right there along beside on that one. Let me mention as a footnote that I will be out of town starting tomorrow evening. I have to make a quick trip over the big blue pond to see some friends so after tonight I won't be taking part in this discussion until early next week. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
I think you misunderstand. We aren't replacing the XF86Config file here. This is for DRI specific driver settings with capabilities extending to having special options for individual programs if need be. Now if I am mistaken and you did understand ... Your argument is bogus. You can't claim that every XML file format leads to unreadable files. Now, if you have a good *technical* reasons why we shouldn't use XML - I would love to hear them. Couple of good reasons to use XML: *) Parser with validation capabilites already written. *) More and more utilities are using it ... fontconfig for example. *) bindings for all major languages. *) A copy of libxml already exists in the tree if a person doesn't already have it. *) Extensible. *) It can be edited with any text editor. On Mon, 27 Jan 2003, Philip Brown wrote: On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote: If anyone has serious objections to XML, please let us know (mail to dri-devel will suffice ;-). I object. Using xml inevitably leads to files that are completely human-unreadable, except perhaps to the original developers. Please stick with ye olde standard XF86Config type format. It could be better, but it is CERTAINLY better than XML. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Mon, 27 Jan 2003, Philip Brown wrote: Your argument is bogus. You can't claim that every XML file format leads to unreadable files. Now, if you have a good *technical* reasons why we shouldn't use XML - I would love to hear them. Looks like you dont understand. technical reasons are NOT the only reasons that should be considered when evaluating config file formats. Config files are (at least on UNIX systems) generally targetted at users being able to edit them. by hand. Yes, XML file format is a perfect canidate for being editing by hand. *users*, not developers. We plan on making a GUI ala like what is done with many of the graphics drivers on windows to be able to tweak and modify the config file as needed. In the end, the common user would use this most likely. Only power users would use the configuration files. Sure, you could design a schema/dtd/whathaveyou in XML that would be more readable and it would probably end up looking a lot like the XF86Config file format. Or one of the other well known config file formats. Okay, so then your argument kinda goes away now doesn't it? I mean, if we can make an xml file look like the standard XF86Config and if the XF86Config is fine with you then ... well ... your non-technical argument falls apart at the seems. If you want to get experience/resume padding doing XML coding, please do it elsewhere. Please don't make this a personal attack. Public forums are not an appropriate place for such things while we are trying to be constructive. Preferably in an area that XML was designed for: in exchanging data between programs and OTHER programs, not between humans and programs. Simplify: GUI configuration tool (program) -- Driver (program) Couple of good reasons to use XML: *) Parser with validation capabilites already written. *) More and more utilities are using it ... fontconfig for example. *) bindings for all major languages. *) A copy of libxml already exists in the tree if a person doesn't already have it. *) Extensible. *) It can be edited with any text editor. C code can be edited with any text editor, too. But the percentage of DRI users that can usefully DO that, is a very small number, comparative to the overall number of users. Hence the GUI ... I think I have covered all the arguments that needed to be addressed. Seriously, if you a technical reason why ... I would love to hear it. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Mon, 27 Jan 2003, Philip Brown wrote: I am trying to point out that none of XML is cool, XML is a hot trend right now I havent had as much XML experience as I'd like are valid reasons for selecting XML as the basis for a file format. I concur completely and I don't think we have specificed any of those as reasons for choosing XML as the format or at least not in any of the e-mails that I have read. Nor is well, there's an xml library, why dont we use it? There are embedded scheme/java/python/perl libraries too. The argument doesnt make any more sense for those . No, the exact reason I gave was that a libxml library exists currently in the tree so people that do not already have it can get it just by using the source they would already have. It is a convience reason. In your last e-mail you wanted to have it nice for end users ... right here is a good example of being nice to them. On the other hand, DRI is meant to integrate with XFree86. XFree86 has a standard configuration file format. We should follow the 'principle of least surprise', and use the same format they are used to for X11 configuration DOES seem to make a good deal of sense, when considering the needs of users as more important than the needs of developers. Two things: 1) Don't kick a gift horse in the mouth. If the users really want something in a certain way are more the happy to do it. 2) The XF86Config file format does what it does very well. It isn't necessarily what we are looking for. It also isn't exactly a library that one can just use. It is a very custom built parser for a very specific purpose. We don't need to re-invent the wheel here. There are GUI tools for Xfree configuration too, and they have managed to get along fine without using XML. If you want a Library for config file parsing, cant you just use whatever the x server itself uses? No - as stated above it is a custom built parser with very specific operating parameters. You can look at it yourself in the XFree86 tree and you will see what I mean. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Tue, 28 Jan 2003, Sven Luther wrote: On Mon, Jan 27, 2003 at 06:04:19PM -0600, D. Hageman wrote: I think you misunderstand. We aren't replacing the XF86Config file here. This is for DRI specific driver settings with capabilities extending to having special options for individual programs if need be. Now if I am mistaken and you did understand ... Your argument is bogus. You can't claim that every XML file format leads to unreadable files. Now, if you have a good *technical* reasons why we shouldn't use XML - I would love to hear them. Couple of good reasons to use XML: *) Parser with validation capabilites already written. *) More and more utilities are using it ... fontconfig for example. *) bindings for all major languages. *) A copy of libxml already exists in the tree if a person doesn't already have it. *) Extensible. *) It can be edited with any text editor. Another disadvantage is that parsing is so damn slow. Technical argument - sweet! The parsing is so damn slow as compared to ... what? Is this with big documents or small documents? Do adding attributes to a tag slow it down even more? If you validate it when you load it up what performance cost does it incur? The thing about an argument like this is that we need to have some actual numbers before it holds any weight. Something to compare it to ... what alternative do you propose that would be faster? Are we talking seconds, minutes, hours ... what? You get my point. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Configuration file format survey
On Mon, 27 Jan 2003, Philip Brown wrote: On Tue, Jan 28, 2003 at 07:22:33AM +0100, Sven Luther wrote: Another disadvantage is that parsing is so damn slow. Yeah, tell me about it. The place where I work had to buy some auxiliary processing boxes to augment the webservers. Black box appliance like things. SSL processing engines? Nope. XSLT accelerators. I don't believe we need to use XSLT in this little project. XSLT is another issue entirely. As a side note, I think you will find that it is spending more time applying the XSLT to the document then actually loading the document if you run some tests. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] 20021224 RPM Test Set
I have put up the RPMS from my 20021224 build of the XFree86 CVS Head and the DRI CVS Head merged at the following location since I have had a few requests for them: http://people.eecs.ku.edu/~dhageman/XFree86/ Remember, please don't bug Mike Harris about these RPMS ... he had nothing to do with except the creation of the original SPEC file. Actually, don't bug me privately if they don't work. They are provided in case someone wants to easily try to test things out. You will still need to build the kernel module for your card from DRI CVS. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 - what can I do to help?
On Sun, 29 Dec 2002, Mark wrote: So i've been sitting on the sidelines waiting for a fix for the rendering bugs in the R200 driver, but it doesn't seem like anyone is tackling it. I'm running a Radeon Mobility 9000. RTCW is playable but with significant artifacts, half life has same. UT2003 looks totally insane, crazy polygons everywhere. Are you running a recent version (CVS version) of the XFree86/DRI code? I have a Radeon Mobility 9000 and purchased RTCW to test it with and only on occasion did I notice some texture problems. I usually found that shutting down the program and restarting it fixed the issues. Other then that it looks great! I can't comment on the UT2003 though. I have seen some screenshots which makes me believe that patch to convert the textures isn't so ... nice. Has anyone looked at this? If someone could maybe point me at a troubled section of code, I could work on it. I would like to get the RTCW and Half-Life/Wine artifacts fixed at least. Seriously, what type of artifacts are you seeing with RTCW? Do you have a demo that I could run to reproduce these on my system? -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 - what can I do to help?
On Sun, 29 Dec 2002, magenta wrote: On Sun, Dec 29, 2002 at 12:07:40PM +, Keith Whitwell wrote: Mark wrote: So i've been sitting on the sidelines waiting for a fix for the rendering bugs in the R200 driver, but it doesn't seem like anyone is tackling it. I'm running a Radeon Mobility 9000. RTCW is playable but with significant artifacts, half life has same. UT2003 looks totally insane, crazy polygons everywhere. Has anyone looked at this? If someone could maybe point me at a troubled section of code, I could work on it. I would like to get the RTCW and Half-Life/Wine artifacts fixed at least. If someone knows of a very simple program which generates these same errors please let me know, it will make it much easier to track down. That might be a good place to start -- try and find or write (perhaps by modifying the mesa demos) a piece of code that breaks the r200 driver. I know that my engine Solace (http://www.cs.nmsu.edu/~joshagam/Solace/) causes such artifacts... my guess is that it happens when playing back a displaylist which was created using glArrayElement(). (I'm guessing that the screenshot someone posted was using the default configurations, which does that by default.) I got a couple of flickers on the right side of the middle sphere using your default radeon registry file. When I used just the plain default registry file I got quite a few more flickers in the cartoonish sphere and the thingie on the right side. Also, if whoever it was who posted that screenshot could change the Solace setting of GL_draw_method to 0 (which switches to immediate mode rendering rather than using vertex arrays) and see if that continues with the funkiness, that would be another useful data point. :) Switching the GL_draw_method to 1 gave me ... from what I can tell perfect rendering ... well ... at least no flickers. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Availability of CVS RPMS
I have RPMS available of the CVS version of the main XFree86 CVS tree merged with the CVS version of the DRI tree dated 20021224. If anyone is interested in testing with these, then I can make the available. No guarantee they will work for you. I only use the radeon stuff out of them, but all drivers are included. They are made from a modified version of Mike Harris's SPEC file. Let me know. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] R200 - what can I do to help?
On Sun, 29 Dec 2002, magenta wrote: On Sun, Dec 29, 2002 at 08:06:58PM -0600, D. Hageman wrote: I know that my engine Solace (http://www.cs.nmsu.edu/~joshagam/Solace/) causes such artifacts... my guess is that it happens when playing back a displaylist which was created using glArrayElement(). (I'm guessing that the screenshot someone posted was using the default configurations, which does that by default.) I got a couple of flickers on the right side of the middle sphere using your default radeon registry file. When I used just the plain default registry file I got quite a few more flickers in the cartoonish sphere and the thingie on the right side. Cartoonish sphere? Do you mean the torus group? There's only one sphere in the default shader-test scene. :) Yes, that would be the one. If you take all the torus together it reminds me of a cartoonish framework for what could be overall a sphere. Imagine stretching a piece of cloth around the whole grouping ... Also, what do you mean by flickers? It was like the image that was supposed to be clipped because it was hidden became visible briefly as the light went by. It just happens briefly and then it is quickly corrected. This is probably not an accurate description, but there it is. Also, if whoever it was who posted that screenshot could change the Solace setting of GL_draw_method to 0 (which switches to immediate mode rendering rather than using vertex arrays) and see if that continues with the funkiness, that would be another useful data point. :) Switching the GL_draw_method to 1 gave me ... from what I can tell perfect rendering ... well ... at least no flickers. Huh. Oops - mistype. Switching the GL_draw method to 0 correct all of the anomalies I was seeing in the display. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Poor performance with Mobile Radeon 7500
I would like to run a benchmark with Wolfstein on my M9 to see what kind of performance I get. Does a common demo file exist to benchmark the 3D performance that already has results posted somewhere to compare with? On Wed, 25 Dec 2002, Chris Howells wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Wednesday 25 December 2002 06:11, magenta wrote: glxgears makes heavy use of displaylists, which the GeForce drivers are very highly-optimized for, but the DRI drivers are not. OK, maybe so. But even with a Real World app like Return to Castle Wolfenstein, the order of speed goes something like this (from fastest to slowest): Radeon Mobility under Windows GeForce 2 Go under Linux/Windows Radeon Mobility under Linux - -- Cheers, Chris Howells -- [EMAIL PROTECTED], [EMAIL PROTECTED] Web: http://chrishowells.co.uk, PGP key: http://chrishowells.co.uk/pgp.txt KDE: http://www.koffice.org, http://printing.kde.org, http://usability.kde.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE+CfUuF8Iu1zN5WiwRAr+VAKCfY2JdR3QwO2Vnepx/Cs/Fv57KbwCgm7RT G/D+JZyzHB3WHl7qeCGAoS4= =g0gX -END PGP SIGNATURE- --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, 12 Dec 2002, Alan Hourihane wrote: On Thu, Dec 12, 2002 at 01:02:30PM +, Alan Cox wrote: On Wed, 2002-12-11 at 22:11, D. Hageman wrote: Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? It takes two to tango so its not just what I need its also what do they need. What I would like to see would be: A single definitive source for the DRM code, one where contributions go back from Linux, from *BSD, from core XFree86 as well as from the DRI project. I would love to see this as well. I am not sure that this two tree CVS devel method is the most efficient. I am sure it was started for good reasons, but I think it taxes some time for people like me who try keep testing the big picture by running both trees in one. The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). I like that idea ... essentially two copies of DRM in the kernel tree. One that is visible always as it is considered most stable with the current release of XFree86 and the running experimental version. Admittably the compatibility with modules also depends on what version of XFree86 as you noted above - it sure ... complicates things. I guess at some point we have to believe that if you are building your own kernel that you are reasonably competent to figure that one out. Not always the case, but unfortunately it is so hard to check the intelligence sitting in front of the console with a configuring script. ;-) For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. I admit that your logic is sound, but answer me this: Does one send the changes back on the stable to the XFree86 team proper or to the DRI team? The two group devel model gets kinda unwieldy at this point. Right now most vendors have to track the individual patches to XFree86 and DRI in between releases ... and they kinda push the changes back into the code base where they belong when they can. Surely we can thing of a better way to do the tango to help everyone out ... -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
On Thu, 12 Dec 2002, Mike A. Harris wrote: On Thu, 12 Dec 2002, Alan Hourihane wrote: The ability to track changes to that with reasons so that we can keep a stable DRM and also the 'DRM of the day' visible to the kernel people - perhaps the devel kernel tree having an option for Development DRM (XFree86 4.4) (Y/M/N). For 'stable DRM' you need to stick with XFree86 4.2.0 and the DRM modules that ship with 4.2.0. For 'DRM of the day' use the DRI trunk. Do the 4.2.0 DRM modules from XFree 4.2.0 have all the bug fixes in them for things pci_alloc_consistent ? No, nor does 4.2.1. Should anyone be using XFree86 CVS stable branch DRM nor trunk DRM then? I presume if bugfixes are not going into XFree86 CVS stable branches, that the DRM in there is snapshoted and then throwaway. This is pretty much what my claim was the other day when we were talking on IRC ... one needs to see the DRI stuff moved into the XFree86 CVS tree on a regular basis to see any decent results. This is why I take the time to merge in the DRI stuff everytime I build new RPMs to test XFree86 code. Changes to the XFree86 code proper seems to not be getting moved over as quickly as it should. If we want to take a recent example - we can use the xf86strncat symbol missing out of the loader code. The issue was first noticed in the DRI tree, but the change didn't get put into the XFree86 tree until about two weeks later ... and then it was just because I happened to make an off hand comment about it on the xfree86-devel list. I checked the vendor and what not tags on the RPMs I built for myself and you are correct that they are undefined. I really like that new version of RPM. It does nice things [tm]. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM Kernel Questions
Alan, What would you like to see be implemented to help get the job done. In other words, what do you need from the DRI team? On Wed, 11 Dec 2002, Alan Cox wrote: On Wed, 2002-12-11 at 20:12, D. Hageman wrote: I have noticed some feedback from Alan and Linus already on this list. Is anyone taking care of things yet? No. There isnt currently a nice setup for this. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Direct Rendering Enabled / Indirect Rendering Used
I finally got a momment this weekend to build the CVS tree since I had not done it since 11/22. My usual build procedure is that I take the regular XFree86 CVS tree and merge in the DRI stuff ... the merge is fairly straight forward as only certain directories really get touched in the DRI tree (I sure wish a better way could be found then keeping two trees active like this ...). The build went fine and when I loaded up X it proceded to tell me that direct rendering was enabled. However - glxinfo reports that indirect rendering is being used. This started for me after that last large Mesa merge into the trunk at the end of November. Did I miss something on this list that I have to do something special? Attached is my log file for XFree86 for the curious and my glxinfo is pasted below. [dhageman@moko dhageman]$ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.4 Mesa 5.0 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_stencil_two_side, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x25 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x27 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x28 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 None 0x29 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x2a 16 dc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.2 (Custom Build: 4.2.99.2-20021209) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 25 November 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-18 i686 [ELF] Build Host: moko.dracken.com Module Loader present OS Kernel: Linux version 2.4.18-18 ([EMAIL PROTECTED]) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Mon Nov 4 10:05:37 CST 2002 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Mon Dec 9 10:32:21 2002 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout D. Hageman Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (WW) `fonts.dir' not found (or not valid) in /usr/X11R6/lib/X11/fonts/CID/. Entry deleted from font path. (Run 'mkfontdir' on /usr/X11R6/lib/X11/fonts/CID/). (**) FontPath set to /usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6
Re: [Dri-devel] Direct Rendering Enabled / Indirect Rendering Used
[dhageman@moko r200]# grep xf86usleep * Binary file r200_dri.so matches Binary file r200_ioctl.o matches Binary file r200_texmem.o matches I have also attached the compiler output for the compilation of that directory. On Mon, 9 Dec 2002, Keith Whitwell wrote: D. Hageman wrote: The issue has been fixed. It seems that I had the symbol xf86usleep in my r200_dri.so. I stuck in the -DDONT_DEFINE_WRAPPERS and recompiled just that and it works correctly now. Next question is that is this the correct way it should be. Should the *_dri.so drivers have access to the xf86* symbols? If not, then should we stick in -DDONT_DEFINE_WRAPPERS to ensure that this doesn't happen? Hmm. This shouldn't happen. Which .o files reference this symbol? They will be somewhere in lib/GL/mesa/src/drv/r200 Keith -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// r200.output Description: Binary data
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
On Thu, 5 Dec 2002, magenta wrote: There's enough cases that the wrapper couldn't cover that we'd have to implement something in the driver anyway. For example, one of the current env vars tells the Radeon driver to not use HW TCL. How could the wrapper do that? That's not what the wrapper would be for. It'd be for adding quality tweaks (you know, like the whole original point to the post which started this discussion, about defaulting to GL_RGB8 all the time), not driver debugging (or replacing the current driver debug mechanism, namely environment variables). Driver debugging should stay the way it is. Funny, that is what I usually imagine preloading libraries for ... debugging. I mean, it is quite obviously available to be used for other things, but I really do feel that it is exploiting a feature. I mean just because the original VW beatle could float doesn't mean you should use it as a boat ya know? I'd just rather see a wrapper library for *quality tweaks* than a whole mess of environment variables which add bloat and weird edge cases to the drivers themselves. Also, a wrapper library would be consistent across *all* drivers on *all* OpenGL implementations, rather than being specifically for, say, a Radeon running DRI. I think you are predicting something that you can not. You can't claim that the other solutions of environment variables or configuration files would cause inconsistancies and random problems without having an implementation demonstrated. Predicting the future is hard - people try it all the time and they usually lose their ass in the stock market. Another point ... do you know which platforms LD_PRELOAD works on and which doesn't? Have you completely done your research on it? DRI at the momment only supports a subset of the platforms out there, but it doesn't do anything too radical that prevents it from being ported to most if not all platforms ... how will this preloading runtime libraries effect that? Also, the intent isn't to make the wrapper library something which everyone runs. Only people who want to run it would run it. It's not a replacement to libGL, it's just something for tweaking quality, when people want the quality to be tweaked. Which is another thing in its favor - users who don't give a damn wouldn't be subjected to the added overhead, instability, and inconsistency which putting it into the driver itself would cause. Again, you are making claims that you can not support. You have no proof that the added overhead, instability, and inconsistancy would be cause by the other solutions. Let us keep the FUD to a minimum please. Basically, I think the people who want this stuff included into the driver itself have lost sight of what this stuff is *for*. I don't think so ... don't think of it as being included in the driver as that the driver looks at a common interface to determine how it should render the data. If the interface is written correctly, then the code wouldn't have to be recreated in each driver causing your so called inconsistancies. I think we all know what we want, but getting there is just going to have to take some friendly debate and in the end ... some willingness to be flexible with the people that are doing most of the work. :-) -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
On Wed, 4 Dec 2002, magenta wrote: Actually, I just thought of a solution which could possibly satisfy all three camps: have a libGL wrapper library (loaded via LD_PRELOAD) which overrides functionality as needed. Want to force FSAA to be enabled? Put it into glXCreateContext(). Want to force GL_RGB8 when the application chooses GL_RGB? Do it in glTexImage(). Hey, if you want to force GL_RGB4 when the application chooses GL_RGB8, you could do that too! Basically, I see no reason to put this configuration into the drivers themselves, as it could easily be done using an LD_PRELOADed library. That isn't a decent solution. You would have to have a large amount of a wrappers laying around to support all the possible hints/options a person would want to use. It is probably the worst in terms of user friendliness as well. Next please ... -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
On Wed, 4 Dec 2002, magenta wrote: On Wed, Dec 04, 2002 at 02:30:31PM -0600, D. Hageman wrote: On Wed, 4 Dec 2002, magenta wrote: Actually, I just thought of a solution which could possibly satisfy all three camps: have a libGL wrapper library (loaded via LD_PRELOAD) which overrides functionality as needed. Want to force FSAA to be enabled? Put it into glXCreateContext(). Want to force GL_RGB8 when the application chooses GL_RGB? Do it in glTexImage(). Hey, if you want to force GL_RGB4 when the application chooses GL_RGB8, you could do that too! Basically, I see no reason to put this configuration into the drivers themselves, as it could easily be done using an LD_PRELOADed library. That isn't a decent solution. You would have to have a large amount of a wrappers laying around to support all the possible hints/options a person would want to use. It is probably the worst in terms of user friendliness as well. Um, why couldn't a single wrapper override all fo the calls it needs to override for the purpose of providing the functionality of a tweak utility? A single library could easily provide every user-configurable setting here. Okay, I guess I could see what you are saying now ... it still isn't exactly what I would call an elegant solution. The more I think about it the more I cringe of the thought of it. We don't have to make workarounds and cheap hacks to accomplish this -- we have the source code ... we can do it right. 'nuff on that ... I guess the best question is since this idea has caused a lot of heat, but everyone seems to agree that it would be a nice idea - How do we decide where to go next with it? -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
On Tue, 3 Dec 2002, magenta wrote: On Tue, Dec 03, 2002 at 02:38:15PM +, Keith Whitwell wrote: I'm with Allen in preferring that we don't add yet another environment variable - especially for something which other OpenGL drivers haven't needed. Hmm. Windows drivers tend to have a GUI setup utility, which often has this sort of choice in it. That's the closest equivalent I can think of. Why not make an extension for a hint? glHint(GL_TEXTURE_FORMAT_HINT_MESA, GL_FASTEST) for bpp-dependent, and GL_NICEST (and GL_DONT_CARE) would always do it as 32bpp if unspecified. That's the normal OpenGL way of doing things like this... I think the goal is to let the users tweak some of the options. If we go this route, every program will have to have a setup page dedicated to turning this on or this little thing off, etc and so forth. It is okay to do this kind of stuff with games and what not, but not every program needs that level of sophistication. I think being able to have a 3rd party app that would be able to tweak driver options wouldn't be a bad idea. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Smoother graphics with 16bpp on radeon
I will have to balk on Linus' opinion in this situation. I will admit that for a hacker, environment variables are the way to go. Quick and easy ... enough said on that. *If* a system is going to be more user friendly, then configuration files (text based) are the way to go. My reasoning for this is that it is really easy to have the documentation right there in the config file. Don't get me wrong - I don't believe in rewarding stupidity - if you can't read the documentation you get what you deserve. I do enjoy the ability to pop into a config file, seeing potential options and tweaks I can do and selecting them appropriate options based on that. A GUI tool that could easily edit this file should be the ultimate goal (or maybe this should be left up to the appropriate desktop environment *vendors*). On Tue, 3 Dec 2002, magenta wrote: On Tue, Dec 03, 2002 at 11:29:34AM -0800, Linus Torvalds wrote: ... They are also often much more efficient and easier to use than config files (ie just say no to another config file parser). Another note: The amount of code needed to parse a configuration file isn't signifigantly more than the amount of code needed to check the various environment variables. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at: http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS issue - unresolved symbols from GLcore?
On Wed, 27 Nov 2002, Brian Paul wrote: Brian Paul wrote: D. Hageman wrote: Is anyone else experiencing unresolved symbols from GLcore from CVS? It seems that it can't resolve fabsf and xf86strncat (or some variant of). I unfortunately trashed my logs when I reverted back to my previous build of XFree86. I will try again today sometime to see if I can make it go ... or at least see if I can get some more information to debug with. I fixed the xf86strncat problem but haven't heard of fabsf being a problem. Can you describe your OS environment? Actually, I've just checked in a fix (I think) for this to Mesa/src/mmath.h. Do a CVS update and try again. -Brian Yup that killed it. I still had one unresolved reference to xf86strncat, but it still loaded up and went anyway. I did notice that rendering has slowed down on the r200 driver by a magnitude of about 5 times. This of course isn't a very accurate measure purely based of glxgears frame rates, but it does make me raise an eyebrow. I will have to poke around to see what else I can see. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] CVS issue - unresolved symbols from GLcore?
Is anyone else experiencing unresolved symbols from GLcore from CVS? It seems that it can't resolve fabsf and xf86strncat (or some variant of). I unfortunately trashed my logs when I reverted back to my previous build of XFree86. I will try again today sometime to see if I can make it go ... or at least see if I can get some more information to debug with. -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.net email is sponsored by: Get the new Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mesa-4-1-branch
On Mon, 25 Nov 2002, Brian Paul wrote: It might make sense to merge to the trunk soon so that there's one code base to focus on. Everyone seems to want the mesa-41 work to get into XFree86 4.3. What do people think? I say go for it. If we can get it into the trunk then it will be likely more people will try it. In reality - more testing is the only way to ensure that it is golden and the more bug reports that are generated, the better the chances of narrowing down the issues involved (worse case scenerio there of course). -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon M9 DRI patch (Was: Radeon 900 Trials andTribulations)
Scott's patch is also included in the one that I sent, so maybe wording it as an addition to wasn't the best wording. The patch that I sent in is a comprehensive patch of all the changes needed to get DRI to work on the 9000s. On Mon, 4 Nov 2002, Keith Whitwell wrote: D. Hageman wrote: I have a solution to why I was running into problems with getting my Radeon 9000 in my laptop working. One of those things that when you realize what is going on - you feel really silly ;-) The issue was that it wasn't using the r200 driver, but rather the standard radeon driver - which will *not* work. The r200 driver seems to work fairly well. I haven't done any major benchmark or testing, but it does render to the screen and most importantly - it doesn't hard lock my laptop. Attached is an addition to Scott Harrison's patch for the Radeon 9000 that will add CHIP_FAMILY_M9 to the list of chipsets that can use the r200 driver. Can you forward Scott's patch as well, I can't seem to find it. Keith --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- //\\ || D. Hageman[EMAIL PROTECTED] || \\// --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
