Re: Intel(r) G45 Programmer's Reference Manual
Panagiotis Papadakos schrieb: On Thursday 16 April 2009 12:29:44 pm Jin, Gordon wrote: Roland Scheidegger wrote on Thursday, April 16, 2009 8:52 AM: I just fixed the link. Please give it a retry. Thanks Gordon ___ xorg mailing list x...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg The link still does not work! Regards Panagiotis http://intellinuxgraphics.org/Vol_4_G45_subsystem.pdf Works for me now. Previously it didn't. Philipp -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel renderbuffer formats
Eric Anholt schrieb: On Sun, 2008-11-16 at 15:53 +0100, Philipp Klaus Krause wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In intel_fbo.c from the 965 driver RGBA, GL_RGBA2, GL_RGBA4, GL_RGB5_A1, GL_RGBA8, GL_RGB10_A2, GL_RGBA12 and GL_RGBA16 are all mapped to GL_RGBA8. Is this limit imposed by the hardware or the driver? Can the hardware do RGBA16? The public specs list r10g10b10a2, r16g16b16a16, and many others as available formats. OK, I've just had a look at it. There are many formats in the list, but most of them are not available as render target and even less are available as alpha blend render target. It seems though that the hardware could support some floating point RGBA targets and some high precision RGB targets (using e.g. RGBA16 as render target without alpha blending effectively giving us RGB16). Philipp - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
intel renderbuffer formats
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In intel_fbo.c from the 965 driver RGBA, GL_RGBA2, GL_RGBA4, GL_RGB5_A1, GL_RGBA8, GL_RGB10_A2, GL_RGBA12 and GL_RGBA16 are all mapped to GL_RGBA8. Is this limit imposed by the hardware or the driver? Can the hardware do RGBA16? Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkgM/0ACgkQbtUV+xsoLpr8RgCgj3AOhFM2ZofGWCbnmMuJMlc9 H3sAoLUzvseY55EjnoEjcc8hOkqi4SGr =HyuG -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Please provide a way to get software rendering
I think it would be useful if one could choose software rendering without having to uninstall hardware drivers. Maybe a driconf option or an environment variable would be the way to go. This could be useful for trying new OpenGL features not yet supported in hardware drivers, like OpenGL 2.0. Philipp P.S.: No, LIBGL_ALWAYS_INDIRECT doesn't do this, accelerated indirect rendering has been implemented a long time ago. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick schrieb: 2. Decompressing textures for software fallbacks. As far as I'm aware, all of the drivers still have some software fallbacks, so this support is still required. This decompression could be done by the hardware: Ortho projection, nearest-neighbour filtering, render a textured quad, read back from the buffer, use it in the software fallbacks. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiJpLcACgkQbtUV+xsoLppYzwCdEsuuq8zA0JzhOiLdN9YEB/yX 0NUAn0kz0hX7Aso+g5K4hk5vTUEhtERi =ixX+ -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Dösinger schrieb: This may be slightly off topic, but I am wondering if there's any way to detect the ability to upload precompressed textures when GL_EXT_texture_compression_s3tc is not available(aka the user hasn't forced it). Wine and CrossOver users are regularly complaining that their games do not work due to the lack of S3TC, but all Wine needs for D3D is the ability to load precompressed textures(*). So I'd be perfectly happy with getting just this feature, if the user just didn't have to do anything manually. I think writing an extension spec is outside of the scope, but is there something else, like setting an environment variable, or just trying to call glCompressedTexImage even thought the extension isn't advertised? Thanks, Stefan (*) D3D has a feature to compress textures, but it is independent of the hardware's features. If you only use DXT1 there's EXT_texture_compression_dxt1. It offers support for using DXT1 precompressed textures. However AFAIK it'S currently not supported in the free drivers (even if GL_EXT_texture_compression_s3tc is avialable). Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiE7OQACgkQbtUV+xsoLprVfACeM/OLWBBziwcJuFfATXbfOBch M84AoIqj96h0eZ0zPrrhv6X1lLuTPQ1K =41u8 -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Texture compression patents
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roland Scheidegger schrieb: If you only use DXT1 there's EXT_texture_compression_dxt1. It offers support for using DXT1 precompressed textures. However AFAIK it'S currently not supported in the free drivers (even if GL_EXT_texture_compression_s3tc is avialable). Yes, that's true. Also, it wouldn't work (if no software decompression is available) in a software fallback (which generally I guess shouldn't be much of a problem). Can't we just render a quad, with filtering set to nearest and readback to decompress and use the decompressed texture for the software fallback? Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiFAdwACgkQbtUV+xsoLpp1VwCgpffxq6x7YOc53fIztLT7j4DM cgIAoJ9b+YbU7G1jc6q2dIEBCcj1k40w =0kIp -END PGP SIGNATURE- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
How to get software rendering
I tried (as documented in the wiki at http://dri.freedesktop.org/wiki/TestingAndDebugging) export LIBGL_SOFTWARE_RENDERING=1 glxinfo and got OpenGL renderer string: Mesa DRI Intel(R) 965GM 4.1.3002 Philipp P.S.: I know such questions should go to dri-users, but I couldn't get an answear there. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM merging?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt schrieb: No. Gem can't coop with it. Let's say you have a 512M system with two 1G video cards, 4G swap space, and you want to fill both card's videoram with render-and-forget textures for whatever purpose. Who's selling that system? Who's building that system at home? Video game consoles? According to Wikipedia PS3 has 256 MB of RAM vs 256 MB of VRAM. Philipp P.S.: Even my ColecoVision, has 1 KB of RAM vs 16 KB of VRAM. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFILHQVbtUV+xsoLpoRAsaLAJ0fXyrk1n4TE0m/egvm10uACnIxLwCgqjl3 BE0DdbGE1R61oBsbf/zi8cU= =nq1l -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Intel releases 965 documentation under CC license
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems Intel has released complete documentation for the 965: http://intellinuxgraphics.com/documentation.html Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHotwubtUV+xsoLpoRApftAJ4h1J4ErqQpqfrT3bZ0h3jy6h5DpwCg2Re5 SD/CL2cbyzLhmTZlN55ln7I= =V5Qd -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
What happened to VQ texture compression?
Some time ago Vector Quantisation (VQ) texture compression was implemented in some chips like the PowerVR series or the ATI MAch64 and R128. Is this still supported by today's hardware? Is there an OpenGL extension for it (I looked briefly through those texture compression extensions that contain some technical detail about the format they're supposed to support, but didn't find anything that looked like VQ)? Is it supported in DRI somehow? Philipp - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
ATI/AMD says they will release complete graphics chip documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to http://www.0xdeadbeef.com/weblog/?p=302 and http://lwn.net/Articles/248227/ they will release complete hardware documentation. Let's hope it's true this time. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3+O3btUV+xsoLpoRArdXAJ9VTEMzpW+3is5gKaPI/wyGJFA8dACeJaAT pwq5drn553FobHhcN3BRgaI= =ZkEN -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Hardware support for function calling needed to implement GLSL?
GL_ARB_*_program doesn't know about functions. It can easily be implemented on a graphics chip whose shader processors don't know about function calling, indirect addressing, stack, etc: Just a lot of registers, directly addressed would do. What about GLSL? Now there's a C-like language, functions (though recursion isn't allowed). Is a stack, indirect addressing, etc needed? Philipp - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [texture_from_pixmap.c] glXBindTexImageEXT undefined
Dieter Nützel wrote: But what is this? If I set 'setenv LIBGL_ALWAYS_INDIRECT' (tcsh) I get: OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R300 20060815 AGP 4x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.5.1 Shouldn't it OpenGL 2.1 like ~mesa/docs/relnotes-7.1.html stated? No. Accelerated indirect rendering is supported. Philipp - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] enhancing the kernel's graphics subsystem
Benjamin Herrenschmidt schrieb: In collaboration with the FB guys, we've been working on enhancing the kernel's graphics subsystem in an attempt to bring some sanity to the Linux graphics world and avoid the situation we have now where several kernel and userspace drivers compete for control of graphics devices. What's the difference between this and Jon Smirls' proposals from early 2005? Philipp - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [nouveau] a million little pieces affecting nvidia drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexy Khrabrov schrieb: When trying to make nvidia drivers sleep, and then later get nouveau to work, I got hopelessly confused about various pieces of video hardware/software and their mutual entanglements. I'd much appreciates if one of you esteemed video sages takes a few steps towards deconfusion. The TLAs floating in this soup are AGP DRI DRM Obviously, we need a new DRM driver for nouveau as it says to compile it. This installs library libdrm.so -- who uses it? We're talking of DRM, while X refers to DRI? DRM is the part of the 3D driver that is part of the kernel. For AGP cards it depends on the AGP driver in the kernel. Mesa does the OpenGL rendering. It contains both a software implementation and some other backends, the most important one is DRI, 3D hardware drivers, which use libdrm to acces the kernel part. So the AGP driver is at the lowest layer, the DRM accesses the AGP driver and the hardware. libdrm is used by DRI (which is part of Mesa) to access the DRM in the kernel. X uses Mesa for OpenGL rendering. GLX is the part of X that is accessed by OpenGL applications. GLX canbe used over a network, but currently the free drivers don't support hardware-acceleration in this case. Nvidia's proprietary drivers do (though somewhat limited). The situation is similar with ATI's proprietary drivers, but Nvidia's proprietary drivers are different. The framebuffer drivers in the kernel are something different. They are used for advanced graphics stuff on the console (as opposed to X). Different numer of lines and columns on the console and such. They access the same hardware as the DRM does, which sometimes leads to problems. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFqWnDbtUV+xsoLpoRAvnLAJsFEqkTzXrYB9uKpXTuwzT5h2JC3gCgiDWz CqTJwMA9XlpM+DCKVkV42Ag= =iviY -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: seeking a pcie card recommendation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian St. Pierre wrote: Hi - I'm assembling a new pc and have gotten bogged down on video card choices. Can someone here recommend a card? * under US$80 * PCI Express -- motherboard is ASUS M2N-E which has PCIE * take advantage of hw 3d acceleration (optional? willing to wait a bit for an open driver) The PC will use an AMD Athlon 64 X2. My 3d needs are fairly light, I'm not a gamer, just doing occasional 3d modeling. (And this will blow away my current PC even if all 3d is done in software.) I was looking at Nvidia cards, but ATI Radeon seems to be *much* better supported. The nouveau project still has a long way to go, so Nvidia cards won't give you 3D acceleration with free drivers. All ATI cards up to the X850 are supported by free drivers. Have a look at the X600 and X700, those should be available for unter 80$. Philipp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFlAcFbtUV+xsoLpoRAsO4AJ9t59mxlt5bk4eKq6pRRCm2yDWSpQCbBIun CvM+CxXfKI3eRBQTPdm9ui8= =UBVB -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Neverball reflections
Adam K Kirchhoff wrote: I was running some test comparing the r200 vs the r300 driver this morning, and noticed a slight rendering issue with the r200 driver with reflections in the game neverball. I suggest you file a bug, so that this problems isn't forgotten as completly as it would be when only mentioned on the mailing list. Philipp -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: driver level sub-pixel rendering?
[EMAIL PROTECTED] wrote: And the high-precision subpixel processing enables videos to be scaled to any size, so that even small videos look like they were recorded in high-resolution. Trilinear texture filtering should do that. It's supported on any graphics card these days. It's more a matter of whether the video player application uses it. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon X1600?
John Clemens schrieb: There was a post on this list at the end of december(?) indicating that ATI was not interested in helping open source with 3D specs anymore.. I'm guessing they didn't do much with the r300 line either.. but does anyone know anything or have any official word on whether the r500 series of radeon cards will ever be supported by anything other than fglrx for 3D? Any official word from ATI? Is anything known about these cards? AFAIK no one has even started reverse-engineering their driver. There is official word from ATI that they will not give any information to developers of free drivers. German computer magazine c't asked them. Theres one or two sentences about it in an article about the linux driver situation (page 168, magazine from 27.12.2005). The r300 driver was written without any information from ATI. It works with cards up to the X850. Philipp --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Auto-discovery of 3D applications
Felix Kühling schrieb: One more show-stopper for auto-discovery of OpenGL apps is the fact that some applications load libGL dynamically at run-time. I haven't got any feedback to my GL application survey, but at the moment I see a built-in database (does lookup-table sound less scary?) of known GL applications as the only realistic solution. I will have to rely on user-feedback for new entries. I'm hoping that the existance of an application menu with a lack of entries will provide sufficient incentive. What do you want? -A list of common OpenGL applications or -A list of OpenGL applications which often need tweaking through driconf ? The only application I often use that didn't work well with default settings was wings3d on a Radeon 9000 Pro before Roland's point size patch. It was unuseable due to too small point sizes; I had to use indirect rendering. But now it works well without any tweaking, so I didn't send you any feedback. Philipp --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sizeof(I830DRIRec) does not match passed size from device driver
Felix Kühling schrieb: See https://bugs.freedesktop.org/show_bug.cgi?id=5792 for details. I'm fairly certain that we have solved all installation and configuration issues. What remains is some size mismatch that prevents 3D from working on an i855 with a recent binary snapshot. Could someone familiar with the driver take a look at this please? Regards, Felix This is not limited to the i855. See my message to dri-users. I have the same problem with an i915. Philipp --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: adding dri support
Rogelio Serrano schrieb: I have reinvented the wheel and now have standalone opengl on framebuffer by hacking egl support into tinygl. I have also copied over code from mesa and it looks like Ihave reinvented mesa too. Which graphics card has the most open specs so i could start reinventing the wheel again and write a 3d driver from scratch? The SiS 530 is fully documented, but it's a bit outdated and AFAIK there's no 3D driver for it yet. AFAIK The Vodoo cards are fully documented and the driver is so bad it could need a rewrite. Philipp --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: persistant problems with drm + mga
Ian Romanick schrieb: Dave Airlie: Can we get those DRM changes pushed into 2.6.15 or is it too late for that? 2.6.15 has been released yesterday. Philipp --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
ATI documentation
ATI stated that they will not release any information about there hardware to developers of free drivers in the foreseeable future. They were asked by the German computer magazine c't. You can find the information on page 168 in the magazine from 27.12.2005. Philipp --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 + NWN
Adam K Kirchhoff schrieb: I'm sure this confirms what are already known issues with the r300 driver, but felt it'd be worth posting anyway. There's definitely something bizarre going on with textures. They're much crisper with the fglrx driver. To me it looks like the fglrx driver does linear filtering, while r300 does nearest filtering. Philipp --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: I want to help with ATI Mobility Radeon 9600
And 3D-acceleration seems to work! But I get some warnings: *WARN_ONCE* File r300_state.c function r300Enable line 457 TODO - double side stencil ! *** No ctx-FragmentProgram._Current!! That's normal for an experimental unfinished driver like the r300 one. It's slower than it will be after further optimization. PÜrobably the warning above means that hardware can do double sided stencil, but it's not implemented yet in the driver and thus won't work or causes a software fallback. Philipp --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: I want to help with ATI Mobility Radeon 9600
I assume you mean the newest file. If a software fallback for a hardware operation is disabled, does that mean that the operation can not be done at all? (I have no clue what a double side stencil is.) Double sided stencil means that you can select different stencil buffer operations depending on whether a rendered polygon is front-facing or back-facing. This can be used to increase speed of stencil shadow volumes, which are used for shadows in games like Doom 3. You can get some extra boost by sticking: Option ColorTiling true into xorg.conf Sounds good that the driver can be made faster, but why would I have to turn it on in a configuration file? Some options cause problems for some users. A typical example are AGP fast writes: While they can increase speed they will lead to crashes with some graphics chip revision / mainboard chipset / BIOS combinations. Tiled rendering was added to the driver later and is not yet as well-tested as the rest. Philipp --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r128 software features patch
Ian Romanick schrieb: Here's my opinion on the matter, but I'd like to hear from Brian or Keith. 1. All drivers should expose GL_ARB_vertex_program and GL_MESA_program_debug. I don't care either way about the NV extensions. So you think we should announce it even though the spec says OpenGL 1.3 and 1.4 are required? Maybe Brian can tell us why he thinks that GL_MESA_program_debug needs 1.4. Philipp --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r128 software features patch
Roland Scheidegger schrieb: Well the discussion only inovlved two people :-). It's quite possible others might think it's worthwile, I'm certainly no authority on that. I know. This is what Ian wrote last time I posted the patch (when it still included GL_EXT_vertex_cull): My only other comment is that *all* the open-source drivers should support *all* of these extensions and GL_SGIS_generate_mipmap. There are a few that even still need fake support for GL_ARB_multisample and GL_ARB_texture_compression added. :( But since the GL_ARB_vertex_program spec says that it requires 1.3 (which the r128 can't do in hardware due to the lack of cube maps, dot3 bumpmapping and texture combining) that one can't be added (making it a configuration option disabled by default probably isn't worth it unless are users complaining about a missing feature). That would only leave GL_NV_vertex_program. Since this only requires OpenGL 1.2.1 it might become a kind of standard for vertex programs on free linux drivers. But apart from that it would need an application that requires it to justify it's addition. Most games probably don't count here since they would require a faster graphics chip to be playable anyway. Celestia might be a candidate for this. It can use GL_NV_vertex_program and there seem to be some people using it on old cards (even mach64). Philipp --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r128 software features patch
I hvae removed GL_EXT_cull_vertex from my patch, since Brian wants to remove it from Mesa, too. Since the r128 doesn't have hardware tcl all interesting features of Mesa's software tcl should be exposed. This patch adds support for GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_EXT_multi_draw_arrays, GL_MESA_pack_invert, GL_NV_vertex_program, GL_NV_vertex_program1_1. For the last two a configuration option has been added. I have tested using the programs in Mesa/progs/tests. They seem to behave just like on i915, that means everything works expect vptest1 and vptest2, where assertions fail. Philipp --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r128 software features patch
Stephane Marchesin schrieb: What is the point of advertising GL_MESA_pack_invert if it's not implemented ? Stephane According to extensions specification this extension's main purpose seems to be making application developers life a little bit easier, just like GL_MESA_window_pos/GL_ARB_window_pos does, not exposing hardware features. So I thought it might be useful to advertize this one. The i915 driver does the same. Philipp --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r128 software features patch
In that sense, I'd consider NV_vertex_program as bloat just as well. Applications really always can deal with not available non-standard extensions very well. About GL_NV_vertex_program: 1) It was the first nice vertex program interface and is used in many old tutorials on vertex shading. 2) Currently Mesa layers GL_ARB_vertex_program on top of GL_NV_vertex_program. A driver that already advertizes GL_ARB_vertex_program can support GL_NV_vertex_program for free. 3) It is a widespread extension, not a Nvidia-specific one: It is implemented by the i915 driver, the mga driver, the tdfx driver, the r300 driver, the non-free 3Dlabs drivers and of course all the Nvidia drivers. 4) I added an option to deactivate it. Philipp --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r128 software features patch
Roland Scheidegger schrieb: btw it looks you can't announce ARB_vertex_program on r128. The extension says not only based on OpenGL 1.3, but it requires OpenGL 1.3. I think that leaves two options 1) Don't add any vertex program stuff to the r128 driver. In that case the patch I posted should be ignored. Vertex program support should be removed from the mga and tdfx drivers, since they only support OpenGL 1.2. 2) Make GL_ARB_vertex_program support a configuration option that defaults to off. The same should be done with the mga and tdfx drivers. Philipp --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r128 software features patch
Since vertex program support was the main point of the patch, and the discussion has shown reasons not to add any vertex program support to the r128 I think that my patch should be ignored. I might create another one once Mesa implements vertex shaders. Philipp --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Roland's point size patch. Was: Re: [Bug 702] Radeon only supports a maximum point size of 1.0.
Roland found out how to do bigger aliased points on r200 hardware a long time ago. AFAIK the patch was never applied since people failed to see it's importance. 3D modellers use points to mark the currently selected vertices. A maximum point size of 1 means they are invisible with today's screen resolutions. This makes the r200 DRI driver useless for 3D modelling with those applications. Bigger point sizes are really necessary! Roland's patch supported only aliased points, but since the maximum point sizes for aliased and antialised points can be different that would never cause a software fallback. I know that the popular free wings3d modeller uses only aliased points and think that it's the same with other 3d modellers. Philipp --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Roland's point size patch. Was: Re: [Bug 702] Radeon only supports a maximum point size of 1.0.
I can apply a patch if you think it's useful. I just thought that antialiased is the norm for points rather than the exception, but if it's not it could indeed be useful. Antialiased points probably are the norm for most applications (games, etc). 3d modellers seem to be an exception here. wings3d uses aliased points. Looking at some Maya plugin developer documentation indicates that Maya, too uses aliased points. Philipp --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R280 texture pipe bug still there [PATCH]
believe it or not pkgconfig actually makes your life easier...once you get to know it ;) It's the unix way. It basically tells you where to find header information for various packages. You copy the package's .pc file to the pkgconfig directory (often /usr/lib/pkgconfig). then try and build again. Alex To someone just wanting to get DRI working the libdrm stuff makes things more complicated. I think libdrm just just install itself to some location where it is found by pkgconfig by default, so that one doesn't have to learn about pkgconfig just to compile Mesa. Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
stencil buffer on the r128
I found 4 mails in a thread about this in the list archive, but all except the first drifted away to GL_EXT_stencil wrap on the r100. Are the patches for this still around somewhere? What has been found out about the hardware stencil buffer on the r128? Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: State of the SiS driver
Alan Cox schrieb: On Sul, 2005-08-14 at 21:03 +0200, Philipp Klaus Krause wrote: not yet. Alan Cox had a semi-working version here: http://www.linux.org.uk/~alan/sis6326.tar.gz This only contains the DRI part. Does that mean it uses the same DRM as the 305? There is a small patch to the 2D driver needed and the 3D driver needs the PCI ids adding. As it stands the sis6326 driver bypasses the DRM most of the time at the moment for debugging and just whacks the hardware as root. I can dig out the other bits if you are interested but I would suggest a better idea would be to buy a real video card 8) In any case it would be good if you just added them to http://www.linux.org.uk/~alan/sis6326.tar.gz so that anyone wanting to do some work on the driver can easily find them. I'm not yet sure if I'll work on it. It might depend on how much time university will leave me for DRI next term. Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
GL_CLAMP, GL_REPEAT problem Mesa/i915/r128
Look at the output of Mesa/progs/tests/texwrap With the i915 driver there's no green without a border. Indirect rendering and the r128 driver always show the area around the [0,1]x[0,1] red aread in green. What is the supposed display with GL_REPEAT? With indirect rendering there is no green grid. With the i915 driver there is exactly when the texture has a border. With the r128 there's always a green grid. Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI Feature Table
What happened to this one? I found some discussion about it in the mailing list archive, but I didn't find it in the wiki. Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI Feature Table
Philipp Klaus Krause schrieb: What happened to this one? I found some discussion about it in the mailing list archive, but I didn't find it in the wiki. Philipp OK I found it at http://dri.sourceforge.net/doc/dri_driver_features.phtml Shouldn't this be ported to the wiki? Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Patch: r128 software features
Ian Romanick schrieb: I could have sworn that the vertex-program extensions and GL_EXT_cull_vertex each required an addition TNL pipeline stage. I see that the i915 driver adds _tnl_vertex_cull_stage and _tnl_vertex_program_stage. Why does r128 not need those additions? The r200 and the i915 use a custom vertex pipeline. The r128 uses the standard variant, which already includes the vertex_program stage. Sorry for the cull vertex stuff. I overlooked that it isn't in the default pipeline. I'll post a patch with that extension removed. Maybe this stage should be added to the default pipeline. My only other comment is that *all* the open-source drivers should support *all* of these extensions and GL_SGIS_generate_mipmap. There are a few that even still need fake support for GL_ARB_multisample and GL_ARB_texture_compression added. :( I have some old cards lying around. I wanted to add these anyway. Since the r128 was the only one to really work (savage would probably need a newer xorg, for SiS problems see my post SiS 305 problems I began with the r128 driver. But not all drivers should always support these always. For cards that support TcL vertex programs are something that replaces hardware with slower software. Therefore I made it a configuration option on the r200 a year ago (with the ARB version on by default). Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
State of the SiS driver
I have some questions about the SiS driver: 1) The SiS driver looks different from the other drivers. It doesn't have a custom tnl_pipeline as all the other drivers except tdfx do. Was this some old style of writing drivers and all others have already been converted? 2) Has any of the work on DRI for SiS 6326 been merged into DRM or Mesa? 3) Is there any documentation for the SiS 305. I mean, what did the people that wrote this driver use? Or is it just a 6326 with another texture unit added so the documentation for the 6326 was used? The wiki says there is no documentation except that two documents from UtahGLX which obviously aren't enough for writing a driver. Was this driver released by SiS or was the chip reverse-engineered? Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Xegl on old hardware?
What are the minimum requirements of Xegl in terms of extensions supported? Which modifications to a driver are necessary for EGL? Wich parts of the driver (DRM, fb, DRI) have to be modified? Will Xegl run fast enough on old hardware like the RagePro 3D or the SiS 305 or Sis 6326? Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Xegl on old hardware?
Adam Jackson schrieb: On Sunday 14 August 2005 09:59, Philipp Klaus Krause wrote: What are the minimum requirements of Xegl in terms of extensions supported? Not much. See http://freedesktop.org/wiki/Software/Xgl, but the major requirements are: NV_texture_rectangle This shouldn't be really necessary if one is willing to waste some texture memory. ARB_texture_border_clamp The r128 for example supports it, but it's not yet exposed in the free driver. ARB_multitexture OK. Everything except the SiS 6326 should supports it, though I don't know about mach64 (the driver has the extension, but I don't think the hardware has really more than one texture unit). ARB_texture_env_combine SiS 305 and 6326 don't support it. Neither do r128 or mach64. Maybe I'll see if I can get Xgl eunning on the r128 or some other older card. Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Patch: r128 software features
Since the r128 has no hardware tcl and tcl has to be
done in software anyway I think it should have a
full-featured tcl. This patch enables some extensions:
GL_ARB_vertex_buffer_object
GL_ARB_vertex_program
GL_EXT_cull_vertex
GL_EXT_multi_draw_arrays
GL_MESA_pack_invert
GL_NV_vertex_program
GL_NV_vertex_program1_1
The last two can be disabled using driconf if desired
for the same reasons I made them disabled by default
when I added vertex program support to the r200 driver
a year ago.
I tested with the programs in Mesa/progs/demos and
Mesa/progs/tests and everything seems to work fine
except vptest1 and vptest2. Since these two
don't work on my i915 either I suppose the problem is
with Mesa's program parsing and not r128-specific.
Philipp
? depend
? r128_software.patch
Index: r128_context.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r128/r128_context.c,v
retrieving revision 1.19
diff --unified -r1.19 r128_context.c
--- r128_context.c 28 Jul 2005 00:29:52 - 1.19
+++ r128_context.c 14 Aug 2005 18:29:42 -
@@ -68,7 +68,12 @@
#define need_GL_ARB_multisample
#define need_GL_ARB_texture_compression
+#define need_GL_ARB_vertex_buffer_object
+#define need_GL_ARB_vertex_program
#define need_GL_EXT_blend_minmax
+#define need_GL_EXT_cull_vertex
+#define need_GL_EXT_multi_draw_arrays
+#define need_GL_NV_vertex_program
#include extension_helper.h
const struct dri_extension card_extensions[] =
@@ -78,14 +83,26 @@
{ GL_ARB_texture_compression,GL_ARB_texture_compression_functions },
{ GL_ARB_texture_env_add,NULL },
{ GL_ARB_texture_mirrored_repeat,NULL },
+{ GL_ARB_vertex_buffer_object, GL_ARB_vertex_buffer_object_functions },
+{ GL_ARB_vertex_program, GL_ARB_vertex_program_functions },
{ GL_EXT_blend_subtract, GL_EXT_blend_minmax_functions },
+{ GL_EXT_cull_vertex,GL_EXT_cull_vertex_functions },
+{ GL_EXT_multi_draw_arrays, GL_EXT_multi_draw_arrays_functions },
{ GL_EXT_texture_edge_clamp, NULL },
+{ GL_MESA_pack_invert, NULL },
{ GL_MESA_ycbcr_texture, NULL },
{ GL_NV_blend_square,NULL },
{ GL_SGIS_generate_mipmap, NULL },
{ NULL,NULL }
};
+const struct dri_extension NV_vp_extensions[] = {
+{ GL_NV_vertex_program, GL_NV_vertex_program_functions },
+{ GL_NV_vertex_program1_1, NULL },
+{ NULL,NULL }
+};
+
+
static const struct dri_debug_control debug_control[] =
{
{ ioctl, DEBUG_VERBOSE_IOCTL },
@@ -248,6 +265,8 @@
driInitExtensions( ctx, card_extensions, GL_TRUE );
if (sPriv-drmMinor = 4)
_mesa_enable_extension( ctx, GL_MESA_ycbcr_texture );
+ if(driQueryOptionb(rmesa-optionCache, nv_vertex_program))
+ driInitExtensions( ctx, NV_vp_extensions, GL_FALSE );
r128InitTriFuncs( ctx );
r128DDInitStateFuncs( ctx );
Index: r128_dd.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r128/r128_dd.c,v
retrieving revision 1.5
diff --unified -r1.5 r128_dd.c
--- r128_dd.c 4 May 2005 20:11:38 - 1.5
+++ r128_dd.c 14 Aug 2005 18:29:42 -
@@ -44,7 +44,7 @@
#include utils.h
-#define DRIVER_DATE 20041026
+#define DRIVER_DATE 20050814
/* Return the width and height of the current color buffer.
Index: r128_screen.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r128/r128_screen.c,v
retrieving revision 1.21
diff --unified -r1.21 r128_screen.c
--- r128_screen.c 29 Jul 2005 00:19:36 - 1.21
+++ r128_screen.c 14 Aug 2005 18:29:43 -
@@ -68,11 +68,14 @@
DRI_CONF_PERFORMANCE_BOXES(false)
#endif
DRI_CONF_SECTION_END
+DRI_CONF_SECTION_SOFTWARE
+DRI_CONF_NV_VERTEX_PROGRAM(true)
+DRI_CONF_SECTION_END
DRI_CONF_END;
#if ENABLE_PERF_BOXES
-static const GLuint __driNConfigOptions = 4;
+static const GLuint __driNConfigOptions = 5;
#else
-static const GLuint __driNConfigOptions = 3;
+static const GLuint __driNConfigOptions = 4;
#endif
extern const struct dri_extension card_extensions[];
Re: State of the SiS driver
Alex Deucher schrieb: 2) Has any of the work on DRI for SiS 6326 been merged into DRM or Mesa? not yet. Alan Cox had a semi-working version here: http://www.linux.org.uk/~alan/sis6326.tar.gz This only contains the DRI part. Does that mean it uses the same DRM as the 305? --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
SiS 305 problems
The Card is a PCI SiS 305 with 32 MB RAM. I use DRM and Mesa from CVS with a 2.6.13-rc5 kernel. I see 1) I get segfaults in many OpenGL programs, including glxgears and gears from Mesa/progs/demos. The segfaults are always in neutral_VertexAttrib4fvARB. The problem seems to occur in all programs using vertices. Programs using only DrawPixels() and such are not affected. 2) The driver has GL_NV_vertex_program in it's extension string. I have not found a single occurance of GL_NV_vertex_program in the driver source. Wile I think the driver really should support vertex programs and wanted to add them anyway this seems strange. 3) I get lots of Mesa 6.3.1 implementation error: User called no-op dispacth function (an unsupported extension function?) messages with the programs that otherwise work. If I remove glutMainLoop() from winpos.c I get none, but if I remove the gl calls from the draw() function they still appear. What could be the cause of these problems? Philipp --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OGL compliance, and DRI interface...
Alan Grimes schrieb: I've been hacking on my version of the N64 emulator again and I noticed I was getting an invalid value error from the texImage2D command... I assumed that it was because it required textures to be a power of two in size... Then I checked the GL spec and the only mention I found was that for cube map textures, the height and width must be equal. If that were the only limitation, I wouldn't be getting: You probably looked at the OpenGL 2.0 specification. Non-power-of-two textures are a new feature in OpenGL 2.0. Philipp --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GL_ARB_texture_env_crossbar for r200
Roland Scheidegger schrieb: Here's a somewhat experimental patch to enable GL_ARB_texture_env_crossbar on r200. It got more ugly than I wanted... Works with tests/crossbar, glean(texcombine), couldn't find anything more which uses it (well ut2k4 seems to, but I couldn't see any difference). There's glest, a free strategy game, which uses GL_ARB_texture_env_crossbar. Philipp --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] on lockups
Vladimir Dergachev schrieb: My understanding is that AGP only does transfers system RAM - video RAM and all transfers in the opposite direction have to use plain PCI transfers at least as far as the bus is concerned. AGP can do both. Every AGP compliant device has to support the System RAM - video RAM part. The other one is optional. Optional not only in the graphics card but in the northbridge, so there are some cheap chipsets that don't support it. This lead to many card manufacturers not supporting it in their cards and drivers. Highend graphics cards like the Wildcat support it. Philipp --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
Nik schrieb: Philipp! Vielen Dank. Philipp Klaus Krause wrote: Nik schrieb: It's unlikely that you'll have to debug the kernel module. The bug probably is is the DRI. Ok, thanks. Any tips on what I should be looking for in the DRI? If the problem is in the DRI, then does that it mean it should affect cards/drivers other than r200? No. The structure of the drivers is about this: The card-speciifc module in the kernel, which is used by the card specific driver part in the DRI. DRI is in the Mesa tree, which also contains the non card-specific stuff: Basically there is the Mesa software implementation and the DRI drivers replace some parts of that with hardware-specific functionality. If I remeber correctly, the problem does not affect Mesa software rendering. Thus it should be in the r200 specififc part. That lives in Mesa/src/mesa/drivers/dri/r200. Philipp --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
Nik schrieb: Philipp Klaus Krause wrote: Nik schrieb: Oh ok. So in terms of names, the structure is: The card-speciifc module in the kernel == radeon the card specific driver part in the DRI. == r200 correct? Yes. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: SIGSEGV in r200 when called by JOGL (Java for OpenGL)
Nik schrieb: ...which brings me to the next point: Presumably, I should be testing/debugging this in a recent version of the DRI source? But which one? Should I be checking out from CVS? Or is it acceptable for me to work with the source of my distro (2.6.11-1.14_FC3)? And could someone please point me to a document that explains how I should proceed to update my machine to the correct DRI version? I tried to update to a number of newer versions of DRI, but I always get symbol missing and/or symbol mismatch errors. For the DRI you should use the latest CVS version. For the Xorg or XFree you can keep your distributions version. For the DRM use the one from CVS or from a recent kernel. You 2.6.11 should be fine. Build instructions are at http://dri.freedesktop.org/wiki/Building It should be enough to install the 3D drivers as described in that document in section 1.8. Philipp --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] glPopAttrib() issue (Scorched3D)
Rune Petersen schrieb: Hi, Enabling water in Scorched3D causes corruption of all textures and I have tracked it down to interaction between glPopAttrib() and the attributes GL_TEXTURE_GEN_S GL_TEXTURE_GEN_T. I using the latest CVS updates of Xorg, Mesa, and r300_driver. This problem is not limited to the r300. I have the same problem on r200 and i915. Philipp --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug 3263] New: glxgears not updating screen after running for several hours, 915GM h/w
This is a known bug in glxgears that has been fixed some time ago. Due to limited floating-point precision the gears stopped turning after a fixed number of frames. Philipp --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 Status Report - Gentoo amd64, Saphire 9600
Hamie schrieb: One other funny I noticed that I've never noticed before without the r300 drivers is that X would 'reload' itself whenever the client closed.. (I was only runnning one at a time, no window manager). Is that normal? It is. --- 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
XGI Volario
Is someone working on writing a driver for these chips? XGI provides a free framebuffer driver and drm, but the Mesa part of their driver is only available as closed-source. Philipp --- 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: [R300 and other radeons] MergedFB lockups
Vladimir Dergachev schrieb: I think I found the cause of lockups in VB mode - they were due to cursor updating function in radeon_mergedfb.c calling OUTREGP() which in turn called INREG. When silken mouse is enabled this function could be called at any time which would do *bad* things when CP engine is active. The fix of putting RADEONWaitForIdleMMIO() works fine on my setup. I have *no* idea why this worked with immediate mode at all and why no issues were reported by R200 and Radeon users (well, I only looked through the mailing lists, perhaps there is something on bugzilla but I don't know how to use that efficiently) Well my rv250 lockups occour only during mouse movement in fullscreen applications. But for month ago there were no lockups. The situation was slowly getting worse since. With current DRM and Mesa driver I get an immediate lockup in gl-117 when moving the mouse. If I use current DRM with an older Mesa it locks up after about a minute of mouse movement. Philipp --- 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: [R300 and other radeons] MergedFB lockups
Vladimir Dergachev schrieb: Interesting :) Could you try this with latest X.org source ? Sorry, but I probably won't find much time. I'll be away from the rv250 during the next week. Next month I'll have to write some exams, while at the beginning of april there are oral exams. I hope to find more time for DRI testing at the beginning of the next term. Also, what is gl-117 ? It's a free flight simulator, included in Debian. Philipp --- 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: [r2xx|r1xx] readpixels-3 and pntparam_1 - Progress?
Roland Scheidegger schrieb: As for pntparam, I couldn't get it really working, and in this form it's overkill for what works (larger point sizes). I'm not so sure it's worth the trouble of whipping up a simpler patch which would only contain that, since only aliased larger point sizes are working, but everyone uses antialiased points... Maybe I'll try it later again. Roland The popular wings3d subdivision modeller uses aliased points. When in vertex editing mode vertices are higlighted by points, selected vertices with points of a different color. Without bigger point sices it is very difficult to see wich vertices are selected at high screen resolutions. Philipp --- 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: OpenGL apps causes frequent system locks
Geller Sandor schrieb: 1. build and install everything from CVS, if the X server can be crashed, go to step 2, otherwise be happy :)) 2. use the X.org CVS version with the stock kernel's drm, if X still crashes, go to step 3. Otherwise use the X.org CVS, live without projected textures... 3. use the X.org and Mesa CVS versions. If X still crashes, then the bug can be in X.org or Mesa or in drm - I'm not able to trace down the problem. Unfortunately all 3 scenarios give the same result: X crashes. Is there any way I can help to track down the problem(s)? My machine doesn't have network connection, so I can use only scripts which run in the background. With expect and gdb maybe it is possible to get at least a backtrace from my non-local-interactive machine. I have the same problems with a rv250. It started about three or four month ago. I always used the xlibmesa-gl1-dri-trunk Debian package and the DRM that's included in the kernel. I'm now running 2.6.11-rc3 (which gave ma a ~10% increase in glxgears fps, but didn't help with stability). Before these problems appeared (I don't remember if it started with a kernel update or a DRI update) GL applciations wouldn't crash, even when running for days. With fglrx stability back then was as bad as it is today with DRI. I haven't tried fglrx since. Maybe we should try to track down which changes introduced the stability problems. Philipp --- 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: OpenGL apps causes frequent system locks
Adam K Kirchhoff schrieb: Agreed, for the most part. I use an 8500 and 9200 at work and at home. I regularly update my Mesa tree and build new version of the r200 driver. The only problems I've experienced is if I leave xscreensaver up and running all night, randomly choosing from the OpenGL screensavers... I'll sometimes (once a week, maybe) find X locked solid, and only a reboot will get it working again. I have the sam eproblem with the GL screensavers. It wasn't there three month ago. Many OpenGL applications work fine, but some just crash. To reproduce the crashes gl-117 (a free fighter plane simulator) seems to be the fastest way. It usually crashes within a few seconds. Three month ago I had never seen it crash with the DRI drivers, even when it ran for an hour. Philipp --- 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: r200 and ATI_fragment_shader
Dave Airlie schrieb: Just to update, I've looked at the fragment shader stuff and the documentation I have isn't enough to implement the spec, we only have access to the second stage registers (PP_CNTL - states second or only pass registers) Is it enough to implement GL_ARB_texture_crossbar? Philipp --- 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: [R300] Xorg cvs problem
Jerome Glisse schrieb: Yellow dog seems to have support for radeon 9600. At least they claim so. I tried to find out the source of their distribution but only manage to get iso for binary. On their site they state that they support only 2D, no hardware-accelerated 3D. --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
Does anyone have figures for the MOST time consuming parts of software 3D in the Mesa libs? Those would be the logical bits to push into hardware first. But I'm not sure I've ever seen a profile output from X to say which parts are actually most would benefit more from acceleration than others... Even without any such data you can easily find out the most important stuff: Since It's a 3D graphics _pipeline_ you should always start by accelerating the back end: implement hardware z- and stencil buffer first. Then work your way from the backof the graphics pipeline. Philipp --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
Thank you for doing this work. We really need to get the open-source ATI driver on par with the propretary driver (both feature-wise and performance-wise). But sadly we will NEVER match it. NO SmoothVision, HyperZ docu ever The nonfree xig driver has been developed without HyperZ docs and outperforms fglrx. Even though I just have a Radeon 9200, I'm very excited about the ongoning R300 effort and with there was a similar project for NVidia cards too. Above applies here, too. - Sorry. The situation seems to be much worse in the future. Bad IP (TRIPS, etc.) madness due to USA-law. True. ATI no longer releases docs. 3dlabs no longer does. Nvidia never did. Intel requires an NDA now. If there weren't all those patents out there we might just try to develop a free graphics chip. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Doom3 works on R200!
Dieter Nützel schrieb: The nonfree xig driver has been developed without HyperZ docs and outperforms fglrx. Are you sure. I thought Xig had it all before. Do you have actual numbers? Haven't looked at them for very long time, but I bought the first version of there X server 1994 (?) for mga. Roland made a comparison a year ago: http://homepage.hispeed.ch/rscheidegger/atilinux_oct03/ati_linux_comp_oct03.html Xig even outperforms the ATI windows drivers. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lock-ups with Radeon - new build
Paulo R. Dallan schrieb: Ok, things are getting worse. After I installed the dri drivers, i had only re-started the x-server - and acceleration worked but not as expected, as mentioned before. After a reboot, when trying to start x, i did modprobe radeon (ok), and issued the startx command. The system locked up. I could not even ping it from another machine. It happened twice in a roll. The solution (for have an x-server operational for the moment) was to run xorgconfig again and selected the generic *radeon* drive (is it the same as the hardware accelerated one?). After this the system is operational again (of course, no acceleration). The radeon driver is a hardware-accelerated driver for Radeon 7500 chips. I don't know why it even works on your card. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lock-ups with Radeon - new build
Paulo R. Dallan schrieb: Another strange thing, as i mentioned before, is that glxgears gives me 400 FPS output, but the drawing is quite slow, while in another machine here i have 200-250FPS and, at the same time, the drawing seems amazingly fast... Any suggestion? The gears turn faster when framerate is higher. Today they're nearly always turning so fast that there are interference effects: Your framerate is high, but the gears turn around once 'till your monitor displays the next frame, so they seem to be standing still. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon 9200se - driver issues
Paulo R. Dallan schrieb: Just complementing: man radeon gives a list of the PCI and AGP ATI cards supported by the xorg radeon driver, and the ATI Radeon 9200se is mentioned there: RV280 Radeon 9200PRO/9200/9200SE, M9+ So, either the man pages are wrong, or I was indeed using the correct driver... Or I'm missing something (help!) :) Best regards! Paulo The XFree86 documentation doesn't even mention ati, so from the XFree86 side these are probably the same. Maybe I was confused by the difference from the DRI side: radeon for 7000 series cards, r200 for 8500-9250. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon 9200se - driver issues
I've just tried the ati generic driver (option from xorgconfig) and the speed got even slower (however, glxinfo also gave me direct rendering: yes!). Actually, I got a little confused over here. In the dri/wiki, under the building description, it is described that the ati is the 2D driver for the Mach64, Rage128 and Radeon chipsets (so I assume the Radeon 9200se is included here; or is it not?). However, the options at xorgconfig that I could find are: (a) generic ati; (b) generic r128 (which I believe it is the Rage128); and (c) generic radeon (which was my first option)... So, do you know which I should choose? I use ati. It is interesting to mention that at the ATI Radeon dri/wiki page, when mentioning 3D acceleration, it explains that from the 7800/rv200 and below are supported by the radeon dri driver, and that from the 8500 to 9200 are supported by the r200 driver (in any case, they seem to use the same drm driver, radeon.ko, if not mistaken); So ok, but what would be the option for the r200 dri driver at xorgconfig? Or should I enter it as a parameter directly at xorg.conf? Or is it automatically detected, after the chipset is recognised? With dri enabled the r200 driver is automatically chosen for 3D acceleration. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI building - Radeon module problem
Paulo R. Dallan schrieb: At first impression, 3d acceleration seemed really bad (). Glxgears was giving me 130, 140 FPS! And this is an Athlon XP 2600 with the ATI 9200se (I know, this video card is not that good, but results should not be so bad, it has 128 Mb, AGP 8x (though dri is only up to 4X), 64 bits)... Any tip of what could be wrong? PS: Changed XOrg.conf to set 16 bits as the default depth and included ' Option AGPMode 4 '. Got a better performance: 400 FPS. Should I also try ' Option AGPFastWrite boolean ' (in this case, in place of boolean 'true', '1', 'yes')? Anyway, are these 400 FPS what I should be expecting as performance, or is it still considered low (the PIII500 with a Savage4 32Mb at AGP 2X gets 200-250 FPS)? I use XFree86 (the version from Debian) at 24 bit color and get over 1900 glxgears fps with my Radeon 9000 Pro, Athlon MP 2600+, so there still seems to be a problem with your setup. with my --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Mesa solo should work again..
Oh, I should point out that TG does do both GLES consultancy and will continue to push Mesa-solo where it makes sense to do so... At some point I'd like to try writing integrating a GLES target into the Mesa codebase. I don't know whether it would be possible or sensible to try and have the code co-exist with the rest of Mesa. I think maybe you'd be able to do a better job of specializing for GLES if you just forked the code off into a new directory, and likewise for the drivers. Keith We could add some of the GLES extensions to Mesa anyway. It would be useful for development of GLES applications. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: winex: ARB_VBO and DirectX for r200 cards.
Mike Mestnik schrieb: I was playing with winex, after paying for some games and a TransGaming subscription. In the cfg there are options to enable/disable the use of some OpenGL extensions, one being ARB_VBO. I saw that when using frglx there were some of these advertised by glxinfo, but not with SW/Mesa or R200/DRI. First I was wondering what it would take, as far as bribes, to get at least as far as the frglx drivers have with supporting this extension. Since I have to pay for winex... I also saw on this list that some R200 DMA memory layouts matched thoes used by DirectX and that to match the OpenGL ordering there was some swaping going on. I know the overhead is minimal, especialy with 32bit CPUs. However it would be a nice laught if OpenGL had some extentions for the CARDs idea of how things should be ordered. The idea being that any DirectX implementation for X(like winex) would not need to swap the bytes into OpenGLs prefered order when the CARD expects the data tobe in DirectX's order. It seems you are using outdated drivers. The current DRI drivers support about as much extensions as the nonfree ATI drivers. GL_ARB_vertex_buffer_object is in both software Mesa and the r200 driver. Recently a software emulation of GL_ARB_vertex_program has been added to the r200 driver, which has been in software Mesa for some time. The only important missing extension I'm aware of that is supported by the hardware is GL_ARB_texture_env_crossbar. You can add the patch for GL_S3_s3tc if you're living in a software-patent free area like Venezuela, Europe or Cuba. Philipp --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxinfo: R200 VS FGLRX side by side...
Ian Romanick schrieb:
Looking at the list, I noticed a couple of odd things. Why don't the
ATI drivers support GL_{ARB,EXT,NV}_texture_rectange or
GL_{ARB,EXT}_blend_equation_separate?
ATI sometimes makes strage decicions about the features their drivers
support: Even though the r200 could support GL_ARB_vertex_shader just
as the r300 does, they only expose GL_ARB_vertex_program.
Beyond that, there are basically
5 groups of useful extensions that they have but we don't:
- GL_ARB_texture_env_crossbar
- GL_ARB_occlusion_query and similar extensions.
- GL_ARB_point_parameters (I thought support was added for this?)
- GL_EXT_multi_draw_arrays
- GL_EXT_fog_coord
I once tried simply enabling GL_EXT_multi_draw_arrays, but there was
a problem: When calling glMultiDrawElementsEXT while creating a display
list the r200 driver called a Mesa function which wasn't to be called
when creating display lists.
Philipp
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
r200 depth readback problem.
Has anyone else experienced problems reading back depth values with the r200 driver? Whenever I read back a depth value from the right part (about a seventh or eighth of the width) I get 1.0. Reading back from other parts of the buffer works OK as does software Mesa everywhere. Philipp --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
At the time the code was written (fall 1999?) the only way Gareth found that he could reliably determine that SSE was fully supported (by CPU and kernel) was to try executing an SSE instruction and catching the exception if it failed. If there's a better way of doing that nowadays, we could update Mesa. A work-around might be for Phillip to set the MESA_NO_SSE env var. Does that mean that software Mesa doesn't use SSE? The problem occurs only with the r200 driver, not with software rendering. Philipp --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: exception testing in r200 driver
Ian Romanick schrieb: Philipp Klaus Krause wrote: Does that mean that software Mesa doesn't use SSE? The problem occurs only with the r200 driver, not with software rendering. Okay, then the SSE test can't be the problem. The exact same code gets executed in both the R200 driver and software Mesa. Actually, do you mean software Mesa (i.e., the libGL.so built by doing 'make linux-x86' in the Mesa tree) or GLX indirect-rendering? In this particular case they are quite different as the former executes in the application's address space, but the later does not. I just moved r200_dri.so away. Is there any way you can figure out where the jvm is terminating? This is so weird... Sorry for confusing people on this list, upon closer examination it seems it isn't the SIGFPE that caused the problem but a signal SIGSEGV raised in a glCallList(). If someone else wants to test: I use the glxgears port to jogl that is in the jogl-demos.jar from the jogl Java OpenGL binding (the one that was created by SUN and SGI). This is part of the error message: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : 11 occurred at PC=0x4D4E5A16 Function=(null)+0x4D4E5A16 Library=/usr/X11R6/lib/modules-dri-trunk/dri/r200_dri.so NOTE: We are unable to locate the function name symbol for the error just occurred. Please refer to release documentation for possible reason and solutions. Current Java thread: at net.java.games.jogl.impl.x11.X11GLImpl.glCallList(Native Method) at demos.gears.Gears$GearRenderer.display(Gears.java:134) at net.java.games.jogl.impl.GLDrawableHelper.display(GLDrawableHelper.java:74) at net.java.games.jogl.GLCanvas$DisplayAction.run(GLCanvas.java:221) at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:290) - locked 0x447898b0 (a net.java.games.jogl.impl.x11.X11OnscreenGLContext) at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:208) at net.java.games.jogl.GLCanvas.display(GLCanvas.java:75) at net.java.games.jogl.Animator$1.run(Animator.java:107) at java.lang.Thread.run(Thread.java:536) Just a small note on why I suspected it was the SIGFPE first even though the above log is rather clear: When debugging my C++ applications using OpenGL, gdb halts on a SIGFPE in _mesa_test_os_sse_exception ehen I use the r200 driver, but doesn't with software rendering, so I just noticed that the java program had a problem with a signal that went away when using software instead of the r200 driver, so I though it was the same. Philipp --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
exception testing in r200 driver
_mesa_test_os_sse_exception, executed upon start of any OpenGL application raises SIGFPE. Normally this is not a problem, applications continue to execute normally. However when using the jogl OpenGL Java binding programs exit. I tried both with Java 1.4 from Sun and sablevm. Philipp --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
What became of the proposal of making fb a DRM client that I saw on dri-devel some time ago? It sounded like a good idea to me. Philipp --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download
Brian Paul schrieb: Pasi Kärkkäinen wrote: Hi all! From the www.opengl.org: OpenGL 2.0 specification available for download http://www.opengl.org/documentation/opengl_current_version.html http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf Any plans for 2.0 support in Mesa? I think the biggest todo is the sw-emulation of glsl? Yeah, implementing the shading language will be a huge project. It would be nice if a group of volunteers would work together to implement it. I'll probably start working on some of the infrastructure for 2.0 support in the near future. But the GLSL parser and code generator will be the bulk of the 2.0 work by far. -Brian Some modifications to Mesa are necessary: -Change glColor3 behaviour, -Seperate legacy and generic vertex attributes. GL_NV_vertex_program, GL_NV_vertex_program1_1 and GL_NV_vertex_program2 needs attribute aliasing. GL_ARB_vertex_program, GL_NV_vertex_program3 allow it. GL_ARB_vertex_shader sas that even for GL_ARB_vertex_program (assuming both extensions present) there may be no attribute aliasing. -I dont' know about GL_ARB_texture_non_power_of_two and GL_ARB_draw_buffers. Are they supported already? -The rest should be there. I planned to do some work towards shader support, but wanted to wait for The 2.0 spec to be released to see what would change. I probably won't find much time before mid-october or so. This is what I had in mind: Frontends for GL_ARB_vertex_program and GL_ARB_vertex_shader, GL_ARB_fragment_program and GL_ARB_fragment_shader that create some intermediate representation. Then, at least four backends: One for SSE to get fast software rendering on newer x86, one that interpretes for the architectures where there is no compiling backend, one for the new intel chips and their fragment program support and finally, one for the Wildcat VP (I don't have docs for it though and doubt that I will ever get any, I haven't asked Intel about i915 yet). So get get something running I would first craete the GL_ARB_vertex_program frontend. Then the interpreting backend. If it's at least as fast as the solution we have now, we can already put it in Mesa. Next will be GL_ARB_vertex_shader frontend and SSE backend. Then we can take the new concept to the fragment shader side, where it should be rather easy to get GL_ARB_fragment_program and GL_ARB_fragment_shader support and get the interpreted and SSE backends running. Next would be the i915 backend, since the driver already supports fragment programs and it shouldn't be left behind. Then when someone uses the fragment shader on let's say the i915 this will happen: If the i915 compiler says it can't handle the program (due to lack of hardware support for some advanced functionality) the SSE backend with software rendeirng will be used if it's on x86. Otherwise the generic, interpreting backend will be used. Philipp --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vertex programs patch for r200 with configuration options -- corrected
Michael Mazack schrieb: r200_context.c shows the following: if(driQueryOptionb(rmesa-optionCache, arb_vertex_program)) _mesa_enable_extension( ctx, GL_ARB_vertex_program); if(driQueryOptionb(rmesa-optionCache, nv_vertex_program)) _mesa_enable_extension( ctx, GL_NV_VERTEX_PROGRAM); Should the nvidia extension be in all caps like that? I know that when I use glGetString(GL_EXTENSIONS) I check for the way they are normally done. If it should be in all caps, can someone give a logical reason for it? Maybe the wrong patch was applied? It was the wrong patch that was applied. I already wrote to Dave Airlie, who applied the patch about that. Philipp --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vertex programs for r200 patch
Dave Airlie schrieb: When will we see this in? http://marc.theaimsgroup.com/?l=dri-develm=109408144803743w=2 I've reviewed it and would be happy with it as well, but I would like a driconf option to turn it off in case it some apps have issues.. adding a driconf option is explained at: http://dri.sourceforge.net/cgi-bin/moin.cgi/ConfigurationInfrastructure Dave. So I'll add driconf options for both GL_ARB_vertex_program (on by default) and GL_NV_vertex_program (off by default). Maybe we should add the 1.4 extensions and make an option for GL_ARB_depth_texture someday. Philipp --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
vertex programs patch for r200 with configuration options
This patch enables GL_ARB_vertex_program and GL_NV_vertex_program support in the r200 driver. Both extensions can be enabled via options, GL_ARB_vertex_program is on by default, GL_NV_vertex_program off. Option descriptions are in german, english and french. Apply with cat r200_vp.patch | patch -p1 in Mesa/src/mesa/drivers/dri Philipp Klaus Krause diff --unified -r dri.bak/common/xmlpool.h dri/common/xmlpool.h --- dri.bak/common/xmlpool.h 2004-05-08 12:08:21 +0200 +++ dri/common/xmlpool.h 2004-09-06 20:32:38 +0200 @@ -273,4 +273,25 @@ DRI_CONF_DESC(de,Anzahl der Textureinheiten) \ DRI_CONF_OPT_END +/* Options for features that are not done in hardware by the driver (like GL_ARB_vertex_program + On cards where there is no documentation (r200) or on rasterization-only hardware). */ +#define DRI_CONF_SECTION_SOFTWARE \ +DRI_CONF_SECTION_BEGIN \ +DRI_CONF_DESC(de,Funktionalität, die nicht durch die Hardware beschleunigt wird) \ +DRI_CONF_DESC(en,Features that are not hardware-accelerated) + +#define DRI_CONF_ARB_VERTEX_PROGRAM(def) \ +DRI_CONF_OPT_BEGIN(arb_vertex_program,bool,def) \ +DRI_CONF_DESC(de,GL_ARB_vertex_program aktivieren) \ +DRI_CONF_DESC(en,Enable GL_ARB_vertex_program) \ +DRI_CONF_DESC(fr,Activer GL_ARB_vertex_program) \ +DRI_CONF_OPT_END + +#define DRI_CONF_NV_VERTEX_PROGRAM(def) \ +DRI_CONF_OPT_BEGIN(nv_vertex_program,bool,def) \ +DRI_CONF_DESC(de,GL_NV_vertex_program aktivieren) \ +DRI_CONF_DESC(en,Enable GL_NV_vertex_program) \ +DRI_CONF_DESC(fr,Activer GL_NV_vertex_program) \ +DRI_CONF_OPT_END + #endif diff --unified -r dri.bak/r200/r200_context.c dri/r200/r200_context.c --- dri.bak/r200/r200_context.c 2004-07-04 22:33:49 +0200 +++ dri/r200/r200_context.c 2004-09-06 20:23:26 +0200 @@ -62,7 +62,7 @@ #include r200_vtxfmt.h #include r200_maos.h -#define DRIVER_DATE 20030328 +#define DRIVER_DATE 20040906 #include vblank.h #include utils.h @@ -166,6 +166,7 @@ _tnl_fog_coordinate_stage, _tnl_texgen_stage, _tnl_texture_transform_stage, + _tnl_vertex_program_stage, /* Try again to go to tcl? * - no good for asymmetric-twoside (do with multipass) @@ -406,6 +407,10 @@ _mesa_enable_extension( ctx, GL_EXT_blend_equation_separate ); _mesa_enable_extension( ctx, GL_EXT_blend_func_separate ); } + if(driQueryOptionb(rmesa-optionCache, arb_vertex_program)) + _mesa_enable_extension( ctx, GL_ARB_vertex_program); + if(driQueryOptionb(rmesa-optionCache, nv_vertex_program)) + _mesa_enable_extension( ctx, GL_NV_VERTEX_PROGRAM); #if 0 r200InitDriverFuncs( ctx ); diff --unified -r dri.bak/r200/r200_screen.c dri/r200/r200_screen.c --- dri.bak/r200/r200_screen.c 2004-07-04 22:33:49 +0200 +++ dri/r200/r200_screen.c 2004-09-06 20:24:02 +0200 @@ -75,6 +75,10 @@ DRI_CONF_SECTION_DEBUG DRI_CONF_NO_RAST(false) DRI_CONF_SECTION_END +DRI_CONF_SECTION_SOFTWARE +DRI_CONF_ARB_VERTEX_PROGRAM(true) +DRI_CONF_NV_VERTEX_PROGRAM(false) +DRI_CONF_SECTION_END DRI_CONF_END; static const GLuint __driNConfigOptions = 11; diff --unified -r dri.bak/r200/r200_state.c dri/r200/r200_state.c --- dri.bak/r200/r200_state.c 2004-05-27 18:56:47 +0200 +++ dri/r200/r200_state.c 2004-09-06 20:22:41 +0200 @@ -2043,6 +2043,10 @@ r200UpdateSpecular ( ctx ); break; + case GL_VERTEX_PROGRAM_ARB: + TCL_FALLBACK(rmesa-glCtx, R200_TCL_FALLBACK_TCL_DISABLE, state); + break; + default: return; } diff --unified -r dri.bak/r200/r200_tcl.h dri/r200/r200_tcl.h --- dri.bak/r200/r200_tcl.h 2004-06-03 00:09:11 +0200 +++ dri/r200/r200_tcl.h 2004-09-06 20:22:41 +0200 @@ -60,6 +60,7 @@ #define R200_TCL_FALLBACK_TEXGEN_5 0x200 /* texgen, unit 5 */ #define R200_TCL_FALLBACK_TCL_DISABLE 0x400 /* user disable */ #define R200_TCL_FALLBACK_BITMAP0x800 /* draw bitmap with points */ +#define R200_TCL_FALLBACK_VERTEX_PROGRAM0x1000/* vertex program active */ #define TCL_FALLBACK( ctx, bit, mode ) r200TclFallback( ctx, bit, mode )
vertex programs patch for r200 with configuration options -- corrected
'Did some more testing and found bugs. Here is the corrected patch. Philipp diff --unified -r dri.bak/common/xmlpool.h dri/common/xmlpool.h --- dri.bak/common/xmlpool.h 2004-05-08 12:08:21 +0200 +++ dri/common/xmlpool.h 2004-09-06 20:39:06 +0200 @@ -273,4 +273,25 @@ DRI_CONF_DESC(de,Anzahl der Textureinheiten) \ DRI_CONF_OPT_END +/* Options for features that are not done in hardware by the driver (like GL_ARB_vertex_program + On cards where there is no documentation (r200) or on rasterization-only hardware). */ +#define DRI_CONF_SECTION_SOFTWARE \ +DRI_CONF_SECTION_BEGIN \ +DRI_CONF_DESC(de,Funktionalität, die nicht durch die Hardware beschleunigt wird) \ +DRI_CONF_DESC(en,Features that are not hardware-accelerated) + +#define DRI_CONF_ARB_VERTEX_PROGRAM(def) \ +DRI_CONF_OPT_BEGIN(arb_vertex_program,bool,def) \ +DRI_CONF_DESC(de,GL_ARB_vertex_program aktivieren) \ +DRI_CONF_DESC(en,Enable GL_ARB_vertex_program) \ +DRI_CONF_DESC(fr,Activer GL_ARB_vertex_program) \ +DRI_CONF_OPT_END + +#define DRI_CONF_NV_VERTEX_PROGRAM(def) \ +DRI_CONF_OPT_BEGIN(nv_vertex_program,bool,def) \ +DRI_CONF_DESC(de,GL_NV_vertex_program aktivieren) \ +DRI_CONF_DESC(en,Enable GL_NV_vertex_program) \ +DRI_CONF_DESC(fr,Activer GL_NV_vertex_program) \ +DRI_CONF_OPT_END + #endif diff --unified -r dri.bak/r200/r200_context.c dri/r200/r200_context.c --- dri.bak/r200/r200_context.c 2004-07-04 22:33:49 +0200 +++ dri/r200/r200_context.c 2004-09-06 22:17:06 +0200 @@ -62,7 +62,7 @@ #include r200_vtxfmt.h #include r200_maos.h -#define DRIVER_DATE 20030328 +#define DRIVER_DATE 20040906 #include vblank.h #include utils.h @@ -166,6 +166,7 @@ _tnl_fog_coordinate_stage, _tnl_texgen_stage, _tnl_texture_transform_stage, + _tnl_vertex_program_stage, /* Try again to go to tcl? * - no good for asymmetric-twoside (do with multipass) @@ -406,6 +407,10 @@ _mesa_enable_extension( ctx, GL_EXT_blend_equation_separate ); _mesa_enable_extension( ctx, GL_EXT_blend_func_separate ); } + if(driQueryOptionb(rmesa-optionCache, arb_vertex_program)) + _mesa_enable_extension( ctx, GL_ARB_vertex_program); + if(driQueryOptionb(rmesa-optionCache, nv_vertex_program)) + _mesa_enable_extension( ctx, GL_NV_vertex_program); #if 0 r200InitDriverFuncs( ctx ); diff --unified -r dri.bak/r200/r200_screen.c dri/r200/r200_screen.c --- dri.bak/r200/r200_screen.c 2004-07-04 22:33:49 +0200 +++ dri/r200/r200_screen.c 2004-09-06 22:09:18 +0200 @@ -75,8 +75,12 @@ DRI_CONF_SECTION_DEBUG DRI_CONF_NO_RAST(false) DRI_CONF_SECTION_END +DRI_CONF_SECTION_SOFTWARE +DRI_CONF_ARB_VERTEX_PROGRAM(true) +DRI_CONF_NV_VERTEX_PROGRAM(false) +DRI_CONF_SECTION_END DRI_CONF_END; -static const GLuint __driNConfigOptions = 11; +static const GLuint __driNConfigOptions = 13; #if 1 /* Including xf86PciInfo.h introduces a bunch of errors... diff --unified -r dri.bak/r200/r200_state.c dri/r200/r200_state.c --- dri.bak/r200/r200_state.c 2004-05-27 18:56:47 +0200 +++ dri/r200/r200_state.c 2004-09-06 20:39:06 +0200 @@ -2043,6 +2043,10 @@ r200UpdateSpecular ( ctx ); break; + case GL_VERTEX_PROGRAM_ARB: + TCL_FALLBACK(rmesa-glCtx, R200_TCL_FALLBACK_TCL_DISABLE, state); + break; + default: return; } diff --unified -r dri.bak/r200/r200_tcl.h dri/r200/r200_tcl.h --- dri.bak/r200/r200_tcl.h 2004-06-03 00:09:11 +0200 +++ dri/r200/r200_tcl.h 2004-09-06 20:39:06 +0200 @@ -60,6 +60,7 @@ #define R200_TCL_FALLBACK_TEXGEN_5 0x200 /* texgen, unit 5 */ #define R200_TCL_FALLBACK_TCL_DISABLE 0x400 /* user disable */ #define R200_TCL_FALLBACK_BITMAP0x800 /* draw bitmap with points */ +#define R200_TCL_FALLBACK_VERTEX_PROGRAM0x1000/* vertex program active */ #define TCL_FALLBACK( ctx, bit, mode ) r200TclFallback( ctx, bit, mode )
Re: via docs
Alan Cox schrieb: [...] then there are a couple we have docs for and no drivers. The Wiki mentions only the SiliconMotion Chips as having docs, but no drivers, and says that SiS docs are available and a driver is in development. Are there any other chips with driver, without docs? Philipp Klaus Krause --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Viewperf-7.1.1 results on SMP
Dieter Ntzel schrieb: Argh, what a regression. most tests show mostly empty and/or black and/or white windows... Strange, I just ran Viewperf 8 on my r200 and didn't notice any problems (expect ensight-01 that didn't even run, but it seems that's a problem with a Viewperf script). Philipp Klaus Krause --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Viewperf-7.1.1 results on SMP
I did use a slightly older cvs version with only my vertex program patch applied and built in the Mes tree without optimizations. Strange, I just ran Viewperf 8 8.0.1? Yes. I've downloaded it in the morning. ;-) on my r200 and didn't notice any problems SMP-system (EnvLINUX.c reports num=2) -DMP? -lpthread? gcc-3.5 -O2 -march=athlon-mp -msse -DMP Some more (hardware) specs, please. Dual Athlon MP, Radeon 9000 Pro I'll retry with new drivers and rebuilt -O3, -mfpmath=sse Viewperf. Philipp --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Viewperf-7.1.1 results on SMP
gcc-3.5 -O2 -march=athlon-mp -msse -DMP Just saw that the it seems to take the options from the Makefile, I just set them in options (included by Makefile, but the CFLAGS defined there is overwrittem) Philipp --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Viewperf-7.1.1 results on SMP
Dieter Nützel schrieb: Philipp Klaus Krause schrieb: gcc-3.5 -O2 -march=athlon-mp -msse -DMP Just saw that the it seems to take the options from the Makefile, I just set them in options (included by Makefile, but the CFLAGS defined there is overwrittem) ;-) That's why I 'included' my changed EnvLINUX.c (taken from EnvSGI.c) files. OK, adding -DMP makes some tests turn completely black (tried with ugs). Still using the old cvs driver with only vertex programs added and built in non-optimizing Mesa tree (driver built with gcc-3.3). Do you see any performance win with GCC-3.5 (auto vectorization) compared to the old -mfpmath=sse? I've never compiled Viewperf test with an older gcc version. Philipp --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] Viewperf-7.1.1 results on SMP
Dieter Ntzel schrieb: src/Makefile [-] CDEBUGFLAGS = -O -mcpu=athlon -march=athlon -mfpmath=sse INCLUDES = -I$(AUX_DIR) -I$(X_DIR)/include/ -I$(LIBGL)/include/ -I$(LIBPNG)/include # Add -DMP to the following line to build a multithreaded viewperf DEFINES = -DXWINDOWS -DSEARCHPATH -DLINUX -DPNG -DMP # edit EnvXXX.c to be your version of Env.c, such as EnvDEC.c ENV_C=EnvLINUX.c CCFLAGS = CFLAGS = $(CCFLAGS) $(CDEBUGFLAGS) $(INCLUDES) $(DEFINES) LIBS = -L$(X_DIR)/lib -Lobjs -L$(AUX_DIR) -L$(TK_DIR) -L$(LIBGL)/lib -L$(LIBPNG) /lib -lvp -lm -lX11 -lXext -laux -lGL -lGLU -lz -lpng -lpthread [-] -mfpmath=sse will be ignored, since -march=athlon doesn't allow it (the original athlon didn't have sse) you have to use -march=athlon-mp. Philipp Klaus Krause --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
vertex programs for r200 patch
The same as the patches I sent earlier, but as a single unified file. For those that didn't read the original posting: This patch enables GL_ARB_vertex_program support for the r200 driver. The vertex programs are executed in software, but since this only replaces tcl everything from the perspective divide onward is still hardware accelerated, even when a vertex program is active. Philipp Klaus Krause Gemeinsame Unterverzeichnisse: r200.bak/CVS und r200/CVS. diff -u r200.bak/r200_context.c r200/r200_context.c --- r200.bak/r200_context.c 2004-08-19 18:20:48 +0200 +++ r200/r200_context.c 2004-08-19 18:44:23 +0200 @@ -62,7 +62,7 @@ #include r200_vtxfmt.h #include r200_maos.h -#define DRIVER_DATE 20030328 +#define DRIVER_DATE 20040819 #include vblank.h #include utils.h @@ -129,6 +129,7 @@ GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_vertex_buffer_object, +GL_ARB_vertex_program, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_secondary_color, @@ -166,6 +167,7 @@ _tnl_fog_coordinate_stage, _tnl_texgen_stage, _tnl_texture_transform_stage, + _tnl_vertex_program_stage, /* Try again to go to tcl? * - no good for asymmetric-twoside (do with multipass) diff -u r200.bak/r200_state.c r200/r200_state.c --- r200.bak/r200_state.c 2004-08-19 18:22:28 +0200 +++ r200/r200_state.c 2004-08-19 18:28:04 +0200 @@ -2043,6 +2043,10 @@ r200UpdateSpecular ( ctx ); break; + case GL_VERTEX_PROGRAM_ARB: + TCL_FALLBACK(rmesa-glCtx, R200_TCL_FALLBACK_TCL_DISABLE, state); + break; + default: return; } diff -u r200.bak/r200_tcl.h r200/r200_tcl.h --- r200.bak/r200_tcl.h 2004-08-19 18:24:38 +0200 +++ r200/r200_tcl.h 2004-08-19 18:25:24 +0200 @@ -60,6 +60,7 @@ #define R200_TCL_FALLBACK_TEXGEN_5 0x200 /* texgen, unit 5 */ #define R200_TCL_FALLBACK_TCL_DISABLE 0x400 /* user disable */ #define R200_TCL_FALLBACK_BITMAP0x800 /* draw bitmap with points */ +#define R200_TCL_FALLBACK_VERTEX_PROGRAM0x1000/* vertex program active */ #define TCL_FALLBACK( ctx, bit, mode ) r200TclFallback( ctx, bit, mode ) Gemeinsame Unterverzeichnisse: r200.bak/server und r200/server.
Re: First DRI uber-benchmark
John Lightsey schrieb: I gave up on specviewperf after waiting over half an hour for the Voodoo 5 to run it. It's just too time consuming. Are there one or two tests that stand out in particular? I'd propose 3dsmax-02, ugs-03 and proe-02 since in the Radeon driver comparison done by Ronald Schneidegger these three were the ones were most rendering errors occured, so running these should find rendering errors in addition to benchmarking. See http://homepage.hispeed.ch/rscheidegger/ for the comparison. Philipp Klaus Krause --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
How to get patch accepted into trunk?
Some time ago I sent patches that enable vertex program support in the r200 driver (software only though) to this list. Now I wonder if they will be integrated into the driver and how this process works. Do the driver maintainers read this list, lok at the patches and decide what they integrate? Will I get any feedback if it's accepted or rejected and why? Is this list the right place to send patches to (I occassionally see them in some messages, but for something as important as the DRI I'd expect there were more patches coming in). Philipp. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to get patch accepted into trunk?
Ronny V. Vindenes schrieb: I haven't tested it yet either, but it struck me that if we're going to add support for non-essential software-only extensions then we probably should add a driconf option to enable/disable such extensions since their existence can affect which code paths clients take? Well, once the programmable codepath in Mesa is optimized a bit, this probably won't be much slower than fixed-function, even with hardware tcl. I think that programmable functionality an essential extension, if you look about at the discussion about glitz, X on top of OpenGL, etc Jon Smirl pointed out that even fragment shaders might be necessary By the way, the i915 driver already does vertex program in software. An option in driconf to enable NV_vertex_program might be useful, I left it out of my patch, but the the only thing to be done to enable it once my patch is applied would be to add it to the extension string. Maybe we should seperate between software-only extensions that don't really cause a slowdown (like vertex programs), and those that do (like fragment programs or depth textures), that would be similar to what Nvidia does (the latter have to be enabled seperately, while the former are always there). The only thing in terms of hardware acceleration that we loose when vertex programs are enabled is hardware tcl. From the perspective divide onward everything is accelerated again. Philipp Klaus Krause --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: vertex program support in r200 driver - patches
Patrick McFarland schrieb: On Thu, 19 Aug 2004 18:40:12 +0200, Philipp Klaus Krause [EMAIL PROTECTED] wrote: Attached are patches to enable support for GL_ARB_vertex_program in the r200 driver. Thats very cool, but does this mean that it is hardware accelerated now? No, I don't have any Radeon docs and the docs that some dri developers have don't cover programmable vertex processing as far as I know. So it seems we'll neve get any hardware accelerated support on these cards. That isn't really as bad as it seems since when vertex processing is done in software the rest of the graphics pipeline can still be hardware accelerated. I've done some benchmarking with a vertex-transform limited scene with a single directional light with ambient, diffuse and specular and both hardware tcl and a vertex program that does the same (it's the first vertex program I ever wrote, so probably one could write a faster one for the same purpose). On a Radeon 9000 Pro, 2x Athlon MP 2600+ I get these framerates: Hardware tcl: 10.0 fps Vertex program: 2.5 fps Since most programs use fixed-fuction vertex processing for most of the scene and vertex programs only for specific ceffects (water waves, animation of player models, etc) it should be ok. I hope that it gets included in the r200 driver. Philipp Klaus Krause --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
r200_ vtxfmt.c : r200VtxfmtInit
How does this function work? To me it seems it assigns undefined things to members of a vfmt struct. I didn't see things like r200_Fallback_DrawElements anywhere else in the code. I looked at this since I tried enabling GL_EXT_multi_draw_arrays and get crashes (an assertion fails in t_array_api.c:379) when calling glMultiDrawElementsEXT while creating a display list. Philipp Klaus Krause --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
