Re: R200 depth tiling questions.
Hi,
Dnia 28-01-2005, pi o godzinie 16:27 +0100, Roland Scheidegger
napisa(a):
Jacek Rosik wrote:
Hi,
I have some questions about r200 depth tiling. Generally I'm also
interested in r100 tiling too, but currently i work on r200.
First of all in functions r200_mba_z16|32 from r200_span.c frontPitch
offset is used. Is it intentional or just because depthOffset is
also the same? Maybe it should be depthOffset?
Yes, I think depthPitch (you surely meant that, yes?) instead of
frontPitch might be a good idea. I don't think there's a good reason to
use frontPitch there, even though currently they are always the same.
Yes, I meant depthPitch. They are the same but only for resolutions
where width is multiple of 32. Depth pitch is rounded to be multiple of
32. Hmm... I think that is wrong since tile size seems to depend on fb
depth and probably tiles on r100 also have different sizes. So this is
correct only for r200 with 32bpp fb depth.
Depth tiles on r200 are 32x16 or 64x16, depending on FB depth, right?
Well, the span functions would indicate that. It doesn't quite match the
experiences made when implementing hyperz, however (where the same
number of tiles needed to be cleared regardless of 16 or 32bit z depth,
and tile size more seemed to correspond to 4x4 microtiles and 8x2
macrotiles, thus a tile size of 32x8). I never really fully understood
that however, something just doesn't fit. See th drm clear code for details.
Thanks, I'll take a look at it.
I don't quite follow third line before last? Can someone enlighten
me?
You mean the pitch 0x20 stuff? Yeah, looks strange.
Looking at it, it seems like it ensures that each block line starts
with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will have
set that (for x 0-31) to 0, y 16-31 to 1 and so on.
Seems to me like it might be related to how the ram is organized (e.g.
something like ensuring it's on a different memory channel or different
bank or whatnot).
Yeah, I thought something similar.
This is, btw, quite similarly strange to what Stephane needed on his
rv100 to get the correct pixel address for color tiling, this one also
tinkered with that 11th bit (see RadeonDoAdjustFrame).
Generally if one could explain tiling a bit for me I would be
grateful. What I'm trying to do is to is to modify depthOffset to be
as close to top-left corner of viewport as possible and modify. I
this possible with shared depth buffer. This means that each 3D
window would have different depthOffset but pointing to the same
shared buffer.
I'm not sure if it's possible to do that with depthOffset (well maybe).
There is however an interesting bit in RB3D_CNTL
(R200_DEPTH_XZ_OFFEST_ENABLE, I guess XZ is a typo, just as is
OFFEST?) and the corresponding (?) register
(R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly
invented for that...
So this would mean that depth buffer can start at different x,y than
color buffer? Can someone with the docs confirm that.
Anyway I think I will experiment with it a little more and see what I'll
get. Unfortunately I'll be quite busy in next weeks, but I hope I'll get
back to it soon.
BTW: I have working solution for color but I wonder if this will work
with color tiling. Of course offset Would have to be aligned to the
closest tile. Can You take a look at it? (It's missing some bits but
generaly apps which don't use depth should work Unfortunately I don't
think there are many ;). Attached is a patch. Any comments are welcome.
Best,
--
Jacek Rosik [EMAIL PROTECTED]
Index: src/mesa/drivers/dri/r200/r200_state_init.c
===
--- src/mesa/drivers/dri/r200/r200_state_init.c (.../vendor/mesa/mesa-20050101) (wersja 22)
+++ src/mesa/drivers/dri/r200/r200_state_init.c (.../branches/radeon-viewport-1.0/mesa) (wersja 22)
@@ -492,6 +492,10 @@
else
rmesa-hw.ctx.cmd[CTX_RB3D_CNTL] |= rmesa-state.color.roundEnable;
+ /* Note that offset will get recalculated later on, when context
+* will be bound to a window. It will point to the top left corner
+* of window's viewport.
+*/
rmesa-hw.ctx.cmd[CTX_RB3D_COLOROFFSET] = ((rmesa-state.color.drawOffset +
rmesa-r200Screen-fbLocation)
R200_COLOROFFSET_MASK);
Index: src/mesa/drivers/dri/r200/r200_ioctl.c
===
--- src/mesa/drivers/dri/r200/r200_ioctl.c (.../vendor/mesa/mesa-20050101) (wersja 22)
+++ src/mesa/drivers/dri/r200/r200_ioctl.c (.../branches/radeon-viewport-1.0/mesa) (wersja 22)
@@ -138,10 +138,10 @@
if (rmesa-state.scissor.enabled) {
cmd.nbox = rmesa-state.scissor.numClipRects;
- cmd.boxes = (drm_clip_rect_t *)rmesa-state.scissor.pClipRects;
+ cmd.boxes = (drm_clip_rect_t *)rmesa-state.scissor.pClipRects3D;
} else {
cmd.nbox = rmesa-numClipRects;
- cmd.boxes =
Re: ARB_vertex_program and r200...
On Sat, Jan 29, 2005 at 01:47:22AM +, Dave Airlie wrote: I've noticed fglrx advertises this for the r200, and doom 3 wants it... So after I manage to beat fragment_shader into shape, going to have a look at how to get ARB_vp working.. r300 guys you have something going on this already? Well, last Friday, Vladimir said: * BIG TODO: write pixel and vertex shader generator code. This code would need to create vertex and pixel shaders based on the current state of GL context. There's headers for the pixel and vertex shaders in the r300_demo CVS, but they don't seem to be referenced by r300_demo. Vladimir? Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 depth tiling questions.
Jacek Rosik wrote: Yes, I meant depthPitch. They are the same but only for resolutions where width is multiple of 32. That's always the case (mode validation pitchInc was 64*pScrn-bitsPerPixel without color tiling), so you don't really need to round up to 32 for depth pitch. Depth pitch is rounded to be multiple of 32. Hmm... I think that is wrong since tile size seems to depend on fb depth and probably tiles on r100 also have different sizes. So this is correct only for r200 with 32bpp fb depth. You could be correct. Well you can try that with a resolution of 800x600 (and without color tiling), that should then give you wrong depth results. It might be possible though the chip actually handles depth buffers with not completely aligned pitches? So this would mean that depth buffer can start at different x,y than color buffer? Can someone with the docs confirm that. That's what I thought, just judging by the register bit... BTW: I have working solution for color but I wonder if this will work with color tiling. Of course offset Would have to be aligned to the closest tile. Can You take a look at it? (It's missing some bits but generaly apps which don't use depth should work Unfortunately I don't think there are many ;). Attached is a patch. Any comments are welcome. Unfortunately I can't really try that with my single monitor ;-). Roland --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 depth tiling questions.
Hi, Dnia 29-01-2005, sob o godzinie 11:19 +0100, Roland Scheidegger napisa(a): Jacek Rosik wrote: BTW: I have working solution for color but I wonder if this will work with color tiling. Of course offset Would have to be aligned to the closest tile. Can You take a look at it? (It's missing some bits but generaly apps which don't use depth should work Unfortunately I don't think there are many ;). Attached is a patch. Any comments are welcome. Unfortunately I can't really try that with my single monitor ;-). I also have single monitor at home. Just set virtual width to be greater than 2048 and move window far to the left. This is basically just like MergedFB works. I use 4000x2000 virtual resolution. Best, -- Jacek Rosik [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Question about grabbing X Window screen
Hello, I am complete newbie to this mailing list and to programming of modern graphic HW, but have the following problem: I want to grab complete X window screen (eg. root window) reasonably fast. When I use standard way by XGetImage, I am able to grab about 1.5 screen (1280x1024x32) per second having CPU usage 100%. (Athlon XP 1.8 GHz, ATI Radeon QD (AGP), X.Org 6.8.1, on P4 1.7GHz, integrated SiS graphic chip it was about 2.5 grabs per sec.). It is too slow, so I mmap-ed /dev/mem and memcpy linear framebuffer. To my surprise a got only slightly better results. I am using kernel 2.6.9, on ATI DRI was enabled, on SiS it was not. I suppose such simple operation can be done pretty fast, but don't know how. Could somebody with better understanding of graphic HW and Linux, point me where to look to learn more about it? Or even better, give me some idea how to do it simply and fast? Is the DRI right place to look at? I was googling about it for a while but didn't got much. Some documentation is at http://dri.freedesktop.org/wiki/Documentation but nothing like detailed description or even tutorial. What I actualy need is not high rate of grabbing - 4 times per second would be ok, if the CPU usage remains low. The program has not to be portable between various graphic cards. It would be nice if it is just a normal user-space program, not a kernel or X Server module. Just last question - would the more up to date graphic card make a big difference in speed of naive XGetImage/memcpy approach? TIA Martin --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ARB_vertex_program and r200...
On Saturday 29 January 2005 02:47, Dave Airlie wrote: I've noticed fglrx advertises this for the r200, and doom 3 wants it... So after I manage to beat fragment_shader into shape, going to have a look at how to get ARB_vp working.. r300 guys you have something going on this already? I don't have an R200, but the R200 registers related to vertex processing are *completely* different from those on the R300. Now maybe the R200 has both a dedicated fixed function pipeline *and* a programmable processor, but unless that is the case, I assume fglrx on R200 tries to map ARB_vp onto fixed function when it can, and falls back to software otherwise. Somebody with R200 hardware would have to test fglrx with the glxtest dumping tool to find out for sure. cu, Nicolai pgpRb0dLUiFNO.pgp Description: PGP signature
Re: ARB_vertex_program and r200...
are *completely* different from those on the R300. Now maybe the R200 has both a dedicated fixed function pipeline *and* a programmable processor, but unless that is the case, I assume fglrx on R200 tries to map ARB_vp onto fixed function when it can, and falls back to software otherwise. actually not sure myself which it might be... I'll switch over to fglrx tomorrow and run some tests... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM build problems?
This morning the radeon DRM won't build for me: CC [M] /usr/home/adamk/saved/source/drm/linux-core/ati_pcigart.o CC [M] /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error: `radeon_postinit' undeclared here (not in a function) /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error: initializer element is not constant /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error: (near initialization for `driver.postinit') /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:106: error: initializer element is not constant /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:106: error: (near initialization for `driver.fops') /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:112: error: initializer element is not constant /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:112: error: (near initialization for `driver.pci_driver') make[2]: *** [/usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o] Error 1 make[1]: *** [_module_/usr/home/adamk/saved/source/drm/linux-core] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.10' make: *** [modules] Error 2 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Question about grabbing X Window screen
On Sat, 2005-01-29 at 11:57 +0100, Martin Bouzek wrote: Hello, I am complete newbie to this mailing list and to programming of modern graphic HW, but have the following problem: I want to grab complete X window screen (eg. root window) reasonably fast. When I use standard way by XGetImage, I am able to grab about 1.5 screen (1280x1024x32) per second having CPU usage 100%. (Athlon XP 1.8 GHz, ATI Radeon QD (AGP), X.Org 6.8.1, on P4 1.7GHz, integrated SiS graphic chip it was about 2.5 grabs per sec.). It is too slow, so I mmap-ed /dev/mem and memcpy linear framebuffer. To my surprise a got only slightly better results. I am using kernel 2.6.9, on ATI DRI was enabled, on SiS it was not. DRI is not involved in this, so really off-topic for this list. (In the future, using DRI as the basis for 2D acceleration might happen. Currently it's only used for 3D graphics.) This would really be better on the [EMAIL PROTECTED] mailing list. I'll answer quickly anyways. 10 megabytes/sec is really not that unreasonable for read speads over PCI (AGP isn't used for reading by the CPU from the frame buffer). Your /dev/mem tests probably indicate pretty much the maximimal possible rate for this technique. (You could try writing a manual memcpy loop using 32-bit quantities or, using MMX, 64-bit quantities. My experience is that doesn't really help, but your milage may vary.) The only real way to do better is to program the card to DMA the data to the CPU. I believe the proprietary nvidia driver does that. I'm not aware of any open-source driver that accelerates GetImage that way. One thing you might want to try is running the 'vesa' driver with the ShadowFB option enabled. All drawing will then be in software and the framebuffer will be in system memory. While drawing will be a bit slower, grabbing the screen image via GetImage will be much faster. If you can get around the video card = cpu bottleneck, you'd probably get better throughput for Xserver = app by using a shared memory pixmap and doing a CopyArea to it. Regards, Owen signature.asc Description: This is a digitally signed message part
Mesa linux-dri fails to build
This mornings cvs snapshot of Mesa using linux-dri config fails to build. A missing drm.h file... It builds fine using linux-x86, but I want it for the r300 stuff, so assuming I acytually need the linux-dri build... is there a date tag I can use that will build? TIA Hamish Marson --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Mesa linux-dri fails to build
On Saturday 29 January 2005 17:21, Hamie wrote: This mornings cvs snapshot of Mesa using linux-dri config fails to build. A missing drm.h file... It builds fine using linux-x86, but I want it for the r300 stuff, so assuming I acytually need the linux-dri build... is there a date tag I can use that will build? You also need to check out drm CVS: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/dri co drm Do this from the directory above your Mesa dir, so that the Mesa and drm directories are in the same directory. - ajax pgpD1lTlShL0E.pgp Description: PGP signature
Re: Mesa linux-dri fails to build
Adam Jackson wrote: On Saturday 29 January 2005 17:21, Hamie wrote: This mornings cvs snapshot of Mesa using linux-dri config fails to build. A missing drm.h file... It builds fine using linux-x86, but I want it for the r300 stuff, so assuming I acytually need the linux-dri build... is there a date tag I can use that will build? You also need to check out drm CVS: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/dri co drm Do this from the directory above your Mesa dir, so that the Mesa and drm directories are in the same directory. - ajax Ah bugger. Thanks. I knew it was something simple. I had a drm cvs, but it wasn't there... H --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
On Fri, 28 Jan 2005, Rune Petersen wrote: Vladimir Dergachev wrote: On Thu, 27 Jan 2005, Rune Petersen wrote: Hi, I get lockups running anything other than glxgears. I am running the 25 jan. snapshots of Xorg r300_driver. Are there any simple way to locate the functions that course lockups? I was thinking of something like simple programs or tutorials. Try NeHe tutorial - nehe.gamedev.net In particular, it would be interesting to find out whether you can run any programs that use textures. for now I have tried lessons up to lesson 20. only 2 give me problems Lesson 16 causes a segfault. Can you make the driver recover the original resolution after a segfault? Lesson 20 causes a hard lockup. Can you confirm if these Lessons work on R300? Hi Rune, I see the same problems on R300. I guess the segfault is possibly due to trying to access framebuffer directly (as using fog triggers a fallback). As for lesson20 I have no idea - try commenting out drawing code and checking which part creates a lockup. Btw, I am getting a partial lockup with lesson20 even without r300_dri.so (when it is absent the driver falls back to software rendering), so it might be due to mode switching. best Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 depth tiling questions.
Jacek Rosik wrote:
Hi
Dnia 29-01-2005, sob o godzinie 02:29 +0100, Stephane Marchesin
napisa(a):
Roland Scheidegger wrote:
I don't quite follow third line before last? Can someone enlighten me?
You mean the pitch 0x20 stuff? Yeah, looks strange.
Looking at it, it seems like it ensures that each block line starts
with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will
have set that (for x 0-31) to 0, y 16-31 to 1 and so on.
Seems to me like it might be related to how the ram is organized (e.g.
something like ensuring it's on a different memory channel or
different bank or whatnot).
This is, btw, quite similarly strange to what Stephane needed on his
rv100 to get the correct pixel address for color tiling, this one also
tinkered with that 11th bit (see RadeonDoAdjustFrame).
Also, since Jacek is interested in depth tiling, I have to mention that
on my rv100, the depth buffer is not tiled until you use hyperz.
Then when hyperz is used, the depth buffer becomes tiled. The depth
tiling function is currently unknown (I still have to RE it) but it
doesn't seem to work if I use the r100 or r200 depth tiling functions as
defined in {radeon,r200}_span.c.
Would 7000 PCI be a rv100? I think I have one somewhere. Without depth
tiling my Idea should be simpler to implement.
Yes. But, I'd like to have hyperz enabled by default soon, so you'll
probably have to deal with depth tiling on this card too.
Anyway it might be useful for some testing.
Generally if one could explain tiling a bit for me I would be
grateful. What I'm trying to do is to is to modify depthOffset to be
as close to top-left corner of viewport as possible and modify. I
this possible with shared depth buffer. This means that each 3D
window would have different depthOffset but pointing to the same
shared buffer.
I'm not sure if it's possible to do that with depthOffset (well
maybe). There is however an interesting bit in RB3D_CNTL
(R200_DEPTH_XZ_OFFEST_ENABLE, I guess XZ is a typo, just as is
OFFEST?) and the corresponding (?) register
(R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly
invented for that...
Yes, AFAICT the same thing (private z buffers) should work on r100.
Now I think the real trouble with private z buffers is how these will
interfere with hyperz...
Huh I thought that hyperz would be simpler with private z buffers. What
about private z buffers and private back buffers. Since most
applications render only to back that would make them as fullscreen
applications. Wouldn't It be simpler to implement hyperz and color
tiling then?
The trouble with hyperz is we're not quite sure how it works for the
corner cases (for example I'm not sure if it's possible to have private
depth buffers + hyperz).
Not to mention that private depth or back buffers are a real pain to add
since you'd need a fb memory allocator.
Btw, you don't want a private back buffer because this would disable
pageflip (which is way faster than the copy).
Stephane
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
Vladimir Dergachev wrote: Hi, I get lockups running anything other than glxgears. I am running the 25 jan. snapshots of Xorg r300_driver. Are there any simple way to locate the functions that course lockups? I was thinking of something like simple programs or tutorials. Try NeHe tutorial - nehe.gamedev.net In particular, it would be interesting to find out whether you can run any programs that use textures. for now I have tried lessons up to lesson 20. only 2 give me problems Lesson 16 causes a segfault. Can you make the driver recover the original resolution after a segfault? Lesson 20 causes a hard lockup. Can you confirm if these Lessons work on R300? Hi Rune, I see the same problems on R300. I guess the segfault is possibly due to trying to access framebuffer directly (as using fog triggers a fallback). As for lesson20 I have no idea - try commenting out drawing code and checking which part creates a lockup. Btw, I am getting a partial lockup with lesson20 even without r300_dri.so (when it is absent the driver falls back to software rendering), so it might be due to mode switching. Lesson 20 have 3 points that causes lockups (maybe more). They are all related. the first is at line 258-259: glBindTexture(GL_TEXTURE_2D, texture[3]); glBegin(GL_QUADS); glBegin() is causing the lockup, but only when textures 1, 2, or 3. if you change it to texture 4: glBindTexture(GL_TEXTURE_2D, texture[4]); glBegin(GL_QUADS); The lesson will now run (until you press space). To me it sounds rather strange that a texture causes the lockup. Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: DRI and Composite
On Fri, 2005-01-28 at 12:50 +0100, Amir Bukhari wrote: Indeed, it's our driver that disables the DRI if Composite is enabled, not the DRI in general. I expect that to stay the same until the two are properly integrated with each other (but it's not my decision to make). If some could point us to the code in the driver which disable DRI when composite is enable we could experiment with it and build for our users binaries for use with lg3d! fglrx is ATI proprietary... -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 on Thinkpad r50p
It's working... Mostly... I get pretty good rates on glxgears... But get a funny error about not enought verticies... [EMAIL PROTECTED]:~$ glxgears r300NewProgram, target=34336, id=0 vertex prog r300NewProgram, target=34820, id=0 fragment prog r300NewProgram, target=35104, id=0 ati fragment prog Using 8 maximum texture units.. r300_render.c:r300_get_primitive_type Not enough vertices to draw primitive 08 - help me ! 8143 frames in 5.0 seconds = 1628.600 FPS 8310 frames in 5.0 seconds = 1662.000 FPS 8241 frames in 5.0 seconds = 1648.200 FPS 8326 frames in 5.0 seconds = 1665.200 FPS 8304 frames in 5.0 seconds = 1660.800 FPS 8317 frames in 5.0 seconds = 1663.400 FPS Not sure if anyone else gets it... I have to take a look see if I undertsand why I get it. Hamish. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM build problems?
On Sat, 29 Jan 2005 09:30:33 -0500, Adam K Kirchhoff [EMAIL PROTECTED] wrote: This morning the radeon DRM won't build for me: CC [M] /usr/home/adamk/saved/source/drm/linux-core/ati_pcigart.o CC [M] /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error: `radeon_postinit' undeclared here (not in a function) /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error: initializer element is not constant /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error: (near initialization for `driver.postinit') /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:106: error: initializer element is not constant /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:106: error: (near initialization for `driver.fops') /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:112: error: initializer element is not constant /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:112: error: (near initialization for `driver.pci_driver') make[2]: *** [/usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o] Error 1 make[1]: *** [_module_/usr/home/adamk/saved/source/drm/linux-core] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.10' make: *** [modules] Error 2 yeah I'm getting the same error. I haven't had time to investigate further. Alex --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM build problems?
On Sat, 29 Jan 2005 16:58:37 -0500, Alex Deucher [EMAIL PROTECTED] wrote: On Sat, 29 Jan 2005 09:30:33 -0500, Adam K Kirchhoff [EMAIL PROTECTED] wrote: This morning the radeon DRM won't build for me: CC [M] /usr/home/adamk/saved/source/drm/linux-core/ati_pcigart.o CC [M] /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error: `radeon_postinit' undeclared here (not in a function) /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error: initializer element is not constant /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error: (near initialization for `driver.postinit') /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:106: error: initializer element is not constant /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:106: error: (near initialization for `driver.fops') /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:112: error: initializer element is not constant /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:112: error: (near initialization for `driver.pci_driver') make[2]: *** [/usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o] Error 1 make[1]: *** [_module_/usr/home/adamk/saved/source/drm/linux-core] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.10' make: *** [modules] Error 2 yeah I'm getting the same error. I haven't had time to investigate further. Alex change: .postinit = radeon_postinit, to: .postinit = postinit, And all builds fine. Alex --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
fallback). As for lesson20 I have no idea - try commenting out drawing code and checking which part creates a lockup. Btw, I am getting a partial lockup with lesson20 even without r300_dri.so (when it is absent the driver falls back to software rendering), so it might be due to mode switching. Lesson 20 have 3 points that causes lockups (maybe more). They are all related. the first is at line 258-259: glBindTexture(GL_TEXTURE_2D, texture[3]); glBegin(GL_QUADS); glBegin() is causing the lockup, but only when textures 1, 2, or 3. if you change it to texture 4: glBindTexture(GL_TEXTURE_2D, texture[4]); glBegin(GL_QUADS); The lesson will now run (until you press space). To me it sounds rather strange that a texture causes the lockup. This is indeed strange.. Is texture[4] used anywhere before ? Does the same happen with latest CVS ? thank you ! Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 on Thinkpad r50p
On Sun, 30 Jan 2005, Hamie wrote: It's working... Mostly... I get pretty good rates on glxgears... But get a funny error about not enought verticies... [EMAIL PROTECTED]:~$ glxgears r300NewProgram, target=34336, id=0 vertex prog r300NewProgram, target=34820, id=0 fragment prog r300NewProgram, target=35104, id=0 ati fragment prog Using 8 maximum texture units.. r300_render.c:r300_get_primitive_type Not enough vertices to draw primitive 08 - help me ! 8143 frames in 5.0 seconds = 1628.600 FPS 8310 frames in 5.0 seconds = 1662.000 FPS 8241 frames in 5.0 seconds = 1648.200 FPS 8326 frames in 5.0 seconds = 1665.200 FPS 8304 frames in 5.0 seconds = 1660.800 FPS 8317 frames in 5.0 seconds = 1663.400 FPS Not sure if anyone else gets it... I have to take a look see if I undertsand why I get it. Looks like everyone gets it - glxgears has begin/end pair with only two vertices for a triangle primitive - maybe a bug.. best Vladimir Dergachev Hamish. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 on Thinkpad r50p
Am Samstag, den 29.01.2005, 17:25 -0500 schrieb Vladimir Dergachev: On Sun, 30 Jan 2005, Hamie wrote: It's working... Mostly... I get pretty good rates on glxgears... But get a funny error about not enought verticies... [EMAIL PROTECTED]:~$ glxgears r300NewProgram, target=34336, id=0 vertex prog r300NewProgram, target=34820, id=0 fragment prog r300NewProgram, target=35104, id=0 ati fragment prog Using 8 maximum texture units.. r300_render.c:r300_get_primitive_type Not enough vertices to draw primitive 08 - help me ! 8143 frames in 5.0 seconds = 1628.600 FPS 8310 frames in 5.0 seconds = 1662.000 FPS 8241 frames in 5.0 seconds = 1648.200 FPS 8326 frames in 5.0 seconds = 1665.200 FPS 8304 frames in 5.0 seconds = 1660.800 FPS 8317 frames in 5.0 seconds = 1663.400 FPS Not sure if anyone else gets it... I have to take a look see if I undertsand why I get it. Looks like everyone gets it - glxgears has begin/end pair with only two vertices for a triangle primitive - maybe a bug.. I saw something like this too, when I implemented and debugged the savage fast path. I don't think it's glxgear's fault. More likely a problem further up in the mesa pipeline. (or are you bypassing the pipeline in the r300 driver?) The t_dd_dmatmp.h template ignores extra vertices that don't add up to a whole primitive. I guess you could do the same. best Vladimir Dergachev -- | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM build problems?
initializer element is not constant /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:112: error: (near initialization for `driver.pci_driver') make[2]: *** [/usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o] Error 1 make[1]: *** [_module_/usr/home/adamk/saved/source/drm/linux-core] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.10' make: *** [modules] Error 2 sorry about that, half a checkin ... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
Vladimir Dergachev wrote: Lesson 20 have 3 points that causes lockups (maybe more). They are all related. the first is at line 258-259: glBindTexture(GL_TEXTURE_2D, texture[3]); glBegin(GL_QUADS); glBegin() is causing the lockup, but only when textures 1, 2, or 3. if you change it to texture 4: glBindTexture(GL_TEXTURE_2D, texture[4]); glBegin(GL_QUADS); The lesson will now run (until you press space). To me it sounds rather strange that a texture causes the lockup. This is indeed strange.. Is texture[4] used anywhere before ? Does the same happen with latest CVS ? There are 5 textures 0 to 4 (including 2 masks ) texture 0 and 4 appear stable 1-3 appear unstable. With the latest CVS I once managed to run the lesson for 3 sec. before it locked up . All other times I got a lockup before it showed the first frame. Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2418] New: Lockup using linux-core on radeon
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=2418 Summary: Lockup using linux-core on radeon Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I use vanilla 2.6.10 (from kernel.org) and drm cvs of 30/01/2005 (so it includes the recent drm fixes) on a radeon 7000. When I modprobe radeon.ko from linux-core, the machine locks up (I can still ping it, but I can't ssh in the box so it looks like it's stuck somewhere in kernel). However, it works fine if I use the linux-2.6 (non core) version. When this happens, I don't find anything in /var/log/messages after a reboot. -- 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. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2419] New: Solo crashes on ia64 on startup
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=2419 Summary: Solo crashes on ia64 on startup Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] When I use solo on ia64, it sometimes causes an MCA upon startup. That's because a memset is done on the framebuffer memory during init. Please refer to this message from Jesse Barnes to know why this is bad : http://sourceforge.net/mailarchive/forum.php?thread_id=6354420forum_id=7177 Here is a patch that fixes this by changing the memset into a for() loop doing memory access one byte at a time : http://icps.u-strasbg.fr/~marchesin/dri/ia64_solo_memset.patch -- 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. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 on Thinkpad r50p
Not sure if anyone else gets it... I have to take a look see if I undertsand why I get it. Looks like everyone gets it - glxgears has begin/end pair with only two vertices for a triangle primitive - maybe a bug.. I saw something like this too, when I implemented and debugged the savage fast path. I don't think it's glxgear's fault. More likely a problem further up in the mesa pipeline. (or are you bypassing the pipeline in the r300 driver?) The t_dd_dmatmp.h template ignores extra vertices that don't add up to a whole primitive. I guess you could do the same. I think we are bypassing it, though I am not really sure. r300 driver does not use any templates - I did not have time to find out how to use those. Both mga and r200 use them in a different way, mga driver way appears to be simpler, but does not use vertex buffers (at least in a way I can understand), also it looks like mga hardware cannot do all primitives natively, while r300 can. best Vladimir Dergachev --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] 3D lockups on R420
On Sun, 30 Jan 2005, Rune Petersen wrote: Vladimir Dergachev wrote: Lesson 20 have 3 points that causes lockups (maybe more). They are all related. the first is at line 258-259: glBindTexture(GL_TEXTURE_2D, texture[3]); glBegin(GL_QUADS); glBegin() is causing the lockup, but only when textures 1, 2, or 3. if you change it to texture 4: glBindTexture(GL_TEXTURE_2D, texture[4]); glBegin(GL_QUADS); The lesson will now run (until you press space). To me it sounds rather strange that a texture causes the lockup. This is indeed strange.. Is texture[4] used anywhere before ? Does the same happen with latest CVS ? There are 5 textures 0 to 4 (including 2 masks ) texture 0 and 4 appear stable 1-3 appear unstable. With the latest CVS I once managed to run the lesson for 3 sec. before it locked up . All other times I got a lockup before it showed the first frame. Does the same happen if you load them in a different order ? What is the difference between these textures ? thank you Vladimir Dergachev Rune Petersen --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r200 fragment shader and constants
Currently the r200 driver has TFACTOR_0 packet, which takes 6 constants, however there are actually 8 constant registers used in ATI_fs and the two extra are just after the the other 6 So what is the best way to approach adding thse two, a) define a new packet for just 2 elements.. makes constant code a bit icky.. b) define a new packet for 8 elements, make driver use it everywhere, leave old code in DRM for backwards compat... (not sure this is possible, as it uses the register address to work things out...) Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r200 fragment shader and constants
b) define a new packet for 8 elements, make driver use it everywhere, leave old code in DRM for backwards compat... (not sure this is possible, as it uses the register address to work things out...) actually this is what I've done for the pixshader vs fragshader instructions. which overlap.. so I'll do the same thing... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R200 depth tiling questions.
Hi
Dnia 29-01-2005, sob o godzinie 02:29 +0100, Stephane Marchesin
napisa(a):
Roland Scheidegger wrote:
I don't quite follow third line before last? Can someone enlighten me?
You mean the pitch 0x20 stuff? Yeah, looks strange.
Looking at it, it seems like it ensures that each block line starts
with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will
have set that (for x 0-31) to 0, y 16-31 to 1 and so on.
Seems to me like it might be related to how the ram is organized (e.g.
something like ensuring it's on a different memory channel or
different bank or whatnot).
This is, btw, quite similarly strange to what Stephane needed on his
rv100 to get the correct pixel address for color tiling, this one also
tinkered with that 11th bit (see RadeonDoAdjustFrame).
Also, since Jacek is interested in depth tiling, I have to mention that
on my rv100, the depth buffer is not tiled until you use hyperz.
Then when hyperz is used, the depth buffer becomes tiled. The depth
tiling function is currently unknown (I still have to RE it) but it
doesn't seem to work if I use the r100 or r200 depth tiling functions as
defined in {radeon,r200}_span.c.
Would 7000 PCI be a rv100? I think I have one somewhere. Without depth
tiling my Idea should be simpler to implement.
Generally if one could explain tiling a bit for me I would be
grateful. What I'm trying to do is to is to modify depthOffset to be
as close to top-left corner of viewport as possible and modify. I
this possible with shared depth buffer. This means that each 3D
window would have different depthOffset but pointing to the same
shared buffer.
I'm not sure if it's possible to do that with depthOffset (well
maybe). There is however an interesting bit in RB3D_CNTL
(R200_DEPTH_XZ_OFFEST_ENABLE, I guess XZ is a typo, just as is
OFFEST?) and the corresponding (?) register
(R200_RB3D_DEPTHXY_OFFSET), which sound to me like they are exactly
invented for that...
Yes, AFAICT the same thing (private z buffers) should work on r100.
Now I think the real trouble with private z buffers is how these will
interfere with hyperz...
Huh I thought that hyperz would be simpler with private z buffers. What
about private z buffers and private back buffers. Since most
applications render only to back that would make them as fullscreen
applications. Wouldn't It be simpler to implement hyperz and color
tiling then?
Best,
--
Jacek Rosik [EMAIL PROTECTED]
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag--drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
