Re: New ioctl for surface allocation/deallocation
> Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback > (both on the idea and the implementation) before I build anything upon it. I'm thinking this could be applicable to a number of devices, so maybe a generic ioctl might be a better idea with some card specific hooks.. Or is there something radeon specific about it I missed... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Pci init code for mesa solo on radeon
Applied - since I suppose I'm looking after solo under the touched it last rule :-) Dave. On Wed, 8 Dec 2004, Stephane Marchesin wrote: > Hi, > > Attached is a patch that adds pci init code for mesa solo on radeon. It's been > tested on an itanium 2 with a radeon 7000 and it works here. > The patch adds a new field in the miniglx.conf config file, to choose between > pci and agp. > > Stephane > > -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New ioctl for surface allocation/deallocation
On Wed, 2004-12-08 at 02:54 +0100, Stephane Marchesin wrote:
>
> The small attached patch adds a new drm ioctl to do surface
> allocation/deallocation on the radeon.
[...]
> Any comments ? I'ts untested, but that's my first ioctl, so I wanted
> feedback (both on the idea and the implementation) before I build
> anything upon it.
I think it's a good start but still missing some details.
> + // allocate the surface
> + for(i=0;i<8;i++)
> + if (!(dev_priv->surfaces&(1< + break;
> +
> + if (i>=8)
> + return DRM_ERR(ENOMEM);
> + else
> + dev_priv->surfaces&=(1< +
> + if ( DRM_COPY_TO_USER( &alloc.surface, &i,
> +sizeof(int) ) ) {
> + DRM_ERROR( "copy_to_user\n" );
> + return DRM_ERR(EFAULT);
IMHO it should also manage the ranges (prevent overlapping, ...) and
parameters of the surfaces.
> + DRM_COPY_FROM_USER_IOCTL( memfree, (drm_radeon_mem_free_t __user *)data,
> + sizeof(memfree) );
> +
> + dev_priv->surfaces&= (~(1
[Bug 2010] depth and stencil readback are broken beyond x > 1023
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=2010 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-12-07 19:28 --- Roland Scheidegger wrote: > and 2047 is > the current limit for 3d rendering anyway). Where does this limit come from ? Is that just one of the MESA-specific "artificial clamps" or something else ? -- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2010] depth and stencil readback are broken beyond x > 1023
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=2010 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-12-07 19:10 --- fixed in cvs (with new limit 2047 instead of 1023, since I don't quite understand if there could be issues if it's increased beyond limits, and 2047 is the current limit for 3d rendering anyway). -- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Reverse engineering ati driver
Stephane Marchesin wrote: Fully? Was HyperZ only missing feature? There are at least 2 other features : - pixel shaders (ATI_fragment_shader). It's R200 only. - occlusion culling (ARB_occlusion_query and friends). Same on R100 and R200. I started working on this one and know the registers numbers and usage, I even began writing some code. Trouble is, it's the first driver that would accelerate occlusion queries and some modifications are needed in Mesa, which I still have to figure out. I have to add one more here : - TCL arrays (this work could benefit both r200 and r300, according to my understanding of the ati driver). It uses type 3 packets 33, 36 and 2F. Stephane --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Pci init code for mesa solo on radeon
Hi,
Attached is a patch that adds pci init code for mesa solo on radeon.
It's been tested on an itanium 2 with a radeon 7000 and it works here.
The patch adds a new field in the miniglx.conf config file, to choose
between pci and agp.
Stephane
Index: src/glx/mini/driver.h
===
RCS file: /cvs/mesa/Mesa/src/glx/mini/driver.h,v
retrieving revision 1.4
diff -u -r1.4 driver.h
--- src/glx/mini/driver.h 5 Jul 2004 23:42:02 - 1.4
+++ src/glx/mini/driver.h 8 Dec 2004 02:14:08 -
@@ -67,7 +67,8 @@
int bpp;
int cpp;
int agpmode;
-
+ int isPCI;
+
unsigned long FBStart; /**< \brief physical address of the framebuffer */
unsigned long MMIOStart; /**< \brief physical address of the MMIO region */
Index: src/glx/mini/example.miniglx.conf
===
RCS file: /cvs/mesa/Mesa/src/glx/mini/example.miniglx.conf,v
retrieving revision 1.2
diff -u -r1.2 example.miniglx.conf
--- src/glx/mini/example.miniglx.conf 14 Apr 2004 02:14:15 - 1.2
+++ src/glx/mini/example.miniglx.conf 8 Dec 2004 02:14:08 -
@@ -14,6 +14,9 @@
# look in /proc/pci.
pciBusID=PCI:1:0:0
+# Is the card PCI or AGP ?
+isPCI=0
+
# Virtual screen dimensions. Can reduce this to save videocard memory
# at the expense of maximum window size available.
virtualWidth=1280
Index: src/glx/mini/miniglx.c
===
RCS file: /cvs/mesa/Mesa/src/glx/mini/miniglx.c,v
retrieving revision 1.15
diff -u -r1.15 miniglx.c
--- src/glx/mini/miniglx.c 29 Nov 2004 17:26:19 - 1.15
+++ src/glx/mini/miniglx.c 8 Dec 2004 02:14:11 -
@@ -830,6 +830,7 @@
dpy->driverContext.cpp = 4;
dpy->rotateMode = 0;
dpy->driverContext.agpmode = 1;
+ dpy->driverContext.isPCI = 0;
fname = getenv("MINIGLX_CONF");
if (!fname) fname = "/etc/miniglx.conf";
@@ -899,6 +900,9 @@
if (sscanf(val, "%d", &dpy->driverContext.agpmode) != 1)
fprintf(stderr, "malformed agpmode: %s\n", opt);
}
+ else if (strcmp(opt, "isPCI") == 0) {
+dpy->driverContext.isPCI = atoi(val) ? 1 : 0;
+ }
}
fclose(file);
Index: src/mesa/drivers/dri/radeon/server/radeon.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/server/radeon.h,v
retrieving revision 1.6
diff -u -r1.6 radeon.h
--- src/mesa/drivers/dri/radeon/server/radeon.h 2 Jun 2004 05:07:11 -
1.6
+++ src/mesa/drivers/dri/radeon/server/radeon.h 8 Dec 2004 02:14:11 -
@@ -109,6 +109,8 @@
drmSize registerSize; /**< \brief MMIO register map size */
drm_handle_t registerHandle; /**< \brief MMIO register map handle
*/
+ int IsPCI;/* Current card is a PCI card */
+
/**
* \name AGP
*/
Index: src/mesa/drivers/dri/radeon/server/radeon_dri.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/radeon/server/radeon_dri.c,v
retrieving revision 1.13
diff -u -r1.13 radeon_dri.c
--- src/mesa/drivers/dri/radeon/server/radeon_dri.c 10 Jul 2004 21:17:52
- 1.13
+++ src/mesa/drivers/dri/radeon/server/radeon_dri.c 8 Dec 2004 02:14:11
-
@@ -421,6 +421,88 @@
return 1;
}
+/* Initialize the PCI GART state. Request memory for use in PCI space,
+ * and initialize the Radeon registers to point to that memory.
+ */
+static int RADEONDRIPciInit(const DRIDriverContext *ctx, RADEONInfoPtr info)
+{
+int ret;
+int flags = DRM_READ_ONLY | DRM_LOCKED | DRM_KERNEL;
+ints, l;
+
+ret = drmScatterGatherAlloc(ctx->drmFD, info->gartSize*1024*1024,
+ &info->gartMemHandle);
+if (ret < 0) {
+ fprintf(stderr, "[pci] Out of memory (%d)\n", ret);
+ return 0;
+}
+fprintf(stderr,
+ "[pci] %d kB allocated with handle 0x%08x\n",
+ info->gartSize*1024, info->gartMemHandle);
+
+ info->gartOffset = 0;
+
+ /* Initialize the CP ring buffer data */
+ info->ringStart = info->gartOffset;
+ info->ringMapSize = info->ringSize*1024*1024 + DRM_PAGE_SIZE;
+
+ info->ringReadOffset = info->ringStart + info->ringMapSize;
+ info->ringReadMapSize = DRM_PAGE_SIZE;
+
+ /* Reserve space for vertex/indirect buffers */
+ info->bufStart= info->ringReadOffset + info->ringReadMapSize;
+ info->bufMapSize = info->bufSize*1024*1024;
+
+ /* Reserve the rest for AGP textures */
+ info->gartTexStart = info->bufStart + info->bufMapSize;
+ s = (info->gartSize*1024*1024 - info->gartTexStart);
+ l = RADEONMinBits((s-1) / RADEON_NR_TEX_REGIONS);
+ if (l < RADEON_LOG_TEX_GRANULARITY) l = RADEON_LOG_TEX_GRANULARITY;
+ info->gartTexMapSize = (s >> l) << l;
+ info->log2GARTTexGran = l;
+
+
New ioctl for surface allocation/deallocation
Hi,
The small attached patch adds a new drm ioctl to do surface
allocation/deallocation on the radeon.
The reason to add a new ioctl is the following : since there are only 8
surfaces someone has to arbitrate between allocations by the ddx (color
buffers) and from the dri (depth buffers). Doing it this way is more
future proof than statically allocating them (for example, if we once do
private z buffers or pbuffers these will be created/destroyed on the fly).
Any comments ? I'ts untested, but that's my first ioctl, so I wanted
feedback (both on the idea and the implementation) before I build
anything upon it.
Stephane
PS : I jumped to drm version 1.14 directly because hyperz already has 1.13
? linux/build
? linux/drm_pciids.h
Index: shared/radeon.h
===
RCS file: /cvs/dri/drm/shared/radeon.h,v
retrieving revision 1.33
diff -u -r1.33 radeon.h
--- shared/radeon.h 23 Oct 2004 06:25:56 - 1.33
+++ shared/radeon.h 8 Dec 2004 01:43:53 -
@@ -45,7 +45,7 @@
#define DRIVER_DATE"20020828"
#define DRIVER_MAJOR 1
-#define DRIVER_MINOR 12
+#define DRIVER_MINOR 14
#define DRIVER_PATCHLEVEL 0
/* Interface history:
@@ -82,6 +82,7 @@
* and GL_EXT_blend_[func|equation]_separate on r200
* 1.12- Add R300 CP microcode support - this just loads the CP on r300
* (No 3D support yet - just microcode loading).
+ * 1.14- Add R100/R200 surface allocation/free support
*/
#define DRIVER_IOCTLS \
[DRM_IOCTL_NR(DRM_IOCTL_DMA)] = { radeon_cp_buffers, 1, 0 }, \
@@ -110,5 +111,7 @@
[DRM_IOCTL_NR(DRM_IOCTL_RADEON_IRQ_EMIT)] = { radeon_irq_emit,1, 0 }, \
[DRM_IOCTL_NR(DRM_IOCTL_RADEON_IRQ_WAIT)] = { radeon_irq_wait,1, 0 }, \
[DRM_IOCTL_NR(DRM_IOCTL_RADEON_SETPARAM)] = { radeon_cp_setparam, 1, 0 }, \
+ [DRM_IOCTL_NR(DRM_IOCTL_RADEON_SURF_ALLOC)] = { radeon_surface_alloc,1, 0 }, \
+ [DRM_IOCTL_NR(DRM_IOCTL_RADEON_SURF_FREE)] = { radeon_surface_free ,1, 0 }, \
#endif
Index: shared/radeon_cp.c
===
RCS file: /cvs/dri/drm/shared/radeon_cp.c,v
retrieving revision 1.45
diff -u -r1.45 radeon_cp.c
--- shared/radeon_cp.c 23 Oct 2004 06:25:56 - 1.45
+++ shared/radeon_cp.c 8 Dec 2004 01:43:54 -
@@ -1519,6 +1519,8 @@
radeon_cp_init_ring_buffer( dev, dev_priv );
dev_priv->last_buf = 0;
+
+ dev_priv->surfaces = 0;
radeon_do_engine_reset( dev );
Index: shared/radeon_drm.h
===
RCS file: /cvs/dri/drm/shared/radeon_drm.h,v
retrieving revision 1.24
diff -u -r1.24 radeon_drm.h
--- shared/radeon_drm.h 23 Oct 2004 06:25:56 - 1.24
+++ shared/radeon_drm.h 8 Dec 2004 01:43:54 -
@@ -399,6 +399,8 @@
#define DRM_RADEON_IRQ_WAIT 0x17
#define DRM_RADEON_CP_RESUME 0x18
#define DRM_RADEON_SETPARAM 0x19
+#define DRM_RADEON_SURF_ALLOC 0x20
+#define DRM_RADEON_SURF_FREE 0x21
#define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_RADEON_CP_INIT, drm_radeon_init_t)
#define DRM_IOCTL_RADEON_CP_START DRM_IO( DRM_COMMAND_BASE +
DRM_RADEON_CP_START)
@@ -425,6 +427,8 @@
#define DRM_IOCTL_RADEON_IRQ_WAIT DRM_IOW( DRM_COMMAND_BASE +
DRM_RADEON_IRQ_WAIT, drm_radeon_irq_wait_t)
#define DRM_IOCTL_RADEON_CP_RESUME DRM_IO( DRM_COMMAND_BASE +
DRM_RADEON_CP_RESUME)
#define DRM_IOCTL_RADEON_SETPARAM DRM_IOW( DRM_COMMAND_BASE +
DRM_RADEON_SETPARAM, drm_radeon_setparam_t)
+#define DRM_IOCTL_RADEON_SURF_ALLOC DRM_IOWR(DRM_COMMAND_BASE +
DRM_RADEON_SURF_ALLOC, drm_radeon_surface_alloc_t)
+#define DRM_IOCTL_RADEON_SURF_FREE DRM_IOW( DRM_COMMAND_BASE +
DRM_RADEON_SURF_FREE, drm_radeon_surface_free_t)
typedef struct drm_radeon_init {
enum {
@@ -624,6 +628,18 @@
int64_t value;
} drm_radeon_setparam_t;
+/* 1.14: Clients can allocate/free a surface
+ */
+
+typedef struct drm_radeon_surface_alloc {
+ int surface;
+} drm_radeon_surface_alloc_t;
+
+typedef struct drm_radeon_surface_free {
+ int surface;
+} drm_radeon_surface_free_t;
+
+
#define RADEON_SETPARAM_FB_LOCATION1 /* determined framebuffer location */
Index: shared/radeon_drv.h
===
RCS file: /cvs/dri/drm/shared/radeon_drv.h,v
retrieving revision 1.37
diff -u -r1.37 radeon_drv.h
--- shared/radeon_drv.h 9 Nov 2004 00:54:19 - 1.37
+++ shared/radeon_drv.h 8 Dec 2004 01:43:55 -
@@ -185,6 +185,8 @@
struct mem_block *gart_heap;
struct mem_block *fb_heap;
+ u32 surfaces;
+
/* SW interrupt */
wait_queue_head_t swi_queue;
atomic_t swi_emitted;
@@ -239,6 +241,8 @@
extern int radeon_mem_init_heap( DRM_IOCTL_ARGS );
extern void radeon_mem_takedown( struct mem_block **heap );
extern v
[Bug 2026] bzflag crashes R200 DRI
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=2026 --- Additional Comments From [EMAIL PROTECTED] 2004-12-07 15:40 --- Oh, and I forgot to mention, this is a SMP system. -- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: new hyperz patch
Dieter Nützel wrote:
True for DoomIII, but who can switch the lights ON, finally...?
;-)
That is some weird texcoord problem. (I actually have a one-line
workaround for that, which breaks submitting texgen and non-texgen
coordinates at the same time more or less completely).
Let me test.
Attached. I've also included the 2nd one-liner in this patch, don't know
if it changes anything with doom3 (but using swtcl fallback for
gl_sphere_map is very problematic at least in nwn).
'Zooming' a 3D VTK prog from the upper left corner into a bigger
window in the desktop middle show missing z/buffer
clearing/redraw.
Was OK before.
Hmm, do you have a screenshot of that (or preferably more than one,
I'm interested what happens when you move the window from top-left
to top-right, bottom-left and bottom-right)?
No zoom, then nothing.
So if you only move the window, everything is ok? That's weird.
After zoom only the lower, left part of the window would be redrawn
right. In all places.
See our domain ;-)
http://www.nuetzel-hh.de/public
Looks like if you zoom the window, someone forgets to tell the driver
the new window size. Are you sure this is caused by hyperz, i.e. if you
use hyperz=false it still is wrong?
I'm wondering if it could be ddx-related (you're still using XFree86
4.3.99 something, right?)
Should I play with the clearmask, again?
No, not unless you're serious about implementing a real
hierarchical-z solution.
Maybe I'm somewhat unclear, here.
I mean this one:
--- radeon_state.c.orig 2004-11-11 22:08:37.0 +0100 +++
radeon_state.c.aktuell 2004-11-13 14:08:32.0 +0100 @@
-894,7 +894,8 @@ } else { /* FIXME : reverse engineer that for Rx00
cards */ - clearmask = (0xff<<22)|(0xff<<6)|
0x003f003f; + /* clearmask =
(0xff<<22)|(0xff<<6)| 0x003f003f; */ + clearmask = 0x0;
Well, with the new patch the clearmask used is always 0 (values other
than 0 make afaik only sense for hyperz).
[Bug 2010] New: depth and stencil readback are broken beyond x >
1023 Fix do not show any changes. zreaddraw is corrupted even
with screen redraw.
Do you mean with hyperz?
Of course ;-)
That's to be expected (at least for now). That bug 2010 depth
readback problem is meant for cases without hyperz.
I see.
It definitely is a problem, but for now it is an expected one :-).
Have a look into SPECViewperf 7.1.2/8.0.1 _ugs_, too. Depth is
mostly broken there, too.
Works perfect (though slow as always...) for me (7.1). Screenshot?
With and without hyperz. (maybe unrelated).
If it is also without hyperz then it most likely is unrelated.
Depth and clear (?) is broken.
http://www.nuetzel-hh.de/public/ugs02QualityFull.png
I'm not quite sure what this picture should look like, I don't have one
with that name.
http://www.nuetzel-hh.de/public/ugs03Full.png
Looks somewhat wrong. I definitely get a different ugs03Full.png - or is
that a 8.0 pic?
E.g. depth would be wrapped on 'big' desktops (1280x1024x24/32).
http://www.nuetzel-hh.de/public/ugs06Full-depth.png
That is indeed most certainly bug 2010 (i.e. it's only wrapped when read
back).
With viewperf-smp I get mostly empty/black windows with ugsXXX.
btw are you using pageflip? I couldn't get correct screenshots with
viewperf with it enabled, though I haven't tried for a while.
Roland
Index: r200_texstate.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c,v
retrieving revision 1.18
diff -u -r1.18 r200_texstate.c
--- r200_texstate.c 18 Oct 2004 00:00:41 - 1.18
+++ r200_texstate.c 7 Dec 2004 23:00:16 -
@@ -984,10 +984,12 @@
rmesa->TexGenNeedNormals[unit] = GL_TRUE;
tgi |= R200_TEXGEN_INPUT_SPHERETexGenEnabled |= R200_TEXGEN_TEXMAT_0_ENABLE << unit;
rmesa->TexGenCompSel |= R200_OUTPUT_TEX_0 << unit;
Re: new hyperz patch
Am Montag, 6. Dezember 2004 22:32 schrieb Roland Scheidegger:
> Dieter Nützel wrote:
> > Am Samstag, 4. Dezember 2004 00:47 schrieb Roland Scheidegger:
> >> Here's the new patch version (finally...).
> >
> > Works so far on r200 here, too;-)
> >
> >> - when only stencil (or only z) buffer is cleared in a visual which
> >> supports stencil and z, now a proper fallback clear is used (still
> >> with z-buffer compression, but not with fast z-clear - I believe
> >> this is a hardware limitation, or if it isn't a hardware limitation
> >> I don't know how to do it...). The algorithm which decides if a
> >> fallback clear is requried isn't very sophisticated though, so if
> >> an app uses a visual with stencil but never uses the stencil it
> >> will always use fallback clears. You can see that with QuakeIII, if
> >> you do r_stencilbits 8 but leave cg_shadows at 1, quake3 will
> >> never write to stencil nor clear it, which causes clear fallbacks.
> >
> > I'm running with both and your fix [Bug 2010] but can't see any
> > problems with q3a.
>
> Well, you should not SEE anything - the clear fallback should just cause
> (and that indeed happens) a performance loss, but no visual anomalies.
OK.
> >> The code required to avoid fallbacks in such cases wouldn't be that
> >> complicated, but kludgy (it would not only be necessary to
> >> remember if stencil has been written or not, but also the last the
> >> last clear values had to be remembered and such). The fallback
> >> clears fix DoomIII and NWN errors.
> >
> > True for DoomIII, but who can switch the lights ON, finally...? ;-)
>
> That is some weird texcoord problem. (I actually have a one-line
> workaround for that, which breaks submitting texgen and non-texgen
> coordinates at the same time more or less completely).
Let me test.
> > Your older version (with my little changes) was much more 'robust'
> > with multiple apps and/or 'zooming' a 3D app (e.g. with VTK).
> >
> > 'Zooming' a 3D VTK prog from the upper left corner into a bigger
> > window in the desktop middle show missing z/buffer clearing/redraw.
> >
> > Was OK before.
>
> Hmm, do you have a screenshot of that (or preferably more than one, I'm
> interested what happens when you move the window from top-left to
> top-right, bottom-left and bottom-right)?
No zoom, then nothing.
After zoom only the lower, left part of the window would be redrawn right.
In all places.
See our domain ;-)
http://www.nuetzel-hh.de/public
> Basically, this shouldn't be different than when you just changed the
> clear mask with the old patch.
> (Except when you're trying to use hier-z, then the results will be
> different - I also believe that the new drm and dri hyperz patches are
> not compatible to the old ones, you need to update both since I changed
> some bit in the ioctl.)
I'm running with both new.
> >> Private z buffers might not help neither for that problem. It would
> >> help for the z buffer compression issue (each application could
> >> use it or not without causing problems), but fast z clear would
> >> still not work correctly. I've not implemented anything though with
> >> regards to multiple apps. glxgears and quake3 seemed to run quite
> >> happily together though (on a rv250).
> >
> > Should I play with the clearmask, again?
>
> No, not unless you're serious about implementing a real hierarchical-z
> solution.
Maybe I'm somewhat unclear, here.
I mean this one:
--- radeon_state.c.orig 2004-11-11 22:08:37.0 +0100
+++ radeon_state.c.aktuell 2004-11-13 14:08:32.0 +0100
@@ -894,7 +894,8 @@
}
else {
/* FIXME : reverse engineer that for Rx00 cards */
- clearmask = (0xff<<22)|(0xff<<6)| 0x003f003f;
+ /* clearmask = (0xff<<22)|(0xff<<6)| 0x003f003f; */
+ clearmask = 0x0;
> > [Bug 2010] New: depth and stencil readback are broken beyond x >
> > 1023 Fix do not show any changes. zreaddraw is corrupted even with
> > screen redraw.
>
> Do you mean with hyperz?
Of course ;-)
> That's to be expected (at least for now). That
> bug 2010 depth readback problem is meant for cases without hyperz.
I see.
> > Have a look into SPECViewperf 7.1.2/8.0.1 _ugs_, too. Depth is mostly
> > broken there, too.
>
> Works perfect (though slow as always...) for me (7.1). Screenshot?
With and without hyperz. (maybe unrelated).
Depth and clear (?) is broken.
http://www.nuetzel-hh.de/public/ugs02QualityFull.png
http://www.nuetzel-hh.de/public/ugs03Full.png
E.g. depth would be wrapped on 'big' desktops (1280x1024x24/32).
http://www.nuetzel-hh.de/public/ugs06Full-depth.png
With viewperf-smp I get mostly empty/black windows with ugsXXX.
I hope someone get it.
Cheers,
Dieter
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which p
Re: Radeon 7200 problems
Hi, Is there any update on the situation I reported? (Full thread on http://sourceforge.net/mailarchive/forum.php?thread_id=4872625&forum_id=7177 ) Could someone please answer the questions I posted? :) Thanks in advance... (Just a user checking if there's a fix for his problems in the mean time...) -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/ --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP 320M HyperZ
Jacek Popławski wrote: Are there any plans to apply patch into Mesa/drm CVS? Yes. If there are no objections till tomorrow I'll commit it. So now is your last chance to complain ;) 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2026] bzflag crashes R200 DRI
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=2026 --- Additional Comments From [EMAIL PROTECTED] 2004-12-07 05:40 --- For reference I run FC3 and play rather to much bzflag on it ith no problems. That is AMD64, FC3 update kernel/X, bzflag from FC3 and Radeon 9000Pro. So it seems any bug is card/system dependant. -- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP 320M HyperZ
I have no idea, but I can give you a patched version based on the CVS of sunday Or I can give you the necessary patches and you can patch it yourself... Mind that the patched version is probably aroud 210 MB or so... Not sure what the size will be after all the binaries have been removed and it's compressed. On Tue, 7 Dec 2004, Jacek [iso-8859-2] Popławski wrote: > Are there any plans to apply patch into Mesa/drm CVS? > > -- > Free Software - find interesting programs and change them > NetHack - meet interesting creatures, kill them and eat their bodies > Usenet - meet interesting people from all over the world and flame them > Decopter - unrealistic helicopter simulator, get it from > http://decopter.sf.net > --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP 320M HyperZ
Are there any plans to apply patch into Mesa/drm CVS? -- Free Software - find interesting programs and change them NetHack - meet interesting creatures, kill them and eat their bodies Usenet - meet interesting people from all over the world and flame them Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net --- 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://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
