Re: [Dri-devel] read/write/select/poll of DRM?
Eric Anholt wrote: Does anything use read/write/poll on the DRM? The drm-filp changes will touch all of the device entry points for BSD, and I was wondering if these functions are still used/useful in the current state of things. I don't think so. There are some gimmick statistics that come out of the device if you cat it, but nothing of actual use in a driver (as far as I know)... Keith --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Improving DRI support for Torque engine games
[EMAIL PROTECTED] wrote: Hello, I do linux ports of Torque engine games from www.garagegames.com. The Torque engine is based on the Tribes 2 engine. From user reports, it seems like the engine has problems with DRI-based cards. I've received reports of problems from users with Voodoo3, Matrix G400, and ATI Radeon 64 DDR cards, ranging from rendering glitches to lockups. I would like to improve the DRI support, but I'm at a loss on how to do it, given that there are many different cards. I have a voodoo3 available, so I could use that to investigate problems. If I fix problems with the voodoo3, is it likely that the other cards will benefit? Some problems may be common across cards, but as the shared component of the drivers (Mesa) is in pretty good shape, it's more likely that the problems you find will be driver specific. That said, the same mistake can be made in multiple drivers. Is anyone in the DRI developer community willing to work with me on these issues? It would be worth it, since many Torque engine games will be released over the next few years (one linux port is complete, two are nearly complete, any many other games are in development). As a first step I'd suggest you get a hold of the cards you're trying to support -- at least a radeon, r200 and maybe a g400. Once you have those, you will be able to provide reasonable help in tracking down bugs. Keith --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page - website in CVS
On Don, 2003-03-13 at 20:49, Smitty wrote: If I can do a CVS commit when I've been changing things on the webserver from the webserver that would be good. You can, but that should be the exception because otherwise the only improvement over the current situation is that there's a backup in the CVS repository. Don't you have a local web server setup you can test with? No. Besides even if I setup apache on my local machine I'd still have to set up a database like the one used for the FAQ on sf.net You could set up a dummy database for testing? I've thought about it a bit more and think that putting just /doc into CVS may be a good idea, the other files either don't change or are only changed by one person at a time / ever. Sounds good to me, we can always add more later. So we create a module called website or whatever containing a doc directory? Anyone, or shall I? I have no objections, btw bear in mind that I managed to delete my local copy of dri/htdocs/ while converting to ResierFS and house cleaning so try not to mess it up.g I always try to be careful. So, which files in doc/ should go into CVS? At a quick glance, only the files in the doc/ directory itself and the images directory; the faq and howto directories are generated, right? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page - website in CVS
On Friday 14 March 2003 05:50 am, you wrote: On Don, 2003-03-13 at 20:49, Smitty wrote: If I can do a CVS commit when I've been changing things on the webserver from the webserver that would be good. You can, but that should be the exception because otherwise the only improvement over the current situation is that there's a backup in the CVS repository. Don't you have a local web server setup you can test with? No. Besides even if I setup apache on my local machine I'd still have to set up a database like the one used for the FAQ on sf.net You could set up a dummy database for testing? Setting up mysql is not hard at all. Also, you can do mysqldump to get the actual data from the sf server, and pipe it right into your own to test with a snapshot of the real data. Nick --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Final new code in texmem-0-0-1 branch (take 2)
Ian, Looks like you've been busy. Here are some comments from the 10,000' level. Keep in mind I haven't looked at your branch, yet. So feel free to point me at the code if my comments are way off base. Ian Romanick wrote: Most of the changes that were in my previous Final new code in texmem-0-0-1 branch patch are in this patch as well. Some of the code, such as the Radeon code-gen updates, has already been committed. http://www.mail-archive.com/[EMAIL PROTECTED]/msg09490.html In addition, a few fixes were made to the device-independent vertical-retrace code. Michal Daenzer pointed out a couple problems with the code, and I've made some work-arounds. The biggest problem was that the user-mode API has to use 64-bit counters for buffer-swaps and retraces, but the kernel ioctls only provide 32-bit counters. I put a small has in vblank.c that should work around most of the problems here. The bulk of the changes were in the GLX support in libGL.so. As mentioned with my previous patch, the current reporting mechanism is wrong. The extensions returned by glXGetClientString(dpy,GLX_EXTENSIONS) is the set of extensions supported by libGL.so. It has *nothing* to do with the server or and direct rendering driver. Keep in mind the spec says string describing some aspect of the client library. So, I believe it's correct to not include server information. You might be able to make a case for including direct rendering driver information, since that's technically part of the client library, but the extensions would need to only list extensions that were supported by all heads, since there is no screen parameter to this entry point. Given that limitation, I think an application developer would use the glXQueryExtensionsString to query the screen specific extensions, and only rely on glXGetClientString to figure out which libGL.so they were dealing with. The extensions returned by glXQueryExtensionsString is the intersection of the set of extensions supported by the client (libGL.so) and the server, plus any client-side extensions (such as GLX_ARB_get_proc_address). I have extended this to include any extensions that are direct rendering only that are supported by the direct rendering driver. This includes extensions like GLX_NV_vertex_array_range. How would you cope with Applications that query a capability, but force indirect rendering? Wouldn't they be misguided into thinking GLX_NV_vertex_array_range was present in the server, when it's probably not available? I believe the DRI is the first project where HW accellerated direct rendering was implemented, but indirect rendering fell back to a software renderer. If we had HW accellerated indirect rendering, I believe these Query functions would work the way they were intended...i.e. the GLX_NV_vertex_array_range would work on an indirect rendering context and should then be advertised by glXQueryExtensionsString. In glxextensions.c I track 5 bits for each extension. Each bit represents one of the following: 1. Is the extension supported by libGL.so? 2. Is the extension supported by the server? 3. Is the extension supported by the direct rendering driver? 4. Is the extension client-side only? 5. Is the extension for direct rendering only? By looking at the state of those five bits, the function __glXGetUsableExtensions can determine which extensions should be exposed by glXQueryExtensionString. If you can figure out a way to add direct rendering only extensions to glXQueryExtensionString without breaking existing applications (something that's hard to qualify) then that sounds like a nice improvement. However, I wouldn't say the existing reporting mechanism is wrong. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Does DRI based kernel driver need a registered major device number?
I have a DRI based DRM driver and wanted to know if it needs a major device number assigned by the linux community, like any standalone driver. Since the driver opens /dev/dri/card0 as it boots up, I'd like to know how exactly does it use the DRIVER_MAJOR, DRIVER_MINOR macros? Are these macros required? Thanks, -- Bhavana --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Final new code in texmem-0-0-1 branch (take 2)
Jens Owen wrote: Ian, Looks like you've been busy. Here are some comments from the 10,000' level. Keep in mind I haven't looked at your branch, yet. So feel free to point me at the code if my comments are way off base. Ian Romanick wrote: Most of the changes that were in my previous Final new code in texmem-0-0-1 branch patch are in this patch as well. Some of the code, such as the Radeon code-gen updates, has already been committed. http://www.mail-archive.com/[EMAIL PROTECTED]/msg09490.html In addition, a few fixes were made to the device-independent vertical-retrace code. Michal Daenzer pointed out a couple problems with the code, and I've made some work-arounds. The biggest problem was that the user-mode API has to use 64-bit counters for buffer-swaps and retraces, but the kernel ioctls only provide 32-bit counters. I put a small has in vblank.c that should work around most of the problems here. The bulk of the changes were in the GLX support in libGL.so. As mentioned with my previous patch, the current reporting mechanism is wrong. The extensions returned by glXGetClientString(dpy,GLX_EXTENSIONS) is the set of extensions supported by libGL.so. It has *nothing* to do with the server or and direct rendering driver. Keep in mind the spec says string describing some aspect of the client library. So, I believe it's correct to not include server information. You might be able to make a case for including direct rendering driver information, since that's technically part of the client library, but the extensions would need to only list extensions that were supported by all heads, since there is no screen parameter to this entry point. Given that limitation, I think an application developer would use the glXQueryExtensionsString to query the screen specific extensions, and only rely on glXGetClientString to figure out which libGL.so they were dealing with. The extensions returned by glXQueryExtensionsString is the intersection of the set of extensions supported by the client (libGL.so) and the server, plus any client-side extensions (such as GLX_ARB_get_proc_address). I have extended this to include any extensions that are direct rendering only that are supported by the direct rendering driver. This includes extensions like GLX_NV_vertex_array_range. How would you cope with Applications that query a capability, but force indirect rendering? Wouldn't they be misguided into thinking GLX_NV_vertex_array_range was present in the server, when it's probably not available? GLX_NV_vertex_array_range defines the glXAllocateMemoryNV() function for allocating high-speed (AGP) memory in the client address space. A renderer running in a remote server won't be able to use it. More below. I believe the DRI is the first project where HW accellerated direct rendering was implemented, but indirect rendering fell back to a software renderer. If we had HW accellerated indirect rendering, I believe these Query functions would work the way they were intended...i.e. the GLX_NV_vertex_array_range would work on an indirect rendering context and should then be advertised by glXQueryExtensionsString. The GLX_NV_vertex_array_range extension, unfortunately, has no formal spec. It's only implied by the GL_NV_vertex_array_range extension (http://oss.sgi.com/projects/ogl-sample/registry/NV/vertex_array_range.txt). It says: OpenGL implementations using GLX indirect rendering should fail to set up the vertex array range (failing to set the vertex array valid bit so the vertex array range functionality is not usable). Additionally, glXAllocateMemoryNV always fails to allocate memory (returns NULL) when used with an indirect rendering context. But a few paragraphs earlier it says: Because wglAllocateMemoryNV and wglFreeMemoryNV are not OpenGL rendering commands, these commands do not require a current context. They operate normally even if called within a Begin/End or while compiling a display list. If glXAllocateMemoryNV() has no notion of a current rendering context, how can it know to return NULL when using an indirect context? These two paragraphs of the spec are in contradiction. My belief is that glXAllocateMemoryNV() should try to allocate fast (AGP) memory regardless of any knowledge of indirect/direct rendering. Only if using a direct rendering context will there be a potential speed-up by using that memory. If using indirect rendering, libGL will simply read (vertex) data out of that region as if it were ordinary memory, pack it into GLX protocol commands, and ship it over the wire. In glxextensions.c I track 5 bits for each extension. Each bit represents one of the following: 1. Is the extension supported by libGL.so? 2. Is the extension supported by the server? 3. Is the extension supported by the direct rendering driver? 4. Is the extension client-side only? 5. Is the extension for direct rendering only? By
Re: [Dri-devel] Final new code in texmem-0-0-1 branch (take 2)
Jens Owen wrote: How would you cope with Applications that query a capability, but force indirect rendering? Wouldn't they be misguided into thinking GLX_NV_vertex_array_range was present in the server, when it's probably not available? I believe the DRI is the first project where HW accellerated direct rendering was implemented, but indirect rendering fell back to a software renderer. If we had HW accellerated indirect rendering, I believe these Query functions would work the way they were intended...i.e. the GLX_NV_vertex_array_range would work on an indirect rendering context and should then be advertised by glXQueryExtensionsString. All of the extensions that I have put in the category, such as GLX_NV_vertex_array_range, are ones that are *never* available in an indirect context. There are a few that fall into that category. They are: GLX_MESA_agp_offset GLX_MESA_swap_control GLX_MESA_swap_frame_usage GLX_NV_vertex_array_range GLX_OML_sync_control GLX_SGI_video_sync In each of these cases there is no GLX protocol defined, so it is impossible to implement them for indirect rendering. The specs for these extensions makes this pretty clear. In all those cases, if one of the functions is called with an indirect context GLX_BAD_CONTEXT is returned. If an app expects these extensions to work with an indirect context, the app is broken. :) We should perhaps look at how the Nvidia drivers advertise some of these extensions. I suspect they probably do it right. :) --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Medical Breakthrough For Men
Introducing VP-RX Pills NO.1 Penis Enlargement Pill On The Market! * Gain 3+ Full Inches In Length * Expand Your Penis Up To 20% Thicker * Stop Premature Ejaculation! * Produce Stronger Erections * 100% Safe To Take, With No Side Effects * Fast Distribution Worldwide * Sold Over 1.2 Million Bottles! * No Pumps! No Surgery! No Exercises! Click below for more information: http://www.pillsmedical.net/cgi-bin/affiliates/clickthru.cgi?id=z1x2c3v4 - You are recieving this message because you have subscribed to one of our or one of our third party partners's offers list. To be opted out of our list email [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] with subject cancel. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri driver features page - website in CVS
You could set up a dummy database for testing? Yes I could, for teh meomnt I installed apache and php, apache works, php doesn't, if I get php working then I'll see about a database. So, which files in doc/ should go into CVS? At a quick glance, only the files in the doc/ directory itself and the images directory; the faq and howto directories are generated, right? IIRC those are Jose's, ask him. g cheers Liam --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Return value for glGetString(GL_VERSION) on R200
Am Freitag, 14. März 2003 02:22 schrieb Ian Romanick: Michael Mazack wrote: Hello, I was wondering about the return value of glGetString(GL_VERSION) on the R200 driver (may be on other drivers too). It seems to return 1.2 Mesa 4.0.4 (this is with XFree86 4.3.0) but the Mesa website says Mesa 4.0 implements the OpenGL 1.3 specification. Is 1.2 the version implemented in the hardware (or mostly implemented in the hardware)? What about 1.3, can it's features be used even though 1.2 is returned (without checking glGetString(GL_VERSION) for 1.3 that is)? If I'm an ignorant fool, please tell me. Comments/explanations/flames are appreciated. There's a whole bunch of stuff that's supported by the software rasterizer in Mesa that isn't supported by all (or most) hardware. Each driver has to enable extensions that it supports. If the right set of extensions is enabled by the driver, the Mesa part of the driver will advertise 1.3. I think the only open-source driver that does this is the R200 driver in CVS. texmem-branch? trunk doesn't (DRI CVS 12.03.2003): Mesa/demos ./glinfo GL_VERSION: 1.2 Mesa 5.0.1 GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_border_clamp 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_transpose_matrix GL_ARB_window_pos GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_convolution GL_EXT_compiled_vertex_array GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_stencil_wrap 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_object GL_EXT_texture_lod_bias GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_texture_rectangle GL_NV_texgen_reflection GL_SGI_color_matrix GL_SGI_color_table GL_RENDERER: Mesa DRI R200 20021125 AGP 4x x86/MMX/3DNow!/SSE TCL GL_VENDOR: Tungsten Graphics, Inc. GLU_VERSION: 1.3 GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess GLUT_API_VERSION: 5 GLUT_XLIB_IMPLEMENTATION: 15 If you run with the environment variable LIBGL_ALWAYS_INDIRECT set, you will get all software, and it should show version 1.3. DRI CVS trunk (12.03.2003) Mesa/demos ./glinfo GL_VERSION: 1.4 Mesa 5.0.1 GL_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 GL_RENDERER: Mesa GLX Indirect GL_VENDOR: Mesa project: www.mesa3d.org GLU_VERSION: 1.3 GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess GLUT_API_VERSION: 5 GLUT_XLIB_IMPLEMENTATION: 15 Regards, Dieter --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Return value for glGetString(GL_VERSION) on R200
Dieter Nützel wrote: Am Freitag, 14. März 2003 02:22 schrieb Ian Romanick: There's a whole bunch of stuff that's supported by the software rasterizer in Mesa that isn't supported by all (or most) hardware. Each driver has to enable extensions that it supports. If the right set of extensions is enabled by the driver, the Mesa part of the driver will advertise 1.3. I think the only open-source driver that does this is the R200 driver in CVS. texmem-branch? trunk doesn't (DRI CVS 12.03.2003): Mesa/demos ./glinfo GL_VERSION: 1.2 Mesa 5.0.1 GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_border_clamp 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_transpose_matrix GL_ARB_window_pos GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_convolution GL_EXT_compiled_vertex_array GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_stencil_wrap 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_object GL_EXT_texture_lod_bias GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_texture_rectangle GL_NV_texgen_reflection GL_SGI_color_matrix GL_SGI_color_table GL_RENDERER: Mesa DRI R200 20021125 AGP 4x x86/MMX/3DNow!/SSE TCL GL_VENDOR: Tungsten Graphics, Inc. GLU_VERSION: 1.3 GLU_EXTENSIONS: GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess GLUT_API_VERSION: 5 GLUT_XLIB_IMPLEMENTATION: 15 Uh...GL_ARB_multisample is one of the required 1.3 extensions. It seems to have gone missing. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI website in CVS driver_naming / features.
http://g7-mac3.fy.chalmers.se/cgi-bin/twiki/view/Forte/WebHome I haven't looked at it That was supposed to read: I haven't looked at it *yet*. That's because the video drivers have had the PCI ID to name mappings changed from Radeon xxx SDR/DDR to Radeon 7200. To my knowledge, it is impossible to distinguish an original Radeon 32/64 SDR/DDR card from a Radeon 7200 card, as all that was changed is the marketing name on the box, and the name mapping in the video driver, etc. If they changed the subdevice ID of the 7200, or bumped the chip revision, then they might be able to be distinguished, however I'm not sure it matters since programatically they're identical. Ja which is why I'm wondering why this is still going on, I've updated the radeon_naming page. Originally the page treated the cards as DRI treated them, ie by which driver they use, hence a 7(0/2/5)00 was a r100 because that was the driver they used. Setting up mysql is not hard at all. Also, you can do mysqldump to get the actual data from the sf server, and pipe it right into your own to test with a snapshot of the real data. Good to know I can bother you when I get to that (after PHP). g I wasn't going to bother with dummy data, may as well do it properly if I'm going to do it all. Liam it depends --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Return value for glGetString(GL_VERSION) on R200
Uh...GL_ARB_multisample is one of the required 1.3 extensions. It seems to have gone missing. Any hope of GL_ARB_multisample being implemented in the hardware? = The nice thing about Windows is - It does not just crash, it displays a dialog box and lets you press 'OK' first. --Arno Schaefer's .sig E-Mail: [EMAIL PROTECTED] Web Site: http://mazack.zikeai.com/ __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Return value for glGetString(GL_VERSION) on R200
Michael Mazack wrote: Uh...GL_ARB_multisample is one of the required 1.3 extensions. It seems to have gone missing. Any hope of GL_ARB_multisample being implemented in the hardware? Not in that hardware! I think only the ATI cards that support it are the R300 family. I think some GeForce 4 family hardware might support it as well. I don't know about anything else. http://delphi3d.net/hardware/extsupport.php?extension=GL_ARB_multisample --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Return value for glGetString(GL_VERSION) on R200
On Fri, 14 Mar 2003 17:04:55 -0800 Ian Romanick [EMAIL PROTECTED] wrote: Uh...GL_ARB_multisample is one of the required 1.3 extensions. It seems to have gone missing. Is that one of the ones ATI wont let us have specs for? If so... Now I think I know why... --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
