Re: dri span patches...
On Thu, Mar 03, 2005 at 04:48:58AM +0100, 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? AFAICS mach64 doesn't apply either the blend equation or the blend functions to the alpha values. You can choose to write either 0, 1, As, 1-As, Ad or 1-Ad to the destination :( -- 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...
On Thu, Mar 03, 2005 at 10:04:02AM +0200, Ville Syrjälä wrote: On Thu, Mar 03, 2005 at 04:48:58AM +0100, 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? AFAICS mach64 doesn't apply either the blend equation or the blend functions to the alpha values. You can choose to write either 0, 1, As, 1-As, Ad or 1-Ad to the destination :( Oh and a quick look at the mach64 driver indicats that it always chooses to write 0. -- 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: [R300] texture breakage
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 :).
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 04:48:58AM +0100, 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? 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. It looks o.k. and if there's hardware that's more obscure than the common cases then they'd have their own span routines anyway. Just watch out on the macro expansion though. You've got this currently... #define GET_SRC_PTR(_x, _y) (read_buf + _x * 2 + _y * pitch) and it should be... #define GET_SRC_PTR(_x, _y) (read_buf + (_x) * 2 + (_y) * pitch) Alan. --- 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
32/64-bit DRM ioctl compatibility patch
I now have the radeon DRI going on my G5 under a 64-bit kernel. I have split out the parts of the changes that I have made that relate to implementing ioctl compatibility for 32-bit processes. The patch is at: http://ozlabs.org/~paulus/drm-64b.patch The patch is against a 2.6.11 kernel tree. I am running this with a 32-bit X server (compiled up from X.org CVS as of a couple of weeks ago) and 32-bit DRI libraries and clients. All the userland stuff is identical to what I am using under a 32-bit kernel on my G4 powerbook (which is a 32-bit machine of course). I haven't tried compiling up a 64-bit X server or clients yet. In the compatibility routines I have assumed that the kernel can safely access user addresses after set_fs(KERNEL_DS). That is, where an ioctl argument structure contains pointers to other structures, and those other structures are already compatible between the 32-bit and 64-bit ABIs (i.e. they only contain things like chars, shorts or ints), I just check the address with access_ok() and then pass it through to the 64-bit ioctl code. I believe this approach may not work on sparc64, but it does work on ppc64 and x86_64 at least. One tricky area which may need to be revisited is the question of how to handle the handles which we pass back to userspace to identify mappings. These handles are generated in the ADDMAP ioctl and then passed in as the offset value to mmap. However, offset values for mmap seem to be generated in other ways as well, particularly for AGP mappings. The approach I have ended up with is to generate a fake 32-bit handle only for _DRM_SHM mappings. The handles for other mappings (AGP, REG, FB) are physical addresses which are already limited to 32 bits, and generating fake handles for them created all sorts of problems in the mmap/nopage code. Comments? 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
[Bug 943] Patch to add support for 32bit DRI clients on 64bit machines
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=943 --- Additional Comments From [EMAIL PROTECTED] 2005-03-03 01:21 --- Created an attachment (id=2011) -- (https://bugs.freedesktop.org/attachment.cgi?id=2011action=view) Patch to add ioctl compatibility routines for 32-bit processes Here is my attempt at implementing ioctl compatibility routines for 32-bit processes on a 64-bit kernel. The patch is against a 2.6.11 Linux kernel tree. I have done the core DRM and the Radeon driver but not any of the other chipset drivers. I haven't changed the ABI, either for 32-bit or for 64-bit processes. I have used this successfully on a G5 powermac running a ppc64 Linux kernel, using unmodified 32-bit X server and client binaries. -- 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: [R300] R300 DRM unfrozen
Vladimir Dergachev wrote: On Wed, 2 Mar 2005, Vladimir Dergachev wrote: On Thu, 3 Mar 2005, Boris Peterbarg wrote: athlon xp 2500+, kernel 2.6.10, xorg cvs from 27/02/05 Yes, I compiled the drivers. xorg loaded them. I'm using udev. With the drm before the changes, /dev/dri/card0 is created. With the new drm it's not. Upon some further thinking: 1) Try updating r300_driver (or checking out a fresh copy - maybe SourceForge lags a little. 2) Check which version of the driver is loading. Did it initialize ok ? My dmesg looks like this: I updated again, but I get only this line on the new drm initialization: [drm] Initialized drm 1.0.0 20040925 The old initialization looks like yours, just with the radeon version being 1.12.1 20041216 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
Re: [R300] R300 DRM unfrozen
1) Try updating r300_driver (or checking out a fresh copy - maybe SourceForge lags a little. 2) Check which version of the driver is loading. Did it initialize ok ? My dmesg looks like this: I updated again, but I get only this line on the new drm initialization: [drm] Initialized drm 1.0.0 20040925 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 ? 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
Re: changes for GL_EXT_framebuffer_object
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? It seems like there might be enough commonality that gl_renderbuffer and gl_texture should both derrive from a common, virtual base class. 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. :) Anyway, it sounds like you've really thought this through. I'm glad you have at least some time to work on it. :) --- 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: [Mesa3d-dev] changes for GL_EXT_framebuffer_object
On Thursday 03 March 2005 10:42, Brian Paul wrote: 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. Would one side effect of this be that the driver could implement (say) accum buffers entirely in swrast but still have hardware acceleration for the normal set of buffers? This might be an interim solution for pbuffers until the DRI drivers get decent memory management. - ajax pgpgDoBDJbNkP.pgp Description: PGP signature
Re: [Mesa3d-dev] changes for GL_EXT_framebuffer_object
Adam Jackson wrote: On Thursday 03 March 2005 10:42, Brian Paul wrote: 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. Would one side effect of this be that the driver could implement (say) accum buffers entirely in swrast but still have hardware acceleration for the normal set of buffers? Yes. It'll also allow hardware accumulation buffers in a straight-forward manner. The Mesa fall-back routines for rasterization, accumulation, etc will do all their pixel-oriented work through the gl_renderbuffer's methods so it won't matter which buffers are hardware or software based. Currently, the software fallbacks, in some places, are more intimately tied to the memory allocation than needed. In the new scheme, all the code for allocating software buffers will be pulled out of the swrast routine and put into a utility routine, probably in drivers/common/. This might be an interim solution for pbuffers until the DRI drivers get decent memory management. Well, GL_EXT_framebuffer_object should be able to replace pbuffers, but it'll still require a DRI mechanism for dynamically allocating rendering buffers (if you want hardware rendering). -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: dri span patches...
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? 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. Like I said, IIRC. If you run the Mesa 'reflect' demo and hit 'a' you should see the contents of the alpha channel. The demo may need to be hacked to request GLUT_ALPHA in glutInitDisplayMode. But that'll show if you've got a functioning alpha channel. Maybe someone with a mach64 or sis can try that. 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). I meant to say that you should go ahead with your changes now (as far as I'm concerned), and don't worry about the GL_EXT_renderbuffer_object stuff or the ignored GLframebuffer parameter for now. Sorry for not being clear. -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: dri span patches...
On Thu, 03 Mar 2005 17:45:15 +0100, Roland Scheidegger [EMAIL PROTECTED] 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? 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. I think the mach64 had some limitations regarding alpha. I think it could only do fog or alpha, but not both at the same time. perhaps what you are seeing is a result of that. Alex --- 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
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 :).
Paul.
Do you still see the same breakage with vertex buffer mode? The textures in
neverball are broken for me in immediate mode with the latest cvs.
Cheers,
Ben Skeggs.
---
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: dri span patches...
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. -- 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...
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 it running with r200 (32 bpp) but do not see big changes (slowdown or speedup). BTW Can you please send me a private copy of dri-span3.diff, again. There are many ugly =3D characters in the archived version. -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...
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. Actually the driver does not write 0, it writes the source alpha value (MACH64_ALPHA_DST_SRCALPHA) as far as I can tell. Actually, this design means it would have some very limited support for blend_func_separate :-). 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 ;-). In practice though, this might just work quite often, the alpha-blended alpha values are probably not required a lot? 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). 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: [R200]Problems with HW TCL in Tuxracer and PPRacer
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). Someday we should figure out why it doesn't work correct in the first place probably (if you kill the fallback, you can clearly see it's not quite correct in ppracer), though it wouldn't hurt to make the fallbacks work better neither (r100 has afaik the same problem, and it can't be fixed by not using a fallback since it doesn't support GL_SPHERE_MAP texgen). 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: dri span patches...
Dieter Nützel wrote: 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. You're right. I really wanted to do a cvs diff to include new files, but I guess it's not possible, and hacking together the diffs manually is just asking for such errors :-). 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 2001/03/21 16:14:20 dawes Exp $ */ +#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 - static void TAG(WriteStencilSpan)( GLcontext *ctx,
Re: dri span patches...
Roland Scheidegger wrote: You're right. I really wanted to do a cvs diff to include new files, but I guess it's not possible, and hacking together the diffs manually is just asking for such errors :-). If you've done a 'cvs add' (or 'cvs rm') on the files, you can do 'cvs diff -Nud'. --- 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] r420 related changes
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 2) RADEONInitDispBandwidth() is disabled for r420 cards. I have no problem enabling this. are there a reason for this? 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? Regarding Xorg are there an easy way to make a diff without needing a duplicate tree? And where should I send the Xorg patches? 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: [R200]Problems with HW TCL in Tuxracer and PPRacer
Roland Scheidegger wrote: 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. One of the appendices of the OpenGL Programming Guide discusses invariance. The basic idea is that certain kinds of OpenGL state changes should not result in any difference in the final rasterization, in terms of fragment x,y,z and/or color. For example, changing GL_DEPTH_FUNC from GL_LESS to GL_GEQUAL should have no effect on the generated fragments. In other cases, a stage change such as enabling/disabling texgen may require that the OpenGL implementation use totally different vertex processing paths (hardware vs. software, perhaps) and the set of fragments generated will be different. That's allowable. The application programmer has to be aware of this if they're relying on some sort of repeatability. That said, I don't know exactly what Tuxracer is doing. -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_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] texture breakage
Ben Skeggs writes: Do you still see the same breakage with vertex buffer mode? The textures in neverball are broken for me in immediate mode with the latest cvs. No, I don't in fact, with vertex buffer mode it is mostly as good as before. The one difference I have noticed is that the first screen of pinball displays the background texture wrongly (half-width and repeated horizontally, and displaced and wrapped vertically), but if I get it to redraw it displays it correctly. 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 Fri, 4 Mar 2005, Paul Mackerras wrote: 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. Does everything work with vb mode ? (you can switch to it in the end of r300_driver/r300/r300_render.c, search for #else) 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: [Linux-fbdev-devel] Re: waitforVBlank, how does this even work?
On Thu, 2005-03-03 at 10:12 -0500, Vladimir Dergachev wrote: 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.. No, again, DMA is what DRM is for, or you want to re-invent the whole architecture ? 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: [R300] 9800 support?
On Thu, 3 Mar 2005, Rune Petersen wrote: 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. My fault - there was probably a reject that I overlooked. Thank you for putting them back ! 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 --- 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: On Thu, 3 Mar 2005, Rune Petersen wrote: 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. I gave it a try, no problem. patch: r420_drm-microcode-fix.patch 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. Ok. 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) 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 Index: radeon_dri.c === RCS file: /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c,v retrieving revision 1.13 diff -u -r1.13 radeon_dri.c --- radeon_dri.c26 Jan 2005 18:23:40 - 1.13 +++ radeon_dri.c3 Mar 2005 23:55:40 - @@ -1037,7 +1037,8 @@ memset(drmInfo, 0, sizeof(drmRadeonInit)); 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 )
Re: [R300] texture breakage
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. 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
