Re: [r300] r420 related changes
Vladimir Dergachev wrote: 3) I can enable more pipes for r420 cards, but am unable to test it on 420 cards with fewer pipes. Do I just add this and wait for someone to complain? A better way would be to read carefully specs of R4xx cards on ATI website to find out how many actual pipes are available :) This page is more helpful: http://www.rojakpot.com/default.aspx?location=3var1=88var2=0 pipes value My card16(7 1) max R3008(3 1) Why do you the value is 7 ? According to my docs the number of pipes is a magic value that should be architecture dependent. Of course, my documentation is for R300 2d only.. I would expect that there is no easy formula. The 7 came from fglrx using radeon_dump. By the way R420 is very sensitive to register reads of some registers. If the value should be architecture dependent it should be safe to use the value 7 on all R420 no matter the number of pipes. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] R300 DRM unfrozen
Vladimir Dergachev wrote: The old initialization looks like yours, just with the radeon version being 1.12.1 20041216 This would imply that, somehow, you are loading old radeon code. Which command are you using to load it ? Well, I ran make in the linux-core directory, and than copied drm.ko and radeon.ko to /lib/modules.../char/drm. This time I even did a reboot afterwards, to check that everything will work. After the reboot I ran `modprobe radeon`. Try using insmod with explicit path specification - this is what I do. You must have leftover radeon.ko someplace. It seems I did have some leftovers. The new code seems to lock up. I attached the end of the log from tuxracer. best Vladimir Dergachev Boris Peterbarg best Vladimir Dergachev Boris Peterbarg --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel log.gz Description: GNU Zip compressed data
Re: dri span patches...
Roland Scheidegger wrote: here's a patch which mainly does 3 things: - convert sis, mach64, and radeon to spantmp2. The sis and mach64 drivers got a slight change, previously you could not read back alpha values (always 0xff) and I don't think there was a good reason for that? IIRC, the mach64 doesn't support destination alpha planes. OpenGL requires that reads of absent alpha planes returns 1.0. I don't know if the SiS chip is the same. The 3 intel drivers and the s3v are not converted due to their support of a RGB555 format spantmp2 can't handle (actually, the i810 does not support the 555 format in its span functions, the driver elsewhere has support for it, this probably can't be right). tdfx and ffb are not converted since they support a 888 format. gamma is not converted since it performs some unusual always-round-up tricks when using RGB565 format. trident is not converted since it doesn't support span functions yet at all :-). - remove HW_CLIPLOOP, HW_ENDCLIPLOOP, CLIPPIXEL and CLIPSPAN macros out of the drivers whenever possible, since they are almost always identical. ffb uses very different macros, and some drivers do not use the driDrawable struct for HW_CLIPLOOP (which btw is interesting, I'm not quite sure why some drivers need to handle that differently, I didn't look too much into it but the difference is due to the handling of front and back buffers somehow), so they keep their own definitions hopefully. There are probably more macro definitions which could be factored out. - change CLIPSPAN to never return negative number of pixels (only change that once! not a dozen times, which is why I've done that macro definition removal in the first place...). Does this look sane? Driver source code should get quite a bit smaller overall. As long as you're looking at the span functions I should tell you that at some point in the future, work on the GL_EXT_framebuffer_object extension will likely require some changes in this area. I'll elaborate on that in another email when I have things better sorted out. I'm doing initial implementation with the xlib renderer now. But one thing that seems to be wrong in the r200 driver (for example) (and probably all the other DRI drivers) is the fact that the r200SetBuffer() function ignores its colorBuffer parameter. As it is now, the function ignores that parameter and always assumes that the span functions are going to be reading/writing to the context's current drawing buffer. The glXMakeContextCurrent and glXMakeCurrentReadSGI functions specify separate 'read' and 'draw' drawables. This allows you to do a glCopyPixels from one window to another, for example. This won't work if the colorBuffer parameter of r200SetBuffer() is ignored. In general, the span functions are relying too much on the GLcontext state, and not enough on the GLframebuffer state. The pointer to the start of the color/depth/stencil buffer, its width, height, pitch, etc. should be obtained via the GLframebuffer passed to r200SetBuffer. To do that, I guess GLframebuffer would need to have a pointer back to the corresponding __DRIDrawablePrivate, since we have no way to contain one in the other. Anyway, I wouldn't change anything right now. Let's wait until the GL_EXT_framebuffer_objects stuff has firmed up. -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r420 related changes
On Thu, 3 Mar 2005, Rune Petersen wrote: With the latest changes to drm in r300_driver I was reminded of a few problems with R420 cards and the r300 driver. 1) the Xorg driver defaults to R200 for R420 cards. RADEONDRIKernelInit() in radeon_dri.c Could you test that your patch works with regular freedesktop.org DRM driver as far as 2d is concerned ? It should print a message in the log that DRI is enabled, though, of course, you would not be able to use R300 Mesa driver. 2) RADEONInitDispBandwidth() is disabled for r420 cards. I have no problem enabling this. are there a reason for this? Well, the reason is that we don't have documentation for R4xx cards to update it - the latest ATI ever released to us is R3xx docs. As you can see there are a lot of arrays tabulating magic values - these can only be obtained from designers of the hardware, or, perhaps, with some diagnostics equipment. There are also special cases for R300 cards and we do not know what they should be for your card. However, if you do need it enabled, we could change the code flow and put a comment warning that this does not come from documentation. This would also need to be discussed on X.org devel list before committing, maybe Hue or Michel or someone else will contribute actual code for R4xx cards. 3) I can enable more pipes for r420 cards, but am unable to test it on 420 cards with fewer pipes. Do I just add this and wait for someone to complain? A better way would be to read carefully specs of R4xx cards on ATI website to find out how many actual pipes are available :) Regarding Xorg are there an easy way to make a diff without needing a duplicate tree? And where should I send the Xorg patches? If you are working from X.org CVS (as anonymous) and you are modifying files inside the tree you can use the following command to obtain the patch: cvs -z3 diff -u E-mail the patch to me - the reason that R4xx cards are not enabled there is that I was not certain whether R3xx microcode would work for them. best Vladimir Dergachev Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
no scatter/gather memory ?
Hi, I upgraded drm (non core) to current cvs (previous one was from 2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting the module I get : [drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory! [drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART! That's really strange, since the gart is the same (it's built into the kernel, 2.4.18 from RHAS 2.1) and the old (2004-07-15) drm module inserts into this exact same kernel without any issues. Anyone has a clue why this happens (or where I should look) ? Stephane --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] texture breakage
Vladimir Dergachev writes: You can just run gdb on the problem. I have seen these segfaults before - they appear to be due to the fact that despite the name we do not implement vertex buffer extension properly.. It turns out bzflag doesn't always segfault, only if I try to turn the Blending option off in the Display settings menu. The segfault is due to doing a procedure call to a NULL function pointer at line 279 of Mesa/src/mesa/tnl/t_vb_render.c in the run_render() function: tnl-Driver.Render.Start( ctx ); i.e. it seems that tnl-Driver.Render.Start is NULL. I notice that r200_swtcl.c does this in radeonFallback(): tnl-Driver.Render.Start = r200RenderStart; Is that statement what should be being executed to initialize tnl-Driver.Render.Start? Or does that only apply for r200, not r300? Paul. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri span patches...
On Thu, Mar 03, 2005 at 06:49:26PM +0100, Roland Scheidegger wrote: Ville Syrjälä wrote: On Thu, Mar 03, 2005 at 05:45:15PM +0100, Roland Scheidegger wrote: Brian Paul wrote: Roland Scheidegger wrote: here's a patch which mainly does 3 things: - convert sis, mach64, and radeon to spantmp2. The sis and mach64 drivers got a slight change, previously you could not read back alpha values (always 0xff) and I don't think there was a good reason for that? IIRC, the mach64 doesn't support destination alpha planes. OpenGL requires that reads of absent alpha planes returns 1.0. I don't know if the SiS chip is the same. Are you sure? At least the driver handles things like GL_DST_ALPHA blend factors, wouldn't you get awfully bogus results if it wouldn't support destination alpha planes in that case? Like I said before only the RGB components are blended. You can choose to write 0, 1, As, 1-As, Ad or 1-Ad to the destination alpha ([EMAIL PROTECTED] register). Currently the driver seems to write 0. It would probably be a better idea to write 1 instead. Sorry, but I just can't see that in the driver. And there's no ALPHA_DST_SEL bit, at least not in the mach64 reg file I have... I was just looking at the specs :) They are named MACH64_ALPHA_DST_* in mach64_reg.h. The driver doesn't explicitly specify any value which means 0 gets written. I actually just stumbled on this issue a few days ago with the mach64 DirectFB driver. My plan for the DirectFB driver is simply to allow ZERO + ZERO/ONE/SRCALPHASAT blend functions for destinations with alpha. It's a rather serious limitation but I think it's better than incorrect rendering. The issue is even worse on older Rage chips since they can only write 0 to the destination alpha. But that is not an issue for the DRI driver since those chips aren't supported. Regardless if it can actually blend alpha values or not, there would be some half-way useful alpha values probably in the buffer. Either you get the correct results or the wrong results. Not sure if there are any really useful things you can do with incorrect values. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] q3demo = _no_ artifacts
Hi, I gave q3demo a try and to my surprise there was no artifacts. This must have been fixed by one of the many changes. Does this only work for me? Or is it time to update the status page? Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] q3demo = _no_ artifacts
Rune Petersen wrote: Hi, I gave q3demo a try and to my surprise there was no artifacts. This must have been fixed by one of the many changes. Does this only work for me? Or is it time to update the status page? I can't actually run q3 anymore to test it (no ioctl32), but I no longer get artifacts in ut2004-demo. I believe that it was elts being implemented which corrected this, but I could be wrong. Cheers, Ben Skeggs. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] texture breakage
Vladimir Dergachev writes: The new call is an attempt to get multitexturing working, at least partly. Does your program use multitexturing ? (Also where can I download it for testing ? ) Thank you ! The screenshots I posted were from Emilia pinball from the Debian pinball package. The source is at pinball.sourceforge.net, I believe. But bzflag, tuxracer and chromium also displayed textures wrongly. I don't know whether those programs use multitexturing. Paul. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
Oh, but I was not suggesting that. I just meant that interrupt handling code is self-contained and can easily serve several consumers. I'm with you here. And the same should IMHO hold for DMA handling. And for memory management of course. DMA handling is the main piece of what the DRM does, memory management is the missing part. No, what we really need is just what we said: merging fbdev DRM and adding memory management. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri span patches...
Dieter Nützel wrote: Am Donnerstag, 3. März 2005 4:48 schrieb Roland Scheidegger: Roland Scheidegger wrote: here's a patch which mainly does 3 things: - convert sis, mach64, and radeon to spantmp2. The sis and mach64 drivers got a slight change, previously you could not read back alpha values (always 0xff) and I don't think there was a good reason for that? Roland, do you had a look on Felix's spantmp2.diff, too. http://marc.theaimsgroup.com/?l=dri-develm=110600974029291w=2 I have missed that completely. Should be possible to work together with this patch just fine, though patch might disagree. BTW Can you please send me a private copy of dri-span3.diff, again. There are many ugly =3D characters in the archived version. You'll even get a newer version, Alan pointed out some subtle issues with the macro expansion (one of the reasons I don't particularly like macros...). Instead of fixing all GET_SRC/DST_PTR macros, I got rid of them too, since they were identical again in all drivers which use spantmp2 (except unichrome which uses different pitches for reading and drawing, it keeps its macros). Roland Index: common/depthtmp.h === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/depthtmp.h,v retrieving revision 1.7 diff -u -r1.7 depthtmp.h --- common/depthtmp.h 14 Feb 2005 09:27:38 - 1.7 +++ common/depthtmp.h 3 Mar 2005 19:25:50 - @@ -1,24 +1,19 @@ /* $XFree86: xc/lib/GL/mesa/src/drv/common/depthtmp.h,v 1.5 2001/03/21 16:14:20 dawes Exp $ */ +#include spantmp_common.h + #ifndef DBG #define DBG 0 #endif - #ifndef HAVE_HW_DEPTH_SPANS #define HAVE_HW_DEPTH_SPANS 0 #endif + #ifndef HAVE_HW_DEPTH_PIXELS #define HAVE_HW_DEPTH_PIXELS 0 #endif -#ifndef HW_READ_LOCK -#define HW_READ_LOCK() HW_LOCK() -#endif -#ifndef HW_READ_UNLOCK -#define HW_READ_UNLOCK() HW_UNLOCK() -#endif - static void TAG(WriteDepthSpan)( GLcontext *ctx, GLuint n, GLint x, GLint y, const GLdepth *depth, Index: common/spantmp.h === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/spantmp.h,v retrieving revision 1.5 diff -u -r1.5 spantmp.h --- common/spantmp.h14 Feb 2005 09:27:38 - 1.5 +++ common/spantmp.h3 Mar 2005 19:25:50 - @@ -27,26 +27,12 @@ *Gareth Hughes [EMAIL PROTECTED] */ +#include spantmp_common.h + #ifndef DBG #define DBG 0 #endif -#ifndef HW_WRITE_LOCK -#define HW_WRITE_LOCK()HW_LOCK() -#endif - -#ifndef HW_WRITE_UNLOCK -#define HW_WRITE_UNLOCK() HW_UNLOCK() -#endif - -#ifndef HW_READ_LOCK -#define HW_READ_LOCK() HW_LOCK() -#endif - -#ifndef HW_READ_UNLOCK -#define HW_READ_UNLOCK() HW_UNLOCK() -#endif - #ifndef HW_READ_CLIPLOOP #define HW_READ_CLIPLOOP() HW_CLIPLOOP() #endif Index: common/spantmp2.h === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/spantmp2.h,v retrieving revision 1.6 diff -u -r1.6 spantmp2.h --- common/spantmp2.h 15 Jan 2005 14:35:35 - 1.6 +++ common/spantmp2.h 3 Mar 2005 19:25:51 - @@ -34,27 +34,12 @@ */ #include colormac.h +#include spantmp_common.h #ifndef DBG #define DBG 0 #endif -#ifndef HW_WRITE_LOCK -#define HW_WRITE_LOCK()HW_LOCK() -#endif - -#ifndef HW_WRITE_UNLOCK -#define HW_WRITE_UNLOCK() HW_UNLOCK() -#endif - -#ifndef HW_READ_LOCK -#define HW_READ_LOCK() HW_LOCK() -#endif - -#ifndef HW_READ_UNLOCK -#define HW_READ_UNLOCK() HW_UNLOCK() -#endif - #ifndef HW_READ_CLIPLOOP #define HW_READ_CLIPLOOP() HW_CLIPLOOP() #endif @@ -65,6 +50,14 @@ #if (SPANTMP_PIXEL_FMT == GL_RGB) (SPANTMP_PIXEL_TYPE == GL_UNSIGNED_SHORT_5_6_5) +#ifndef GET_SRC_PTR +#define GET_SRC_PTR(_x, _y) (read_buf + (_x) * 2 + (_y) * pitch) +#endif + +#ifndef GET_DST_PTR +#define GET_DST_PTR(_x, _y) ( buf + (_x) * 2 + (_y) * pitch) +#endif + #define INIT_MONO_PIXEL(p, color) \ p = PACK_COLOR_565( color[0], color[1], color[2] ) @@ -92,6 +85,14 @@ #elif (SPANTMP_PIXEL_FMT == GL_BGRA) (SPANTMP_PIXEL_TYPE == GL_UNSIGNED_INT_8_8_8_8_REV) +#ifndef GET_SRC_PTR +#define GET_SRC_PTR(_x, _y) (read_buf + (_x) * 4 + (_y) * pitch) +#endif + +#ifndef GET_DST_PTR +#define GET_DST_PTR(_x, _y) ( buf + (_x) * 4 + (_y) * pitch) +#endif + # define INIT_MONO_PIXEL(p, color) \ p = PACK_COLOR_(color[3], color[0], color[1], color[2]) Index: common/stenciltmp.h === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/common/stenciltmp.h,v retrieving revision 1.4 diff -u -r1.4 stenciltmp.h --- common/stenciltmp.h 14 Feb 2005 09:27:38 - 1.4 +++ common/stenciltmp.h 3 Mar 2005 19:25:51 - @@ -1,23 +1,11 @@ /* $XFree86: xc/lib/GL/mesa/src/drv/common/stenciltmp.h,v 1.3
changes for GL_EXT_framebuffer_object
This extension can't be easily/cleanly added to Mesa without rewriting and changing some existing code. But ultimately, the changes will be for the better, much in the way that GL_NV/ARB_vertex_program improved the TNL code. I'll assume people are familiar with GL_EXT_framebuffer_object. If not, read the spec. The new code will be C object-oriented so I'll use OOP terms here. The basic idea is to merge the GLframebuffer class (in mtypes.h) with the new gl_framebuffer class (in fbobject.h). The stencil, depth, accum, aux, etc. buffer pointers in GLframebuffer will go away, replaced by gl_renderbuffer_attachment members. Each of the logical buffers (such as color, depth, stencil, etc) which form the overall framebuffer will be represented by a gl_renderbuffer object (see fbojbect.h). These renderbuffers can either be allocated/managed by the device driver, or by core Mesa as a software fallback. Device drivers will have the opportunity to derive device-specific classes from the gl_renderbuffer and gl_framebuffer classes. They're allocated with the ctx-Driver.NewRenderbuffer() and ctx-Driver.NewFramebuffer() functions. Each of these classes have their own Delete member functions. The gl_framebuffer class will be used both for user-allocated framebuffers (made via glBindFramebufferEXT) and for the window-system framebuffers that correspond to GLX windows. gl_renderbuffer objects have an AllocateStorage() method that's used for allocating storage for the buffer's depth/color/stencil/etc. In the case of DRI drivers, this would be a no-op for the statically allocated window buffers, but would allocate VRAM for user-allocated renderbuffers. There's also a Delete() method. The gl_renderbuffer's GetPointer(), GetRow(), GetValues(), PutRow(), and PutValues() methods will used by the software fallback routines to access the pixels in a buffer. This will replace the current swrast span read/write routines. Note that there's no distinction between color, depth or stencil in these routines. The gl_renderbuffer's BaseFormat and DataType will implicitly specify which kind of pixel data is being accessed. Also, a gl_renderbuffer object can be used as a wrapper for texture images. This will allow render-to-texture functionality. A yet-to-be-written routine will be called to set up the wrapper when the user wants render-to-texture. If the device supports rendering into texture memory, the wrapper will describe how to do that. Otherwise, a software-fallback wrapper would be used. All this means that core Mesa can treat windows, off-screen pbuffers and texture images in a unified manner. I'll continue to plug away on this stuff in my spare time. -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R200]Problems with HW TCL in Tuxracer and PPRacer
Michel Dnzer wrote: On Thu, 2005-03-03 at 20:22 +0100, Roland Scheidegger wrote: Michel Dnzer wrote: On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote: When using HW TCL in Tuxracer or PPRacer (that is essentially the same game) with my Radeon 8500 with DRI drivers dated 25 february 2005 you can see that there are problems with light reflection in those places where there's ice (for example in the first stage that is full of ice pools ) . You mean the flickering? That's probably Z fighting, most likely a problem in the game itself. You should bring this up with the PPRacer project, now that there's active development there... No, this is a result of the tcl fallback used for the GL_SPHERE_MAP texgen (it is z fighting I guess). Sure, but Brian told me the application has to be prepared for and deal with this. Really? Interesting. What does it have to do? I never really understood what exactly caused the z-fighting issues with the fallbacks. Roland --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] texture breakage
On Fri, 4 Mar 2005, Paul Mackerras wrote: Vladimir Dergachev writes: Does everything work with vb mode ? (you can switch to it in the end of r300_driver/r300/r300_render.c, search for #else) Most things seem to work, except bzflag segfaults. I could try to track down where tonight if that would help. You can just run gdb on the problem. I have seen these segfaults before - they appear to be due to the fact that despite the name we do not implement vertex buffer extension properly.. best Vladimir Dergachev Paul. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] 9800 support?
Adam K Kirchhoff wrote: Any idea why the PCI IDs for the radeon 9800 were removed from the DRM? AFIK most/all IDs added were lost when the DRM was updated. No special reason. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r420 related changes
Could you test that your patch works with regular freedesktop.org DRM driver as far as 2d is concerned ? It should print a message in the log that DRI is enabled, though, of course, you would not be able to use R300 Mesa driver. I gave it a try, no problem. patch: r420_drm-microcode-fix.patch I am committing it now.. Should show up before tomorrow morning. (I am using nfs over ipsec over wireless, it is very slow, but that's where my tree is) 3) I can enable more pipes for r420 cards, but am unable to test it on 420 cards with fewer pipes. Do I just add this and wait for someone to complain? A better way would be to read carefully specs of R4xx cards on ATI website to find out how many actual pipes are available :) This page is more helpful: http://www.rojakpot.com/default.aspx?location=3var1=88var2=0 pipes value My card16(7 1) max R3008(3 1) Why do you the value is 7 ? According to my docs the number of pipes is a magic value that should be architecture dependent. Of course, my documentation is for R300 2d only.. I would expect that there is no easy formula. best Vladimir Dergachev If we ignore RV350: My guess would be that the value is equal to num_pipes/2 - 1. Another guess would be that it is safe to set the value to the max possible numbers of pipes for each card type: value R420 (7 1) R300 (3 1) cvs -z3 diff -u E-mail the patch to me - the reason that R4xx cards are not enabled there is that I was not certain whether R3xx microcode would work for them. Thank you Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no scatter/gather memory ?
Stephane Marchesin wrote: Hi, I upgraded drm (non core) to current cvs (previous one was from 2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting the module I get : [drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory! [drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART! Ok, it looks like drm cvs (core and non core) has been broken on ia64 since august. Patch attached. Stephane Index: linux/drm_bufs.h === RCS file: /cvs/dri/drm/linux/drm_bufs.h,v retrieving revision 1.45 diff -u -r1.45 drm_bufs.h --- linux/drm_bufs.h16 Jan 2005 05:40:12 - 1.45 +++ linux/drm_bufs.h4 Mar 2005 14:10:26 - @@ -74,7 +74,7 @@ if ( (offset (~PAGE_MASK)) || (size (~PAGE_MASK)) ) return -EINVAL; -#if !defined(__sparc__) !defined(__alpha__) +#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__) if ( offset + size offset || offset virt_to_phys(high_memory) ) return -EINVAL; #endif Index: linux-core/drm_bufs.c === RCS file: /cvs/dri/drm/linux-core/drm_bufs.c,v retrieving revision 1.54 diff -u -r1.54 drm_bufs.c --- linux-core/drm_bufs.c 5 Feb 2005 08:00:14 - 1.54 +++ linux-core/drm_bufs.c 4 Mar 2005 14:10:27 - @@ -63,7 +63,7 @@ if ((offset (~PAGE_MASK)) || (size (~PAGE_MASK))) return -EINVAL; -#if !defined(__sparc__) !defined(__alpha__) +#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__) if (offset + size offset || offset virt_to_phys(high_memory)) return -EINVAL; #endif
Re: [r300] q3demo = _no_ artifacts
On Sat, 5 Mar 2005, Ben Skeggs wrote: Rune Petersen wrote: Hi, I gave q3demo a try and to my surprise there was no artifacts. This must have been fixed by one of the many changes. Does this only work for me? Or is it time to update the status page? I can't actually run q3 anymore to test it (no ioctl32), but I no longer get artifacts in ut2004-demo. I believe that it was elts being implemented which corrected this, but I could be wrong. The rendering quality had indeed improved. I still get artifacts in quake3, also the menu does not have flaming Quake string on top. However, q3demo appears to be simpler than quake3 and the particular levels easier on the renderer. For example the same dock level displays fine in both q3demo and quake3, but nearby levels often give me white walls artifact, with textures appearing and disappearing on them depending on distance and angle of view. I also see dithering see-through objects while they should be opaque (like the pedestal) Also I believe we are still not doing correct things in many cases, especially as pixel shaders are concerned (no Gourad, multitexturing messed up). best Vladimir Dergachev Cheers, Ben Skeggs. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] q3demo = _no_ artifacts
Also I believe we are still not doing correct things in many cases, especially as pixel shaders are concerned (no Gourad, multitexturing messed up). I believe I now have a good understanding of how to implement multitexturing properly, I could be wrong. But I'll find out very shortly. I'm working on some code now that I hope will make (at least) the mesa multiarb demo render correctly. Also, Is there anybody working on figuring out the missing texture formats? The problems with the texenv demo aren't only caused by incorrect texenv's, but most of the used texture formats are missing. I believe we have all the information about texture formats we need in r300_reg.h. I did not put the strings for other texture formats because I did not have anything to test them with and be sure of the result. It is easier to get the format right when you are adding it (and know which entry you are messing is), rather than add it blindly and then find out that a couple of components are in the wrong order. best Vladimir Dergachev Cheers, Ben Skeggs. best Vladimir Dergachev Cheers, Ben Skeggs. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] Neverputt Neverball changes...
FYI, something has happened to the driver in the past week :-) http://68.44.156.246/neverputt.png --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] q3demo = _no_ artifacts
Vladimir Dergachev wrote: Also I believe we are still not doing correct things in many cases, especially as pixel shaders are concerned (no Gourad, multitexturing messed up). I believe I now have a good understanding of how to implement multitexturing properly, I could be wrong. But I'll find out very shortly. I'm working on some code now that I hope will make (at least) the mesa multiarb demo render correctly. Also, Is there anybody working on figuring out the missing texture formats? The problems with the texenv demo aren't only caused by incorrect texenv's, but most of the used texture formats are missing. I believe we have all the information about texture formats we need in r300_reg.h. I did not put the strings for other texture formats because I did not have anything to test them with and be sure of the result. It is easier to get the format right when you are adding it (and know which entry you are messing is), rather than add it blindly and then find out that a couple of components are in the wrong order. I'm not entirely sure of how to correctly define the texture formats. While I was messing with texenv's I made texenv.c printf what format it was using, and changed the WARN_ONCE into a printf to find out all the missing formats. I ended up adding something for entry 15, which corresponded to when texenv.c was using GL_ALPHA. I added R300_EASY_TX_FORMAT(W, X, X, X, ALPHA_1CH) to get the result to *look* correct, but I don't know if it *is* correct. Ben Skeggs. best Vladimir Dergachev Cheers, Ben Skeggs. best Vladimir Dergachev Cheers, Ben Skeggs. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r420 related changes
Vladimir Dergachev wrote: Why do you the value is 7 ? According to my docs the number of pipes is a magic value that should be architecture dependent. Of course, my documentation is for R300 2d only.. I would expect that there is no easy formula. The 7 came from fglrx using radeon_dump. Ahh ! In this case it should be safe to use. What was the entire value written in the register ? no it's 0x1f. I'll add to the CVS. By the way R420 is very sensitive to register reads of some registers. For many registers the chip must be idle before the read. If the value should be architecture dependent it should be safe to use the value 7 on all R420 no matter the number of pipes. Well, I would assume that the number of pipes is the same on all R420. Otherwise we might have problems. pipes are not the same on all R420 the same can be said for R300, R350 I think I make the change and then see if I can can get some others to confirm this with other R420 cards (forums). Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 lockups...
Nicolai Haehnle wrote: On Tuesday 22 February 2005 21:57, Adam K Kirchhoff wrote: No luck. I setup my xorg.conf file to limit X to 640x480, and used xrandr to drop the refresh rate to 60... Launched neverputt at 640x480, fullscreen. Lockup was nearly instantaneous... The music continues, at least till neverputt dies, and the mouse moves around. Rebooted and tried again... Exact same result. At least when I was running it at 1024x768 on a mergedfb desktop of 2560x1024, I was able to play a hole or two of golf... Two times now, I've tried running it at 640x480 on my large mergedfb desktop. I get further than I did when the screen resolution was 640x480, but not much. I just tried two times now running it at 1280x1024 on my large mergedfb desktop, and it plays fine for a number of holes. Usually locks up between holes. My conclusion is that these lockups are occuring when the framerate is at it's highest (ie. low resolution, low texture, low activity), which I believe is a situation someone else described on here not to long ago. That was me, so I can confirm that, and it *is* different from the problem reported by John Clemens in the other thread (the one called [r300] Radeon 9600se mostly working). Unfortunately, I won't have access to my test setup for the next weeks, so I don't have anything new. cu, Nicolai Nicolai, Since we seem to be the only ones experiencing this problem (or the only ones talking about it) let me know if there's anything I can do to help resovle it. My device driver programming skills are certainly lacking, but I can (and will) test just about anything, and know how to add debugging statements if pointed in the right direction :-) Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] texture breakage
On Fri, 4 Mar 2005, Paul Mackerras wrote: Vladimir Dergachev writes: You can just run gdb on the problem. I have seen these segfaults before - they appear to be due to the fact that despite the name we do not implement vertex buffer extension properly.. It turns out bzflag doesn't always segfault, only if I try to turn the Blending option off in the Display settings menu. The segfault is due to doing a procedure call to a NULL function pointer at line 279 of Mesa/src/mesa/tnl/t_vb_render.c in the run_render() function: tnl-Driver.Render.Start( ctx ); i.e. it seems that tnl-Driver.Render.Start is NULL. I notice that r200_swtcl.c does this in radeonFallback(): tnl-Driver.Render.Start = r200RenderStart; Is that statement what should be being executed to initialize tnl-Driver.Render.Start? Or does that only apply for r200, not r300? We should probably have analogous code for r300. best Vladimir Dergachev Paul. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r420 related changes
Why do you the value is 7 ? According to my docs the number of pipes is a magic value that should be architecture dependent. Of course, my documentation is for R300 2d only.. I would expect that there is no easy formula. The 7 came from fglrx using radeon_dump. Ahh ! In this case it should be safe to use. What was the entire value written in the register ? By the way R420 is very sensitive to register reads of some registers. For many registers the chip must be idle before the read. If the value should be architecture dependent it should be safe to use the value 7 on all R420 no matter the number of pipes. Well, I would assume that the number of pipes is the same on all R420. Otherwise we might have problems. best Vladimir Dergachev Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] texture breakage
On Thu, 3 Mar 2005, Paul Mackerras wrote:
Jerome Glisse writes:
If you find the guilty commit let me know :)
It appears to be this code in r300_state.c (line 1625):
#if 0
/* textures enabled ? */
if(rmesa-state.texture.tc_count0){
rmesa-state.vertex_shader=SINGLE_TEXTURE_VERTEX_SHADER;
} else {
rmesa-state.vertex_shader=FLAT_COLOR_VERTEX_SHADER;
}
#endif
r300GenerateSimpleVertexShader(rmesa);
If I remove the r300GenerateSimpleVertexShader call and change the #if
0 to 1, it works again (well, as well as it did before :).
The new call is an attempt to get multitexturing working, at least partly.
Does your program use multitexturing ? (Also where can I download it for
testing ? ) Thank you !
best
Vladimir Dergachev
Paul.
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] q3demo = _no_ artifacts
Vladimir Dergachev wrote: On Sat, 5 Mar 2005, Ben Skeggs wrote: Rune Petersen wrote: Hi, I gave q3demo a try and to my surprise there was no artifacts. This must have been fixed by one of the many changes. Does this only work for me? Or is it time to update the status page? I can't actually run q3 anymore to test it (no ioctl32), but I no longer get artifacts in ut2004-demo. I believe that it was elts being implemented which corrected this, but I could be wrong. The rendering quality had indeed improved. I still get artifacts in quake3, also the menu does not have flaming Quake string on top. However, q3demo appears to be simpler than quake3 and the particular levels easier on the renderer. For example the same dock level displays fine in both q3demo and quake3, but nearby levels often give me white walls artifact, with textures appearing and disappearing on them depending on distance and angle of view. I also see dithering see-through objects while they should be opaque (like the pedestal) Also I believe we are still not doing correct things in many cases, especially as pixel shaders are concerned (no Gourad, multitexturing messed up). I believe I now have a good understanding of how to implement multitexturing properly, I could be wrong. But I'll find out very shortly. I'm working on some code now that I hope will make (at least) the mesa multiarb demo render correctly. Also, Is there anybody working on figuring out the missing texture formats? The problems with the texenv demo aren't only caused by incorrect texenv's, but most of the used texture formats are missing. Cheers, Ben Skeggs. best Vladimir Dergachev Cheers, Ben Skeggs. Rune Petersen --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] 9800 support?
Any idea why the PCI IDs for the radeon 9800 were removed from the DRM? --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: waitforVBlank, how does this even work?
With which part ? ;) On having a small stub module that does just IRQs ... I think the base module should be the fbdev (mode setting etc...) Oh, but I was not suggesting that. I just meant that interrupt handling code is self-contained and can easily serve several consumers. I'm with you here. And the same should IMHO hold for DMA handling. And for memory management of course. With one refinement - the DMA code would need to be a customer of IRQ code.. best Vladimir Dergachev -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/
Re: [r300] q3demo = _no_ artifacts
On Sat, 5 Mar 2005, Ben Skeggs wrote: Vladimir Dergachev wrote: It is easier to get the format right when you are adding it (and know which entry you are messing is), rather than add it blindly and then find out that a couple of components are in the wrong order. I'm not entirely sure of how to correctly define the texture formats. While I was messing with texenv's I made texenv.c printf what format it was using, and changed the WARN_ONCE into a printf to find out all the missing formats. I ended up adding something for entry 15, which corresponded to when texenv.c was using GL_ALPHA. I added R300_EASY_TX_FORMAT(W, X, X, X, ALPHA_1CH) to get the result to *look* correct, but I don't know if it *is* correct. To get the idea of what format is required look first at the old R200 table. For entry 15 it says _ALPHA(I8) . This means that we have 8-bit image, with single channel, I probably stands for intensity, and _ALPHA just toggles a bit in R200 indicating alpha channel is present. Thus I would try one of these R300 variants: R300_EASY_TX_FORMAT(ONE, ONE, ONE, X, X8) or R300_EASY_TX_FORMAT(X, X, X, X, X8) One of these should look right and the other be either dimmer or lighter than intended. best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri span patches...
On Thu, Mar 03, 2005 at 08:10:33PM +0100, Roland Scheidegger wrote: Ville Syrjälä wrote: Like I said before only the RGB components are blended. You can choose to write 0, 1, As, 1-As, Ad or 1-Ad to the destination alpha ([EMAIL PROTECTED] register). Currently the driver seems to write 0. It would probably be a better idea to write 1 instead. Sorry, but I just can't see that in the driver. And there's no ALPHA_DST_SEL bit, at least not in the mach64 reg file I have... I was just looking at the specs :) They are named MACH64_ALPHA_DST_* in mach64_reg.h. The driver doesn't explicitly specify any value which means 0 gets written. I actually just stumbled on this issue a few days ago with the mach64 DirectFB driver. My plan for the DirectFB driver is simply to allow ZERO + ZERO/ONE/SRCALPHASAT blend functions for destinations with alpha. It's a rather serious limitation but I think it's better than incorrect rendering. The issue is even worse on older Rage chips since they can only write 0 to the destination alpha. But that is not an issue for the DRI driver since those chips aren't supported. I think now I understand. It has alpha channel and all, but it simply won't perform the blending equation on the alpha channel, instead simply writing zero, one, source alpha, 1 - minus source alpha, dst alpha, or 1 - dst alpha. Exactly. Actually the driver does not write 0, it writes the source alpha value (MACH64_ALPHA_DST_SRCALPHA) as far as I can tell. Ok I missed that with my grepping. I was probably looking for ALPHA_DST_SEL myself too :) Actually, this design means it would have some very limited support for blend_func_separate :-). I had the same though :) Looks like a stupid design limitation to me (what would it cost to implement that additional blend adder to the 3 you need anyway?), but ah well. Maybe this wasn't required by DirectX 1.0 ;-). Mach64 chips have quite a few stupid alpha limitations. Most likely the nastiest one being that texture alpha can't be modulated. And then there's the whole fog vs. alpha thing. In practice though, this might just work quite often, the alpha-blended alpha values are probably not required a lot? Not with X. With DirectFB they are needed every time you render to an ARGB window and then expect to display the window alpha blended on screen. Regardless if it can actually blend alpha values or not, there would be some half-way useful alpha values probably in the buffer. Either you get the correct results or the wrong results. Not sure if there are any really useful things you can do with incorrect values. I meant that you might just get the correct alpha values sometimes (depending on the blend func that should be true I guess). Right. Though there are only a few combinations that give correct results. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri span patches...
Brian Paul wrote: Roland Scheidegger wrote: here's a patch which mainly does 3 things: - convert sis, mach64, and radeon to spantmp2. The sis and mach64 drivers got a slight change, previously you could not read back alpha values (always 0xff) and I don't think there was a good reason for that? IIRC, the mach64 doesn't support destination alpha planes. OpenGL requires that reads of absent alpha planes returns 1.0. I don't know if the SiS chip is the same. Are you sure? At least the driver handles things like GL_DST_ALPHA blend factors, wouldn't you get awfully bogus results if it wouldn't support destination alpha planes in that case? It does not export BGRA visuals however for some reason. Note that r128 driver (which was converted to use spantmp2 by Ian and thus got that same change in behaviour reading back RGBA pixels already) does not export visuals with a alpha component neither (just BGR 888, if I read that right). SIS OTOH exports BGRA visuals. Does this look sane? Driver source code should get quite a bit smaller overall. As long as you're looking at the span functions I should tell you that at some point in the future, work on the GL_EXT_framebuffer_object extension will likely require some changes in this area. I'll elaborate on that in another email when I have things better sorted out. I'm doing initial implementation with the xlib renderer now. But one thing that seems to be wrong in the r200 driver (for example) (and probably all the other DRI drivers) is the fact that the r200SetBuffer() function ignores its colorBuffer parameter. As it is now, the function ignores that parameter and always assumes that the span functions are going to be reading/writing to the context's current drawing buffer. The glXMakeContextCurrent and glXMakeCurrentReadSGI functions specify separate 'read' and 'draw' drawables. This allows you to do a glCopyPixels from one window to another, for example. This won't work if the colorBuffer parameter of r200SetBuffer() is ignored. In general, the span functions are relying too much on the GLcontext state, and not enough on the GLframebuffer state. The pointer to the start of the color/depth/stencil buffer, its width, height, pitch, etc. should be obtained via the GLframebuffer passed to r200SetBuffer. To do that, I guess GLframebuffer would need to have a pointer back to the corresponding __DRIDrawablePrivate, since we have no way to contain one in the other. Anyway, I wouldn't change anything right now. Let's wait until the GL_EXT_framebuffer_objects stuff has firmed up. I do not think these changes should interfere with that however, since the code generated should not change at all, it's just unuglifying by moving macros around (except for those drivers which got converted to use spantmp2, but you'll need to make it work with that anyway if somehow that template won't be able to deal with these necessary changes). Roland --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R200]Problems with HW TCL in Tuxracer and PPRacer
On Thu, 2005-03-03 at 20:22 +0100, Roland Scheidegger wrote: Michel Dnzer wrote: On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote: When using HW TCL in Tuxracer or PPRacer (that is essentially the same game) with my Radeon 8500 with DRI drivers dated 25 february 2005 you can see that there are problems with light reflection in those places where there's ice (for example in the first stage that is full of ice pools ) . You mean the flickering? That's probably Z fighting, most likely a problem in the game itself. You should bring this up with the PPRacer project, now that there's active development there... No, this is a result of the tcl fallback used for the GL_SPHERE_MAP texgen (it is z fighting I guess). Sure, but Brian told me the application has to be prepared for and deal with this. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: changes for GL_EXT_framebuffer_object
Ian Romanick wrote: Brian Paul wrote: I'll assume people are familiar with GL_EXT_framebuffer_object. If not, read the spec. If you still have questions after reading the spec, you can ask me on #dri-devel on freenode. I try to be on there as often as I can. The gl_renderbuffer's BaseFormat and DataType will implicitly specify which kind of pixel data is being accessed. I assume gl_renderbuffer will also have a method like ChooseTextureFormat that the driver can over-ride? Well, I don't think most GPUs allow rendering to as many different image buffer formats as they support for texture image formats. They're a little different. But I have to admit I haven't gotten down to that level of detail yet. It seems like there might be enough commonality that gl_renderbuffer and gl_texture should both derrive from a common, virtual base class. You mean gl_texture_image? I hadn't considered that before. I'll have to think about it. Also, a gl_renderbuffer object can be used as a wrapper for texture images. This will allow render-to-texture functionality. A yet-to-be-written routine will be called to set up the wrapper when the user wants render-to-texture. If the device supports rendering into texture memory, the wrapper will describe how to do that. Otherwise, a software-fallback wrapper would be used. Do you have any ideas about how this would work? One thing that I'm curious about, and has come up numerous times in the working-group discussions, is supporting render-to-texture when a blit is required. For example, on a architecture with separate texture and framebuffer memory, the driver would have to render to framebuffer memory, then copy that to the texture when the mipmap level was configured to be used as a texture source. Certain restrictions in the spec were crafted specifically to handle this case. It sounds like the wrapper idea should cover this, but I just want to be sure. :) Again, I haven't gotten to that level of detail. The business of wrapping a texture image with a gl_renderbuffer seems like a fairly reasonable/flexible approach at this time, but nothing's set in stone yet. Anyway, it sounds like you've really thought this through. I'm glad you have at least some time to work on it. :) -Brian --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r200] 'readpix' sigfault back trace SSE/MMX is culprit
Am Dienstag, 1. März 2005 19:46 schrieb Roland Scheidegger: Dieter Nützel wrote: Looking a bit at this, this seems to be caused because the number of pixels to read can be less than zero after CLIPSPAN (don't know if that's a bug in itself or not). That was my first thought, too (moving the window out to the left...) ;-) This is no problem for the generic read (since the for loop will just terminate instantly), but the mmx/sse/sse2 optimized routines only test if it's 0 pixels to read, and don't bail out if it's less than zero. I haven't looked closely what exactly will happen (i.e. the loops may never terminate at all), but this certainly seems like a bad thing... Here's a one-liner fix, which will cause CLIPSPAN hopefully never return a negative n1. Seems to work here. Ian, what do you think? Would it be better to have the optimized read/write functions deal with negative values instead? Ian, any thoughts? Thanks, Dieter --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri span patches...
Am Donnerstag, 3. März 2005 20:36 schrieb Roland Scheidegger: Dieter Nützel wrote: Am Donnerstag, 3. März 2005 4:48 schrieb Roland Scheidegger: Roland Scheidegger wrote: here's a patch which mainly does 3 things: - convert sis, mach64, and radeon to spantmp2. The sis and mach64 drivers got a slight change, previously you could not read back alpha values (always 0xff) and I don't think there was a good reason for that? Roland, do you had a look on Felix's spantmp2.diff, too. http://marc.theaimsgroup.com/?l=dri-develm=110600974029291w=2 I have missed that completely. Should be possible to work together with this patch just fine, though patch might disagree. BTW Can you please send me a private copy of dri-span3.diff, again. There are many ugly =3D characters in the archived version. You'll even get a newer version, Alan pointed out some subtle issues with the macro expansion (one of the reasons I don't particularly like macros...). Instead of fixing all GET_SRC/DST_PTR macros, I got rid of them too, since they were identical again in all drivers which use spantmp2 (except unichrome which uses different pitches for reading and drawing, it keeps its macros). Sorry, you lost spantmp_common.h in dri_span4.diff. /opt/Mesa grep -r spantmp_common.h * src/mesa/drivers/dri/common/stenciltmp.h:#include spantmp_common.h src/mesa/drivers/dri/common/depthtmp.h:#include spantmp_common.h src/mesa/drivers/dri/common/spantmp.h:#include spantmp_common.h src/mesa/drivers/dri/common/spantmp2.h:#include spantmp_common.h src/mesa/drivers/dri/common/spantmp2.h.orig:#include spantmp_common.h /opt/Mesa find -name spantmp_common.h -Dieter --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r420 related changes
On Fri, 2005-03-04 at 01:50 +0100, Rune Petersen wrote: if ( (info-ChipFamily == CHIP_FAMILY_R300) || (info-ChipFamily == CHIP_FAMILY_R350) || - (info-ChipFamily == CHIP_FAMILY_RV350) ) + (info-ChipFamily == CHIP_FAMILY_RV350) || + (info-ChipFamily == CHIP_FAMILY_R420) ) drmInfo.func = DRM_RADEON_INIT_R300_CP; else if ( info-ChipFamily = CHIP_FAMILY_R200 ) Why not just test for info-ChipFamily = CHIP_FAMILY_R300 instead of for every R300 family explicitly? Otherwise, it looks like the R200 microcode will be used, which is certainly wrong... Incidentally, I think the R300 check in RADEONDRIScreenInit() should be moved to the top as well, or the IGP and R200 checks will preempt it? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no scatter/gather memory ?
On Friday, March 4, 2005 6:20 am, Stephane Marchesin wrote: Stephane Marchesin wrote: Hi, I upgraded drm (non core) to current cvs (previous one was from 2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting the module I get : [drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory! [drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART! Ok, it looks like drm cvs (core and non core) has been broken on ia64 since august. Patch attached. What is this code trying to do anyway? It looks like it's checking for overflow and trying to make sure that the offset is in I/O space? Are those checks really necessary? It also looks like drm_addbufs_pci uses virt_to_bus, which won't work on many non-x86 platforms. Hmm... the version in latest 2.6 kernel tree doesn't seem to have these problems, which one is the master copy? Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no scatter/gather memory ?
Jesse Barnes wrote: On Friday, March 4, 2005 6:20 am, Stephane Marchesin wrote: Stephane Marchesin wrote: Hi, I upgraded drm (non core) to current cvs (previous one was from 2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting the module I get : [drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory! [drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART! Ok, it looks like drm cvs (core and non core) has been broken on ia64 since august. Patch attached. What is this code trying to do anyway? It looks like it's checking for overflow and trying to make sure that the offset is in I/O space? Are those checks really necessary? Well... they probably check that you can fit the result of pci_resource_start into an unsigned int :) (I'm only half joking - see radeon_cp.c which passes that as the offset argument for initmap). So yes, initmap should have an unsigned long or some kind of pointer as its second arg instead... It also looks like drm_addbufs_pci uses virt_to_bus, which won't work on many non-x86 platforms. Hmm... the version in latest 2.6 kernel tree doesn't seem to have these problems, which one is the master copy? It's drm cvs, which gets merged into 2.6 from time to time. Stephane --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r420 related changes
On Fri, 4 Mar 2005, Michel [ISO-8859-1] Dänzer wrote: On Fri, 2005-03-04 at 01:50 +0100, Rune Petersen wrote: if ( (info-ChipFamily == CHIP_FAMILY_R300) || (info-ChipFamily == CHIP_FAMILY_R350) || -(info-ChipFamily == CHIP_FAMILY_RV350) ) +(info-ChipFamily == CHIP_FAMILY_RV350) || +(info-ChipFamily == CHIP_FAMILY_R420) ) drmInfo.func = DRM_RADEON_INIT_R300_CP; else if ( info-ChipFamily = CHIP_FAMILY_R200 ) Why not just test for info-ChipFamily = CHIP_FAMILY_R300 instead of for every R300 family explicitly? Otherwise, it looks like the R200 microcode will be used, which is certainly wrong... Incidentally, I think the R300 check in RADEONDRIScreenInit() should be moved to the top as well, or the IGP and R200 checks will preempt it? I was afraid that R300 microcode would not work for newer cards as my understanding of it is somewhat limited. Do you think it would be safe to load an older microcode to a newer card ? Upon a closer look it appears that this part only affects the choice of the microcode, so in a way, your suggestion would avoid loading the really old Radeon microcode. As for DRIScreenInit - I looked at the code again and its logic appears correct to me, could you elaborate a bit where you would like the R300 check to appear ? thank you ! Vladimir Dergachev -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
[PATCH] fix write combining on ia64
Some ia64 platforms may not support write combining on all type of memory, so we need to consult the EFI memory map before we try to set the write combine attribute of a page. This patch will try to map a page write combined if it's not an AGP page and the EFI memory map says it's ok, otherwise it falls back to a regular, uncached mapping. Can someone please apply this to the drm tree? Thanks, Jesse Index: drm_vm.c === RCS file: /cvs/dri/drm/linux-core/drm_vm.c,v retrieving revision 1.49 diff -u -p -r1.49 drm_vm.c --- drm_vm.c12 Jan 2005 16:07:49 - 1.49 +++ drm_vm.c4 Mar 2005 19:03:31 - @@ -639,9 +639,13 @@ int drm_mmap(struct file *filp, struct v vma-vm_flags |= VM_IO; /* not in core dump */ } #if defined(__ia64__) - if (map-type != _DRM_AGP) + if (efi_range_is_wc(vma-vm_start, vma-vm_end - + vma-vm_start) (map-type != _DRM_AGP)) vma-vm_page_prot = - pgprot_writecombine(vma-vm_page_prot); + pgprot_writecombine(vma-vm_page_prot); + else + vma-vm_page_prot = + pgprot_noncached(vma-vm_page_prot); #endif offset = dev-driver-get_reg_ofs(dev); #ifdef __sparc__
Re: [r300] r420 related changes
Vladimir Dergachev wrote: On Fri, 4 Mar 2005, Michel [ISO-8859-1] Dnzer wrote: On Fri, 2005-03-04 at 01:50 +0100, Rune Petersen wrote: if ( (info-ChipFamily == CHIP_FAMILY_R300) || (info-ChipFamily == CHIP_FAMILY_R350) || - (info-ChipFamily == CHIP_FAMILY_RV350) ) + (info-ChipFamily == CHIP_FAMILY_RV350) || + (info-ChipFamily == CHIP_FAMILY_R420) ) drmInfo.func = DRM_RADEON_INIT_R300_CP; else if ( info-ChipFamily = CHIP_FAMILY_R200 ) Why not just test for info-ChipFamily = CHIP_FAMILY_R300 instead of for every R300 family explicitly? Otherwise, it looks like the R200 microcode will be used, which is certainly wrong... Incidentally, I think the R300 check in RADEONDRIScreenInit() should be moved to the top as well, or the IGP and R200 checks will preempt it? I was afraid that R300 microcode would not work for newer cards as my understanding of it is somewhat limited. Do you think it would be safe to load an older microcode to a newer card ? No. Long before the r300 project began, I wanted to see what would happen if I loaded r200 microcode onto my 9800. The first attempt at running a GL app locked my computer solid :-) Adam --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no scatter/gather memory ?
On Friday, March 4, 2005 10:31 am, Jesse Barnes wrote:
Seems like we need something like this instead?
Index: linux-core/drm_dma.c
===
RCS file: /cvs/dri/drm/linux-core/drm_dma.c,v
retrieving revision 1.39
diff -u -r1.39 drm_dma.c
--- linux-core/drm_dma.c31 Oct 2004 15:16:44 - 1.39
+++ linux-core/drm_dma.c4 Mar 2005 18:29:03 -
@@ -141,6 +141,9 @@
buf-filp = NULL;
buf-used = 0;
+ pci_unmap_page(dev-pdev, buf-bus_address, buf-total,
+ PCI_DMA_FROMDEVICE);
+
This is wrong since we may get here with AGP or other memory that wasn't
pci_map*'d in the first place. It should also use pci_unmap_single instead.
if (drm_core_check_feature(dev, DRIVER_DMA_QUEUE)
waitqueue_active(buf-dma_wait)) {
wake_up_interruptible(buf-dma_wait);
Index: linux-core/drm_bufs.c
===
RCS file: /cvs/dri/drm/linux-core/drm_bufs.c,v
retrieving revision 1.54
diff -u -r1.54 drm_bufs.c
--- linux-core/drm_bufs.c 5 Feb 2005 08:00:14 - 1.54
+++ linux-core/drm_bufs.c 4 Mar 2005 18:29:04 -
@@ -752,7 +752,9 @@
buf-used = 0;
buf-offset = (dma-byte_count + byte_count +
offset); buf-address = (void *)(page + offset);
- buf-bus_address = virt_to_bus(buf-address);
+ buf-bus_address = pci_map_page(dev-pdev, page,
offset, + buf-total,
+ PCI_DMA_TODEVICE);
buf-next = NULL;
This should be pci_map_single instead I think, since the buffer may be more
than one page like you said?
buf-bus_address = pci_map_single(dev-pdev,
bus-address,
buf-total,
PCI_DMA_BIDIRECTIONAL);
Jesse
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r420 related changes
On Fri, 2005-03-04 at 13:53 -0500, Vladimir Dergachev wrote:
On Fri, 4 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Fri, 2005-03-04 at 01:50 +0100, Rune Petersen wrote:
if ( (info-ChipFamily == CHIP_FAMILY_R300) ||
(info-ChipFamily == CHIP_FAMILY_R350) ||
- (info-ChipFamily == CHIP_FAMILY_RV350) )
+ (info-ChipFamily == CHIP_FAMILY_RV350) ||
+ (info-ChipFamily == CHIP_FAMILY_R420) )
drmInfo.func = DRM_RADEON_INIT_R300_CP;
else
if ( info-ChipFamily = CHIP_FAMILY_R200 )
Why not just test for info-ChipFamily = CHIP_FAMILY_R300 instead of
for every R300 family explicitly? Otherwise, it looks like the R200
microcode will be used, which is certainly wrong... Incidentally, I
think the R300 check in RADEONDRIScreenInit() should be moved to the top
as well, or the IGP and R200 checks will preempt it?
I was afraid that R300 microcode would not work for newer cards as my
understanding of it is somewhat limited. Do you think it would be safe to
load an older microcode to a newer card ?
No, as I said above.
Upon a closer look it appears that this part only affects the choice of
the microcode, so in a way, your suggestion would avoid loading the really
old Radeon microcode.
Yes, this code only decides between the supported microcode versions. If
there will be any chips in the future for which neither of the current
choices work, the DRI will likely have to be disabled for them anyway.
As for DRIScreenInit - I looked at the code again and its logic appears
correct to me, could you elaborate a bit where you would like the R300
check to appear ?
if (info-IsIGP) {
req_minor = 10;
req_patch = 0;
} else if (info-ChipFamily = CHIP_FAMILY_R200) {
req_minor = 5;
req_patch = 0;
} else if (info-ChipFamily = CHIP_FAMILY_R300) {
req_minor = 12;
req_patch = 0;
} else {
The IGP and R200 cases will match before the R300 case. The order should
be from highest to lowest required DRM version.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] use DRM_SOURCE_PATH from environment if available
This simple patch makes it a little easier to build against arbitrary drm trees. It'll pull in DRM_SOURCE_PATH from the environment if set, otherwise it'll default to it's current value. Jesse Index: configs/default === RCS file: /cvs/mesa/Mesa/configs/default,v retrieving revision 1.12 diff -u -r1.12 default --- configs/default 8 Dec 2004 15:16:36 - 1.12 +++ configs/default 4 Mar 2005 20:55:38 - @@ -11,7 +11,7 @@ MESA_TINY=0 # external projects -DRM_SOURCE_PATH=$(TOP)/../drm +DRM_SOURCE_PATH ?= $(TOP)/../drm # Compiler and flags CC = cc --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Trouble building linux-solo-ia64
I got this error when I tried to build linux-solo-ia64: gcc -c -I. -I../../../include -I../../../src/mesa -I../../../src/mesa/main -I../../../src/mesa/glapi -I../../../src/mesa/math -I../../../src/mesa/transform -I../../../src/mesa/swrast -I../../../src/mesa/swrast_setup -I../../../src/mesa/drivers/dri/common -I/home/jbarnes/working/r300/r300_driver/drm/libdrm -I/home/jbarnes/working/r300/r300_driver/drm/shared -DDRI_NEW_INTERFACE_ONLY -D_POSIX_SOURCE-D_SVID_SOURCE -D_BSD_SOURCE -D_POSIX_C_SOURCE=199309L -D_GNU_SOURCE -DGLX_DIRECT_RENDERING -Wmissing-prototypes -g -std=c99 -Wundef -fPIC -ffast-math -DDRI_NEW_INTERFACE_ONLY -D_POSIX_SOURCE -D_SVID_SOURCE -D_BSD_SOURCE -D_POSIX_C_SOURCE=199309L -D_GNU_SOURCE -DGLX_DIRECT_RENDERING ../../../src/mesa/drivers/dri/common/glcontextmodes.c -o ../../../src/mesa/drivers/dri/common/glcontextmodes.o ../../../src/mesa/drivers/dri/common/glcontextmodes.c:38:28: dri_interface.h: No such file or directory make[3]: *** [../../../src/mesa/drivers/dri/common/glcontextmodes.o] Error 1 make[3]: Leaving directory `/home/jbarnes/working/dri/Mesa/src/glx/mini' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/home/jbarnes/working/dri/Mesa/src' make[1]: *** [default] Error 1 make[1]: Leaving directory `/home/jbarnes/working/dri/Mesa' make: *** [linux-solo-ia64] Error 2 So I modified src/glx/mini/Makefile to -Iinclude/GL/internal, is that the right fix? Thanks, Jesse --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r420 related changes
there will be any chips in the future for which neither of the current
choices work, the DRI will likely have to be disabled for them anyway.
As for DRIScreenInit - I looked at the code again and its logic appears
correct to me, could you elaborate a bit where you would like the R300
check to appear ?
if (info-IsIGP) {
req_minor = 10;
req_patch = 0;
} else if (info-ChipFamily = CHIP_FAMILY_R200) {
req_minor = 5;
req_patch = 0;
} else if (info-ChipFamily = CHIP_FAMILY_R300) {
req_minor = 12;
req_patch = 0;
} else {
The IGP and R200 cases will match before the R300 case. The order should
be from highest to lowest required DRM version.
I agree - I have no idea how it came to be this way, sorry !
Vladimir Dergachev
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?
On Fri, 2005-03-04 at 15:18 +0200, Ville Syrjälä wrote: On Fri, Mar 04, 2005 at 09:08:27AM +1100, Benjamin Herrenschmidt wrote: Oh, but I was not suggesting that. I just meant that interrupt handling code is self-contained and can easily serve several consumers. I'm with you here. And the same should IMHO hold for DMA handling. And for memory management of course. DMA handling is the main piece of what the DRM does, The actual bits that feed DMA buffers to the hardware are very small. And I just meant that like the IRQ code those need to be easily accessible from other components (fbdev, video capture module etc.) Feeding DMA buffers in what sense ? The buffers are matches with various functions. For AGP buffers, you have to get into the whole allocation mecanism, pure PCI DMA isn't always possible on some hosts. Also, those buffers are what ? Data for blits ? textures ? they always belong to some sort of command, which we want to eventually validate in a way by the kernel unless you want your client to be root... No, honestly, I don't see the point in breaking up our current DRM/fbdev thing. Ben. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2516] some rasterization fallbacks cause segfaults
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2516
--- Additional Comments From [EMAIL PROTECTED] 2005-03-04 16:48 ---
Some more debugging info (still from texdown):
(gdb) print count
$13 = 3
(gdb) print ((TNLcontext *)ctx-swtnl_context)-clipspace-attr[0]
$14 = {attrib = 0, format = 6, vertoffset = 0, vertattrsize = 16,
inputptr = 0x8207b90 , inputstride = 16, insert = 0x3b0d0db0,
emit = 0x3afeb3a0 insert_4f_3, extract = 0x3afec7d0 extract_4f_viewport,
vp = 0x808cd90}
(gdb) print ((TNLcontext *)ctx-swtnl_context)-clipspace-attr[1]
$15 = {attrib = 3, format = 15, vertoffset = 144, vertattrsize = 4,
inputptr = 0x80614ec , inputstride = 0, insert = 0x3b0d0eac,
emit = 0x3afeb910 insert_4ub_4f_rgba_3,
extract = 0x3afec990 extract_4chan_4f_rgba, vp = 0x808cd90}
(gdb) print ((TNLcontext *)ctx-swtnl_context)-clipspace-attr[2]
$16 = {attrib = 8, format = 3, vertoffset = 16, vertattrsize = 16,
inputptr = 0x81f2954 , inputstride = 16, insert = 0x3b0d0d5c,
emit = 0x3afeb4b0 insert_2f_2, extract = 0x3afec8a0 extract_4f, vp =
0x808cd90}
(gdb) print VB-AttribPtr
$17 = {0x0, 0x81f69ec, 0x81f6a08, 0x81f6a24, 0x81f6a40, 0x81f6a5c, 0x81f6a78,
0x81f6a94, 0x81f6ab0, 0x81f6acc, 0x81f6ae8, 0x81f6b04, 0x81f6b20, 0x81f6b3c,
0x81f6b58, 0x81f6b74, 0x81f6b90, 0x81f6bac, 0x81f6bc8, 0x81f6be4, 0x81f6c00,
0x81f6c1c, 0x81f6c38, 0x81f6c54, 0x81f6c70, 0x81f6c8c, 0x81f6ca8, 0x81f6cc4,
0x81f6ce0, 0x0, 0x0}
So, the first pointer (for attrib 0 (position)) is the NULL pointer leading to
the segfault, the other ones (attrib 3 (color0), attrib 8 (tex0)) look rather
reasonable (?). Unfortunately I'm no tnl wizard...
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no scatter/gather memory ?
Stephane Marchesin writes: Ok, it looks like drm cvs (core and non core) has been broken on ia64 since august. Patch attached. Stephane Index: linux/drm_bufs.h === RCS file: /cvs/dri/drm/linux/drm_bufs.h,v retrieving revision 1.45 diff -u -r1.45 drm_bufs.h --- linux/drm_bufs.h 16 Jan 2005 05:40:12 - 1.45 +++ linux/drm_bufs.h 4 Mar 2005 14:10:26 - @@ -74,7 +74,7 @@ if ( (offset (~PAGE_MASK)) || (size (~PAGE_MASK)) ) return -EINVAL; -#if !defined(__sparc__) !defined(__alpha__) +#if !defined(__sparc__) !defined(__alpha__) !defined(__ia64__) if ( offset + size offset || offset virt_to_phys(high_memory) ) return -EINVAL; #endif Note that that check is also wrong for ppc64. I think it is going to be wrong for most 64-bit platforms, since it is assuming that you can never have ram at a higher physical address than any I/O devices. On 64-bit platforms it is quite common to have some ram and some I/O below 4GB, and some more ram above 4GB. I don't see why we need the check anyway, unless some architecture (x86?) will actually panic if you try to ioremap a physical address that is below virt_to_phys(high_memory) or something. Paul. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] texture breakage
Vladimir Dergachev writes: We should probably have analogous code for r300. Do you mean we should have swtcl code for r300, or something else? Paul. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] texture breakage
On Sat, 5 Mar 2005, Paul Mackerras wrote: Vladimir Dergachev writes: We should probably have analogous code for r300. Do you mean we should have swtcl code for r300, or something else? There are two issues: 1. As was explained to me we need to have swtcl code in case we need to do software fallback for some unsupported feature 2. Right *now* we are doing only swtcl, as no acceleration for transform and lightning is being done. So either way there is some code to port/write. best Vladimir Dergachev Paul. --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: no scatter/gather memory ?
Paul Mackerras wrote: Note that that check is also wrong for ppc64. I think it is going to be wrong for most 64-bit platforms, since it is assuming that you can never have ram at a higher physical address than any I/O devices. On 64-bit platforms it is quite common to have some ram and some I/O below 4GB, and some more ram above 4GB. I don't see why we need the check anyway, unless some architecture (x86?) will actually panic if you try to ioremap a physical address that is below virt_to_phys(high_memory) or something. Wouldn't this check even break on x86 with PAE? Those boxes certainly have parts of their ram mapped above io memory too. Or does that high_memory variable stay below 4GB with PAE? Roland --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 mesa-solo trouble
Jesse Barnes wrote: Ok, so I've got everything built and the sample server starts (after applying the attached patch): [EMAIL PROTECTED] miniglx]# ./sample_server [miniglx] probed chipset 0x4e4b got MMIOAddress 0x20001090 offset 268435456 [drm] added 65536 byte SAREA at 0xa00204fa [drm] mapped SAREA 0xa00204fa to 0x20001120, size 65536 [drm] framebuffer handle = 0xc041c800 [drm] register handle = 0xc041c010 [pci] 8192 kB allocated with handle 0x0551c000 [pci] ring handle = 0xa0020551c000 [pci] ring read ptr handle = 0xa0020562 [pci] vertex/indirect buffers handle = 0xa00205624000 [pci] GART texture map handle = 0xa00205824000 Using 8 MB AGP aperture Using 1 MB for the ring buffer Using 2 MB for vertex/indirect buffers Using 1 MB for AGP textures Will use back buffer at offset 0x60 Will use depth buffer at offset 0xb0 Will use 245760 kb for textures at offset 0x100 [drm] Added 32 65536 byte vertex/indirect buffers [drm] dma control initialized, using IRQ 67 [drm] Initialized kernel gart heap manager, 5111808 page flipping disabled [miniglx] Setting mode: visible 1280x1024 virtual 1280x1024x32 [miniglx] Readback mode: visible 1280x1024 virtual 1280x1024x32 RADEONEngineRestore [1]+ Stopped ./sample_server [EMAIL PROTECTED] miniglx]# bg then I start up the sample test app: [EMAIL PROTECTED] miniglx]# ./miniglxtest [miniglx] probed chipset 0x4e4b CreateNotify Authorize - magic 1 Unknown device ID 4E4B, please report. Assuming plain R300. Using 8 maximum texture units.. sizeof(drm_r300_cmd_header_t)=4 sizeof(drm_radeon_cmd_buffer_t)=32 Allocating 284420 bytes command buffer (max state is 11140 bytes) *WARN_ONCE* File r300_state.c function r300Enable line 516 Don't know how to enable polygon offset point/line. Help me ! *** DestroyNotify Segmentation fault Any ideas? Is this because I'm using the radeon server/ directory (at least it looks like the r300 dir's server/ dir has items symlinked back to radeon/)? Ok, I (finally) found it. You need the attached one-liner to set the mode. The rest is just something I have in my tree to make it gcc2-friendly. Stephane Index: miniglx.c === RCS file: /cvs/mesa/Mesa/src/glx/mini/miniglx.c,v retrieving revision 1.17 diff -u -r1.17 miniglx.c --- miniglx.c 5 Jan 2005 22:40:34 - 1.17 +++ miniglx.c 5 Mar 2005 03:27:48 - @@ -1103,6 +1103,7 @@ drmVersionPtr version; drm_handle_t hFB; intjunk; +drm_magic_t magic; err_msg = XF86DRIOpenConnection; err_extra = NULL; @@ -1117,8 +1118,6 @@ if (fd 0) goto done; -drm_magic_t magic; - err_msg = drmGetMagic; err_extra = NULL; @@ -1989,6 +1988,7 @@ else sharePriv = NULL; + ctx-driContext.mode = vis-visual-mode; ctx-driContext.private = dpy-driScreen.createNewContext(dpy, vis-visual-mode, GLX_WINDOW_BIT, sharePriv, ctx-driContext);
Re: Fixing memset on ia64 other archs
You also have to add the file, memops.h, to src/mesa/drivers/dri/comon I've added powerpc ia64 for now. Let me now if other archs need this too. committed... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] R300 DRM unfrozen
radeon.ko to /lib/modules.../char/drm. This time I even did a reboot afterwards, to check that everything will work. After the reboot I ran `modprobe radeon`. Try using insmod with explicit path specification - this is what I do. You must have leftover radeon.ko someplace. It seems I did have some leftovers. Module dependency can be nasty this way. I, personally, prefer to always use insmod with explicit path specification for modules that are being tested. The new code seems to lock up. I attached the end of the log from tuxracer. Does glxgears work ? best Vladimir Dergachev --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
