r6xx/r7xx support in DRM and radeonhd, release of r600_demo
Good news! Alex Deucher and I have worked hard in the last months to finally get some triangles (and textures, etc.) out of r6xx and r7xx chips from AMD. This includes work on the initial r6xx drm implementation by Dave Airlie, and a lot of work by John Bridgman to get the final go with the necessary IP reviews. The results are now finally upstream: - the r6xx-r7xx-support branch of mesa/drm This only includes the easy bits, so far it's only sufficient for X11 acceleration, additional bits will be needed for a fully working DRI driver. E.g. there is no packet submission interface yet, as a packet verifyer is missing. - the r6xx-r7xx-support branch of driver/xf86-video-radeonhd This adds early EXA acceleration bits, not exactly working and more for developers than for users. - the new mesa/r600_demo repo This is a bringup utility that uses the Xserver's DRM interface for programming the chip directly, and is used for understanding features of the chips before bringing the code to the X11 driver or Mesa. Due to the IP review process we cannot publish the original git repository at the moment, but I will publish a list of git commits at a later point of time, so if you find something interesting / strange you have a chance of validating that yourself. I explained the code and some of the chip's behavior in my latest blog entry ( http://emmes.livejournal.com/3435.html ) - you might want to read that before actually digging into the code. We documented everything we encountered during the development of r600_demo, but that has to be IP reviewed as well, and will probably be published only after the register documentation, most probably in the form of one or multiple wiki pages. We have also started with a DRI driver - actually, the driver already does software fallbacks correctly (except for z Buffer readbacks), but doesn't have a single register banging line of code yet. We'll publish that early next year, when there is actually something to show. I'm afraid that the current state of code and documentation is probably not enough for non-NDA developers to add substantial stuff to a driver, but that will certainly change over time. It certainly is enough to do some first own experiments with r600_demo, but be aware that the different chipset generations behave subtly different, so if possible test / let test with multiple chipsets before publishing any patches (which are of course welcome!). Have fun Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon r6xx DRM...
On Jun 05, 08 00:39:26 +0200, Jerome Glisse wrote: I was envisioning a completely separate r600 DRI driver for r6xx+, since, if I understand correctly, the r6xx 3D engine is a completely new chip with nothing in common with the older Radeons. On the other hand, though, I haven't seen the actual documentation, so I have no idea exactly how different this new chipset actually is. For the long term, yes. For the short term we probably want something running fast, and that means basing stuff on code that's already there. Maybe it would be the right time for creating a legacy free DRM for r600 (probably earlier chips later on as well) for a DRI2/gallium/ TTM/GEM framework. But not before we have some code running and really understand how the chip is programmed and behaves in practise. If the new driver won't be an incremental change to the existing radeon drivers, I'd recommend basing it on Gallium. I agree that gallium is the way to go, but it seems that they can get somethings in less time than gallium will need to mature a bit and become useable. I have deeply experienced the difference btw the easier to start from somethings working than to start from scratch. Definitely. No completely new driver without using gallium. And it would be a hard time if you didn't already know that the thing you're trying to do actually works. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: gallium (was Re: radeon r6xx DRM...)
On Jun 04, 08 18:30:56 -0600, Brian Paul wrote: Gallium might ultimately wind up in its own repository as a stand-alone project. Afterall, Gallium drivers could be used by APIs other than OpenGL. Yes, but the base project is called Mesa and not OpenGL. So that wouldn't exactly stop that ;-) When either of those things happens a Mesa 8.0 release would probably be appropriate. I haven't thought about a time frame yet, but the end of the year might be a good goal. Sounds good. Especially as nobody really has to wait until then to dig into it. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon r6xx DRM...
On Jun 05, 08 00:36:12 +0200, Jerome Glisse wrote: Well i don't know anythings about r6xx but for radeon i was discussing with Dave a plan to add a new ioctl to submit packet in new cleaner way so that we can reuse current mesa driver with future memory manager enabled legacy free radeon drm module. The plan is basicly to send well formated That sounds *very* interesting. I guess this was only a quick first discussion, so there probably isn't any hard evidence (read: code or text ;) to share... packet to the ioctl and to take advantage of nop packet or add new unknow packet type transformed into nop by drm to sneak in additional information that will be needed latter (when using a memory manager). I don't know when What information would that be? The equivalence of texture / surface / memory region numbers? I don't know whether abusing NOPs for that is actually the right idea, though. i will have time to tackle this, i always have great hope of doing it soon but each time my day end i am just totaly exhausted. ... I wonder why already feel the pain... So my only advice/wishes :) is that you start from somethings like that ie not and ioctl where you submit packet inside a container structure but directly a buffer which can be parsed by hw. Maybe this can make cmd checking code a little bit more complexe but i don't think so. Why do you think it would be problematic to have a new ioctl with a container structure? Not that I intend to do anything TTM/GEM related ATM, but I'm curious. Oh and have fun with r6xx =) Thnx :) Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon r6xx DRM...
I'm in the process of skimming through the 3D programming documentation of the r6xx chips. AMD announced on XDC 2008 to make it public, so it will show up pretty soon. It's one massive beast, more than 650 pages... Obviously, the first step to get 3D working on r6xx is to update the radeon DRM to support these chips, and I think I've understood enough now to start working on this thing. I assume working in a public user repro is the best way to collaborate, but I'd be fine working in a branch on the main repro or just sending patches, just what fits best. r6xx looks substantially different than previous chipsets, but I think it still fits into the radeon driver. If it turns out that for exposing additional features and using DRI2 it's better to split out parts, that can be decided later on. Any comments on advancing here, or pitfalls to avoid? Has anybody already some ideas how to restructure things if necessary? So long Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VRAM vs suspend.
On May 31, 08 18:31:45 +0200, Jerome Glisse wrote: On Sat, 31 May 2008 14:53:22 +0100 Matthew Garrett [EMAIL PROTECTED] wrote: On Fri, May 30, 2008 at 07:57:32PM +0200, Matthias Hopf wrote: At least on suspend to RAM many GPUs can probably be programmed to keep VRAM contents alive. In that case you wouldn't have to save that data as well. You have to deal with it for suspend to disk, so it's a problem that needs solving regardless. You'll also reduce power consumption if you don't need to keep the VRAM powered. Also from discussion i did have keeping vram powered isn't reliable accross device it will depends on manufacturer and likely with no easy to guess out. Agreed with StD and reliability. I don't think power consumption is too high, especially as it will save quite some time during suspend resume (no swapping to main memory, no potential swapping of main memory to disk first for freeing up space). You'll only know after measuring, though... Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - 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: VRAM vs suspend.
On May 30, 08 20:43:39 +0200, Stefan Dösinger wrote: Am Freitag, 30. Mai 2008 19:57:32 schrieb Matthias Hopf: At least on suspend to RAM many GPUs can probably be programmed to keep VRAM contents alive. In that case you wouldn't have to save that data as well. It's a bit far fetched and probably out of question here, but Direct3D has the concept of a lost device for cases like that. Whenever the video memory AFAIR this concept has been nuked with D3D10, because it created too many issues with the 3D clients. AFAIK You get a lost device also if you changed from a fullscreen 3D app to the desktop. Now OpenGL doesn't have that, apps rely on opengl to restore their textures. However, it might be an option to add an extension which allows apps to tell the GL implementation that it can deal with lost resources. If non-game apps like Compiz support this, it would be enough to improve the suspend performance considerably. Agreed. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - 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 vs GEM discussion questions
On May 21, 08 11:35:43 -0700, Ian Romanick wrote: | We haven't touched the texsubimage path, having not found it in a | profile yet. It'll probably be doing map/write/unmap, which (as noted | elsewhere in the thread) is pretty much the worst thing you can do. If | you have a relevant application where texsubimage is showing up in the | profile, I'd enjoy playing with it. Anything that uses shadow maps (or any other render-to-texture type effect) without framebuffer objects will hit this path. Since iD only uses stencil volume shadows, it's not surprising that you haven't hit it yet. And I don't think glTexSubImage is the problem, I think glCopyTexSubImage is the problem. Also all video texture paths use TexSubimage, e.g. the OpenGL paths of both major video players. Also, I'm pretty sure some games do that. Games also used to use this path for mirror and distortion effects, though nowadays FBOs are probably used in most cases. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - 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: VRAM vs suspend.
On May 19, 08 20:52:49 +0100, Dave Airlie wrote: Now I would be willing to provide a drm tuneable sorta like memory overcommit that could be used on embedded systems and basically says I've designed my system so I never need suspend/resume and I really udnerstand what I'm doing, so don't ensure I have backing store for VRAM allocations. This would never be the default. At least on suspend to RAM many GPUs can probably be programmed to keep VRAM contents alive. In that case you wouldn't have to save that data as well. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - 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: DRM enhancements document
On Aug 23, 07 12:00:39 +0300, Daniel Stone wrote: If you have ioctl number 32, your next free one is 43, and you want to change the semantics of UPDATE_WINDOW, then you rename 32 to UPDATE_WINDOW_OLD, create UPDATE_WINDOW as 43 with the new structure, and handle both cases. I consider this giving headaches. I never had any similar issues with a tag-based approach. The problem there comes with the added complexity of parsing all the data. Maybe I'm a bit biased (had an Amiga for a long time, and this was the base argument parsing for OS routines), but it worked astonishingly well. If every tag is int32 and its parameter int32 as well, this isn't too problematic. Question is whether everything needed can be represented in 32 bit values, strings are a completely different concept and don't match well here, as pointers are probably difficult to handle over the user land / kernel barrier... Easy to use, hard to use right. Right. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - 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
Re: DRM enhancements document
On Aug 20, 07 19:51:31 +0300, Daniel Stone wrote: On Mon, Aug 20, 2007 at 05:27:43PM +0200, Matthias Hopf wrote: On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters Please be sure that if you design this using ioctls the design should be forward and backward compatible. AFAICS the only way to ensure this is some sort of tag-based parameter space (parameters are a list of tag,value pairs, terminated by a special tag). Otherwise you're stuck with one parameter list, which you cannot enhance easily, and version control both in user and kernel space will be a nightmare. With tags you can just ignore the tags you don't know about. Well, either that, or you can have a version field as the very first member (think: X11 requests), or simply bump the ioctl number every time you change the API (think: shared libraries). But that exactly makes version control difficult (lots of cases, especially if the exact requirements aren't clear from day one). Without a version field, this is made impossible, something that must be avoided at all costs. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - 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
Re: DRM enhancements document
On Aug 20, 07 15:45:00 -0700, Keith Packard wrote: On Mon, 2007-08-20 at 17:27 +0200, Matthias Hopf wrote: Because we won't get an ix86 emulator in kernel space, Linus and others have been pretty clear about that. Graphics hardware sometimes needs BIOS calls, on non-i386 hardware that has to be done by an emulator. Post-boot, for the primary card, I don't know what hardware requires BIOS calls at ths point. We certainly shouldn't encourage people to build drivers that do. No. But you already limit yourself to the primary card, a new design shouldn't be limited that way. And an astonishingly big number of people have to rely on vesa fb, because driver development for their hardware sucks big time (no docs, no hardware in time, etc.). Currently AFAIK we don't allow changing the resolution here during runtime, I'd like to see a new framework being flexible enough with this respect. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - 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
Re: DRM enhancements document
On Aug 22, 07 17:21:09 +0300, Daniel Stone wrote: But that exactly makes version control difficult (lots of cases, especially if the exact requirements aren't clear from day one). I honestly don't understand the problem. Your ioctl number is _that_ request. It's not referring to a vague concept, but a single structure you've already specified. Well, you already know what parameters you need for selecting crtcs/outputs/modes/etc.? I would assume that the needed parameters will change over time, as new features are thought of etc. And I could imagine that this happens frequently. If you have ioctl number 32, your next free one is 43, and you want to change the semantics of UPDATE_WINDOW, then you rename 32 to UPDATE_WINDOW_OLD, create UPDATE_WINDOW as 43 with the new structure, and handle both cases. I consider this giving headaches. I never had any similar issues with a tag-based approach. Well, it's not my baby, I won't cry ;-) Just trying to give some help. Without a version field, this is made impossible, something that must be avoided at all costs. Except that your ioctl then becomes variably-sized unless you add loads of padding and hope for the best. If every tag is int32 and its parameter int32 as well, this isn't too problematic. Question is whether everything needed can be represented in 32 bit values, strings are a completely different concept and don't match well here, as pointers are probably difficult to handle over the user land / kernel barrier... CU Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - 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
Re: DRM enhancements document
On Aug 12, 07 17:50:12 +0200, [EMAIL PROTECTED] wrote: On Thu, Aug 02, 2007 at 07:31:01PM +0200, Jerome Glisse wrote: There should be master (possibly one for each card) which be the only one being able to do this call: DRM_IOCTL_MODE_SETCRTC - set CRTC parameters Please be sure that if you design this using ioctls the design should be forward and backward compatible. AFAICS the only way to ensure this is some sort of tag-based parameter space (parameters are a list of tag,value pairs, terminated by a special tag). Otherwise you're stuck with one parameter list, which you cannot enhance easily, and version control both in user and kernel space will be a nightmare. With tags you can just ignore the tags you don't know about. I fail to understand why you want to put the manager in a daemon, instead of just letting the kernel do the management, like it does for all other hardware. Why is graphics hardware supposed to be different in this regard? Because we won't get an ix86 emulator in kernel space, Linus and others have been pretty clear about that. Graphics hardware sometimes needs BIOS calls, on non-i386 hardware that has to be done by an emulator. This is just one reason. One other is that you want to address graphics in user space anyways for performance reason. Of course, mode setting isn't exactly performance critical. You just cannot compare graphics hardware with any other hardware at all. Graphics chips are more complicated than any CPU on the market, which other hardware type is similar? Even high-speed interconnects like infiniband are trivial compared to that. That said, I'm not 100% confident that the currently discussed way is the right solution. OTOH I don't know the right solution myself either... Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de - 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
Re: radeon problems with current cvs code
On May 03, 06 14:35:45 +0200, Luca Dionisi wrote: On 3/28/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: It will, just no yet. It's beeing developped on intel chipsets at the moment and will probably be ported over at one point. I can't tell more precisely. As far as you know, does the ATI binary driver have FBO support? It has pBuffer support, which is good enough for Xgl, if that's what you're asking. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mesa strict aliasing probs fixed
find a patch attached that fixes all remaining strict-aliasing problems
when compiling Mesa with gcc 4 (at least for me).
Are you sure you've got the #ifdef logic correct?
Actually, no. And I didn't recognize what you were referring to until
today...
You are right, it should have been the other way round.
However, I dug a little bit deeper, and found that even the interface
(in glut/glx/glutint.h) only wants to get a void **, and as we do not
have to access the fbconfig anyway, I patched everything to be void **.
This compiles cleanly.
#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
typedef void *fbc_t;
#else
typedef GLXFBConfigSGIX fbc_t;
#endif
I would expect that the proper test would be:
#if defined(GLX_SGIX_fbconfig)
typedef GLXFBConfigSGIX fbc_t;
#else
typedef void *fbc_t;
#endif
I still keep the test for GLX_VERSION_1_1. It shouldn't hurt, and maybe
there are some subtle flaws in old header files.
Would mind creating a new patch? I don't have any time to do so.
-Brian
I know, this took much longer than it should, however, here's finnally
the updated patch.
Thanks
Matthias
--
Matthias Hopf [EMAIL PROTECTED] ____ __
Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED]
Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de
Index: src/glut/glx/glut_dstr.c
===
RCS file: /cvs/mesa/Mesa/src/glut/glx/glut_dstr.c,v
retrieving revision 1.5
diff -u -p -r1.5 glut_dstr.c
--- src/glut/glx/glut_dstr.c12 Feb 2003 23:56:23 - 1.5
+++ src/glut/glx/glut_dstr.c1 Sep 2005 16:30:17 -
@@ -1530,11 +1530,7 @@ main(int argc, char **argv)
char *str, buffer[1024];
int tty = isatty(fileno(stdin));
int overlay = 0, showconfig = 0;
-#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
- GLXFBConfigSGIX fbc;
-#else
void *fbc;
-#endif
#if !defined(_WIN32)
dpy = XOpenDisplay(NULL);
@@ -1563,10 +1559,10 @@ main(int argc, char **argv)
} else {
if (overlay) {
vinfo = getVisualInfoFromString(str, treatAsSingle,
-requiredOverlayCriteria, numRequiredOverlayCriteria,
requiredOverlayCriteriaMask, (void**) fbc);
+requiredOverlayCriteria, numRequiredOverlayCriteria,
requiredOverlayCriteriaMask, fbc);
} else {
vinfo = getVisualInfoFromString(str, treatAsSingle,
-requiredWindowCriteria, numRequiredWindowCriteria,
requiredWindowCriteriaMask, (void**) fbc);
+requiredWindowCriteria, numRequiredWindowCriteria,
requiredWindowCriteriaMask, fbc);
}
if (vinfo) {
printf(\n);
Index: src/glut/glx/glut_overlay.c
===
RCS file: /cvs/mesa/Mesa/src/glut/glx/glut_overlay.c,v
retrieving revision 1.4
diff -u -p -r1.4 glut_overlay.c
--- src/glut/glx/glut_overlay.c 12 Feb 2003 23:56:23 - 1.4
+++ src/glut/glx/glut_overlay.c 1 Sep 2005 16:30:17 -
@@ -362,11 +362,7 @@ glutEstablishOverlay(void)
GLUToverlay *overlay;
GLUTwindow *window;
XSetWindowAttributes wa;
-#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
- GLXFBConfigSGIX fbc;
-#else
void *fbc;
-#endif
/* Register a routine to free an overlay with glut_win.c;
this keeps glut_win.c from pulling in all of
@@ -389,7 +385,7 @@ glutEstablishOverlay(void)
__glutFatalError(out of memory.);
overlay-vis = determineOverlayVisual(overlay-treatAsSingle,
-overlay-visAlloced, (void **) fbc);
+overlay-visAlloced, fbc);
if (!overlay-vis) {
__glutFatalError(lacks overlay support.);
}
Index: src/glut/glx/glut_win.c
===
RCS file: /cvs/mesa/Mesa/src/glut/glx/glut_win.c,v
retrieving revision 1.6
diff -u -p -r1.6 glut_win.c
--- src/glut/glx/glut_win.c 12 Feb 2003 23:56:23 - 1.6
+++ src/glut/glx/glut_win.c 1 Sep 2005 16:30:17 -
@@ -30,7 +30,7 @@ GLUTwindow *__glutMenuWindow = NULL;
void (*__glutFreeOverlayFunc) (GLUToverlay *);
XVisualInfo *(*__glutDetermineVisualFromString) (char *string, Bool *
treatAsSingle,
- Criterion * requiredCriteria, int nRequired, int requiredMask, void** fbc) =
NULL;
+ Criterion * requiredCriteria, int nRequired, int requiredMask, void **fbc) =
NULL;
static Criterion requiredWindowCriteria[] =
{
@@ -471,11 +471,7 @@ __glutCreateWindow(GLUTwindow * parent,
unsigned long attribMask;
int winnum;
int i;
-#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
- GLXFBConfigSGIX fbc;
-#else
void *fbc;
-#endif
#if defined(_WIN32)
WNDCLASS wc;
@@ -501,7 +497,7 @@ __glutCreateWindow(GLUTwindow * parent,
#if !defined(_WIN32)
window-vis = __glutDetermineWindowVisual(window-treatAsSingle,
-window-visAlloced, (void**) fbc);
+window-visAlloced, fbc);
if (!window-vis) {
__glutFatalError(
visual
Re: why no open source driver for NVIDIA/ATI
On Jul 28, 05 19:29:19 +0200, Roland Scheidegger wrote: R200 did not really have pixel shaders. They had a configurable pixel pipeline, that's different. Comparable to GeForce2, a little bit better. Looks better to me than GeForce3/4, really, if only for the dependant texture read. You nowadays indeed have (directx) games which have PS 1.4 (thus r200) as minimum, but won't work on GF3/4. GeForce3 didn't improve much here compared to GeForce2. You could have dependant texture read in GeForce3 as well (NV_texture_shader), but I think that the later R2xx were a little bit more flexible. The GeForce3 had 3D textures (except for an early sample we had at Unversity :-/ ), and IIRC this was before the Radeon7500. If the Radeon7500 has it, the radeon 7200 (radeon sdr/ddr as it was called) should have it too. And that was certainly way before geforce3. It seems to have it as well. I don't remember the release dates, though. I think I remember, that the OpenGL drivers exposed this feature on the GeForce first. Well - sort of. R300 still does not do IEEE computations in its pixel shader (I think R400 doesn't either), which gives you crappy results for GPGPU applications. True, but that's not really what these cards are intended for. R300 does nice fast fp24 calculations, with FX5 you could choose between really slow fp16 and even slower fp32 :-). Oh or you could choose quite fast int8... Sort of. Well, fp16 was quite ok. And on FX6 this is really fast now. Yep. They used to do good hardware. Have fallen behind a bit compared to GeForce6, but not much. Well, r520 should do fp32, longer shaders and what not. The chip's late though, we'll see. (is it only me or is this all slightly offtopic?) Yep, let's end it now :^) Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de --- 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: why no open source driver for NVIDIA/ATI
On Jul 27, 05 17:14:25 -0400, Patrick McFarland wrote: On Wednesday 27 July 2005 04:54 pm, Ian Romanick wrote: Also, what stops you from splitting up a shader, and running the peices back to back over multiple passes? Can't you emulate longer shaders doing that? No. Temporary registers are stepping in your back. And even with Multiple render targets (does the R200 support that already?) you wouldn't have enough targets for the available number of registers. And you do not *want* to support that. It would be dog slow. Better let the application choose to use a render path that does not need pixel shaders, and give you a decent frame rate at worse quality. It can only do so by recognizing that your card does *not* support pixel shader. The only valid approach would be to create another pixel shader extension, that only promotes features R200 is able to implement. Have fun to hack this yourself! It is tons of work. And there's no application out there that would use it. So, I looked into this really deeply in the past for other things. The problem is it gets *very* hard to deal with framebuffer blend modes. If you have an arbitrary triangle list, triangles in the list may overlap. You *could* work with offscreen memory and per-triangle multiple passes. You don't want to, though. So, how many games use blend modes other than dst=src? Also, even if it isn't All. This, BTW, is what ATI's fbuffer in all about. I'm trying to find more information about this fbuffer, but Google isn't being too friendly. It's not Google's fault. Back in University I used to hack a lot for my PhD thesis using latest OpenGL features. fbuffer is something ATI used in advertizing and nowhere else. They claim they can store the intermediate pixel shader state in this fbuffer and make multipass shaders work this way transparently. I doubt it ever worked, because you shouldn't have instruction limits in this case, but you have, and much smaller limits than the GeForce has. I also think to remember that fbuffer advertizement was only added with R300. So no help for R200. Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 I hate to say it, but some seem to do ;- CU Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de --- 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: why no open source driver for NVIDIA/ATI
On Jul 28, 05 11:52:10 +0200, Wladimir van der Laan wrote: This is the sound of me hating ATI for making such useless pixel shaders. R200 did not really have pixel shaders. They had a configurable pixel pipeline, that's different. Comparable to GeForce2, a little bit better. Hey hey calm down a little there, up until the R300 ATI has been on the forefront for implementing new features on their chips like: - 3d textures. NVidia only came up with those in the FX5 series, ati had them already in the Radeon7500. The GeForce3 had 3D textures (except for an early sample we had at Unversity :-/ ), and IIRC this was before the Radeon7500. - Multi render target support. ATI r300 can do it, NVidia FX5 series cannot. Right, the lack of multiple render targets sucked. - Floating point textures. ATI r300 can do it perfectly, NVidia FX5 series is limited to TEXTURE_RECTANGLE. Well - sort of. R300 still does not do IEEE computations in its pixel shader (I think R400 doesn't either), which gives you crappy results for GPGPU applications. ATI their Linux drivers are a crippled bunch, that's for a fact, and that's a big reason why open source r300 drivers get so much attention. But don't offend their chip designers :) Yep. They used to do good hardware. Have fallen behind a bit compared to GeForce6, but not much. Wladimir Ogre3D Team (http://www.ogre3d.org) Nice engine, BTW! Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de --- 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: Mesa strict aliasing probs fixed
Would mind creating a new patch? I don't have any time to do so. Sure. Just don't expect this to happen today. I'll have a couple of other patches next week, some of which are likely to be debatable. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de --- 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
Mesa strict aliasing probs fixed
Hi,
find a patch attached that fixes all remaining strict-aliasing problems
when compiling Mesa with gcc 4 (at least for me).
CU all
Matthias
--
Matthias Hopf [EMAIL PROTECTED], SuSE labs, Zimmer 3.2.06, Tel. 74053-715
Index: src/glut/glx/glut_dstr.c
===
RCS file: /cvs/mesa/Mesa/src/glut/glx/glut_dstr.c,v
retrieving revision 1.5
diff -u -p -r1.5 glut_dstr.c
--- src/glut/glx/glut_dstr.c12 Feb 2003 23:56:23 - 1.5
+++ src/glut/glx/glut_dstr.c8 Jul 2005 17:04:00 -
@@ -34,6 +34,12 @@ static int glxcap[NUM_GLXCAPS] =
GLX_LEVEL,
};
+#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
+typedef void *fbc_t;
+#else
+typedef GLXFBConfigSGIX fbc_t;
+#endif
+
#ifdef TEST
#if !defined(_WIN32)
@@ -41,7 +47,7 @@ char *__glutProgramName = dstr;
Display *__glutDisplay;
int __glutScreen;
XVisualInfo *(*__glutDetermineVisualFromString) (char *string, Bool *
treatAsSingle,
- Criterion * requiredCriteria, int nRequired, int requiredMask, void **fbc) =
NULL;
+ Criterion * requiredCriteria, int nRequired, int requiredMask, fbc_t *fbc) =
NULL;
char *__glutDisplayString = NULL;
#endif
static int verbose = 0;
@@ -626,7 +632,7 @@ loadVisuals(int *nitems_return)
static XVisualInfo *
findMatch(FrameBufferMode * fbmodes, int nfbmodes,
- Criterion * criteria, int ncriteria, void **fbc)
+ Criterion * criteria, int ncriteria, fbc_t *fbc)
{
FrameBufferMode *found;
int *bestScore, *thisScore;
@@ -1420,7 +1426,7 @@ static int nfbmodes = 0;
static XVisualInfo *
getVisualInfoFromString(char *string, Bool * treatAsSingle,
- Criterion * requiredCriteria, int nRequired, int requiredMask, void **fbc)
+ Criterion * requiredCriteria, int nRequired, int requiredMask, fbc_t *fbc)
{
Criterion *criteria;
XVisualInfo *visinfo;
@@ -1530,11 +1536,7 @@ main(int argc, char **argv)
char *str, buffer[1024];
int tty = isatty(fileno(stdin));
int overlay = 0, showconfig = 0;
-#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
- GLXFBConfigSGIX fbc;
-#else
- void *fbc;
-#endif
+ fbc_t *fbc;
#if !defined(_WIN32)
dpy = XOpenDisplay(NULL);
@@ -1563,10 +1565,10 @@ main(int argc, char **argv)
} else {
if (overlay) {
vinfo = getVisualInfoFromString(str, treatAsSingle,
-requiredOverlayCriteria, numRequiredOverlayCriteria,
requiredOverlayCriteriaMask, (void**) fbc);
+requiredOverlayCriteria, numRequiredOverlayCriteria,
requiredOverlayCriteriaMask, fbc);
} else {
vinfo = getVisualInfoFromString(str, treatAsSingle,
-requiredWindowCriteria, numRequiredWindowCriteria,
requiredWindowCriteriaMask, (void**) fbc);
+requiredWindowCriteria, numRequiredWindowCriteria,
requiredWindowCriteriaMask, fbc);
}
if (vinfo) {
printf(\n);
Index: src/glut/glx/glut_overlay.c
===
RCS file: /cvs/mesa/Mesa/src/glut/glx/glut_overlay.c,v
retrieving revision 1.4
diff -u -p -r1.4 glut_overlay.c
--- src/glut/glx/glut_overlay.c 12 Feb 2003 23:56:23 - 1.4
+++ src/glut/glx/glut_overlay.c 8 Jul 2005 17:04:00 -
@@ -28,6 +28,12 @@
#include glutint.h
#include layerutil.h
+#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
+typedef void *fbc_t;
+#else
+typedef GLXFBConfigSGIX fbc_t;
+#endif
+
static Criterion requiredOverlayCriteria[] =
{
{LEVEL, EQ, 1}, /* This entry gets poked in
@@ -315,7 +321,7 @@ __glutFreeOverlay(GLUToverlay * overlay)
}
static XVisualInfo *
-determineOverlayVisual(int *treatAsSingle, Bool * visAlloced, void **fbc)
+determineOverlayVisual(int *treatAsSingle, Bool * visAlloced, fbc_t *fbc)
{
if (__glutDisplayString) {
XVisualInfo *vi;
@@ -362,11 +368,7 @@ glutEstablishOverlay(void)
GLUToverlay *overlay;
GLUTwindow *window;
XSetWindowAttributes wa;
-#if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig)
- GLXFBConfigSGIX fbc;
-#else
- void *fbc;
-#endif
+ fbc_t *fbc;
/* Register a routine to free an overlay with glut_win.c;
this keeps glut_win.c from pulling in all of
@@ -389,7 +391,7 @@ glutEstablishOverlay(void)
__glutFatalError(out of memory.);
overlay-vis = determineOverlayVisual(overlay-treatAsSingle,
-overlay-visAlloced, (void **) fbc);
+overlay-visAlloced, fbc);
if (!overlay-vis) {
__glutFatalError(lacks overlay support.);
}
@@ -567,7 +569,7 @@ glutLayerGet(GLenum param)
{
XVisualInfo *vi;
Bool dummy, visAlloced;
- void *fbc;
+ fbc_t fbc;
vi = determineOverlayVisual(dummy, visAlloced, fbc);
if (vi) {
Index: src/glut/glx/glut_win.c
===
RCS file: /cvs/mesa/Mesa/src/glut/glx/glut_win.c,v
retrieving revision 1.6
diff -u -p -r1.6 glut_win.c
--- src/glut/glx/glut_win.c 12 Feb 2003 23:56:23 - 1.6
+++ src/glut/glx
Re: Mesa strict aliasing probs fixed
On Jul 13, 05 09:16:32 -0600, Brian Paul wrote: find a patch attached that fixes all remaining strict-aliasing problems when compiling Mesa with gcc 4 (at least for me). Are you sure you've got the #ifdef logic correct? I just copied the one that was already present and didn't think much about it. #if defined(GLX_VERSION_1_1) defined(GLX_SGIX_fbconfig) typedef void *fbc_t; #else typedef GLXFBConfigSGIX fbc_t; #endif I would expect that the proper test would be: #if defined(GLX_SGIX_fbconfig) typedef GLXFBConfigSGIX fbc_t; #else typedef void *fbc_t; #endif I would expect that as well. But I wanted a minimal invasive change. Feel free to change this ;) I'd probably also replace 'fbc_t' with 'fbconfig_t' to make it more readable. That's perfectly fine for me. Thanks Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OpenGL without X
On May 17, 05 23:13:07 +0200, Jerome Glisse wrote: Sorry but what is exactly xen (googling give me pointless informations i think...). :) The next generation virtualization support. Something like user mode linux, just much more performant. See it like vanderpool, with the difference that you need support from the operating system that should run on Xen, and not support from the processor. BTW, it is shipped with SuSE Linux 9.3. Read more at http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de --- 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=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Howto flush Texture Cache on R100?
Hi! Does anybody know a reliable way to flush the texture cache of R100 Radeon chips? (e.g. Radeon 7200, 7500, etc.) Background: I found some glitches with X.org's Render extension, and a workaround, but I would rather like to have a solid resolution and not that kind of hack: http://freedesktop.org/bugzilla/show_bug.cgi?id=1424 CU all Matthias -- Matthias Hopf [EMAIL PROTECTED] /-- /-- /-- [EMAIL PROTECTED] Maxfeldstr. 5 / 90409 Nuernberg\-\ | | \-\ |-- www.mshopf.de Phone +49-911-74053-715--/ \_/ --/ \-- labs --- 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
