Re: [Dri-devel] r100 regression: gltext screensaver too dark
Felix Kühling wrote: On 01 Aug 2003 23:39:49 +0200 Michel Dänzer <[EMAIL PROTECTED]> wrote: On Fri, 2003-08-01 at 23:10, Felix Kühling wrote: On Fri, 1 Aug 2003 19:28:24 +0200 Felix Kühling <[EMAIL PROTECTED]> wrote: I'm currently testing the trunk on my Radeon 7500, especially Keith's recent TCL and dma_tmp work. All real applications seem to work fine but gltext xscreensaver is way too dark now. It looks like there is only ambient light. With RADEON_TCL_FORCE_DISABLE=1 it looks ok. More xscreensaver demos have the same problem: gears, lament, engine, queens, endgame, sballs, sierpinsky3d, maybe more. engine is interesting because the ignition flashes are still visible. And with sierpinsky3d it seems like the light source is there but is effective only in a very small radius. This sounds like the bug Keith fixed in revision 1.16 of r200_state.c . That's the revision I have checked out. Apperently this hasn't been propagated to r100. :( I'll try to port his change to r100. But I won't have time tomorrow. If someone's faster than me ... ;-) You're probably right. Go ahead & check in a fix - I'll be away the next few days. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Re: [Dri-devel] Radeon 9000 Mobility (r250 lf) issue
BTW, what about the drm modules, do they recognize the hardware also, or do they not care about being loaded or not. I think they check, but I'm not sure. I'd have to look. I don't think so. The FreeBSD varients have a table of pci ids, but that's got a lot to do with the FreeBSD device model. The linux ones just let it all hang out, I think. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Re: [Dri-devel] Radeon 9000 Mobility (r250 lf) issue
It would be simple to add some checking to ensure the chipid is recognized by the 3d driver, just hasn't been done yet. Let me work up a patch that does this in a more generally way. The current big switch-statement is somewhat unpleasant.Do the embedded drivers have a header file where they get PCI IDs? I assume that xf86PciInfo.h is not available. :) We should probably just import it. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Re: [Dri-devel] Radeon 9000 Mobility (r250 lf) issue
Ian Romanick wrote: Michel Dänzer wrote: On Wed, 2003-07-30 at 03:06, Ian Romanick wrote: Antoine REVERSAT wrote: I just compiled dri from the CVS for my radeon 9000 Mobbility card (r250 lf) and it wont work as good as it is expected to (I.E : 30 fps in Quake3) The thing is when i do a glxinfo it is reported as a r200 chip which it isn't... So i'd like to know if you are aware of this and what solutions do i have. I also wanted to know if support should be better or if this is normal. For information i'm running Gentoo linux 1.4_RC4 with 2.4.21-ac3 patched kernel (patched for the mmu_cr4 problem) I'm running Xfree 4.3.0. If you need more informations let me know. Here's a patch that should clear some of that up, at least for the R200-family of chips. I did change the code to include xf86PciInfo.h. In spite of the comment there, it doesn't seem to produce any errors. Is this a safe change to make? Also, do we really need to check the device ID against R100-family IDs in the R200 driver? Apparently, people do try to use the wrong drivers on the Mesa embedded and whatnot branches... How can that be? The user has to select which 3D driver to use (i.e., the 2D driver doesn't select it for them)? What's to stop someone with an R200 from "selecting" the MGA driver? There's no 2D driver. It would be simple to add some checking to ensure the chipid is recognized by the 3d driver, just hasn't been done yet. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Observations about dynamic extension registration
Ian Romanick wrote: Felix Kühling wrote: On Wed, 30 Jul 2003 09:20:28 -0700 Ian Romanick <[EMAIL PROTECTED]> wrote: Felix Kühling wrote: I see: C SPECIFICATION const char * glXQueryExtensionsString( Display *dpy, int screen ) I don't mean what the GLX specification says to do. I mean what our code actually implements. Internally there is a *single* *global* table & extension string. So it's not even tracking it per-display. It's worse than that. :( Yeah, I was just pointing out how extension tracking is specified. they are instead tracked per-display. This doesn't "matter" right now because we don't support the configuration that you describe (at least not as far as I know!). Each card would be it's own display. Maybe these configs don't work for one reason or another, but the configuration framework was designed with this in mind and also the code in dri_glx.c handles the case of different drivers for different screens. I see two choices here, either glxextensions.c manages multiple screens itself or the four bitfields server/client_support/only are managed in __GLXscreenConfigsRec. In either case glXGetUsableExtensions would have to be told about the screen. A screen number in the first case or a __GLXscreenConfigsRec pointer in the second case. Since glXGetUsableExtensions is only called from glXQueryExtensionsString (glxcmds.c, line 1416), that should be an easy change to make. It gets more complicated with __glXEnableExtension. If it has to access per-screen extension information it would need some sort of a screen parameter too. As it's called by the driver, this is a binary compatibility problem. Furthermore it is called from __driRegisterExtensions which doesn't know the screen itself. It is a binary compatabilty problem, but a minor one. Since no code with __glXEnableExtension has ever shipped with XFree86 (stable release or their CVS), our exposure is pretty low. Low enough that I wouldn't worry about it much. There is a pre-texmem code-path that was used by the R200 driver that needs to be maintained. I'm not sure how to keep that working. The quick and dirty solution would be a global screen pointer that indicates the screen currently being configured. A more invasive but more elegant solution is this: I observed that glXQueryExtensionsString calls glXInitialize first which in turn loads and initializes the dri drivers (calls their createScreen functions). Thus, before an extension string is returned all drivers are initialized. So why not register extensions in the driver's createScreen function? The only reason I can see is the call to glXRegisterExtensions in glXGetProcAddress. Is there a good reason for not calling glXInitialize in glXGetProcAddress instead? That's a really good idea. I think that solves most of the problems. Keith, do you have a problem with that change? Not off the top of my head. It's worth asking Brian about this, as he's had greater involvement in those paths than I. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Re: [Dri-devel] DRI weirdness on PowerPC + ATI 7500 (r200)
Ian Romanick wrote: Jérôme Marant wrote: Michel Dänzer <[EMAIL PROTECTED]> writes: Yes, like that. And fishes appear as rectangles, as well as trees. BTW, does setting RADEON_AGPTEXTURING_FORCE_DISABLE work around it? If so, Ian is working on fixing it. I've tried export RADEON_AGPTEXTURING_FORCE_DISABLE=1 and it seems to works fine now. Here is a patch that should fix the root of the problem. There are a couple things about the patch that I don't like, which I why I haven't already commited it. 1. I don't like the hard-coding of 2*1024*1024 as the size of the indirect buffers. This was copied directly from the R200 driver, but I don't like it. We may want to change the size of this buffer at some point, and hard-coding the value into the client-side driver will make that difficult. Agreed. 2. I don't like the hackish handing of the pre-1.3 DRM case. Are there other PCI IDs that need the 128MB offset? Do we even support the pre-1.3 DRM anymore? If we don't support the pre-1.3 DRM (and don't intend to fix the support), I'd like to chop all the pre-1.3 stuff out. That will make the Radeon driver "look" a lot more like the R200 driver. That's a good thing IMHO. I think we should drop the pre-1.3 support. It's broken & would take a fair effort to fix. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Observations about dynamic extension registration
Felix Kühling wrote: Hi, as I'm going to clean up vsync related stuff on the config-0-0-1-branch I read the code for dynamic glx extension registration in xc/lib/GL/dri/dri_glx.c and xc/lib/GL/glx/glxextensions.[ch]. I stumbled over this comment in front of __glXRegisterExtensions: ** In older versions of libGL (prior to October 2002) we _always_ ** called this function during libGL start-up. Now, we only call ** it from glXGetProcAddress() as a last resort. However, __glXRegisterExtensions is still called in driCreateDisplay. Hmm, on the other hand I found this comment in radeon_screen.c in front of __driRegisterExtensions: /* This function is called by libGL.so as soon as libGL.so is loaded. * This is where we'd register new extension functions with the dispatcher. Do the __driRegisterExtensions functions in the drivers rely on being called during initialisation? In fact I believe it could be dangerous if __driRegisterExtensions was called later as it may override extensions disabled in e.g. CreateContext due to lacking hardware support. Fortunately __glXRegisterExtensions returns immediately if it is called the second or later time. Maybe it's just a matter of updating a few comments after all. The __driRegisterExtensions is used to add named entrypoints to the dispatch table, that can be retrieved with glXGetProcAddress, etc. It doesn't "turn on" extensions in the sense that they are added to the extensions string managed by mesa/src/extensions.c Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Congratulations to recent changes
Martin Spott wrote: Keith Whitwell <[EMAIL PROTECTED]> wrote: Anyway, I'm glad this fixed your problem. Yep, now I can continue to promote the use ATI boards in the FlightGear manua ;-) If anyone likes, I now have a different one. This shows up with HW-TCL only when I use more komplex textured aircrafts. With the default C172 everything looks fine. Here some triangles on the ground remain untextured: http://document.ihg.uni-duisburg.de/bitmap/FGFS/artefact_01.png This looks a lot like a regression due to my recent changes to r200_tcl.c and t_dd_dmatmp2.h Does it go away if you turn off tcl? Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] VIA Status
Alan Cox wrote: VIA sent me a new code drop today which fixed some stuff broke other stuff but generally went in a forward direction. I've got a pile of 2D cleanups to do that Egbert wants for the 2D side, but the good news is I cleaned up their (now cleaner) 3D stuff and it now sort of works with XFree 4.3.0. Sort of being: if you use NoAccel for the 2D and providing you run "glxgears" with none of the window obscured. I'm still trying to get my head around the span code and why it doesn't want to call my SetReadBuffer function. Hopefully with that resolved it'll run the screensavers too. The semantics surrounding readbuffer's are a bit non-obvious, and there may be some bugs in either my understanding or mesa's implementation wrt that function. It's worth examining the other drivers & posting questions on mesa-devel where Brian is more active... Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] mga strips/fans
Ville Syrjälä wrote: This patch enables triangle strips and fans support on G400. - New drm should be compatible with old userspace and vice versa. - I threw that cull_dualtex stuff out. I moved the spcial case to EmitHWStateLocked() and it's only used when an old drm is detected. It is needed because the old drm swaps the WARPs with dualtex for some reason. I also changed the drm's WACCEPTSEQ dualtex value to 0x1c00 from 0x1e00. I don't think there's any need to touch seqlen. Only wfirsttag needs to be toggled. Ugh - these are pretty major changes. How thoroughly have you tested them? The WARP is swapped because the 2nd warp is designed for dual texturing. I'm not sure I believe that the singletex warp will do the right thing for multitexturing - in fact I'm sure I can remember bugs when I didn't swap them over correctly. - I changed the dualtex fan WACCEPTSEQ value to the one used in the WARP DDK. I'm not entirely sure about this but I suspect the change was needed due to the cull_dualtex stuff. I only have single tex + fan apps so I'll have to write a test for this... Hmm. This might be reverting the fix to the infamous G400 q3 lockup. Be sure to play many hours of quake with this test before considering it right. It's probably worth checking back to see exactly what the fix to this bug was, but we definitely had to go against what the DDK said to fix it. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] NWN
Adam K Kirchhoff wrote: On Mon, 28 Jul 2003, Roland Scheidegger wrote: Paul Heldens wrote: glxinfo ... direct rendering: Yes ... OpenGL renderer string: Mesa DRI R200 20030328 AGP 1x x86/MMX+/SSE2 TCL OpenGL version string: 1.3 Mesa 5.0.1 ... When I try to start: ./nwn Error The NWN forum says this has to do with impropper initialisation of opengl subsystem. ? clues someone ? It's a R250 card with ~3 weeks old trunk snapshot. You need this patch http://sourceforge.net/mailarchive/forum.php?thread_id=2054806&forum_id=7177 for nwn to work (unless you're using the beta 3 client or older, you definitely need it for 1.29, haven't checked for 1.30 if it's still needed). Unfortunately this patch is not yet in the trunk as it might break other things. Seems like a chicken-and-egg problem, if it's not in the trunk almost nobody (except those people who need it to get something running) tests it, but without testing it won't make it into the trunk ;-). For the record, the patch runs fine here. Oh and if you make it past the Error, you might want to use R200_NO_TCL=1 as there are some issues with NWN - or try updating dri, the bugs might get fixed... How many people need to report that this patch works and has no negative side effects before it gets merged in? I'm OK with this going in. We're generally pretty good at committing patches, but sometimes they slip through. Try reposting with a [PATCH] designator to make it obvious that there's something that needs consideration, etc. Anyway, I'm going to hold off until Ian's issue is resolved. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Q3A SMP problems (was Re: [Dri-devel] i830 latest trunk --- compilationerror)
If I had an SMP box I'd be able to track this down on my own. Instead all I have are these stinking nearly-top-of-the-line uniprocessor boxes. :) You can't get hyperthreading running on any of them? Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Congratulations to recent changes
Martin Spott wrote: Currently I don't know _what_ has been changed because ATM I don't have access to the mailing list. But there _must_ have been substantial changes because apparently the "too dark lightning with TCL on Radeon" bug has been fixed. Running FlightGear on a Radeon9100 with the R200 driver I can't tell the difference beween disabling and enabling TCL any more. Obviously this is a change that happened in the X server modules because I didn't recompile the kernel modules yet. Thanks (I hope the good news don't rely on some sort of 'accident' ;-) Martin. Somebody took the trouble to produce a small demo that exercised a related problem. It's so much easier to debug a driver with a small demo-sized example of a bug than to try & wade through the behaviour an unfamiliar mega-sized app like flightgear... Anyway, I'm glad this fixed your problem. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3 bugs with DRI on ATI radeon 7500 M7 card
Roland Scheidegger wrote: Keith Whitwell wrote: Bertrand Lamy wrote: hello everybody I have found 3 bugs in the DRI driver. See the attached file for description. Each program is the 'minimal' code to get the bug. I also give my computer configuration. I am quite sure that the bugs lie in the driver cause: - it does not bug when using mesa and no 3D card (program launched with noglx) - it does not bug on others computers: one with a nvidia card, one with another ATI radeon PS: I have joined a shot of the bug obtained with the program test_gl3.c I've fixed this one (test_gl3.c) & am working on the others. Keith These changes (not sure if the cvs I got has all of them, got r200_state.c version 1.16) change lighting considerably in NWN. However, it's still not correct, it is too dark now. I've uploaded a new picture (especially weird is IMHO the highlighted door which is now completely black): http://homepage.hispeed.ch/rscheidegger/nwn_newlight.jpg This sounds like the BilliardGL, etc. regression that I fixed up yesterday. I've just ordered a copy of NWN, so I'll be able to test directly... Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3 bugs with DRI on ATI radeon 7500 M7 card
Michel Dänzer wrote: On Sun, 2003-07-27 at 13:56, Michel Dänzer wrote: Keith, while you're debugging the Radeon drivers... :) I just did a little testing roundup with the r200 driver: Keith strikes again. :) Some updates: Unfortunately, these changes broke lighting for billard-gl, foobillard, fsv, gltron and some of the rss-glx hacks; some parts of these look too dark now. The foobilliard problem looks a bit like depth fighting requiring the use of PolygonOffset in the app to fix... Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3 bugs with DRI on ATI radeon 7500 M7 card
Michel Dänzer wrote: Another regression is that some things are invisible in amoeba (some textures) and crack-attack (pretty much everything involved in the actual game :). crack-attack is fixed. What about amoeba? I'm having trouble downloading this - it seems I need some data file, but I can't find it on the referenced website. Have you got a url? Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3 bugs with DRI on ATI radeon 7500 M7 card
Bertrand Lamy wrote: hello everybody I have found 3 bugs in the DRI driver. See the attached file for description. Each program is the 'minimal' code to get the bug. I also give my computer configuration. I am quite sure that the bugs lie in the driver cause: - it does not bug when using mesa and no 3D card (program launched with noglx) - it does not bug on others computers: one with a nvidia card, one with another ATI radeon PS: I have joined a shot of the bug obtained with the program test_gl3.c I've fixed this one (test_gl3.c) & am working on the others. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Patch] Another triangle fan bug
Ian Romanick wrote: [EMAIL PROTECTED] wrote: The following patch alters the way triangle fans are split to cover dma buffer boundaries. Without the patch the first polygon after the split will be missing. I've only tested the sw tcl case (as my chipset doesn't support hw tcl) and the problem only manifests when emitting verts (since elts don't appear to split), but I'm certain this is correct behaviour when rendering triangle fans. This patch does in fact address a specific bug (XF86 bug #185). Good catch. That's another part of the puzzle, but it doesn't "fix" all of the SW TCL triangle fan problems by itself. For example, running Think Tanks with this patch on my Radeon 7200 DDR and RADEON_TCL_FORCE_DISABLE set, I get the same hang as with the TCL path w/o my emit_elts replacement patch. I think Keith may have the right idea: we need to take a long, hard look at just re-writing a bunch of the DMA template routines. I think that there's a need for someone to perform the same changes in t_dd_dmatmp.h as I've done for t_dd_dmatmp2.h -- the older template is probably subject to the same bugs. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Another dmatmp2 patch (quads_elts)
Keith Whitwell wrote: Michael wrote: Keith Whitwell wrote: Where can I download Think Tanks? http://www.garagegames.com/pg/demo.php?id=12 Just played a game with the patched driver & it looked ok. I'll test some other stuff too. OK, I've tested with mesa demos, conform, wolf, tuxracer, thinktanks, chromium bsu. All look ok (though some conform failures have snuck in from somewhere). I'm going to commit the patch. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Another dmatmp2 patch (quads_elts)
Michael wrote: Keith Whitwell wrote: Where can I download Think Tanks? http://www.garagegames.com/pg/demo.php?id=12 Just played a game with the patched driver & it looked ok. I'll test some other stuff too. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Lighting only Fallback?
Guido Landra wrote: Hi, I am using radeon driver standard pipeline, having: _radeon_tcl_stage, _tnl_vertex_transform_stage, _tnl_normal_transform_stage, _tnl_lighting_stage, _tnl_fog_coordinate_stage, _tnl_texgen_stage, _tnl_texture_transform_stage, _radeon_render_stage, _tnl_render_stage My need is to access LitColor[FRONT] and LitColor[BACK] colors generated by MESA. I want to access that values from radeon_maos_vbtmp.h templates. I want transforming done by card and lighting vertices done from MESA. I know this additional work is not really needed, I do this only for test purposes. So I changed pipeline to _tnl_lighting_stage, _radeon_tcl_stage, _tnl_vertex_transform_stage, _tnl_normal_transform_stage, _tnl_fog_coordinate_stage, _tnl_texgen_stage, _tnl_texture_transform_stage, _radeon_render_stage, _tnl_render_stage Is this enough to have lighted vertices color calculated? I tried this way but I get random colors in VB->ColorPtr[0]->Ptr Any idea? Because the lighting stage depends on the results generated by earlier stages. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Another dmatmp2 patch (quads_elts)
Dieter Nützel wrote:
Am Donnerstag, 24. Juli 2003 22:32 schrieb Keith Whitwell:
Michel Dänzer wrote:
On Thu, 2003-07-24 at 22:04, Keith Whitwell wrote:
Michel Dänzer wrote:
On Thu, 2003-07-24 at 21:10, Keith Whitwell wrote:
Keith Whitwell wrote:
BTW. Here's an updated pair of patches. These ones should compile,
but I haven't done much testing yet.
Looks like I broke big-endian, too (sorry Michel).
No worries, you didn't. :)
Are you sure? The EMIT_ELT macro isn't being used any more & I'm just
accessing dest directly, as in 'dest[offset] = elt'...
Everything I've tried so far (glxgears, armagetron, quake2, bzflag,
morph3d) seems to work perfectly. Maybe the ugliness indeed is no
necessary? :) Not that I understand how... *shrug*
What about things that were broken with the old version. Is there a list
of test cases that we can run through?
Think Tanks?
I'll try VTK and the like.
Q3 SMP didn't work after Ian's context fixes.
Where can I download Think Tanks?
Is Felix patch needed?
Index: extras/Mesa/src/tnl_dd/t_dd_dmatmp2.h
===
RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/tnl_dd/t_dd_dmatmp2.h,v
retrieving revision 1.4
diff -u -r1.4 t_dd_dmatmp2.h
--- extras/Mesa/src/tnl_dd/t_dd_dmatmp2.h 26 Aug 2002 22:16:02 -
1.4
+++ extras/Mesa/src/tnl_dd/t_dd_dmatmp2.h 24 Jul 2003 10:48:33 -
@@ -1053,7 +1053,7 @@
if (currentsz < 8)
currentsz = dmasz;
- for (j = start; j + 3 < count; j += nr - 2 ) {
+ for (j = start; j + 3 < count; j += nr ) {
nr = MIN2( currentsz, count - j );
if (nr >= 4)
Maybe, I'll investigate.
Keith
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Another dmatmp2 patch (quads_elts)
Michel Dänzer wrote: On Thu, 2003-07-24 at 22:32, Keith Whitwell wrote: Michel Dänzer wrote: On Thu, 2003-07-24 at 22:04, Keith Whitwell wrote: Michel Dänzer wrote: On Thu, 2003-07-24 at 21:10, Keith Whitwell wrote: Keith Whitwell wrote: BTW. Here's an updated pair of patches. These ones should compile, but I haven't done much testing yet. Looks like I broke big-endian, too (sorry Michel). No worries, you didn't. :) Are you sure? The EMIT_ELT macro isn't being used any more & I'm just accessing dest directly, as in 'dest[offset] = elt'... Everything I've tried so far (glxgears, armagetron, quake2, bzflag, morph3d) seems to work perfectly. Maybe the ugliness indeed is no necessary? :) I'm afraid not, I understand what you mean now, I guess the broken paths are rarely used. Actually, I changed the context mid stream. I did originally mean that I'd broken big-endian in general, but apparently I haven't. Then, I wondered if you have a test case for the original brokenness that we're trying to address with this patch. If big-endian works for those apps, I don't see any reason it shouldn't work in general. What about things that were broken with the old version. Is there a list of test cases that we can run through? I wonder myself. I can only say that it doesn't fix the HW TCL problems e.g. in bzflag, but I guess that was to be expected. Felix pointed out the quakeforge console, which is fixed with the combination of yours and his patches indeed. OK, time to reread old emails... Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Another dmatmp2 patch (quads_elts)
Michel Dänzer wrote: On Thu, 2003-07-24 at 22:04, Keith Whitwell wrote: Michel Dänzer wrote: On Thu, 2003-07-24 at 21:10, Keith Whitwell wrote: Keith Whitwell wrote: BTW. Here's an updated pair of patches. These ones should compile, but I haven't done much testing yet. Looks like I broke big-endian, too (sorry Michel). No worries, you didn't. :) Are you sure? The EMIT_ELT macro isn't being used any more & I'm just accessing dest directly, as in 'dest[offset] = elt'... Everything I've tried so far (glxgears, armagetron, quake2, bzflag, morph3d) seems to work perfectly. Maybe the ugliness indeed is no necessary? :) Not that I understand how... *shrug* What about things that were broken with the old version. Is there a list of test cases that we can run through? Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Another dmatmp2 patch (quads_elts)
Michel Dänzer wrote: On Thu, 2003-07-24 at 21:10, Keith Whitwell wrote: Keith Whitwell wrote: BTW. Here's an updated pair of patches. These ones should compile, but I haven't done much testing yet. Looks like I broke big-endian, too (sorry Michel). No worries, you didn't. :) Are you sure? The EMIT_ELT macro isn't being used any more & I'm just accessing dest directly, as in 'dest[offset] = elt'... Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Another dmatmp2 patch (quads_elts)
BTW. Here's an updated pair of patches. These ones should compile, but I
haven't done much testing yet.
I keep dipping in & out of this, so I loose track somewhat... What are the
simplest test cases for these crashes?
Keith
Index: r200/r200_tcl.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/r200/r200_tcl.c,v
retrieving revision 1.9
diff -u -r1.9 r200_tcl.c
--- r200/r200_tcl.c 30 Apr 2003 01:50:49 - 1.9
+++ r200/r200_tcl.c 24 Jul 2003 18:58:35 -
@@ -103,32 +103,22 @@
#define LOCAL_VARS r200ContextPtr rmesa = R200_CONTEXT(ctx)
-#define ELTS_VARS GLushort *dest
+#define ELT_TYPE GLushort
#define ELT_INIT(prim, hw_prim) \
r200TclPrimitive( ctx, prim, hw_prim | R200_VF_PRIM_WALK_IND )
-#define GET_ELTS() rmesa->tcl.Elts
+#define GET_MESA_ELTS() rmesa->tcl.Elts
-#define NEW_PRIMITIVE() R200_NEWPRIM( rmesa )
-#define NEW_BUFFER() r200RefillCurrentDmaRegion( rmesa )
-
/* Don't really know how many elts will fit in what's left of cmdbuf,
* as there is state to emit, etc:
*/
-#if 0
-#define GET_CURRENT_VB_MAX_ELTS() \
- ((R200_CMD_BUF_SZ - (rmesa->store.cmd_used + 16)) / 2)
-#define GET_SUBSEQUENT_VB_MAX_ELTS() ((R200_CMD_BUF_SZ - 16) / 2)
-#else
/* Testing on isosurf shows a maximum around here. Don't know if it's
* the card or driver or kernel module that is causing the behaviour.
*/
-#define GET_CURRENT_VB_MAX_ELTS() 300
-#define GET_SUBSEQUENT_VB_MAX_ELTS() 300
-#endif
+#define GET_MAX_HW_ELTS() 300
#define RESET_STIPPLE() do { \
R200_STATECHANGE( rmesa, lin ); \
@@ -147,32 +137,22 @@
} while (0)
-/* How do you extend an existing primitive?
- */
-#define ALLOC_ELTS(nr) \
-do { \
- if (rmesa->dma.flush == r200FlushElts &&\
- rmesa->store.cmd_used + nr*2 < R200_CMD_BUF_SZ) { \
- \
- dest = (GLushort *)(rmesa->store.cmd_buf + \
- rmesa->store.cmd_used); \
- rmesa->store.cmd_used += nr*2; \
- } \
- else { \
- if (rmesa->dma.flush)\
-rmesa->dma.flush( rmesa ); \
- \
- r200EmitAOS( rmesa, \
-rmesa->tcl.aos_components, \
-rmesa->tcl.nr_aos_components, \
-0 ); \
- \
- dest = r200AllocEltsOpenEnded( rmesa,\
- rmesa->tcl.hw_primitive, \
- nr );\
- } \
-} while (0)
+#define ALLOC_ELTS(nr) r200AllocElts( rmesa, nr )
+static GLushort *r200AllocElts( r200ContextPtr rmesa, GLuint nr )
+{
+ if (rmesa->dma.flush)
+ rmesa->dma.flush( rmesa );
+
+ r200EmitAOS( rmesa,
+ rmesa->tcl.aos_components,
+ rmesa->tcl.nr_aos_components, 0 );
+
+ return r200AllocEltsOpenEnded( rmesa, rmesa->tcl.hw_primitive, nr );
+}
+
+
+#define CLOSE_ELTS() R200_NEWPRIM( rmesa )
/* TODO: Try to extend existing primitive if both are identical,
@@ -217,17 +197,15 @@
#ifdef MESA_BIG_ENDIAN
/* We could do without (most of) this ugliness if dest was always 32 bit word
aligned... */
-#define EMIT_ELT(offset, x) do {\
+#define EMIT_ELT(dest, offset, x) do {\
int off = offset + ( ( (GLuint)dest & 0x2 ) >> 1 ); \
GLushort *des = (GLushort *)( (GLuint)dest & ~0x2 );\
(des)[ off + 1 - 2 * ( off & 1 ) ] = (GLushort)(x); } while (0)
#else
-#define EMIT_ELT(offset, x) (dest)[offset] = (GLushort) (x)
+#define EMIT_ELT(dest, offset, x) (dest)[offset] = (GLushort) (x)
#endif
-#define EMIT_TWO_ELTS(offset, x, y) *(GLuint *)(dest+offset) = ((y)<<16)|(x);
-#define INCR_ELTS( nr ) dest += nr
-#define RELEASE_ELT_VERTS() \
- r200ReleaseArrays( ctx, ~0 )
+
+#define EMIT_TWO_ELTS(dest, offset, x, y) *(GLuint *)((dest)+offset) = ((y)<<16)|(x);
Index: radeon/radeon_tcl.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_tcl.c,v
retrieving revision 1.8
diff -u
Re: [Dri-devel] Another dmatmp2 patch (quads_elts)
Keith Whitwell wrote: BTW. Here's an updated pair of patches. These ones should compile, but I haven't done much testing yet. Looks like I broke big-endian, too (sorry Michel). I'll fix that in the next round. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i810 texture upload patch
Dave Airlie wrote: http://www.skynet.ie/~airlied/patches/dri/i810_tex_upload.diff I used the texenv demos from Mesa 5.0 to test this, I tested it with the old driver and this one, and they both look the same.. however neither of them show the intensity row like my Nvidia card on my main desktop .. on the i810 I just get four boxes of differing greys, like the lumiance one (slightly different greys), but on the NVidia it is more like the Alpha row... if no issues I'll commit this, and move onto texmem proper.. Dave. The patch is based pretty closely on the i830, right? Looks good to me. How do the boxes look if you set 'LIBGL_ALWAYS_INDIRECT=t' ? Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Memory layout, was: Re: [Dri-devel] [Bug 314] No 3D support forRadeon IGP chips
Michel Dänzer wrote: On Tue, 2003-07-22 at 23:53, Keith Whitwell wrote: I don't think we can get away with breaking older clients, though this does look like it would only break the situation where you have old 3d client with new 2d driver, which is a slightly unusual situation. Yes, I think the 2D driver and in particular the DRM are much more likely to be old. The real question is how much does the 3d client actually rely on the radeon memory layout? It gets pointers to most things it cares about in the initialization messages, these could be adjusted to point to the correct places in the new layout. I'm afraid this doesn't work, e.g. - rmesa->hw.ctx.cmd[CTX_RB3D_COLOROFFSET] = rmesa->state.color.drawOffset; + rmesa->hw.ctx.cmd[CTX_RB3D_COLOROFFSET] = rmesa->state.color.drawOffset+rmesa->radeonScreen->fbBase; and rmesa->state.color.drawOffset = rmesa->radeonScreen->frontOffset; but rmesa->state.color.drawOffset probably needs to stay the same for software rendering? (it seems to be used as an offset into the framebuffer mapping) Further, if a client is known to be old, the kernel can go through its commands & adjust them for the new layout This might actually work, nifty. :) I wonder how much effort this would take and/or whether it would have an impact on performance though. A slight impact, but that's the price you pay for backwards compatibility. If people want max performance, they can upgrade to a newer 3d client. In any case, I doubt it would be measurable. I'd prefer this approach (in addition to the turn-on ioctl) to anything that involves bumping the major version. Well, if this works, we might actually get away without bumping the major, which would be great... let's hope this works out taking into consideration everything including video capturing, radeonfb, ... More than great - necessary. We can't be bumping the major number without very good reason, and I just don't see that here. Keith --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Memory layout, was: Re: [Dri-devel] [Bug 314] No 3D support for RadeonIGP chips
I don't think we can get away with breaking older clients, though this does look like it would only break the situation where you have old 3d client with new 2d driver, which is a slightly unusual situation. The real question is how much does the 3d client actually rely on the radeon memory layout? It gets pointers to most things it cares about in the initialization messages, these could be adjusted to point to the correct places in the new layout. Further, if a client is known to be old, the kernel can go through its commands & adjust them for the new layout (assuming we can't dupe the client into using the right values for itself). I'd prefer this approach (in addition to the turn-on ioctl) to anything that involves bumping the major version. Keith --- Additional Comments From [EMAIL PROTECTED] 2003-22-07 17:39 --- This could become a backwards compatibility nightmare, as the framebuffer aperture is currently hardcoded everywhere to be at 0. :\ At the very least, the DRM minor version must be bumped, new entries must only be added at the end of structs used for communication between components, and each component must be careful only to use them if they are known to contain valid values. However, as a different memory layout is desirable for other reasons like video capturing, we should make another attempt at a discussion to get it right once and for all, probably on dri-devel but at least including people like Ben Herrenschmidt and Vladimir Dergachev as well. Here's an idea for a scheme to preserve at least some level of backwards compatibility: Add a new ioctl for the X server to tell the DRM 'I want to use the new memory layout'. Unless this is called, everything keeps working as it is now (i.e. things like DRI on IGP chips or video capturing won't work). Otherwise, the DRM bumps its major version as well. The 3D driver is adapted to cope with both major DRM versions. This would provide backwards compatibility for the new 3D driver with old X servers / DRMs / hardware. Old 3D drivers would stop working with the combination of new X server and new DRM, but this might be as good as it gets in terms of backwards compatibility. Or maybe someone else has a better idea? --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3 bugs with DRI on ATI radeon 7500 M7 card
Bertrand Lamy wrote: hello everybody I have found 3 bugs in the DRI driver. See the attached file for description. Each program is the 'minimal' code to get the bug. I also give my computer configuration. I am quite sure that the bugs lie in the driver cause: - it does not bug when using mesa and no 3D card (program launched with noglx) - it does not bug on others computers: one with a nvidia card, one with another ATI radeon PS: I have joined a shot of the bug obtained with the program test_gl3.c -blam Thanks, Bertrand. Unless someone beats me to it, I'll be looking at these over the next couple of days. Keith --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Patch] Radeon point size > 1.0
[EMAIL PROTECTED] wrote:
On Thu, Jul 17, 2003 at 08:03:47AM -0500, Keith Whitwell wrote:
Ian Romanick wrote:
Keith Whitwell wrote:
As you state, the trouble with this patch is that all rasterization
falls back to software when poinsize != 1, even if no points are
actually rendered.
To get good behaviour you really need to do something a little different.
First, yes, you will want a rasterization fallback for points. That
means at least you have to turn of HW TCL when (pointsize != 1),
otherwise you won't find it so easy to catch points with the existing
infrastructure. (We could try & get fancy, but let's keep it simpler).
Then, have a look at radeonChooseRenderState() in radeon_swtcl.c. In
here you will need to figure out how to hook in a software
rasterization fallback *only* for points. This isn't something the
radeon driver currently does, but other drivers *do*. Take a look at
the equivalent function in the mga driver -- mgaChooseRenderState()
-- which does hook in per-primitive-type fallbacks.
Shouldn't it be possible to simulate large (or small) points by
replacing them with a polygon? There would be some trickery involved to
get it right, but I'd thing that on TCL hardware this would be a much
better way to go. Could this be done by adding another pipeline stage?
I've kind of permanently kept this issue on my back-burner, but it
seems to be heating up lately. :) Maybe it's time to stir the pot...
Yep, in fact emitting a polygon in this fallback is probably a better idea
(and easier) than trying to go to software rendering. In fact all the old
drivers do it this way -- emit two triangles in the point routine.
Keith
Attached is another point size patch. Thanks for taking the time to look
through my first patch. This one uses per-primitive fallbacks as you suggested.
I originally had radeon_point_fallback calling swrast but this caused a lot of
rendering glitches (I'm fairly certain the Z-buffer format was responsible).
Currently I'm altering the reduced_hw_prim and hw_prim values and emitting two
triangles when the fallback is in effect.
So far it seems to be a big improvement from the original hack but it's still a
work in progress.
Dylan
Dylan,
The patch is starting to look pretty good. Probably the glitches you saw were
because there was no synchronization between swrast & hardware rasterization.
You'd need to call radeonSpanRenderStart() and radeonSpanRenderFinish()
before & after groups of points. (Hopefully not before/after each individual
point, but that would work too).
Index: xc/lib/GL/mesa/src/drv/radeon/radeon_swtcl.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_swtcl.c,v
retrieving revision 1.19
diff -u -r1.19 radeon_swtcl.c
--- xc/lib/GL/mesa/src/drv/radeon/radeon_swtcl.c 10 Jun 2003 18:50:46 - 1.19
+++ xc/lib/GL/mesa/src/drv/radeon/radeon_swtcl.c 19 Jul 2003 14:26:14 -
@@ -531,7 +531,7 @@
#define HAVE_POLYGONS0
#define HAVE_ELTS1
-static const GLuint hw_prim[GL_POLYGON+1] = {
+static GLuint hw_prim[GL_POLYGON+1] = {
RADEON_CP_VC_CNTL_PRIM_TYPE_POINT,
RADEON_CP_VC_CNTL_PRIM_TYPE_LINE,
0,
@@ -701,7 +701,7 @@
return GL_TRUE; /* too many vertices */
}
- for (i = 0 ; !(flags & PRIM_LAST) ; i += length)
+ for (i = VB->FirstPrimitive ; !(flags & PRIM_LAST) ; i += length)
{
flags = VB->Primitive[i];
length = VB->PrimitiveLength[i];
Is this something you see as a general bug, or is it somehow related to your
patch?
Keith
---
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon triangle fan hang
Ian Romanick wrote:
Michael wrote:
Ian Romanick wrote:
Here's a patch that prevents Think Tanks (and possibly other heavy
users of triangle fans) from crashing on Radeon hardware.
To be pedantic - it's not caused by heavy usage of triangle fans, it
was caused by a single triangle fan primitive occuring at the end of a
cmd_buf [that could be filled with anything other than triangle fan
primitives]
Right. But the odds of hitting this with infrequent use of triangle
fans is pretty low. :)
Basically, I just in-lined emit_elts and did some minor clean-up.
Yeah, that should work - but I did wonder whether other primitives /
paths might have the same issue? There has been a few rendering
related bugs reported that are "fixed" by changing the size of cmd_buf
- which is one indirect way of "fixing" something like this. Other
similar errors might not cause hardware hangs.
There are a couple of other functions that look suspect:
render_line_loop_elts (only if PRIM_END is set), render_tri_strip_elts
(only if PRIM_PARITY is set), and render_poly_elts (this is virtually
identical to render_tri_fan_elts). Neither the R100 or R200 have
line-loops in hardware, so I'm not worried about render_line_loop_elts.
Given the huge numbers of apps that make massive use of triangle strips,
I'm surprised that render_tri_strip_elts hasn't caused problems. NWN
and FlightGear don't happen to use the render_poly_elts path, do they?
More digging required...
The attached patch is a work-in-progress which shows my ideas on how this code
could be cleaned up. It makes the allocation of space for verts & elts a lot
more explicit & should avoid some of the odd behaviour arising from the old
code. There are several cases where it should fix bad behaviours.
It's not finished yet & I don't have a huge amount of time, but it's probably
worth sharing.
Keith
? diff
? dmatmp2.diff
Index: t_dd_dmatmp2.h
===
RCS file: /cvsroot/dri/xc/xc/extras/Mesa/src/tnl_dd/t_dd_dmatmp2.h,v
retrieving revision 1.4
diff -u -r1.4 t_dd_dmatmp2.h
--- t_dd_dmatmp2.h 26 Aug 2002 22:16:02 - 1.4
+++ t_dd_dmatmp2.h 19 Jul 2003 19:27:19 -
@@ -75,12 +75,14 @@
LOCAL_VARS;
ELTS_VARS;
- ALLOC_ELTS( nr );
-
- for ( i = 0 ; i < nr ; i+=2, elts += 2 ) {
+ for ( i = 0 ; i+1 < nr ; i+=2, elts += 2 ) {
EMIT_TWO_ELTS( 0, elts[0], elts[1] );
INCR_ELTS( 2 );
}
+ if (i < nr) {
+ EMIT_ELT( 0, elts[0] );
+ INCR_ELTS( 1 );
+ }
}
static void TAG(emit_consecutive_elts)( GLcontext *ctx, GLuint start, GLuint nr )
@@ -89,8 +91,6 @@
LOCAL_VARS;
ELTS_VARS;
- ALLOC_ELTS( nr );
-
for ( i = 0 ; i+1 < nr ; i+=2, start += 2 ) {
EMIT_TWO_ELTS( 0, start, start+1 );
INCR_ELTS( 2 );
@@ -160,8 +160,7 @@
if (PREFER_DISCRETE_ELT_PRIM( count-start, HW_LINES ))
{
- int dmasz = GET_SUBSEQUENT_VB_MAX_ELTS();
- int currentsz;
+ int dmasz = GET_MAX_HW_ELTS();
GLuint j, nr;
ELT_INIT( GL_LINES, HW_LINES );
@@ -169,18 +168,12 @@
/* Emit whole number of lines in each full buffer.
*/
dmasz = dmasz/2;
- currentsz = GET_CURRENT_VB_MAX_ELTS();
- currentsz = currentsz/2;
- if (currentsz < 4) {
-NEW_BUFFER();
-currentsz = dmasz;
- }
for (j = start; j + 1 < count; j += nr - 1 ) {
GLint i;
ELTS_VARS;
-nr = MIN2( currentsz, count - j );
+nr = MIN2( dmasz, count - j );
ALLOC_ELTS( (nr-1)*2 );
@@ -189,10 +182,7 @@
INCR_ELTS( 2 );
}
-if (nr == currentsz) {
- NEW_BUFFER();
- currentsz = dmasz;
-}
+CLOSE_ELTS();
}
}
else
@@ -223,96 +213,60 @@
return;
if (PREFER_DISCRETE_ELT_PRIM( count-start, HW_LINES )) {
-int dmasz = GET_SUBSEQUENT_VB_MAX_ELTS();
-int currentsz;
+int dmasz = GET_MAX_HW_ELTS();
ELT_INIT( GL_LINES, HW_LINES );
/* Emit whole number of lines in each full buffer.
*/
dmasz = dmasz/2;
-currentsz = GET_CURRENT_VB_MAX_ELTS();
-currentsz = currentsz/2;
-
-if (currentsz < 4) {
- NEW_BUFFER();
- currentsz = dmasz;
-}
/* Ensure last vertex doesn't wrap:
*/
-currentsz--;
dmasz--;
for (; j + 1 < count; ) {
GLint i;
ELTS_VARS;
- nr = MIN2( currentsz, count - j );
+ nr = MIN2( dmasz, count - j );
- ALLOC_ELTS( (nr-1)*2 );
- for ( i = j ; i+1 < j+nr ; i+=1 ) {
- EMIT_TWO_ELTS( 0, (i+0), (i+1) );
+ ALLOC_ELTS( nr*2 ); /* allocs room for 1 more line */
+ for ( i = 0 ; i < nr - 1 ; i+=1 ) {
+ EMIT_TWO_ELTS( 0, (j+i), (j+i+1) );
INCR_ELTS( 2 );
Re: [Dri-devel] radeon triangle fan hang
Ian Romanick wrote:
Ian Romanick wrote:
[EMAIL PROTECTED] wrote:
Hello,
No idea if this problem has been raised, but I had a problem running
the demos
@ http://www.garagegames.com on a radeon ddr 32.
It seems to crash (lock hardware, the new IRQ code gives EBUSY, but
the exit()
isn't clean) rendering triangle fan elts :-
xc/extras/Mesa/src/tnl_dd/t_dd_dmatmp2.h
for (j = start + 1 ; j + 1 < count; j += nr - 1 ) {
nr = MIN2( currentsz, count - j + 1 );
TAG(emit_elts)( ctx, elts+start, 1 );
TAG(emit_elts)( ctx, elts+j, nr - 1 );
NEW_PRIMITIVE();
currentsz = dmasz;
iff the first vertex is emitted by itself at the end
of a CmdBuf.
Here's a patch that prevents Think Tanks (and possibly other heavy
users of triangle fans) from crashing on Radeon hardware. There seem
to be some other texture related problems, but I haven't had a chance
to delve into that. This should also fix similar problems on R200
hardware, but I haven't tested that out yet either.
Basically, I just in-lined emit_elts and did some minor clean-up. One
problem that I have with emit_elts is that it seems to assume that the
number of elts to emit is *always* a multiple of 2. Clearly this may
not always be the case.
I just tried it out on a 64MB R200 (my R100 card is 32MB), and the
texturing problems went away. My current thinking, therefore, is that
there's a texture management problem lurking in there. I'll try to take
a look into it. Could this be the same as the (fixed) problem with the
i830 driver?
Unlikely, as the i830 just uses memcpy to the texture memory to upload
textures, while the radeon etc, use a blit/dma operation which is synchronized
with the 3d render stream. It might be the case that some of the
synchronization commands aren't working right, but that's a slight long shot.
Keith
---
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Patch] Radeon point size > 1.0
Ian Romanick wrote: Keith Whitwell wrote: [EMAIL PROTECTED] wrote: Hi, Attached is a small patch for the Radeon driver. It allows use of the full range of point sizes defined in Mesa. It uses the rasterization fallback mechanism when rendering points outside the hardware supported range (!= 1.0). Since point sizes greater than one don't seem be be an implementation requirement this behaviour only occurs when the enironment variable RADEON_LARGE_POINTS is set. I am interested in finding a more efficient solution, but I'm not very familiar with the code yet. Could anyone suggest a good place to start? As you state, the trouble with this patch is that all rasterization falls back to software when poinsize != 1, even if no points are actually rendered. To get good behaviour you really need to do something a little different. First, yes, you will want a rasterization fallback for points. That means at least you have to turn of HW TCL when (pointsize != 1), otherwise you won't find it so easy to catch points with the existing infrastructure. (We could try & get fancy, but let's keep it simpler). Then, have a look at radeonChooseRenderState() in radeon_swtcl.c. In here you will need to figure out how to hook in a software rasterization fallback *only* for points. This isn't something the radeon driver currently does, but other drivers *do*. Take a look at the equivalent function in the mga driver -- mgaChooseRenderState() -- which does hook in per-primitive-type fallbacks. Shouldn't it be possible to simulate large (or small) points by replacing them with a polygon? There would be some trickery involved to get it right, but I'd thing that on TCL hardware this would be a much better way to go. Could this be done by adding another pipeline stage? I've kind of permanently kept this issue on my back-burner, but it seems to be heating up lately. :) Maybe it's time to stir the pot... Yep, in fact emitting a polygon in this fallback is probably a better idea (and easier) than trying to go to software rendering. In fact all the old drivers do it this way -- emit two triangles in the point routine. Keith --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [Patch] Radeon point size > 1.0
[EMAIL PROTECTED] wrote: Hi, Attached is a small patch for the Radeon driver. It allows use of the full range of point sizes defined in Mesa. It uses the rasterization fallback mechanism when rendering points outside the hardware supported range (!= 1.0). Since point sizes greater than one don't seem be be an implementation requirement this behaviour only occurs when the enironment variable RADEON_LARGE_POINTS is set. I am interested in finding a more efficient solution, but I'm not very familiar with the code yet. Could anyone suggest a good place to start? As you state, the trouble with this patch is that all rasterization falls back to software when poinsize != 1, even if no points are actually rendered. To get good behaviour you really need to do something a little different. First, yes, you will want a rasterization fallback for points. That means at least you have to turn of HW TCL when (pointsize != 1), otherwise you won't find it so easy to catch points with the existing infrastructure. (We could try & get fancy, but let's keep it simpler). Then, have a look at radeonChooseRenderState() in radeon_swtcl.c. In here you will need to figure out how to hook in a software rasterization fallback *only* for points. This isn't something the radeon driver currently does, but other drivers *do*. Take a look at the equivalent function in the mga driver -- mgaChooseRenderState() -- which does hook in per-primitive-type fallbacks. Keith --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps1 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Problem with latest trunk and i810?
Dave Airlie wrote: Yes, that would be cleaner. patch for not only the i810 but also the fixes for radoen/r128/mga drivers, along with the changes to xf86drm.[ch] ... http://www.skynet.ie/~airlied/patches/dri/agp_drm.diff I think XFree86 tree is going to need something along these lines also, but I don't have an XFree86 tree on my PC (apart from 4.3)... if no-one screams I'll apply it tomorrow... Looks like David has already ported & applied it to XFree86. Keith --- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Problem with latest trunk and i810?
Dave Airlie wrote: I'd lean towards using ~0 as the error value and keeping the existing types, etc. potential patch at: http://www.skynet.ie/~airlied/patches/dri/i810_drm_agp.diff I wonder if we should change the drmAgpAlloc function to set the handle to DRM_AGP_NO_HANDLE? Yes, that would be cleaner. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Problem with latest trunk and i810?
Dave Airlie wrote: and of course d) revert back to using memory->memory, requires whoever switched us to key to explain :-) Okay this was done by David Dawes back in April, and was taken from the XFree trunk, it looks like it is needed. so one of the other three approaches is needed... I'd lean towards using ~0 as the error value and keeping the existing types, etc. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
Jens Owen wrote: Ian Romanick wrote: The real difference comes at the unlock. When a thread wants to release the futex, it increments the variable. If the value is greater than zero, the thread happily continues on. If the value is zero or negative, the thread calls into the kernel to wake-up the next waiting thread. It is this last part that differentiates the futex from the existing DRI lock. It is also this last part that gives the behavior we were trying to achieve by calling sched_yield after releasing the DRI lock. I wonder if we didn't throw out the baby with the bathwater when we reorganized the kernel side DMA buffer management. To be more specific, we do call the kernel unlock routine when there is lock contention, but it's not clear which compile time code paths are used by Linux in the supporting DRM code responsible for waking up the contending thread. Check out DRM(unlock) in xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_drv.h This is precisely where Linux specific support for "wake-up the next waiting thread" should reside. I see calls to wake_up_interruptible(&dev->lock.lock_queue), but they are ifdef'ed by __HAVE_KERNEL_CTX_SWITCH. I'm not certain which compile time paths we're using in this code these days...but somebody is waking up the clients that are waiting for the lock and this is precisely where it should be happening. When it does happen here, this behavior would appear to be almost identical to the behavior of the futex you describe. We don't set that switch, I think, but if you look further down that function in the cruddy code at the bottom, there's a call to DRM(lock_free) which also does the wake_up_interruptible(). Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Problem with latest trunk and i810?
Ronald Baljeu wrote: On Mon, Jul 07, 2003 at 09:59:15AM +0100, Keith Whitwell wrote: Ronald Baljeu wrote: The traditional approach would be to do a binary search to narrow down which change caused the problems -- probably using the DRI cvs tree. Keith Ok, after several days of searching I think I found something here. In i810_dri.c of the Xfree CVS (I could not get into the DRI CVS) several calls are made to drmAgpAlloc(). To test whether this call was successful the returned handle is checked: if it is 0 it is assumed the call failed. Like this: drmAgpAlloc(pI810->drmSubFD, back_size, 0, NULL, &agpHandle); if (agpHandle != 0) /* ok */ else /* error */ However I think 0 is a legal handle. Shouldn't the return value of the call be checked instead? Looking at the kernel modules and header files I noticed how this used to work this way. The agpHandle used to be a pointer internally (in the agp_memory struct), but it has been changed to a key. It's difficult to describe what I mean. Maybe this helps: xc/programs/Xserver/hw/xfree86/drivers/i810/i810_dri.c: call to drmAgpAlloc() as described above xc/programs/Xserver/hw/xfree86/os-support/linux/drm/xf86drm.c: body of drmAgpAlloc(), with a call to ioctl(DRM_IOCTL_AGP_ALLOC) xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h: #define DRM_IOCTL_AGP_ALLOC DRM_IOWR(0x34, drm_agp_buffer_t) xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_drv.h: mapping DRM_IOCTL_AGP_ALLOC to DRM(agp_alloc) xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm_agpsupport.h: body of DRM(agp_alloc) In the body of DRM(agp_alloc) a small change was made from: entry->handle= (unsigned long)memory->memory; to: entry->handle= (unsigned long)memory->key; So, tracing this back from kernel to userland, this key is now passed as agpHandle in the example above, instead of the memory pointer. Now the handle can legally be 0, but the source of i810_dri.c still treats it like a pointer of which 0 indicates an error. Could this be the source of the problem? Or am I way off ;-) Ronald, If you're way off, at this point it sounds like you've got a better idea than I... I'm forwarding this to dri-devel in the hope that this rings a bell with someone there. From CVS you can tell who made the change - that might help to get a quick response... Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: sched_yield()
Ian Romanick wrote: Ian Romanick wrote: Linus Torvalds wrote: You _really_ want to use futex'es for any user-space locking. It's back-ported to 2.4.x, and it gets these cases _right_. There are fair user-space locks based on futexes as part of modern glibc sources, and they are _fast_, since all non-contention (common case) is done entirely in user space, and they do the right thing (*) when there is contention. You're right. We do _really_ want to use futex'es. However, I don't think they're available on *BSD or Solaris. I don't know if there's anyone working on DRI right now that knows enough about Linux and *BSD to be able to determine what the effort would be to make futex'es or a futex-like wrapper for those systems. I honestly believe that is the only reason we haven't already started using futex'es. We also have the problem of having to support old kernels with new user-mode drivers. Hmmm...I'll have to look in to futex'es more... As promised, I have finally looked into the mystical futex. The short version is that it should be dead simple to convert the existing DRI drivers to use either the existing locking method or a futex. And now for the rest of the story... A futex is actually very similar to the existing DRI lock. This is the main thing that will make transitioning the to futex interface so simple. Basically, a futex is just a variable in shared memory. When a thread wants to acquire the futex it decrements the variable. If it's non-negative, the thread happily continues on. If the value is negative, the thread calls into the kernel to block. At this point, the futex is virtually identical to the existing DRI lock. The real difference comes at the unlock. When a thread wants to release the futex, it increments the variable. If the value is greater than zero, the thread happily continues on. If the value is zero or negative, the thread calls into the kernel to wake-up the next waiting thread. It is this last part that differentiates the futex from the existing DRI lock. It is also this last part that gives the behavior we were trying to achieve by calling sched_yield after releasing the DRI lock. I don't think you can get the same behaviour as the DRI lock from just a futex alone. Specifically, the DRI lock makes it easy to notice when you weren't the last locking context, eg: Context A locks Context A unlocks Context A locks Here both Futex & DRI lock say "OK, nothing to do, context A gets the lock" Context A unlocks Context B locks At this point, a native futex would say "ok, B gets the lock, no problems, nothing to do", wheras the DRI lock would say "Agh! different context grabbing the lock, gotta do some extra work", specifically set the hardware up the way B expects it to be. Now, in the original DRI design, it was concieved that the kernel would do a lot of that extra work to virtualize the hardware, while actually we end up doing it all in userspace. I guess all this means is that we need a 'last context' variable in addition to the futex, to detect this situation. But that does mean that we have to alter (slightly) the sarea layouts, right? Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [PATCH] Fix 64bit cleanness in radeon, lock padding.
Andi Kleen wrote: The DRM code in Linux 2.5.73 has a new radeon getparam that is clearly not 64bit clean. It tries to return a pointer to an lock in an int, which clearly cannot work. The AMD64 compiler prints a warning for this. RADEON_PARAM_SAREA_HANDLE does not seem to be used in the code, so I just disabled it. This does get used in the embedded driver which is in process of being merged. However, it looks like I'll need to come up with an alternate way of providing/determining that information. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] RTCW ET quick benchmark
Jacek Popławski wrote: I have Radeon 9100, Athlon XP 1800+, 256MB RAM and Linux-2.4.21. I was benchmarking RTCW ET with DRI. I tried to change value 216 to something bigger in xc/xc/extras/Mesa/src/tnl/t_context.h: #define IMM_MAX_COPIED_VERTS 3 #define IMM_MAXDATA (216 + IMM_MAX_COPIED_VERTS) #define IMM_SIZE (IMM_MAXDATA + MAX_CLIPPED_VERTICES) I set 400, then 600. Recompiled whole source tree, tested both TCL and NO-TCL. No change in fps ratio, no matter if there is 216, 400 or 600. However, I noticed something else. I started with TCL enabled, I set 1024x768 with high detailed geometry. Fps ratio was 17-23, but then I found place on map where fps ratio drop to 4. It would be interesting to find out exactly what was taking the time up at that point -- maybe some large state was being emitted very often? Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] disabling debugging from binaries?
Jacek Popławski wrote: There are many places in code like: if (R200_DEBUG & DEBUG_PRIMS) but I don't see how to disable debugging at all from binaries. Should not these ifs be in: #ifdef DEBUG #endif Have a look at r200_context.h - you can get the same effect by defining DO_DEBUG to zero. It's not worth the effort though. Keith --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Only "normal" DRI and Mesa CVS access asdeveloper, now?
José Fonseca wrote: On Sat, Jun 28, 2003 at 04:18:15PM +0200, Dieter Nützel wrote: Mesa3d seems to be affected, too. No mesa CVS update for 10 days, now ;-( My DRI CVS is 12 days old... No chance from "old Europe" anymore? I've just checked and the tarballs in http://cvs.sourceforge.net/cvstarballs/projectname-cvsroot.tar.gz for DRI and Mesa3d are just as old as the anonymous CVS server, and from the SF documents there is no other way to directly access the repository (except contact the SF team, but you can't put that in a cron job, can you? ;-) Basically this means that CVS mirroring is impossible and the only solution to the current problem is to move the repository elsewhere. Is there a solid alternative to sourceforge? One with better backing that will keep it going if large numbers of projects start using it? I don't know why the silence from the DRI SF project admins - I'm CC'ing to them now (at least those currently in the active) in the hope to hear what they have to say about this. Not so much silence as a lack of answers... I remind again that this issue should be presented to the SF team to know what's their position and what to expect from the future. This issue [of the unreliable CVS anonymous serving] together with the recent news of closing inactive and old projects may well be a sign that SF is saturating again, but this time the saturation appears to be fought not by further investment, but degrading the quality of the services. If true then it's a matter of time to collapse, or at least be unusable for big projects such as DRI. This is a reasonable proposition -- let's start putting a draft together, then. --- SF admins, We're concerned about the recent changes to anonymous cvs access, in particular the way in which changes committed by developers take an extended period (upto days) to become visible to anonymous cvs users. As we rely heavily on a test/debug/fix cycle that includes input and interaction from anonymous cvs users, this delay represents a real roadblock for our development efforts. Can you outline the reasons that this has started happening, whether it will be resolved and if so on what timescale? DRI project developers Keith Whitwell ... --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Ian Romanick wrote: Keith Whitwell wrote: Here's a patch that mainly works. I've still seen the odd case of the texture apparently getting uploaded to the backbuffer. ...but *only* if you have a kernel module installed that understands rectangle state. As it is, the code in radeon_state_init.c allows texture rectangle state to be emitted even if the DRM cannot handle the RADEON_PP_TEX_SIZE_? packets. The result is an immediate "drmCommandWrite: -22" for any GL program. :( I copied over the test from radeon_context.c to the two places in radeon_state_init.c that set-up the state atoms, but that's not a very pretty sollution. OK, my bad -- I'll fix this up. Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Torque Engine causes machine lockup on radeon mobilityM7
Zik Saleeba wrote: I'm still trying to track down the cause of the Torque Engine radeon crash. I've instrumented the calls Torque makes to gl so I can work out what's happening when it dies. The sequence of gl calls from the frame where it crashes can be downloaded at: http://www.zikzak.net/~zik/crash_frame.c.txt Note that this isn't quite executable C code and doesn't include all the textures etc. but at least it gives an idea of what commands were being executed when it died. Is this any help to anyone? Would more information be helpful? I'm working on something that might be related at the moment - but if that doesn't fix your problem, it might be worthwhile putting more time into this. Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon triangle fan hang
[EMAIL PROTECTED] wrote: On Tue, Jun 24, 2003 at 03:31:59PM +0100, Keith Whitwell wrote: [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2003 at 02:13:17PM +0100, Keith Whitwell wrote: Please try this diff - it may fix the problem in a lot of cases. I'll try it later to see if I'm missing something here, but the first thought is that NEW_BUFFER() isn't called because GET_CURRENT_VB_MAX_ELTS() always returns 300? Note that there is some redundancy, as ALLOC_ELTS will eventually make a check on available space during the allocation, so should get a new buffer if there isn't enough space available. Hence the macro shouldn't need to be accurate. Yeah, that might cause it to hang though. As I said in the reply to Ian, if it's not accurate it'll risk passing the test, but later flushing the first elt of the triangle fan by itself and hanging but as you say, ALLOC_ELTs works, calling ALLOC_ELTS(nr) should work, but because emit_elts does the alloc, tri_fan_elts calls it twice effectively doing ALLOC_ELTS(1), emit one, ALLOC_ELTS(nr-1) emit the rest. OK. I see it again now. I'll put something together - probably a cleanup of t_dd_dmatmp2.h so this splitting can't happen. Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Only "normal" DRI and Mesa CVS access as developer,now?
Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2003-06-23 at 20:24, José Fonseca wrote: On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote: These sourceforge "backup" server move is very annoying. It's hindering open source so much. Do we have other options? [...] If not then the solution would imply moving the CVS repository to a new machine, but where would that be? XFree86.org? I've tried to get a discussion going about migrating to XFree86 (and Mesa, ...) before, without success. Maybe we'll have more luck this time. :) The migration to mesa is in progress. To XFree86? Well, that's another question. That sounds more negative than I wanted. Basically, after the drivers are living in Mesa cvs, we could well end up just submitting patches to XFree86 for the rest - but that would be giving up a significant amount of control. Probably we'd always want to maintain an xc/ tree somewhere for infrastructure work. Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon triangle fan hang
[EMAIL PROTECTED] wrote: On Tue, Jun 24, 2003 at 02:13:17PM +0100, Keith Whitwell wrote: Please try this diff - it may fix the problem in a lot of cases. I'll try it later to see if I'm missing something here, but the first thought is that NEW_BUFFER() isn't called because GET_CURRENT_VB_MAX_ELTS() always returns 300? Note that there is some redundancy, as ALLOC_ELTS will eventually make a check on available space during the allocation, so should get a new buffer if there isn't enough space available. Hence the macro shouldn't need to be accurate. Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon triangle fan hang
[EMAIL PROTECTED] wrote: On Tue, Jun 24, 2003 at 02:13:17PM +0100, Keith Whitwell wrote: Please try this diff - it may fix the problem in a lot of cases. I'll try it later to see if I'm missing something here, but the first thought is that NEW_BUFFER() isn't called because GET_CURRENT_VB_MAX_ELTS() always returns 300? I haven't got a test machine running, atm. However, I felt that the problem was firstly that NEW_BUFFER() flushes the *wrong* buffer - ie the DMA buffer, rather than the command buffer. Elts used to go into DMA, now they are put in the command buffer. The GET_CURRENT_VB_MAX_ELTS() macro is difficult to get right because there is the possibility of state, etc. being emitted - maybe we can tickle things to get state emitted & can then make an accurate calculation. Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Only "normal" DRI and Mesa CVS access as developer,now?
Michel Dänzer wrote: On Mon, 2003-06-23 at 20:24, José Fonseca wrote: On Mon, Jun 23, 2003 at 06:58:39PM +0200, Dieter Nützel wrote: These sourceforge "backup" server move is very annoying. It's hindering open source so much. Do we have other options? [...] If not then the solution would imply moving the CVS repository to a new machine, but where would that be? XFree86.org? I've tried to get a discussion going about migrating to XFree86 (and Mesa, ...) before, without success. Maybe we'll have more luck this time. :) The migration to mesa is in progress. To XFree86? Well, that's another question. Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon triangle fan hang
Please try this diff - it may fix the problem in a lot of cases. Keith Warning: Remote host denied X11 forwarding. Index: radeon_tcl.c === RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_tcl.c,v retrieving revision 1.8 diff -u -r1.8 radeon_tcl.c --- radeon_tcl.c30 Apr 2003 01:50:55 - 1.8 +++ radeon_tcl.c24 Jun 2003 13:11:15 - @@ -115,7 +115,7 @@ #define NEW_PRIMITIVE() RADEON_NEWPRIM( rmesa ) -#define NEW_BUFFER() radeonRefillCurrentDmaRegion( rmesa ) +#define NEW_BUFFER() radeonFlushCmdBuf( rmesa, __FUNCTION__ ) /* Don't really know how many elts will fit in what's left of cmdbuf, * as there is state to emit, etc:
Re: [Dri-devel] 3rd TMU on radeon
Ian Romanick wrote: Andreas Stenglein wrote: I tried to get the 3rd TMU working on radeon, and with this patch it works at least without hw-TCL for multiarb.c from Mesa/demos. (RADEON_TCL_FORCE_DISABLE=1) With hw-TCL the 3rd texture is visible, but isnt rotating. The patch also includes some code for the kernelmodule for cube-textures on radeon, and some comments where I dont know what to do. You can switch off the 3rd TMU with export RADEON_NO_3RD_TMU=1 It would be nice if someone with knowledge about TCL could have a look at it. Which programs/demos/games could/should be tested as they make use of the 3rd texture unit? As another data point, I have attached my very old patch to enable the 3rd TMU on Radeon. IIRC, it worked w/HW TCL, vtxfmt, & codegen. It is now quite outdated. There were a couple of reasons I did not commit any of this. 1. A lot of it (i.e., calculate_max_texture_levels) would be superseded by the texmem branch (which has now been merged to the trunk). 2. Enabling the 3rd TMU can drastically reduce the maximum available texture size on some memory configurations. This is even more significant on the R200 which has 6 TMUs. 3. There are some problems with some fast-pathing in the vtxfmt code. The code assumes that the allowable range for 'target' (see radeon_vtxfmt_c.c, line 542) is a power of two. If an app calls glMultiTexCoord2fv with a target of 3 (assuming the mask value is changed from 1 to 3), the driver will explode. 4. A similar problem to #3 exists with the codegen path. The fast paths selected in radeon_makeX86MultiTexCoord2fvARB (see radeon_vtxfmt_x86.c, line 354) and friends may not be expandable to the 3 (or 6 for R200) TMU cases. At worst a test can be used in this code. If there's no sane way to avoid it, we have to do it & that's that. The first issue is a non-issue now. My original intention, before discovering the second issue, was to "merge" the patch after merging the texmem branch. It turns out that it took much longer to make the branch mergable than initiallly anticipated. I think we're going to have to wrestle with the second issue at some point. When the next round of texmem work is complete, we won't be able to predict apriori how big the largest texture set can be. Even now, I find it unlikely that on an R200 there would be 6 2048x2048 cube maps (the worst case) bound at any time. This renders the current calculation somewhat bogus to begin with. It seems that the existing closed-source drivers just advertise the hardware maximum in all cases. If the hardware maximum is advertised, then an app could bind a set of textures that can't fit in memory at once. The driver would then have to fallback to software. I believe the open-source drivers used to function this way, but doing so caused problems with Quake2. I'm really not sure what the right sollution is. Correct - and in fact they still should function this way if the situation somehow arises that the bound textures can't all be uploaded. Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 3rd TMU on radeon
Andreas Stenglein wrote:
thanks a lot!
btw, I got the 3rd TMU working with hw-tcl and codegen, too.
(at least multiarb.c works)
I'm going to clean the patch up a bit, so that it only contains
things related to 3rd TMU support.
Am 2003.06.23 12:17:26 +0200 schrieb(en) Michel Dänzer:
On Sat, 2003-06-21 at 14:14, Andreas Stenglein wrote:
[...] some comments where I dont know what to do.
I'll try to address some of them:
+ if( (sPriv->drmMinor < 3) || (getenv( "RADEON_NO_3RD_TMU")) ) /*
question: is the check for drmMinor necessary? */
+ ctx->Const.MaxTextureUnits = 2;
+ else
+ ctx->Const.MaxTextureUnits = RADEON_MAX_TEXTURE_UNITS; /* 3 */
Does the 3rd TMU require any DRM support not present before that minor
version?
I dont know ;) I think I have to try if 3rd TMU works when
RADEON_COMPAT is set.
On the other hand I think DRI from stock XFree86 4.3.0 wont even work
with old radeon.o kernelmodules...
Is there a list which versions of the drm-modules were distributed?
(linux 2.4, 2.5, bsd x.x, XFree86 4.x.x, GATOS etc.)
+ /* question: shouldn't the following be controlled by the
kernelmodule */
+ /* and/or Xserver-configuration if it can crash the card? */
else if (getenv("RADEON_TCL_FORCE_ENABLE")) {
fprintf(stderr, "Enabling TCL support... this will probably
crash\n");
fprintf(stderr, " your card if it isn't capable of
TCL!\n");
Why? :)
I do wonder if trying to enable HW TCL makes sense though, there was a
bit of confusion about TCL support on the various chips at the time.
Maybe we can clean this up with the new config infrastructure.
I think that wont help: some_bad_user could put that code back and
install his own radeon_dri.so to lockup the graphicscard of a
workstation he only has user-rights to.
So access to hw-accelerated 3d has to be restricted to trusted users,
at least if you have a card without tcl.
There are so many ways to get any of these graphics cards to lock up the
system - they're all prone to lockup if you do just one single thing wrong -
you can send a bunch of very nice legal commands, but in some unspecified
wrong order and have the card lockup. The rules for avoiding lockups are so
complex and poorly defined that it's practically impossible to guarentee that
it won't happen.
Keith
---
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Gamma DRM driver status
José Fonseca wrote: On Mon, Jun 23, 2003 at 08:20:31AM +0100, Keith Whitwell wrote: José Fonseca wrote: The Gamma DRM driver is quite peculiar in several aspects. I'd like to know if those differences are result of experiments which might be worth to generalise to other drivers or if instead it's mostly deprecated and should be made more equal to the others. It is mostly deprecated and should be made more equal to the others. For one instance, the Gamma is the only one uses the freelists which the source of other drivers refer it would be used there too. On the other hand most of the gamma source duplicates source in the DRM templates. Hmm -- for a long time there was #if __HAVE_OLD_DMA in the drm templates, giving a more complex dma engine. The gamma driver was the only one to define it and I recently moved that code into gamma_* files -- so now it probably does look like duplication. The current oddity situation is not very convenient since it limits the kind of changes (either janitorial or architectural) one can do without breaking the gamma driver. The alternatives are 1) fix the gamma driver (hard) or 2) fork the gamma driver off - move everything it needs into a gamma_*.[ch] file and continue developing everything else independently. I for one want to write a general API for DMA buffer pools to be shared by all drivers, but I need some advice concerning what my position towards the Gamma source code should be. I'd like to just remove the whole driver, but unfortunately it doesn't seem to be an option. With a card it should only be a week or two's work to get it in line with the other drivers, or seperating it from the other drivers would take a day or two, but be messier. Well I wouldn't want to remove the driver as a matter of principle - we already support a small subset of the existing 3D cards and I wouldn't want to see that number further reduced. Seperating it from the other drivers would indeed be very messier and difficult to maintain in the future. So what I'm going to do is to focus on the all other drivers now and in the end get the gamma in line with them. It's not feasible to do make this while keeping binary compability (the gamma driver even exposes read interface for the file), i.e., the driver will refuse to work with previous versions. This shouldn't be a problem attending the appereantly very low number of users of this driver. BTW, do we have a owner of such card among the subscribers which can do some testing when the time comes? I think Alan Cox. Alan Hourihane had one, but I think it died -- I find it very hard to keep gamma details in my head for some reason. Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Gamma DRM driver status
José Fonseca wrote: The Gamma DRM driver is quite peculiar in several aspects. I'd like to know if those differences are result of experiments which might be worth to generalise to other drivers or if instead it's mostly deprecated and should be made more equal to the others. It is mostly deprecated and should be made more equal to the others. For one instance, the Gamma is the only one uses the freelists which the source of other drivers refer it would be used there too. On the other hand most of the gamma source duplicates source in the DRM templates. Hmm -- for a long time there was #if __HAVE_OLD_DMA in the drm templates, giving a more complex dma engine. The gamma driver was the only one to define it and I recently moved that code into gamma_* files -- so now it probably does look like duplication. The current oddity situation is not very convenient since it limits the kind of changes (either janitorial or architectural) one can do without breaking the gamma driver. The alternatives are 1) fix the gamma driver (hard) or 2) fork the gamma driver off - move everything it needs into a gamma_*.[ch] file and continue developing everything else independently. I for one want to write a general API for DMA buffer pools to be shared by all drivers, but I need some advice concerning what my position towards the Gamma source code should be. I'd like to just remove the whole driver, but unfortunately it doesn't seem to be an option. With a card it should only be a week or two's work to get it in line with the other drivers, or seperating it from the other drivers would take a day or two, but be messier. Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] spam collection of the past few days
I'm getting referred-to-moderator messages for dri-patches on cvs commits, still... Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] spam collection of the past few days
Michel Dänzer wrote: On Tue, 2003-06-17 at 13:23, Alan Hourihane wrote: On Tue, Jun 17, 2003 at 01:17:03PM +0200, Michel Dänzer wrote: Anyway, many possible solutions have been discussed; if only the list admin(s) cared to at least comment on them. I'm the list admin. Thanks for speaking up. And I have to say I'd be willing to stand down and let someone take over. The amount of spam I have to keep clearing anyway is time consuming to say the least. If I were to make the lists subscriber only, this task would only increase. So if anyone wants to take my place, just say so. I've already volunteered to take on a share. I obviously wouldn't want to do it all myself either. Any other takers? I'm curious - what does the work consist of? Is there already some filtering going on? Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i810 page flipping mesa and dri patches
Dave Airlie wrote: http://www.skynet.ie/~airlied/patches/dri i810_mesa.diff i810_drivers.diff The only contentious piece I believe is the changes to i810_accel.c that do the draws to both front and back buffers, but as I know these aren't good enough to do complete page flipping, so I've no problem not commiting these if people think they aren't helping anything and just cluttering up code.. You're already using a shadow type mechanism, right? Drawing twice like that would be redundant, unless you finished the job & were able to get rid of the shadow code? Keith --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] copy_from_user question
Keith Whitwell wrote:
Hollis Blanchard wrote:
On Wednesday, Jun 4, 2003, at 17:45 US/Central, José Fonseca wrote:
On Wed, Jun 04, 2003 at 05:17:52PM -0500, Hollis Blanchard wrote:
This is what the Stanford checker turned up recently when analyzing the
copy_to/from_user calls in the Linux kernel:
[...]
This is all because the DRM_COPY_FROM_USER_UNCHECKED is being called in
radeon_cp_dispatch_indices. If the copy_from_user is needed, the whole
sarea_priv structure must be in user space, in which case all the other
direct sarea references are in error. The other possibility is that
copy_from_user isn't needed here at all. Can anyone comment?
The SAREA, and hence drm_radeon_sarea_t and 'boxes', lives on a
shared memory
segment accessible by all intervenients (kernel, X server, client). So
the copy_from_user shouldn't be used.
I guess that at some point, radeon_cp_dispatch_indices was called on
userspace cliprects, but now it appears only to be called on the SAREA.
Perhaps Keith can tell more about it.
Any further comments here? I didn't quite follow the explanation of
where SAREA lives, but I guess copy_from_user should be replaced?
Anyone have a patch?
I started one, but won't be able to finish it off until Monday (probably).
Well, it's later than monday. Here's a simple change to fix the problem.
Keith
? diff
? ff
? sarea_stanford.diff
Index: radeon_state.c
===
RCS file:
/cvsroot/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/radeon_state.c,v
retrieving revision 1.21
diff -u -r1.21 radeon_state.c
--- radeon_state.c 10 Jun 2003 18:54:17 - 1.21
+++ radeon_state.c 13 Jun 2003 15:06:15 -
@@ -888,15 +888,14 @@
static void radeon_cp_dispatch_vertex( drm_device_t *dev,
drm_buf_t *buf,
- drm_radeon_tcl_prim_t *prim,
- drm_clip_rect_t *boxes,
- int nbox )
+ drm_radeon_tcl_prim_t *prim )
{
drm_radeon_private_t *dev_priv = dev->dev_private;
- drm_clip_rect_t box;
+ drm_radeon_sarea_t *sarea_priv = dev_priv->sarea_priv;
int offset = dev_priv->agp_buffers_offset + buf->offset + prim->start;
int numverts = (int)prim->numverts;
+ int nbox = sarea_priv->nbox;
int i = 0;
RING_LOCALS;
@@ -916,10 +915,8 @@
do {
/* Emit the next cliprect */
if ( i < nbox ) {
- if (DRM_COPY_FROM_USER_UNCHECKED( &box, &boxes[i], sizeof(box)
))
- return;
-
- radeon_emit_clip_rect( dev_priv, &box );
+ radeon_emit_clip_rect( dev_priv,
+ &sarea_priv->boxes[i] );
}
/* Emit the vertex buffer rendering commands */
@@ -998,18 +995,17 @@
static void radeon_cp_dispatch_indices( drm_device_t *dev,
drm_buf_t *elt_buf,
- drm_radeon_tcl_prim_t *prim,
- drm_clip_rect_t *boxes,
- int nbox )
+ drm_radeon_tcl_prim_t *prim )
{
drm_radeon_private_t *dev_priv = dev->dev_private;
- drm_clip_rect_t box;
+ drm_radeon_sarea_t *sarea_priv = dev_priv->sarea_priv;
int offset = dev_priv->agp_buffers_offset + prim->offset;
u32 *data;
int dwords;
int i = 0;
int start = prim->start + RADEON_INDEX_PRIM_OFFSET;
int count = (prim->finish - start) / sizeof(u16);
+ int nbox = sarea_priv->nbox;
DRM_DEBUG("hwprim 0x%x vfmt 0x%x %d..%d offset: %x nr %d\n",
prim->prim,
@@ -1048,12 +1044,9 @@
(count << RADEON_NUM_VERTICES_SHIFT) );
do {
- if ( i < nbox ) {
- if (DRM_COPY_FROM_USER_UNCHECKED( &box, &boxes[i], sizeof(box)
))
- return;
-
- radeon_emit_clip_rect( dev_priv, &box );
- }
+ if ( i < nbox )
+ radeon_emit_clip_rect( dev_priv,
+ &sarea_priv->boxes[i] );
radeon_cp_dispatch_indirect( dev, elt_buf,
prim->start,
@@ -1453,9 +1446,7 @@
prim.numverts = vertex.count;
prim.vc_format = dev_priv->sarea_priv->vc_format;
- radeon_cp_dispatch_vertex( dev, buf, &prim,
-
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Andreas Stenglein wrote: while trying to activate the 3rd TMU on radeon I discovered that "txr" states get emitted even in the yuvsqare (and multiarb) demo (which use only standard textures): (RADEON_DEBUG=state and yuvsqare demo:) radeonBindTexture( 0x8132dc8 ) unit=0 radeonEmitState radeonEmitState - lost context emit TEX/tex-0/9 emit CTX/context/14 skip state TXR/txr-2 skip state TXR/txr-1 skip state TEX/tex-2 skip state TEX/tex-1 emit ZBS/zbias/3 emit MSC/misc/2 emit VPT/viewport/7 emit TXR/txr-0/3 emit MSK/mask/4 emit LIN/line/5 emit SET/setup/5 I dont know if its bad, but I think it shouldnt happen. I changed the CHECK in radeon_state_init.c for txr and now it doesnt happen anymore, at least in yuvsquare. radeon_state_init.c:CHECK( txr0, ctx->Texture.Unit[0]._ReallyEnabled & TEXTURE_RECT_BIT) radeon_state_init.c:CHECK( txr1, ctx->Texture.Unit[1]._ReallyEnabled & TEXTURE_RECT_BIT) btw. heres also a patch for mplayer vo_gl.c which uses GL_NV_texture_rectangle. I sent a (sligtly) older version to mplayer-dev-eng, but unfortunately it got caught by some filter/ wasnt released by the mailinglist moderator. Interesting. The two other extensions I'd consider useful for this are MESA_ycbcr_texture (yuv textures) and the agp allocator/agp client texturing present in the r200 driver. Does mplayer produce data in a format useable as a ycbcr texture? Keith --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Michel Dänzer wrote: On Tue, 2003-06-10 at 13:14, Keith Whitwell wrote: Andreas Stenglein wrote: 3) in radeon_ioctl.c, function radeonEmitVbufPrim() the first cmd is cleared before filled with the cmd_type: cmd[0].i = 0; cmd[0].header.cmd_type = RADEON_CMD_PACKET3_CLIP; should this be done in radeonEmitBlit() also or is that not necessary? Quite possibly it should. Definitely a good idea, or the other header fields may have random contents. Actually, why not clear the header in AllocCmdBuf() instead of in the callers? While it may be cleared unnecessarily sometimes like that, the potential for random behaviour might be the worse option. Sounds good... Keith --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Keith Whitwell wrote:
Brian Paul wrote:
Keith Whitwell wrote:
Andreas Stenglein wrote:
Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell:
Keith Whitwell wrote:
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
OK, the final piece of the puzzle fell into place. Without the
radeon docs you might hav had trouble find this -- basically, the
radeon still expects texture rectangle texcoords to be in 0..1
range, rather than 0..width,0..height like the r200.
I haven't got the code running for this yet, but modifying the app
to supply the texcoords the hardware expects gives a good image.
Keith
yes, its unbelievable... it works with texcoords 0...1 ;)
1) Do you have an idea how to make it work with the right texcoords?
I was thinking that this would be a fairly easy option:
a) Disable TCL for all rectangular texture operations
b) Insert a new stage to the swtcl pipeline, based on
Mesa/src/tnl/t_vb_texmat.c, to perform a 1/w, 1/h scale to all
texrect coordinates.
c) premultiply the texture matrix by a scaling matrix?
I wanted to keep things seperate -- but it does sound nice. It would
need some new infrastructure - if it were to work with tcl fallbacks,
then t_vb_texmat.c would have to use a premultiplied one also. Further,
swrast expects "normal" 0..dimension texcoords, so it would have to be
turned off during rasterization fallbacks.
It seems like it would require hooks into core mesa, just to deal with
this one piece of hardware that works this way. Adding a new
renderstage keeps it in the driver.
I could add a new renderstage *and* premultiply only the hw texture
matrix (keeping hwtcl), but that's even more work.
Here's a patch that mainly works. I've still seen the odd case of the texture
apparently getting uploaded to the backbuffer.
Keith
? Am
? diff
? ff
Index: radeon_context.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.c,v
retrieving revision 1.38
diff -u -r1.38 radeon_context.c
--- radeon_context.c26 May 2003 19:48:51 - 1.38
+++ radeon_context.c10 Jun 2003 15:37:48 -
@@ -147,6 +147,7 @@
NULL
};
+extern const struct gl_pipeline_stage _radeon_texrect_stage;
extern const struct gl_pipeline_stage _radeon_render_stage;
extern const struct gl_pipeline_stage _radeon_tcl_stage;
@@ -165,18 +166,10 @@
&_tnl_texgen_stage,
&_tnl_texture_transform_stage,
- /* Try again to go to tcl?
-* - no good for asymmetric-twoside (do with multipass)
-* - no good for asymmetric-unfilled (do with multipass)
-* - good for material
-* - good for texgen
-* - need to manipulate a bit of state
-*
-* - worth it/not worth it?
-*/
-
- /* Else do them here.
+ /* Scale texture rectangle to 0..1.
*/
+ &_radeon_texrect_stage,
+
&_radeon_render_stage,
&_tnl_render_stage, /* FALLBACK: */
0,
@@ -387,6 +380,8 @@
_math_matrix_set_identity( &rmesa->tmpmat );
driInitExtensions( ctx, card_extensions, GL_TRUE );
+ if( rmesa->dri.drmMinor >= 9 || getenv( "RADEON_RECTANGLE_FORCE_ENABLE")) /*
FIXME! a.s. */
+ _mesa_enable_extension( ctx, "GL_NV_texture_rectangle");
radeonInitDriverFuncs( ctx );
radeonInitIoctlFuncs( ctx );
radeonInitStateFuncs( ctx );
Index: radeon_context.h
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_context.h,v
retrieving revision 1.28
diff -u -r1.28 radeon_context.h
--- radeon_context.h13 May 2003 21:46:39 - 1.28
+++ radeon_context.h10 Jun 2003 15:37:49 -
@@ -259,6 +259,11 @@
#define TEX_PP_BORDER_COLOR 8
#define TEX_STATE_SIZE 9
+#define TXR_CMD_0 0 /* rectangle textures */
+#define TXR_PP_TEX_SIZE 1 /* 0x1d04, 0x1d0c for NPOT! */
+#define TXR_PP_TEX_PITCH2 /* 0x1d08, 0x1d10 for NPOT! */
+#define TXR_STATE_SIZE 3
+
#define ZBS_CMD_0 0
#define ZBS_SE_ZBIAS_FACTOR 1
#define ZBS_SE_ZBIAS_CONSTANT 2
@@ -422,6 +427,7 @@
struct radeon_state_atom grd; /* guard band clipping */
struct radeon_state_atom fog;
struct radeon_state_atom glt;
+ struct radeon_state_atom txr[2]; /* for NPOT */
};
struct radeon_state {
Index: radeon_ioctl.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_ioctl.c,v
retrieving revision 1.44
diff -u -r1.44 radeon_ioctl.c
--- radeon_ioctl.c 21 May 2003 17:32:09 - 1.44
+++ radeon_ioctl.c 10 Jun 2003 15:37:49 -
@@ -389,6 +389,73 @@
#endif
}
+/* using already shifted color_fmt! */
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Brian Paul wrote: Keith Whitwell wrote: Andreas Stenglein wrote: Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell: Keith Whitwell wrote: Andreas Stenglein wrote: @keithw: here is another version. yuvrect.c seems to work texrect.c still doesnt work any hints? OK, the final piece of the puzzle fell into place. Without the radeon docs you might hav had trouble find this -- basically, the radeon still expects texture rectangle texcoords to be in 0..1 range, rather than 0..width,0..height like the r200. I haven't got the code running for this yet, but modifying the app to supply the texcoords the hardware expects gives a good image. Keith yes, its unbelievable... it works with texcoords 0...1 ;) 1) Do you have an idea how to make it work with the right texcoords? I was thinking that this would be a fairly easy option: a) Disable TCL for all rectangular texture operations b) Insert a new stage to the swtcl pipeline, based on Mesa/src/tnl/t_vb_texmat.c, to perform a 1/w, 1/h scale to all texrect coordinates. c) premultiply the texture matrix by a scaling matrix? I wanted to keep things seperate -- but it does sound nice. It would need some new infrastructure - if it were to work with tcl fallbacks, then t_vb_texmat.c would have to use a premultiplied one also. Further, swrast expects "normal" 0..dimension texcoords, so it would have to be turned off during rasterization fallbacks. It seems like it would require hooks into core mesa, just to deal with this one piece of hardware that works this way. Adding a new renderstage keeps it in the driver. I could add a new renderstage *and* premultiply only the hw texture matrix (keeping hwtcl), but that's even more work. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Andreas Stenglein wrote: Am 2003.06.10 12:12:56 +0200 schrieb(en) Keith Whitwell: Keith Whitwell wrote: Andreas Stenglein wrote: @keithw: here is another version. yuvrect.c seems to work texrect.c still doesnt work any hints? OK, the final piece of the puzzle fell into place. Without the radeon docs you might hav had trouble find this -- basically, the radeon still expects texture rectangle texcoords to be in 0..1 range, rather than 0..width,0..height like the r200. I haven't got the code running for this yet, but modifying the app to supply the texcoords the hardware expects gives a good image. Keith yes, its unbelievable... it works with texcoords 0...1 ;) 1) Do you have an idea how to make it work with the right texcoords? I was thinking that this would be a fairly easy option: a) Disable TCL for all rectangular texture operations b) Insert a new stage to the swtcl pipeline, based on Mesa/src/tnl/t_vb_texmat.c, to perform a 1/w, 1/h scale to all texrect coordinates. I can send you some unfinished code for this, if you want. 2) Since the default bordermode GL_REPEAT doesnt work/isnt allowed with npot textures, should there something be done about that? Probably... 3) in radeon_ioctl.c, function radeonEmitVbufPrim() the first cmd is cleared before filled with the cmd_type: cmd[0].i = 0; cmd[0].header.cmd_type = RADEON_CMD_PACKET3_CLIP; should this be done in radeonEmitBlit() also or is that not necessary? Quite possibly it should. 4) I missed a line in radeon_context.c: driCalculateMaxTextureLevels( rmesa->texture_heaps, rmesa->nr_heaps, & ctx->Const, 4, 11, /* max 2D texture size is 2048x2048 */ 0, /* 3D textures unsupported. */ 0, /* cube textures unsupported. */ ===> 11, /* max texture rectangle size is 2048x2048 */ 12, GL_FALSE ); Looks good, too. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Keith Whitwell wrote: Andreas Stenglein wrote: @keithw: here is another version. yuvrect.c seems to work texrect.c still doesnt work any hints? OK, the final piece of the puzzle fell into place. Without the radeon docs you might hav had trouble find this -- basically, the radeon still expects texture rectangle texcoords to be in 0..1 range, rather than 0..width,0..height like the r200. I haven't got the code running for this yet, but modifying the app to supply the texcoords the hardware expects gives a good image. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Keith Whitwell wrote: Andreas Stenglein wrote: @keithw: here is another version. yuvrect.c seems to work texrect.c still doesnt work any hints? I find the radeon_sanity.c output very helpful when things just arent working. Here's a patch to bring it uptodate with your changes. If you run it, you'll see that the hardware just isn't being told anything about these textures, so its no suprise that it doesn't display them properly. OK, the reason for this is just a typo in import_tex_obj_state(): line 1286 should read: RADEON_DB_STATECHANGE( rmesa, &rmesa->hw.txr[unit] ); Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Andreas Stenglein wrote:
@keithw: here is another version.
yuvrect.c seems to work
texrect.c still doesnt work
any hints?
I find the radeon_sanity.c output very helpful when things just arent working.
Here's a patch to bring it uptodate with your changes. If you run it,
you'll see that the hardware just isn't being told anything about these
textures, so its no suprise that it doesn't display them properly.
Keith
Index: radeon_sanity.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_sanity.c,v
retrieving revision 1.6
diff -u -r1.6 radeon_sanity.c
--- radeon_sanity.c 30 Apr 2003 01:50:52 - 1.6
+++ radeon_sanity.c 9 Jun 2003 23:37:38 -
@@ -82,6 +82,61 @@
{ RADEON_SE_ZBIAS_FACTOR,2,"RADEON_SE_ZBIAS_FACTOR" },
{ RADEON_SE_TCL_OUTPUT_VTX_FMT,11,"RADEON_SE_TCL_OUTPUT_VTX_FMT" },
{ RADEON_SE_TCL_MATERIAL_EMMISSIVE_RED,17,"RADEON_SE_TCL_MATERIAL_EMMISSIVE_RED" },
+ { 0, 4, "R200_PP_TXCBLEND_0" },
+ { 0, 4, "R200_PP_TXCBLEND_1" },
+ { 0, 4, "R200_PP_TXCBLEND_2" },
+ { 0, 4, "R200_PP_TXCBLEND_3" },
+ { 0, 4, "R200_PP_TXCBLEND_4" },
+ { 0, 4, "R200_PP_TXCBLEND_5" },
+ { 0, 4, "R200_PP_TXCBLEND_6" },
+ { 0, 4, "R200_PP_TXCBLEND_7" },
+ { 0, 6, "R200_SE_TCL_LIGHT_MODEL_CTL_0" },
+ { 0, 6, "R200_PP_TFACTOR_0" },
+ { 0, 4, "R200_SE_VTX_FMT_0" },
+ { 0, 1, "R200_SE_VAP_CNTL" },
+ { 0, 5, "R200_SE_TCL_MATRIX_SEL_0" },
+ { 0, 5, "R200_SE_TCL_TEX_PROC_CTL_2" },
+ { 0, 1, "R200_SE_TCL_UCP_VERT_BLEND_CTL" },
+ { 0, 6, "R200_PP_TXFILTER_0" },
+ { 0, 6, "R200_PP_TXFILTER_1" },
+ { 0, 6, "R200_PP_TXFILTER_2" },
+ { 0, 6, "R200_PP_TXFILTER_3" },
+ { 0, 6, "R200_PP_TXFILTER_4" },
+ { 0, 6, "R200_PP_TXFILTER_5" },
+ { 0, 1, "R200_PP_TXOFFSET_0" },
+ { 0, 1, "R200_PP_TXOFFSET_1" },
+ { 0, 1, "R200_PP_TXOFFSET_2" },
+ { 0, 1, "R200_PP_TXOFFSET_3" },
+ { 0, 1, "R200_PP_TXOFFSET_4" },
+ { 0, 1, "R200_PP_TXOFFSET_5" },
+ { 0, 1, "R200_SE_VTE_CNTL" },
+ { 0, 1, "R200_SE_TCL_OUTPUT_VTX_COMP_SEL" },
+ { 0, 1, "R200_PP_TAM_DEBUG3" },
+ { 0, 1, "R200_PP_CNTL_X" },
+ { 0, 1, "R200_RB3D_DEPTHXY_OFFSET" },
+ { 0, 1, "R200_RE_AUX_SCISSOR_CNTL" },
+ { 0, 2, "R200_RE_SCISSOR_TL_0" },
+ { 0, 2, "R200_RE_SCISSOR_TL_1" },
+ { 0, 2, "R200_RE_SCISSOR_TL_2" },
+ { 0, 1, "R200_SE_VAP_CNTL_STATUS" },
+ { 0, 1, "R200_SE_VTX_STATE_CNTL" },
+ { 0, 1, "R200_RE_POINTSIZE" },
+ { 0, 4, "R200_SE_TCL_INPUT_VTX_VECTOR_ADDR_0" },
+ { 0, 1, "R200_PP_CUBIC_FACES_0" }, /* 61 */
+ { 0, 5, "R200_PP_CUBIC_OFFSET_F1_0" }, /* 62 */
+ { 0, 1, "R200_PP_CUBIC_FACES_1" },
+ { 0, 5, "R200_PP_CUBIC_OFFSET_F1_1" },
+ { 0, 1, "R200_PP_CUBIC_FACES_2" },
+ { 0, 5, "R200_PP_CUBIC_OFFSET_F1_2" },
+ { 0, 1, "R200_PP_CUBIC_FACES_3" },
+ { 0, 5, "R200_PP_CUBIC_OFFSET_F1_3" },
+ { 0, 1, "R200_PP_CUBIC_FACES_4" },
+ { 0, 5, "R200_PP_CUBIC_OFFSET_F1_4" },
+ { 0, 1, "R200_PP_CUBIC_FACES_5" },
+ { 0, 5, "R200_PP_CUBIC_OFFSET_F1_5" },
+ { RADEON_PP_TEX_SIZE_0, 2, "RADEON_PP_TEX_SIZE_0" },
+ { RADEON_PP_TEX_SIZE_1, 2, "RADEON_PP_TEX_SIZE_1" },
+ { RADEON_PP_TEX_SIZE_2, 2, "RADEON_PP_TEX_SIZE_1" },
};
struct reg_names {
@@ -168,7 +223,13 @@
{ RADEON_SE_TCL_MATERIAL_SPECULAR_BLUE, "RADEON_SE_TCL_SPECULAR_BLUE" },
{ RADEON_SE_TCL_MATERIAL_SPECULAR_ALPHA, "RADEON_SE_TCL_SPECULAR_ALPHA" },
{ RADEON_SE_TCL_SHININESS, "RADEON_SE_TCL_SHININESS" },
- { RADEON_SE_COORD_FMT, "RADEON_SE_COORD_FMT" }
+ { RADEON_SE_COORD_FMT, "RADEON_SE_COORD_FMT" },
+ { RADEON_PP_TEX_SIZE_0, "RADEON_PP_TEX_SIZE_0" },
+ { RADEON_PP_TEX_SIZE_1, "RADEON_PP_TEX_SIZE_1" },
+ { RADEON_PP_TEX_SIZE_2, "RADEON_PP_TEX_SIZE_2" },
+ { RADEON_PP_TEX_SIZE_0+4, "RADEON_PP_TEX_PITCH_0" },
+ { RADEON_PP_TEX_SIZE_1+4, "RADEON_PP_TEX_PITCH_1" },
+ { RADEON_PP_TEX_SIZE_2+4, "RADEON_PP_TEX_PITCH_2" },
};
static struct reg_names scalar_names[] = {
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Keith Whitwell wrote:
Andreas Stenglein wrote:
hello,
Am 2003.06.09 18:05:35 +0200 schrieb(en) Keith Whitwell:
Andreas,
Applied this today & had a brief look.
I needed to bump the version number in shared/drm/radeon.h to 1.9.0
before the extensions were enabled. Maybe this got missed from the
diff?
I didn't want to bump the version before the packets for
cubemap-texturing are in place... so I just added a check
for >= 1.9.0 OR getenv( "RADEON_RECTANGLE_FORCE_ENABLE")
What problems are you having with texrect.c? I get:
texrect: radeon_ioctl.c:414: radeonEmitBlit: Assertion `(src_offset &
1023) == 0' failed.
Is this the same as you're seeing?
No, I dont get the assertion. It "just doesnt work as expected":
I get white textures with grey/black points/lines.
If I disable/comment out the radeonEmitBlit(), it looks
the same, so maybe the blit doesnt work?
On the other hand the assertion you get shouldn't occur, so
it looks like I missed something.
The strange part is, that yuvrect (at least seems to) work(s) well.
yuvrect even worked without the additional txsize/txpitch packet.
And yuvrect works when RADEON_AGPTEXTURING_FORCE_DISABLE=1.
Keith
thanks for having a look at the patch
greetings,
Andreas
PS: here's the begin of some output I get
when running texrect, with RADEON_DEBUG=ioctl
(unfortunately it sometimes hangs the Xserver until
I kill texrect)
I've been playing a bit more -- it's kind of odd what works &
doesn't... I haven't really got a handle on it yet...
OK, at least I know why the yuv code appeared to sortof work: it was hitting
a fallback path and reverting to software rendering. Basically some code is
missing for yuv support in radeonUpdateTextureEnv().
The attached patch includes the missing code. Now at least everything doesn't
work. I still seem to get upload blits landing in the backbuffer on occasion.
Keith
Keith
Index: radeon_texstate.c
===
RCS file: /cvsroot/dri/xc/xc/lib/GL/mesa/src/drv/radeon/radeon_texstate.c,v
retrieving revision 1.17
diff -u -r1.17 radeon_texstate.c
--- radeon_texstate.c 26 May 2003 19:48:52 - 1.17
+++ radeon_texstate.c 9 Jun 2003 23:17:04 -
@@ -814,6 +823,7 @@
break;
case GL_LUMINANCE:
case GL_RGB:
+case GL_YCBCR_MESA:
color_combine = radeon_color_combine[unit][RADEON_REPLACE];
alpha_combine = radeon_alpha_combine[unit][RADEON_DISABLE];
break;
@@ -837,6 +847,7 @@
break;
case GL_RGB:
case GL_LUMINANCE:
+case GL_YCBCR_MESA:
color_combine = radeon_color_combine[unit][RADEON_MODULATE];
alpha_combine = radeon_alpha_combine[unit][RADEON_DISABLE];
break;
@@ -850,6 +861,7 @@
switch ( format ) {
case GL_RGBA:
case GL_RGB:
+case GL_YCBCR_MESA:
color_combine = radeon_color_combine[unit][RADEON_DECAL];
alpha_combine = radeon_alpha_combine[unit][RADEON_DISABLE];
break;
@@ -872,6 +884,7 @@
case GL_RGB:
case GL_LUMINANCE:
case GL_LUMINANCE_ALPHA:
+case GL_YCBCR_MESA:
color_combine = radeon_color_combine[unit][RADEON_BLEND];
alpha_combine = radeon_alpha_combine[unit][RADEON_MODULATE];
break;
@@ -895,6 +908,7 @@
case GL_RGB:
case GL_LUMINANCE:
case GL_LUMINANCE_ALPHA:
+case GL_YCBCR_MESA:
color_combine = radeon_color_combine[unit][RADEON_ADD];
alpha_combine = radeon_alpha_combine[unit][RADEON_MODULATE];
break;
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Andreas Stenglein wrote: hello, Am 2003.06.09 18:05:35 +0200 schrieb(en) Keith Whitwell: Andreas, Applied this today & had a brief look. I needed to bump the version number in shared/drm/radeon.h to 1.9.0 before the extensions were enabled. Maybe this got missed from the diff? I didn't want to bump the version before the packets for cubemap-texturing are in place... so I just added a check for >= 1.9.0 OR getenv( "RADEON_RECTANGLE_FORCE_ENABLE") What problems are you having with texrect.c? I get: texrect: radeon_ioctl.c:414: radeonEmitBlit: Assertion `(src_offset & 1023) == 0' failed. Is this the same as you're seeing? No, I dont get the assertion. It "just doesnt work as expected": I get white textures with grey/black points/lines. If I disable/comment out the radeonEmitBlit(), it looks the same, so maybe the blit doesnt work? On the other hand the assertion you get shouldn't occur, so it looks like I missed something. The strange part is, that yuvrect (at least seems to) work(s) well. yuvrect even worked without the additional txsize/txpitch packet. And yuvrect works when RADEON_AGPTEXTURING_FORCE_DISABLE=1. Keith thanks for having a look at the patch greetings, Andreas PS: here's the begin of some output I get when running texrect, with RADEON_DEBUG=ioctl (unfortunately it sometimes hangs the Xserver until I kill texrect) I've been playing a bit more -- it's kind of odd what works & doesn't... I haven't really got a handle on it yet... Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] GL_NV_texture_rectangle on radeon
Andreas Stenglein wrote: @keithw: here is another version. yuvrect.c seems to work texrect.c still doesnt work Andreas, Applied this today & had a brief look. I needed to bump the version number in shared/drm/radeon.h to 1.9.0 before the extensions were enabled. Maybe this got missed from the diff? What problems are you having with texrect.c? I get: texrect: radeon_ioctl.c:414: radeonEmitBlit: Assertion `(src_offset & 1023) == 0' failed. Is this the same as you're seeing? Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i845 driver and MTRR's..
Keith Whitwell wrote:
Linus Torvalds wrote:
On Tue, 3 Jun 2003, Linus Torvalds wrote:
[ Finally got some debugging time for the other DRI problem I've
seen, namely hugely flashing textures in tuxracer on i830, but
_only_ iff MTRR
support is compiled into the kernel ]
I've got some more information, including a workaround..
I get horrible texture flashing iff:
- MTRR's are enabled (no idea why it matters, but it does. It might
justbe timing-related, since proper MTRR programming speeds up
things by afactor of two)
- I only allocate 32MB of video memory.
I see this too (I haven't tried disabling mtrrs). It looks a lot like
the driver is using the framebuffer to store texture data & getting into
all sorts of troubles...
Acutally, I'm pretty sure this is entirely a userspace problem, introduced
with the texmem-ification of the i830 driver.
Unlike most drivers i830 texture uploads are just memcpys to the texture area
in the framebuffer (which is just agp memory). The reasoning behind this is
that the usual technique of loading the texture into dma buffers & having the
card upload to the framebuffer is redundant as the dma buffers would be agp
memory, just like the framebuffer, so why not put the texture right where it's
meant to be & avoid the extra copy.
The downside to this is synchronization: Texture memory accessed this way has
to be synchronized with commands on the ring which expect to be able to access
other, earlier textures at a given location in texture memory.
So, in the pre-texmem code, we had things like this:
void i830SwapOutTexObj(i830ContextPtr imesa, i830TextureObjectPtr t)
{
...
if (t->age > imesa->dirtyAge)
imesa->dirtyAge = t->age;
...
}
which kept a pretty rough idea of how long it would be necessary to sleep
before texture memory we believed to be free would really no longer be
accessed by queued commands.
That code seems to have disappeared post-texmem-merge.
Possibilities I see are:
- restore the old tracking code (or an improved version). This would have to
go into the shared texmem.c code, right?
- be very pessimistic and sync before any texture upload
- push texture uploads through the dma command stream and live with the
double copy.
Keith
Keith
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i845 driver and MTRR's..
Linus Torvalds wrote: On Tue, 3 Jun 2003, Linus Torvalds wrote: [ Finally got some debugging time for the other DRI problem I've seen, namely hugely flashing textures in tuxracer on i830, but _only_ iff MTRR support is compiled into the kernel ] I've got some more information, including a workaround.. I get horrible texture flashing iff: - MTRR's are enabled (no idea why it matters, but it does. It might just be timing-related, since proper MTRR programming speeds up things by a factor of two) - I only allocate 32MB of video memory. I see this too (I haven't tried disabling mtrrs). It looks a lot like the driver is using the framebuffer to store texture data & getting into all sorts of troubles... Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] copy_from_user question
Hollis Blanchard wrote: On Wednesday, Jun 4, 2003, at 17:45 US/Central, José Fonseca wrote: On Wed, Jun 04, 2003 at 05:17:52PM -0500, Hollis Blanchard wrote: This is what the Stanford checker turned up recently when analyzing the copy_to/from_user calls in the Linux kernel: [...] This is all because the DRM_COPY_FROM_USER_UNCHECKED is being called in radeon_cp_dispatch_indices. If the copy_from_user is needed, the whole sarea_priv structure must be in user space, in which case all the other direct sarea references are in error. The other possibility is that copy_from_user isn't needed here at all. Can anyone comment? The SAREA, and hence drm_radeon_sarea_t and 'boxes', lives on a shared memory segment accessible by all intervenients (kernel, X server, client). So the copy_from_user shouldn't be used. I guess that at some point, radeon_cp_dispatch_indices was called on userspace cliprects, but now it appears only to be called on the SAREA. Perhaps Keith can tell more about it. Any further comments here? I didn't quite follow the explanation of where SAREA lives, but I guess copy_from_user should be replaced? Anyone have a patch? I started one, but won't be able to finish it off until Monday (probably). Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XF86DRIOpenFullScreen and friends
Brian Paul wrote: Ian Romanick wrote: Since I seem to have launched into another round of GLX clean-up, I've added SGI_make_current_read to my hit list. There are a coupld of obvious libGL-to-driver interface changes that need to happen to support this. 1. Add 'GLXDrawable currentReadable' to the end of __GLXcontextRec. 2. Add 'bindContext2' to __DRIcontextRec. The DRI utility code would just hook bindContext2 directly to driBindContext2. 3. Add 'unbindContext2' to __DRIcontextRec. The DRI utility code would have to be updated. A new driUnbindContext2 would be added, and driUnbindContext would just call that. driUnbindContext2 would look exactly like driUnbindContext except that if the read and draw drawables passed in are different, it would decrement the ref. count on both. All three of those changes should be pretty trivial. The hardest part will be writing glXMakeCurrentReadSGI / glXMakeContextCurrent. The existing glXMakeCurrent would serve as a model. I was thinking that all three functions (or at least the two new ones) could be just thin wrappers that call a single function that does the real work. Like my fbconfig code, the code would detect which flavor of the protocol to use. One nice thing about this is that we could support the SGI extension when the server supports GLX 1.3 but not the SGI extension (i.e., the current Nvidia drivers). I would welcome any comments (positive or negative) on that. The question I have is about the interaction of driBindContext2 and driUnbindContext (both in lib/GL/dri/dri_util.c) with XF86DRIOpenFullScreen and XF86DRICloseFullScreen. It looks to me like this bit of protocol is only used when the env. var. LIBGL_DRI_AUTOFULLSCREEN is set. From looking through both the client-side and the server-side code, it appears that this bit of protocol really only cares about the write drawable. If that is the case, then the protocol shouldn't need to be updated to support SGI_make_current_read or the parallel functionality in GLX 1.3. Is that correct? If it really is only used when the env. var. is set, is there any chance we could just rip it out? Obviously it would have to be left as-is on the server-side, but it seems like the client-side support could go away. What's a little bit less obvious to me is the changes that need to be made on the server side, but that can wait. :) I don't want to bite off more than I can chew... I don't recall if the XF86DRIOpen/CloseFullScreen() functions are really used. I never worked on that path. I think it was meant for doing page-flipping swapbuffers, but I think Keith implemented that feature without using those functions. Yes. As far as I'm concerned they can go away altogether. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Martin Spott wrote: "Matt Sealey" <[EMAIL PROTECTED]> wrote: I'm sure that MPlayer or Xine actually support an OpenGL output plugin already. Chances are it's Xine, but I haven't touched it in 6 months, maybe they removed it? I believe it's still there. Before propagating the use of 'new' API's in Xinre for example please remember that this software was designed to run on other platforms, too, that don't know anything of MESA (IRIX for example). Um.. IRIX doesn't have OpenGL now? That's not what I was claiming. People where talking about 'MESA_ycbcr_texture' which I was referring to (see my posting), Typically it's pretty easy to write GL programs to not rely on given extensions being present. The GL extension mechanism makes this fairly painless. And as the fallback paths are already in place, I can't see it being much of a problem. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Alex Deucher wrote: Gabucino, Do you know if either plugin uses MESA_ycbcr_texture? this would avoid the need for you to convert YUV data to RGB in order to render it as a texture. Should speed things up of OGL. when I looked at the xine plugin source, it did not support this. For systems that do not support the extension, you could always fall back to RGB. As Ian mentioned, some of the other extensions coming down the pike will also help performance: APPLE_client_storage and such... http://mesa3d.sourceforge.net/MESA_ycbcr_texture.spec http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt http://oss.sgi.com/projects/ogl-sample/registry/APPLE/fence.txt I've just been looking at the one in Xine, and it just uses plain RGB square textures. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] i810 drm page flipping support..
Dave Airlie wrote: Hi all, I'd like to start commiting the changes to the i810 driver for page flipping, although it isn't working perfectly (and cannot using the current system) I would like to have the code in place, I'm using it here for a single 3d app and it works fine... The first patch I'd like to commit is the DRM changes the patch is at http://www.skynet.ie/~airlied/patches/dri/i810_drm.diff I'd like someone to look over it before I commit it, basically to make sure I've changed the version number correctly.. I bumped the minor version as I've added the flip ioctl which I think is correct, I also updated the date... I persume then in my i810_dri code I should only attempt page flipping if I get a version with a minor at least equal to my new one... Correct. The patch looks good. Do you actually get a speedup from page flipping on the i810? Are there ever any visual corruptions that you would attribute to the hardware? Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] copy_from_user question
José Fonseca wrote: Hollis, On Wed, Jun 04, 2003 at 05:17:52PM -0500, Hollis Blanchard wrote: This is what the Stanford checker turned up recently when analyzing the copy_to/from_user calls in the Linux kernel: [...] This is all because the DRM_COPY_FROM_USER_UNCHECKED is being called in radeon_cp_dispatch_indices. If the copy_from_user is needed, the whole sarea_priv structure must be in user space, in which case all the other direct sarea references are in error. The other possibility is that copy_from_user isn't needed here at all. Can anyone comment? The SAREA, and hence drm_radeon_sarea_t and 'boxes', lives on a shared memory segment accessible by all intervenients (kernel, X server, client). So the copy_from_user shouldn't be used. I guess that at some point, radeon_cp_dispatch_indices was called on userspace cliprects, but now it appears only to be called on the SAREA. Perhaps Keith can tell more about it. Yes, there's no need to be calling COPY_FROM_USER on these cliprects - just referencing them directly would be fine. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Keith Whitwell wrote: Right, but I want to build a libGL without MiniGLX, just with DRI. Do you think it will be feasible for this new DRI interface to work with drivers not based on Mesa? If so, the code should not be in the src/mesa/ subtree. I have to admit I'm lost now. Denis is proposing a new public DRI-based API, presumably for fbdev-type environments. Suppose this API became popular and other parties wanted to implement drivers for it - drivers not based on Mesa. Is that conceivable? If so, this new interface should not be in src/mesa/ Hmm - I think that's a side issue to this reorg. Let's keep to code that exists - I'm not sure that everyone's communicating acurately at the moment. I think that there will probably always be some small details about the code that don't accurately map onto how the repository works, and also that talking about code is fairly error prone compared to actually working with it. Brian - I'm happy to make a start with your original layout. Lets get that up and running so that we can talk in concrete terms about any additional & minor rearrangements for the final switchover. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Keith Whitwell wrote: Hmm - I think that's a side issue to this reorg. Let's keep to code that exists - I'm not sure that everyone's communicating acurately at the moment. I think that there will probably always be some small details about the code that don't accurately map onto how the repository works, and also that talking about code is fairly error prone compared to actually working with it. Brian - I'm happy to make a start with your original layout. Lets get that up and running so that we can talk in concrete terms about any additional & minor rearrangements for the final switchover. Right. So then, if anyone has anything they want to check into Mesa CVS do it soon and then be prepared to go a few days without check-ins. I don't want the repository changed while I'm working on a local copy. I may begin work this evening (around 7pm mountain time). When I begin I'll post a "no more check-ins" message. Just to double check we're on the same page - the new tree won't try and include the cvs history prior to this point, right? We're starting a new tree from scratch and leaving the history in the old one? Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore, but..(pointers to colour buffers again..)
Matt Sealey wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ian Romanick
Sent: Wednesday, June 04, 2003 4:49 PM
To: DRI developer's list
Subject: [Dri-devel] Re: [Mesa3d-dev] Not confused so much anymore,
but.. (pointers to colour buffers again..)
Marcelo E. Magallon wrote:
On Wed, Jun 04, 2003 at 08:27:06AM +0100, Matt Sealey wrote:
> > By "resize" you mean, e.g., "color buffer resize"? That doesn't work.
> > From the documentation:
> >
> >glViewport specifies the affine transformation of x and y from
> >normalized device coordinates to window coordinates.
>
> Sure but if the window coordinates are width 300, height 300, then the
> maximum size of the buffer is really 300x300 in window coordinates.
>
> There's not any point allocating or keeping a larger colour buffer than
> you are going to have physical display pixels :)
Uhm...
[example cut]
Did I miss you point?
The point is that people *almost always* call glViewport when they get a
window resize event. That gives the driver a chance to ask the system
what the window size is.
Aiiee.. I already said I don't know what the window size is at all. There
is no point where Mesa CAN be told what the window size is. It never talks
to find out either. Back to Square One!
Read the X11 driver. From get_buffer_size(), simplified for email:
/*
* Return the size (width, height) of the X window for the given
* GLframebuffer.
* Output: width - width of buffer in pixels.
* height - height of buffer in pixels.
*/
static void
get_buffer_size( GLframebuffer *buffer, GLuint *width, GLuint *height )
{
/* We can do this cast because the first field in the XMesaBuffer
* struct is a GLframebuffer struct. If this weren't true, we'd
* need a pointer from the GLframebuffer to the XMesaBuffer.
*/
const XMesaBuffer xmBuffer = (XMesaBuffer) buffer;
unsigned int winwidth, winheight;
Window root;
int winx, winy;
unsigned int bw, d;
XGetGeometry( xmBuffer->xm_visual->display, xmBuffer->frontbuffer, &root,
&winx, &winy, &winwidth, &winheight, &bw, &d );
*width = winwidth;
*height = winheight;
}
Can you see what this function does? This is GetBufferSize for the X11
driver. You'll have to do something similar for yours.
If the size is different than the last time, it can resize its internal
buffers. It doesn't just use the values supplied by glViewport.
So what values DOES it use?
The ones you tell it when it asks you by calling the 'GetBufferSize' callback.
That callback is there because mesa doesn't know and isn't able to tell the
buffer size.
Keith
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Right, but I want to build a libGL without MiniGLX, just with DRI. Do you think it will be feasible for this new DRI interface to work with drivers not based on Mesa? If so, the code should not be in the src/mesa/ subtree. I have to admit I'm lost now. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): Denis Oliver Kropp wrote: I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. dri_glx.c and glxclient.h are part of XFree86 GLX/DRI AFAIK, so I think they belong into src/glx/. Last time I checked (I worked on this stuff back in November), the dri_glx.c and glxclient.h files were chopped/modified versions of what's in the XFree86/DRI tree made for the embedded subset project. That's why I was suggesting that they go into a dri-es/ directory. MiniGLX doesn't need dri_glx.c or glxclient.h. Also, extra "-es" versions shouldn't be needed as drivers/dri/ won't get that big and works for embedded and full driver builds. I belive that Keith put a lot of work into the radeon-es driver in order to reduce the code size for our client. Thus, I expected that code would live in a separate radeon-es/ directory. Keith? No - the 'es' stuff is dead - it's all in the radeon/ directory and controlled by compile directives. I actually spent a bit of time scratching my head trying to figure out what 'es' meant - forgetfulness, I guess. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. What about this? dri/- dri driver interface api/- public api common/- reusable driver code radeon/ - DRI driver r200/ - DRI driver mga/- DRI driver What's the "public api"? Hmm, maybe the libGL code? Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Mesa3d-dev] Re: Mesa tree re-org
Brian Paul wrote: Denis Oliver Kropp wrote: Quoting Brian Paul ([EMAIL PROTECTED]): src/ mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code math/- math/vector routines m_*.[ch] swrast/- s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/- vertex array stuff ac_*.[ch] drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver radeon/- DRI/fbdev driver radeon-es/- subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- es dri code Oops, dri/ is indented one tab too far, and probably not named very well. It should be probably be src/dri-es/ since it implements DRI facilities for the embedded subset. I think the DRI drivers should be moved into the dri/ directory which itself should be in the drivers/ directory, because drivers/ contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc. The dri/ directory will contain windowing system independent code as a public interface to the DRI drivers. The DRI drivers won't be used by applications directly. My suggestion: drivers/ common/- reusable driver code and transform_dd/ files x11/- X11 (XMesa) driver osmesa/- OSMesa driver swfbdev/- software fbdev driver windows/ beos/ ggi/ glide/- was FX driver dos/ dri/- dri driver interface common/- reusable driver code radeon/- DRI/fbdev driver r200/- DRI/fbdev driver mga/- DRI/fbdev driver Where do you propose that the files currently in Mesa/src/dri/ (such as dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was planning on. I'm trying to keep the tree fairly shallow (one of the things that intimidates people about the XFree86/DRI tree is its size and depth) so I'm not sure we need drivers/dri/ yet. I agree with the idea of keeping things as shallow as possible, but Denis' proposal does address the issue that I had earlier in terms of the way some of the drivers are windowsystem+drivers and some are just (dri) drivers. This way all the things in drivers/ would be equivalent objects. Also, I want to try to keep all source files as leaves in the tree. That is, a directory foo/ won't contain both files and subdirs; just one or the other. This is another worthy goal, however... Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM janitorial (New patch, covering AGP)
José Fonseca wrote: The new attached patch also covers the drm_agpsupport.h janitorial. As nobody stepped against it, I'll start commiting soon. Except for this first time, I don't plan to commit more than one header "janitorial" per day. This means that anybody can track regressions with the nightly snapshots. For the other branches out there, when merging/syncing with the trunk the only special thing to do is replace "drm_agpsupport.h" by "drm_agp_tmp.h" and so forth, in the *_drv.c file. José Fonseca The patch looks good to me... Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa tree re-org
Brian Paul wrote: David Dawes wrote: On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote: Sounds like the Mesa directory re-org should happen sooner, rather than later. I've been doing some research into CVS and it looks like there are two approaches to doing the re-org: 1. Use the usual cvs add/remove/commit commands to move everything around. This would work, but it would be pretty tedious and we'd sort of lose the CVS histories. 2. Download the nightly CVS tarball to my machine, reorganize it, then upload it to SourceForge and have the SF admins install it as the new CVS tree. The one issue with this approach is that it would effect all CVS branches. A benefit would be the ability to _really_ remove the old, empty directories. I prefer option 2. Depending on how you do option 2, you'll lose the ability to check out older versions as they used to be. I'm not a CVS expert, but my understanding is that tags are stored in each of the ,v files (not in a special tag file) and the ,v files have no paths stored in them. So, checking out an old branch will result in the OLD files in the NEW directory tree. I can live with that. Is that what you're describing? It is possible to do a combination of the two approaches, but that would require quite a bit of work. For example, the old ,v files wouldn't be removed, but rather copied to the new location, and the old tags for the files in the new locations would either be removed or renamed. Yes, we could do that but I'm prepared to make a clean break at this point. Another option is to keep the old repository as-is, and start a new one (i.e., a new top level directory under the same $CVSROOT), seeded with the reorganised files from the old one. Does anyone else think we should do that? I'm open to it. Actually, I think I'd prefer this. The only issue is deciding on a name for the new module - 'mesa' is taken... Perhaps we could rename the existing tree and start a new one under 'mesa'? Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Matt Sealey wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michel Dänzer Sent: Tuesday, June 03, 2003 12:42 AM To: Alex Deucher Cc: Keith Whitwell; [EMAIL PROTECTED] Subject: Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture On Tue, 2003-06-03 at 00:09, Alex Deucher wrote: perhaps it would be better to just write opengl output plugins for video applications that used MESA_ycbcr_texture. I think so, e.g. you lose direct rendering by putting this into the server. I'm sure that MPlayer or Xine actually support an OpenGL output plugin already. Chances are it's Xine, but I haven't touched it in 6 months, maybe they removed it? All I remember is that it was terribly slow to output to a YUV or RGB texture and use OpenGL to display it. Whatever app was playing the movie etc. did a lot better when it used plain ordinary writing to pixmaps and blitting them to the window. That can probably be fixed with little effort. There have been a few people using DRI drivers with video in mind, so the paths to do this efficiently are looking a bit clearer these days. Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Endless loop in radeon_do_wait_for_idle()
Linus Torvalds wrote: On Mon, 2 Jun 2003, Keith Whitwell wrote: Under what circumstances does this actually happen? First 3d app run? Even something like 'glinfo'? I don't even get a desktop - the thing hangs at initialization time (probably when clearing the screen. My hardware may actually have gone bad, for all I know. If I disable DRI (by using a 8-bit depth), then the server can be killed, but it still doesn't actually seem to ever get to the desktop. I'm assuming it is looping internally waiting for the chip to un-busy itself. What if you take the dri/drm out of the equation by deleting the "dri" lines from XF86Config? Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Alex Deucher wrote: perhaps it would be better to just write opengl output plugins for video applications that used MESA_ycbcr_texture. However, looking at the code for several video apps, most that have an OGL output still use RGB textures with the the YUV->RGB conversion done in software. Not sure I quite understand you - but definitely changing those apps to use the Mesa extension (if available) would be a win. I'm not quite sure why you expressed a desire elsewhere to make the video stuff an xfree module - I'd have thought a library or plugin to existing library would make more sense. Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa tree re-org
Keith Whitwell wrote: Brian Paul wrote: Sounds like the Mesa directory re-org should happen sooner, rather than later. I've been doing some research into CVS and it looks like there are two approaches to doing the re-org: 1. Use the usual cvs add/remove/commit commands to move everything around. This would work, but it would be pretty tedious and we'd sort of lose the CVS histories. 2. Download the nightly CVS tarball to my machine, reorganize it, then upload it to SourceForge and have the SF admins install it as the new CVS tree. The one issue with this approach is that it would effect all CVS branches. A benefit would be the ability to _really_ remove the old, empty directories. I prefer option 2. How about a mixed approach: Open a branch with the existing CVS to prototype the new structure, do all the add/remove/commit stuff there until you have a working tree, then do (2) as a final irreversable step. My first step would be to wrap-up version 5.0.2 (bug fix release) and get that out of the way. That would leave the embedded-* branches. Do those of you working on those branches have any concerns? Below is the latest proposal for the new tree layout. Comments? -Brian Mesa/ docs/- documentation include/ GL/- OpenGL public headers gl.h glext.h glx.h glxext.h glu.h ... src/ glu/ sgi/- SGI GLU code (C++) mesa/- old Mesa GLU code (C) mini/- subset GLU for embedded glut/ glx/- GLUT based on GLX beos/- GLUT for BeOS dos/- GLUT for DOS ggi/- GLUT for GGI There's a miniglut as well, fwiw. widgets/- SGI widget code mesa/ glapi/ glapi*.[ch]- dispatcher files APIspec file gl*.py- Python API scripts main/- core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/- was tnl t_*.[ch] X86/3Dnow code transform_dd/- TCL templates for drivers t_dd_*.[ch] Call this driver_templates, maybe? Actually, there's a lot of overlap between this and the drivers/common directory -- maybe just move all this code to there? Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa tree re-org
Brian Paul wrote: Sounds like the Mesa directory re-org should happen sooner, rather than later. I've been doing some research into CVS and it looks like there are two approaches to doing the re-org: 1. Use the usual cvs add/remove/commit commands to move everything around. This would work, but it would be pretty tedious and we'd sort of lose the CVS histories. 2. Download the nightly CVS tarball to my machine, reorganize it, then upload it to SourceForge and have the SF admins install it as the new CVS tree. The one issue with this approach is that it would effect all CVS branches. A benefit would be the ability to _really_ remove the old, empty directories. I prefer option 2. My first step would be to wrap-up version 5.0.2 (bug fix release) and get that out of the way. That would leave the embedded-* branches. Do those of you working on those branches have any concerns? Below is the latest proposal for the new tree layout. Comments? -Brian Mesa/ docs/ - documentation include/ GL/ - OpenGL public headers gl.h glext.h glx.h glxext.h glu.h ... src/ glu/ sgi/- SGI GLU code (C++) mesa/ - old Mesa GLU code (C) mini/ - subset GLU for embedded glut/ glx/- GLUT based on GLX beos/ - GLUT for BeOS dos/- GLUT for DOS ggi/- GLUT for GGI There's a miniglut as well, fwiw. widgets/ - SGI widget code mesa/ glapi/ glapi*.[ch] - dispatcher files APIspec file gl*.py - Python API scripts main/ - core Mesa sources attrib.c context.c enable.c ... CPU detection code transform/ - was tnl t_*.[ch] X86/3Dnow code transform_dd/ - TCL templates for drivers t_dd_*.[ch] Call this driver_templates, maybe? math/ - math/vector routines m_*.[ch] swrast/ - s/w rasterization s_*.[ch] mmx_blend.S swsetup/- was swrast_setup ss_*.[ch] arraycache/ - vertex array stuff ac_*.[ch] drivers/ common/ - reusable driver code X11/- X11 (XMesa) driver osmesa/ - OSMesa drier swfbdev/- software fbdev driver radeon/ - DRI/fbdev driver radeon-es/ - subset radeon fbdev driver r200/ ... mga/- DRI/fbdev driver windows/ beos/ ggi/ glide/ - was FX driver dos/ One thing that is a bit confusing is that some drivers are just drivers, wheras others are combinations of drivers and window system interfaces. It would be nice to have just drivers here and move the various window system binding codes to another directory. This way you'd get to see a lot of similarity between the framebuffer-type drivers and it might be possible to abstract them down to not much, using either templates from common/ or a new module like the one Phil proposed. So, anyway, the new proposal would be something like libGL/ X11 - standalone X11 libGL miniglx - standalone fbdev window system dri - libGL that understands XFree86 DRI amiga - dos - etc. In most cases you'd want to still compile the driver into the libGL object st
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Alex Deucher wrote: I've been thinking of trying to implement an XV adapter using OpenGL and MESA_ycbcr_texture for YUV or regular RGB textures for RGB video. This would not only provide a default Xv adapter (in the event that the hw didn't have one) or it would provide hw accelerated video playback on hw that supports the appropriate OGL extensions. You would also not be limited to a single window like most hardware that only provides a single overlay. I mentioned this a while back, but I hadn't had much time to think about it. I'm new to openGL so I'm still trying to figure out what all would be involved. From what I've read traditional openGL textures have to be a power of 2 and be RGB. MESA_ycbcr_texture seems to handle the YUV colorspace, and it perhaps NV_texture_rectangle allows you to get around the power of 2 issue. Am I even on the right track here? Absolutely. It would be written as an xfree86 modules like "v4l." The module would then accept data from Xv clients but rather than writing the data to the overlay hardware, it would act like an openGL client and write the data to the screen using an RGB or YUV texture. The question is, can an xfree86 module be an opengl/DRI client? Hmm - maybe... You'll probably run into some issues with the locking mechanism used by the DRI drivers - the X server currently holds the lock all the time it is active, so you'd have to release the lock before calling into any GL functions, which is loosing some of the cleanness you get by using GL. Unfortunately, i'm more familiar with the 2D aspects of xfree86. I'm still learning about opengl programming and the 3D side of the hardware. I need to decide how to best map the Xv functions to their OGL implementation. An comments on the feasibility of this or how I would best proceed are welcome. The GLX_NV_vertex_array_range allows GL clients to be allocated actual AGP memory, which will speed up texture uploads in the R200 driver if you do *everything* right. Note - this is only r200 at this stage. Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [PATCH] A bunch of libGL.so optimizations
I haven't released 5.1 (devel release) yet so 5.2 (stable release) won't be coming for a while. 5.1 is in pretty good shape though. I'm trying to decide if I should do the directory re-org before or after the 5.1 release. Thoughts? I don't see any reason to delay... Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Endless loop in radeon_do_wait_for_idle()
Linus Torvalds wrote: On Fri, 30 May 2003, Linus Torvalds wrote: Modulo that, X is happy, with no error messages apart from a mention of the irq issue in the logs up until the lockup: (II) RADEON(0): [drm] failure adding irq handler, there is a device already using that irq [drm] falling back to irq-free operation (II) RADEON(0): [drm] Initialized kernel agp heap manager, 5111808 (II) RADEON(0): Direct rendering enabled Forcing fifo debugging makes the thing print out an endless loop of [drm:radeon_do_wait_for_idle] *ERROR* failed! radeon_status: RBBM_STATUS = 0x80010140 CP_RB_RTPR = 0x9b6f CP_RB_WTPR = 0x9b6f AIC_CNTL = 0x AIC_STAT = 0x0004 AIC_PT_BASE = 0x TLB_ADDR = 0x TLB_DATA = 0x which doesn't tell me anything, but maybe somebody with docs can tell why it claims to be busy. The ring buffer read and write pointers change every printout (increment by 6), but the read pointer is always the same as the write pointer. Reading the header files, RBBM_STATUS seems to say that there are 64 entries in the FIFO, and that the FIFO is busy. Which doesn't make much sense to me. Anything useful I can do to debug this? The results I get if I have radeon_do_wait_for_idle() show this info unconditionally are pretty similar: Jun 2 14:53:24 test9 kernel: radeon_status: Jun 2 14:53:24 test9 kernel: RBBM_STATUS = 0x0140 Jun 2 14:53:24 test9 kernel: CP_RB_RTPR = 0x020d Jun 2 14:53:24 test9 kernel: CP_RB_WTPR = 0x020d Jun 2 14:53:24 test9 kernel: AIC_CNTL = 0x Jun 2 14:53:24 test9 kernel: AIC_STAT = 0x0004 Jun 2 14:53:24 test9 kernel: AIC_PT_BASE = 0x Jun 2 14:53:24 test9 kernel: TLB_ADDR = 0x Jun 2 14:53:24 test9 kernel: TLB_DATA = 0x Just the two bits in RBBM_STATUS different. Bit 31 is a general busy flag, while bit 16 is saying that the command processor (CP) is busy. I take this as meaning that it thinks there are commands on the ring not yet fully processed - which doesn't make sense. Under what circumstances does this actually happen? First 3d app run? Even something like 'glinfo'? Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Endless loop in radeon_do_wait_for_idle()
Linus Torvalds wrote: Have others seen this? Current DRI CVS tree, current 2.5.x kernel (which is pretty current kernel-module-wise, the only difference to the current DRI tree _seems_ to be the documentation updates). Same thing happens with an older DRI CVS tree too (with new kernel modules), for that matter. It's not really an endless loop, since radeon_do_wait_for_idle() will return eventually, but the callers will just call it again on failure. It works on another Radeon box I have access to, and one difference is that the failing box does not have access to interrupts for the video card: ... Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected an Intel 440GX Chipset. agpgart: Maximum main memory to use for agp memory: 816M agpgart: AGP aperture is 256M @ 0xe000 [drm] Initialized radeon 1.8.0 20020828 on minor 0 ... agpgart: Found an AGP 1.0 compliant device at 00:00.0. agpgart: Putting AGP V2 device at 00:00.0 into 1x mode agpgart: Putting AGP V2 device at 01:00.0 into 1x mode PCI: No IRQ known for interrupt pin A of device 01:00.0. Probably buggy MP table. This same machine _used_ to work fine last time I tested it, but that's a month or two ago. I've tried with current DRI trunk on 2.4, rigging up the 2d driver to fail the irq test, and that seems to work OK with limited testing. Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [PATCH] A bunch of libGL.so optimizations
Nicholas Wourms wrote: Keith Whitwell wrote: [SNIP] Boy, this looks interesting. Unfortunately I'm about to leave on a week's holidays so I won't be able to properly read the patch or comment until I get back. I'm broadly in favour of applying this but would love to participate in the discussions that will surround it first... I guess I'll have to read all about it when I get back... Keith, Have you had a chance to look at this patch? There doesn't seem to be much discussion on this list regarding it, so I thought I might try to jumpstart it again. The patch does have a few issues. Firstly it doesn't apply cleanly to the current trunk so there'll be a bit of work wiggling it in. Secondly, it makes some major changes in files marked "/* DO NOT EDIT - This file generated automatically with glx86asm.py script */" -- the change will have to be moved to the generating script. Thirdly, and this isn't really the patch's problem, it raises for me again the question: Wouldn't we be better off using straight gnu assembler syntax, rather than the somewhat tortured macros in there currently? Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [PATCH] A bunch of libGL.so optimizations
Nicholas Wourms wrote: Keith Whitwell wrote: [SNIP] Boy, this looks interesting. Unfortunately I'm about to leave on a week's holidays so I won't be able to properly read the patch or comment until I get back. I'm broadly in favour of applying this but would love to participate in the discussions that will surround it first... I guess I'll have to read all about it when I get back... Keith, Have you had a chance to look at this patch? There doesn't seem to be much discussion on this list regarding it, so I thought I might try to jumpstart it again. I looked through it a couple of days ago. I'm pretty much in favour of it, though I don't yet understand all aspects of its behaviour, particularly the runtime fixup of the entrypoints. Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
