[Bug 2679] New: X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 Summary: X.org 6.8.2 does not activate DRI on i865 but says it does Product: DRI Version: XOrg CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Hi, I am trying to use X.org 6.8.2 on my Debian Sarge. My machine is a Dell Dimension 3000 with an Intel 865G Graphics Chipset. :00:02.0 VGA compatible controller: Intel Corp. 82865G Integrated Graphics Device (rev 02) XFree 4.3.0 from Sarge works almost well but the i810 driver still has some bugs so I tried X.org 6.8.2 (compiled by myself). Xorg.log and glxinfo say DRI is enabled. But every 3D programs I tried (especially crack-attack and quake3) are obviously way slower than under XFree 4.3.0. It looks to me that they are as slow as when DRI is disabled. glxgears reports 500fps with XFree/DRI and 800 with XFree without DRI (my processor is faster than my GPU ???) glxgears under Xorg reports 800 too. That's why it looks like without DRI. dmesg looks good except this: mtrr: base(0xe802) is not aligned on a size(0x96) boundary .config, lspci, dmesg, xorg.conf and Xorg.0.log attached Note that this Dell machine has a buggy BIOS which does not report Video RAM well. I tried the i865 patch to fix it, but this didn't change anything. This leads to Xorg.0.log containing things like: (WW) I810(0): Detected stolen memory (8000 kB) doesn't match what the BIOS reports (130880 kB) (II) I810(0): I830CheckAvailableMemory: 441340 kB available (--) I810(0): Pre-allocated VideoRAM: 8060 kByte (==) I810(0): VideoRAM: 32768 kByte -- 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
[Bug 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 00:17 --- Created an attachment (id=2052) -- (https://bugs.freedesktop.org/attachment.cgi?id=2052action=view) Xorg config -- 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
[Bug 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 00:17 --- Created an attachment (id=2053) -- (https://bugs.freedesktop.org/attachment.cgi?id=2053action=view) lspci -vv -- 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
[Bug 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 00:18 --- Created an attachment (id=2054) -- (https://bugs.freedesktop.org/attachment.cgi?id=2054action=view) dmesg output -- 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
[Bug 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 00:18 --- Created an attachment (id=2055) -- (https://bugs.freedesktop.org/attachment.cgi?id=2055action=view) Kernel config (2.6.11) -- 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
[Bug 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 00:18 --- Created an attachment (id=2056) -- (https://bugs.freedesktop.org/attachment.cgi?id=2056action=view) Xorg output -- 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] texture breakage
Vladimir Dergachev writes: 2. Right *now* we are doing only swtcl, as no acceleration for transform and lightning is being done. Does this mean we're not using the vertex processors at all? 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: [PATCH] DRM texture dispatch using BITBLT_MULTI
This was solution i wanted to implement (but not time to do :(), i really
think that os x driver use this to upload texture. I don't think this
will change
anything for x86 setup. Thus if no one is against, may we apply this change ?
Moreover could this change also affect way X do bitblit with xrender
acceleration ?
Because we got this issue too with X bitblit (there have been discusion on this
on xorg list).
Jerome Glisse
On Wed, 9 Mar 2005 11:24:02 +1100, Paul Mackerras [EMAIL PROTECTED] wrote:
I started looking into the issue of how we handle various texture
formats on R300 on big-endian machines. It became evident that
textures were getting byte-swapped on their way to the framebuffer.
Setting RADEON_HOST_DATA_SWAP_32BIT in RADEON_RBBM_GUICNTL doesn't
seem to have any effect on R300.
We can cope with the byte-swap for textures with 4 bytes/texel, but
not for textures with 2 or 1 byte/texel. So instead of using a
HOSTDATA_BLT in radeon_cp_dispatch_texture, I changed it to use a
BITBLT_MULTI. I still copy the texture into gart memory, but instead
of using an indirect buffer I just put the blit command into the ring
buffer. This avoids the byte swap that the CP does and gets the
texture to the framebuffer without being byte-swapped. It should be
just as fast this way as with the HOSTDATA_BLT.
The patch below implements this. With this patch we also need a patch
to the r300 client driver code, which I will post shortly.
Paul.
diff -urN cvs/r300_driver/drm/shared-core/radeon_state.c
r300_driver/drm/shared-core/radeon_state.c
--- cvs/r300_driver/drm/shared-core/radeon_state.c 2005-03-05
09:26:06.0 +1100
+++ r300_driver/drm/shared-core/radeon_state.c 2005-03-09 10:32:45.0
+1100
@@ -1471,7 +1471,7 @@
}
-#define RADEON_MAX_TEXTURE_SIZE (RADEON_BUFFER_SIZE - 8 * sizeof(u32))
+#define RADEON_MAX_TEXTURE_SIZE RADEON_BUFFER_SIZE
static int radeon_cp_dispatch_texture(DRMFILE filp,
drm_device_t * dev,
@@ -1488,6 +1488,7 @@
u32 height;
int i;
u32 texpitch, microtile;
+ u32 offset;
RING_LOCALS;
DRM_GET_PRIV_WITH_RETURN(filp_priv, filp);
@@ -1508,16 +1509,6 @@
RADEON_WAIT_UNTIL_IDLE();
ADVANCE_RING();
-#ifdef __BIG_ENDIAN
- /* The Mesa texture functions provide the data in little endian as the
-* chip wants it, but we need to compensate for the fact that the CP
-* ring gets byte-swapped
-*/
- BEGIN_RING(2);
- OUT_RING_REG(RADEON_RBBM_GUICNTL, RADEON_HOST_DATA_SWAP_32BIT);
- ADVANCE_RING();
-#endif
-
/* The compiler won't optimize away a division by a variable,
* even if the only legal values are powers of two. Thus, we'll
* use a shift instead.
@@ -1601,23 +1592,6 @@
buffer =
(u32 *) ((char *)dev-agp_buffer_map-handle +
buf-offset);
dwords = size / 4;
- buffer[0] = CP_PACKET3(RADEON_CNTL_HOSTDATA_BLT, dwords + 6);
- buffer[1] = (RADEON_GMC_DST_PITCH_OFFSET_CNTL |
-RADEON_GMC_BRUSH_NONE |
-(format 8) |
-RADEON_GMC_SRC_DATATYPE_COLOR |
-RADEON_ROP3_S |
-RADEON_DP_SRC_SOURCE_HOST_DATA |
-RADEON_GMC_CLR_CMP_CNTL_DIS |
-RADEON_GMC_WR_MSK_DIS);
-
- buffer[2] = (texpitch 22) | (tex-offset 10);
- buffer[3] = 0x;
- buffer[4] = 0x;
- buffer[5] = (image-y 16) | image-x;
- buffer[6] = (height 16) | image-width;
- buffer[7] = dwords;
- buffer += 8;
if (microtile) {
/* texture micro tiling in use, minimum texture width
is thus 16 bytes.
@@ -1726,8 +1700,26 @@
}
buf-filp = filp;
- buf-used = (dwords + 8) * sizeof(u32);
- radeon_cp_dispatch_indirect(dev, buf, 0, buf-used);
+ buf-used = size;
+ offset = dev_priv-gart_buffers_offset + buf-offset;
+ BEGIN_RING(7);
+ OUT_RING(CP_PACKET3(RADEON_CNTL_BITBLT_MULTI, 5));
+ OUT_RING(RADEON_GMC_SRC_PITCH_OFFSET_CNTL |
+RADEON_GMC_DST_PITCH_OFFSET_CNTL |
+RADEON_GMC_BRUSH_NONE |
+(format 8) |
+RADEON_GMC_SRC_DATATYPE_COLOR |
+RADEON_ROP3_S |
+RADEON_DP_SRC_SOURCE_MEMORY |
+RADEON_GMC_CLR_CMP_CNTL_DIS |
+RADEON_GMC_WR_MSK_DIS );
+ OUT_RING((texpitch 22) | (offset 10));
+ OUT_RING((texpitch 22) |
Re: [PATCH] R300 texture format updates
On Wed, 9 Mar 2005 11:53:47 +1100, Paul Mackerras [EMAIL PROTECTED] wrote: I have updated the table of texture formats in r300_texstate.c based on the definitions and comments in Mesa/src/mesa/main/texformat.h. These changes assume that radeon_cp_dispatch_texture doesn't byte-swap, i.e. that the patch I just posted has been applied. Nice too see more people helping for PPC side :) i got texture format for YCBR but i have to do more test to see if it's correct. Jerome Glisse --- 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] Problem with current cvs on PPC
Hi, Doh, sorry to waste everyones time. I installed cvs X over 6.8.1 and it was picking up some old stuff. I moved 6.8.1 and reinstall cvs and all is well. Now anything I can help test on PPC? Vladimir posted some todo list not so long ago, see if there is anythings not already done that you can do. Help is more than welcome :) Jerome Glisse --- 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
[PATCH] 32-bit ioctl compatibility for CVS DRM
Here is a patch that adds 32-bit ioctl compatibility code to the CVS
DRM (i.e. the drm CVS module at dri.freedesktop.org).
I have taken a different approach to the problem of 32-bit map handles
this time. I only generate a fake 32-bit handle for _DRM_SHM mappings
as before, but now I put the 32-bit handle in map-offset for those
mappings (previously map-offset and map-handle were the same for
_DRM_SHM mappings). This simplifies the code quite a bit.
(In fact I ported the ioc32 code to the R300 version of the DRM and
tested it, and then rediffed the resulting patch against the
dri.freedesktop.org CVS DRM. But the R300 version is the same as the
dri.freedesktop.org version in the places that I have modified, so it
should be fine.)
Paul.
diff -urN cvs/drm/linux-core/Makefile.kernel cvsdrm/linux-core/Makefile.kernel
--- cvs/drm/linux-core/Makefile.kernel 2005-01-16 18:49:55.0 +1100
+++ cvsdrm/linux-core/Makefile.kernel 2005-03-09 22:42:46.0 +1100
@@ -25,6 +25,11 @@
via-objs:= via_irq.o via_drv.o via_ds.o via_map.o via_mm.o via_dma.o
via_verifier.o
mach64-objs := mach64_drv.o mach64_dma.o mach64_irq.o mach64_state.o
+ifeq ($(CONFIG_COMPAT),y)
+drm-objs+= drm_ioc32.o
+radeon-objs += radeon_ioc32.o
+endif
+
obj-m += drm.o
obj-$(CONFIG_DRM_TDFX) += tdfx.o
obj-$(CONFIG_DRM_R128) += r128.o
diff -urN cvs/drm/linux-core/drmP.h cvsdrm/linux-core/drmP.h
--- cvs/drm/linux-core/drmP.h 2005-02-07 21:44:28.0 +1100
+++ cvsdrm/linux-core/drmP.h2005-03-09 22:42:46.0 +1100
@@ -1025,6 +1025,9 @@
extern void drm_free(void *pt, size_t size, int area);
#endif
+extern int drm_register_ioc32(void);
+extern void drm_unregister_ioc32(void);
+
/[EMAIL PROTECTED]/
#endif /* __KERNEL__ */
diff -urN cvs/drm/linux-core/drm_bufs.c cvsdrm/linux-core/drm_bufs.c
--- cvs/drm/linux-core/drm_bufs.c 2005-02-05 19:00:14.0 +1100
+++ cvsdrm/linux-core/drm_bufs.c2005-03-09 22:42:46.0 +1100
@@ -109,6 +109,15 @@
}
EXPORT_SYMBOL(drm_initmap);
+#ifdef CONFIG_COMPAT
+/*
+ * Used to allocate 32-bit handles for _DRM_SHM regions
+ * The 0x1000 value is chosen to be out of the way of
+ * FB/register and GART physical addresses.
+ */
+static unsigned int map32_handle = 0x1000;
+#endif
+
/**
* Ioctl to specify a range of memory that is available for mapping by a
non-root process.
*
@@ -286,15 +295,18 @@
down(dev-struct_sem);
list_add(list-head, dev-maplist-head);
+#ifdef CONFIG_COMPAT
+ /* Assign a 32-bit handle for _DRM_SHM mappings */
+ /* We do it here so that dev-struct_sem protects the increment */
+ if (map-type == _DRM_SHM)
+ map-offset = map32_handle += PAGE_SIZE;
+#endif
up(dev-struct_sem);
found_it:
if (copy_to_user(argp, map, sizeof(*map)))
return -EFAULT;
- if (map-type != _DRM_SHM) {
- if (copy_to_user(argp-handle,
-map-offset, sizeof(map-offset)))
- return -EFAULT;
- }
+ if (copy_to_user(argp-handle, map-offset, sizeof(map-offset)))
+ return -EFAULT;
return 0;
}
@@ -336,7 +348,7 @@
r_list = list_entry(list, drm_map_list_t, head);
if (r_list-map
- r_list-map-handle == request.handle
+ r_list-map-offset == (unsigned long) request.handle
r_list-map-flags _DRM_REMOVABLE)
break;
}
diff -urN cvs/drm/linux-core/drm_context.c cvsdrm/linux-core/drm_context.c
--- cvs/drm/linux-core/drm_context.c2004-10-19 00:16:41.0 +1000
+++ cvsdrm/linux-core/drm_context.c 2005-03-09 22:42:46.0 +1100
@@ -231,7 +231,7 @@
map = dev-context_sareas[request.ctx_id];
up(dev-struct_sem);
- request.handle = map-handle;
+ request.handle = (void *) map-offset;
if (copy_to_user(argp, request, sizeof(request)))
return -EFAULT;
return 0;
@@ -266,7 +266,8 @@
down(dev-struct_sem);
list_for_each(list, dev-maplist-head) {
r_list = list_entry(list, drm_map_list_t, head);
- if (r_list-map r_list-map-handle == request.handle)
+ if (r_list-map
+r_list-map-offset == (unsigned long) request.handle)
goto found;
}
bad:
diff -urN cvs/drm/linux-core/drm_drv.c cvsdrm/linux-core/drm_drv.c
--- cvs/drm/linux-core/drm_drv.c2005-02-08 09:55:54.0 +1100
+++ cvsdrm/linux-core/drm_drv.c 2005-03-09 22:42:46.0 +1100
@@ -497,6 +497,10 @@
goto err_p3;
}
+#ifdef CONFIG_COMPAT
+ drm_register_ioc32();
+#endif
+
DRM_INFO(Initialized %s %d.%d.%d %s\n,
CORE_NAME,
CORE_MAJOR, CORE_MINOR, CORE_PATCHLEVEL, CORE_DATE);
@@ -512,6 +516,9 @@
Re: [R300] Current(3/8/05) xorg/r300 cvs PPC issues
Paul has done some work on this issue with today cvs you should see improvement in all this area. best, Jerome Glisse On Tue, 08 Mar 2005 14:49:34 -0500, Keith Conger [EMAIL PROTECTED] wrote: Hi, Ok currently I've noticed the following issues: 1) Xv Color issues 2) Text rendering problems in mozilla 3) Textures in 3d apps are upside down and show 4copies when there should be one. Let me know If you need more details. -- Keith Conger [EMAIL PROTECTED] http://pimpstation.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://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] texture breakage
On Wed, 9 Mar 2005, Paul Mackerras wrote: Vladimir Dergachev writes: 2. Right *now* we are doing only swtcl, as no acceleration for transform and lightning is being done. Does this mean we're not using the vertex processors at all? No, we do use VAP - we are simply not programming it do lighting. All it does is apply model transformation matrix and pass through of texture coordinates. If normals are supplied these are passed through as well, so it is broken in that regard too. 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: [PATCH] R300 texture format updates
On Wed, 9 Mar 2005, Jerome Glisse wrote: On Wed, 9 Mar 2005 11:53:47 +1100, Paul Mackerras [EMAIL PROTECTED] wrote: I have updated the table of texture formats in r300_texstate.c based on the definitions and comments in Mesa/src/mesa/main/texformat.h. These changes assume that radeon_cp_dispatch_texture doesn't byte-swap, i.e. that the patch I just posted has been applied. Nice too see more people helping for PPC side :) i got texture format for YCBR but i have to do more test to see if it's correct. Mesa/progs/test/yuvsquare - resize the window to get rid of a factor of 2 in texture coordinates.. For some reason this only works right after resizing. best Vladimir Dergachev Jerome Glisse --- 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
[Bug 2683] New: libGLcore.a:m_debug_clip.o: No
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=2683 Summary: libGLcore.a:m_debug_clip.o: No libGLcore.a:m_debug_clip.o: No libGLcore.a:m_debug_*.o: No symbols found Product: DRI Version: XOrg CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: libGLcore AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Since updating to X.Org 6.8.2 I see these warning/errors in the Xserver logfile: Skipping /usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_clip.o: No symbols found Skipping /usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_norm.o: No symbols found Skipping /usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_xform.o: No symbols found Looking at the sources it seems that these symbols are only included when DEBUG is set (obviously it was not set in my build). So can these warnings/errors be ignored and is this only a bug in Imakefile so these files should not have been included by libGLcore.a when DEBUG is not set? -- 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
[Bug 2683] libGLcore.a:m_debug_clip.o: No symbols found
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=2683 [EMAIL PROTECTED] changed: What|Removed |Added Summary|libGLcore.a:m_debug_clip.o:|libGLcore.a:m_debug_clip.o: |No |No symbols found |libGLcore.a:m_debug_clip.o:|libGLcore.a:m_debug_clip.o: |No |No |libGLcore.a:m_debug_*.o: |libGLcore.a:m_debug_*.o: |No symbols found|No symbols found -- 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: [PATCH] DRM texture dispatch using BITBLT_MULTI
[ Please don't top-post ] On Wed, 2005-03-09 at 10:38 +0100, Jerome Glisse wrote: I don't think this will change anything for x86 setup. Yeah, the real question is whether it breaks pre-R300 chips on big endian machines, but it looks fine to me. Moreover could this change also affect way X do bitblit with xrender acceleration ? No, as I explained to you before, the X driver has to deal with different byte orders because the X server doesn't provide the data in little endian. On Wed, 9 Mar 2005 11:24:02 +1100, Paul Mackerras [EMAIL PROTECTED] wrote: I started looking into the issue of how we handle various texture formats on R300 on big-endian machines. It became evident that textures were getting byte-swapped on their way to the framebuffer. Yep, the comment the patch removes explains this. :) We can cope with the byte-swap for textures with 4 bytes/texel, but not for textures with 2 or 1 byte/texel. So instead of using a HOSTDATA_BLT in radeon_cp_dispatch_texture, I changed it to use a BITBLT_MULTI. I still copy the texture into gart memory, but instead of using an indirect buffer I just put the blit command into the ring buffer. Nice. It might also be interesting to experiment with copying the texture data into the ring itself instead of into indirect buffers (and use type 3 NOP packets to have the CP skip it), if someone feels so inclined. This avoids the byte swap that the CP does and gets the texture to the framebuffer without being byte-swapped. It should be just as fast this way as with the HOSTDATA_BLT. Yeah, it might actually be slightly faster. :) + OUT_RING((texpitch 22) | (offset 10)); + OUT_RING((texpitch 22) | (tex-offset 10)); Are source and destination pitch always the same? + OUT_RING(0); + OUT_RING((image-x 16) | image-y); + OUT_RING((image-width 16) | height); + ADVANCE_RING(); + radeon_cp_discard_buffer(dev, buf); I think this needs a RADEON_WAIT_UNTIL_2D_IDLE(), or the indirect buffer might get reused before the blit is complete. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Current(3/8/05) xorg/r300 cvs PPC issues
Hi, Updated cvs and textures look right except now they are all red. I also get 200fps on nehe lesson6 much better then the 1fps I was getting. Thanks, Keith On Wed, 2005-03-09 at 14:16 +0100, Jerome Glisse wrote: Paul has done some work on this issue with today cvs you should see improvement in all this area. best, Jerome Glisse On Tue, 08 Mar 2005 14:49:34 -0500, Keith Conger [EMAIL PROTECTED] wrote: Hi, Ok currently I've noticed the following issues: 1) Xv Color issues 2) Text rendering problems in mozilla 3) Textures in 3d apps are upside down and show 4copies when there should be one. Let me know If you need more details. -- Keith Conger [EMAIL PROTECTED] http://pimpstation.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://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 -- Keith Conger [EMAIL PROTECTED] http://pimpstation.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://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 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 10:39 --- I played with kernel drivers a little bit. Looks like XFree does not have DRI working when I load the i915 driver instead of the traditional i830 which makes XFree DRI work. I'm not sure whether XFree is supposed to work on this driver. But if yes, then the breakage is probably in this kernel driver. I tried i915 from 2.6.9, 2.6.10, 2.6.11 and the one that is provided with Xorg 6.8.2 sources, none worked. They all lead to 800fps, that is no DRI. Did somebody ever successfully use the i915 driver on a i865 chipset ? -- 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
[Bug 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 11:08 --- Do this to check if DRI is enabled properly. export LIBGL_DEBUG=1; glxinfo and attach all the output here. -- 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] Current(3/8/05) xorg/r300 cvs PPC issues
On Wed, 09 Mar 2005 11:28:32 -0500, Keith Conger [EMAIL PROTECTED] wrote: Hi, Updated cvs and textures look right except now they are all red. I also get 200fps on nehe lesson6 much better then the 1fps I was getting. You also have to upload drm, if you did this simply means that Paul maybe hasn't yet commited change for the client side (ie r300 driver). Thanks, Keith On Wed, 2005-03-09 at 14:16 +0100, Jerome Glisse wrote: Paul has done some work on this issue with today cvs you should see improvement in all this area. best, Jerome Glisse On Tue, 08 Mar 2005 14:49:34 -0500, Keith Conger [EMAIL PROTECTED] wrote: Hi, Ok currently I've noticed the following issues: 1) Xv Color issues 2) Text rendering problems in mozilla 3) Textures in 3d apps are upside down and show 4copies when there should be one. Let me know If you need more details. -- Keith Conger [EMAIL PROTECTED] http://pimpstation.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://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 -- Keith Conger [EMAIL PROTECTED] http://pimpstation.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://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 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 11:29 --- Created an attachment (id=2064) -- (https://bugs.freedesktop.org/attachment.cgi?id=2064action=view) output of glxinfo This output was generated with LIBGL_DEBUG=1. But I didn't see any difference with the casewhere LIBGL_DEBUG is not defined. Let me know if you want me to recompile Xorg with some debugging options. -- 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
[Bug 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 11:45 --- According to the glxinfo output, DRI is enabled and working fine. -- 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
[Bug 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 12:46 --- (In reply to comment #9) According to the glxinfo output, DRI is enabled and working fine. Yes, that's what I noticed too... But the fact is that real 3D applications (something way complicated than glxgears) is way slower under Xorg than under XFree86. And disabling DRI and DRM in X.org doesn't change anything... Basically Quake3 has about 1 fps in the main menu (didn't event try to start a game) while it's totally playable under XFree86. I didn't notice anything interesting when comparing their logs. Crack-attack is very slow too. Is there a better 3D benchmarks than glxgears somewhere ? I'd like to get some real numbers. Getting more frame with DRI disabled under XFree than with DRI enabled is pretty boring... -- 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 Status Report - Gentoo amd64, Saphire 9600
Hamie schrieb: One other funny I noticed that I've never noticed before without the r300 drivers is that X would 'reload' itself whenever the client closed.. (I was only runnning one at a time, no window manager). Is that normal? It is. --- 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: [PATCH] DRM texture dispatch using BITBLT_MULTI
Michel Dänzer writes: Yeah, the real question is whether it breaks pre-R300 chips on big endian machines, but it looks fine to me. Yes, we previously had two byte-swaps on those machines, and now we have no byte-swap, so the outcome should be identical. Nice. It might also be interesting to experiment with copying the texture data into the ring itself instead of into indirect buffers (and use type 3 NOP packets to have the CP skip it), if someone feels so inclined. Just to avoid the overhead of allocating an indirect buffer? I think that could be worthwhile for smaller textures, although for smaller textures it would probably be just as fast, and a lot simpler, to write the texture directly to the framebuffer. I assumed that the indirect buffer would be at least 1kB-aligned (indirect buffers seem to be page-aligned, from what I could see in the code that creates them). This means that I didn't have to worry about losing bits when shifting buf-offset right 10 bits. We wouldn't have that guarantee if we were putting the texture in the ring buffer, which might make calculation of suitable x and y values interesting. :) + OUT_RING((texpitch 22) | (offset 10)); + OUT_RING((texpitch 22) | (tex-offset 10)); Are source and destination pitch always the same? I found it quite hard to understand what was going on with tex-width, tex-height and tex-pitch vs. image-width and image-height, since they seem to be used inconsistently. It turns out that in fact tex-pitch isn't actually the pitch of the texture image - it can be a power of two multiple of the actual texture pitch. By the time the data gets to the indirect buffer it is laid out as we want it in the framebuffer, though, and what we want is just a 1-D block copy, and using the same pitch, with width equal to pitch / pixelsize, effectively gives us a 1-D block copy. Do you have a better explanation of how tex-width/height/pitch relate to image-width/height? + OUT_RING(0); + OUT_RING((image-x 16) | image-y); + OUT_RING((image-width 16) | height); + ADVANCE_RING(); + radeon_cp_discard_buffer(dev, buf); I think this needs a RADEON_WAIT_UNTIL_2D_IDLE(), or the indirect buffer might get reused before the blit is complete. Well, radeon_cp_dispatch_indirect doesn't seem to wait for the blit to complete either, so I was just following what the old code did. I must admit I don't yet understand how indirect buffers get recycled. Regards, 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_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 Status Report - Gentoo amd64, Saphire 9600
Hamie wrote: Hi. A quick status report/feedback on how the r300 effort fares on my workstation. Hardware is an AMD64 3200 (Socket 939, on an Asus A8V Deluxe Motherboard). 1GB RAM dual channeled (2x 512MB sticks) and a Saphire Radeon 9600 card (Mobility Radeon 9600 M10 - PCI ID 1002,4e51). Todays CVS works, yesterdays didn't... I belive it's the 64bit/32boit IOCTL's that were posted today or late yesterday that did the trick there. Up till now I'd either get a complete hang, or (Last night) X would start show a black screen with the movable cursor nothing more. No keyboard access at all no displaying anything else). Today it goes a lot better. X actually starts correctly, and I can bring up an xterm, glxinfo runs (But still says no direct rendering, Xorg.0.log says different) and glxgears now gives a result of 739fps (Default size) vs 270fps using the default non dri setup. (Which still looks a bit slow to me... My 1.6GHz Pentium-M laptop with a FireGL-T2-128 can get ~300fps, I expected more from an Athlon 64 AGP8... Anyway). Things now work... Although I did expect better frame rates. Especially since other have reported much much higher ones... My config log are appended below if anyone else is interested in duplicating/criticising what I've got. One other funny I noticed that I've never noticed before without the r300 drivers is that X would 'reload' itself whenever the client closed.. (I was only runnning one at a time, no window manager). Is that normal? Ahem... Brain fade... Damned thing wasn't picking up the new GL libs r300_dri.so... I found a couple of problems... 1. Gentoo seems to install the libs dri modules for X in /usr/lib/modules/dri instead of under /usr/X11R6 2. The Mesa cvs I have doesn't seem to copy r300_dri.so from $BASE/lib64... In fact the install script just does a cp $BASE/lib*/lib to the destination lib directory. WHich misses r300_dri.so because it's in $BASE/lib64, and NOT in a sub-directory... Maybe I did somethign wrong when I set it up... I'd better check the readme's again. Anway... Now I get ~1080fps in glxgears and tuxracer is actually playable... But the ice is as others have reported black with strange swirly bits on it now again... --- 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 Status Report - Gentoo amd64, Saphire 9600
Philipp Klaus Krause wrote: Hamie schrieb: One other funny I noticed that I've never noticed before without the r300 drivers is that X would 'reload' itself whenever the client closed.. (I was only runnning one at a time, no window manager). Is that normal? It is. Right. Ta... I've never actually tried running it like that, so wasn't sure... Anyway... Results were much better once I'd got the r300_dri.so actually copied the libs loaded from the correct place... --- 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 Status Report - Gentoo amd64, Saphire 9600
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hamie wrote: | 1. Gentoo seems to install the libs dri modules for X in | /usr/lib/modules/dri instead of under /usr/X11R6 Sure, but if you don't have a broken install, /usr/X11R6 symlinks to /usr so you won't notice. The usual problem is more like installing opengl stuff to /usr/lib/opengl/implementation. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCL3n/XVaO67S1rtsRAqU9AKCENCi2LPlIG34OuF2p+PYY9Sfa8gCfcuRt +Tf6L3giS6y5RUXhe+qAVKk= =h1wy -END PGP SIGNATURE- --- 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: [PATCH] DRM texture dispatch using BITBLT_MULTI
Paul Mackerras wrote: + OUT_RING((texpitch 22) | (offset 10)); + OUT_RING((texpitch 22) | (tex-offset 10)); Are source and destination pitch always the same? I found it quite hard to understand what was going on with tex-width, tex-height and tex-pitch vs. image-width and image-height, since they seem to be used inconsistently. It turns out that in fact tex-pitch isn't actually the pitch of the texture image - it can be a power of two multiple of the actual texture pitch. By the time the data gets to the indirect buffer it is laid out as we want it in the framebuffer, though, and what we want is just a 1-D block copy, and using the same pitch, with width equal to pitch / pixelsize, effectively gives us a 1-D block copy. Do you have a better explanation of how tex-width/height/pitch relate to image-width/height? I had trouble to understand that too, both when I added support for compressed textures and then again for tiled textures. This IS confusing. You might not need that for r300, however this will break texture tiling for older chips. texpitch includes the tile bits, so you need different pitches for source and destination (or you'd need to tile everything yourself). Also, be careful with that 1-D block copy assumption - you cannot tweak all parameters like you want, since all the pitch, width and height parameters need to be correct, otherwise the gpu will tile the textures incorrectly. Roland --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2679] X.org 6.8.2 does not activate DRI on i865 but says it does
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=2679 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 15:05 --- The glxinfo output looks ok, but you'll get more diagnostics when you set export LIBGL_DEBUG=verbose Also try running real applications with this environment variable set. You should see some diagnostics about what's going on while loading the 3D driver. There is a known issue with some broken games what load libGL dynamically with RTLD_LOCAL (though AFAIK Quake3 is not affected). A workaround is to export LD_PRELOAD=/usr/lib/libGL.so.1. -- 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
[Bug 2516] some rasterization fallbacks cause segfaults
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2516 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 15:06 --- Some more debugging showed the problem: When a rasterization fallback is hit, _tnl_need_projected_coords must be set to true. This indeed happens, however r200ChooseVertexState will get called later and this may set (depending on current vertex format) this to false again. When this is set to false this will cause VB-NdcPtr to be NULL (in t_vb_vertex.c, run_vertex_stage) which will in turn cause the VB-AttribPtr[VERT_ATTRIB_POS] to be NULL too (ss_context.c, _swsetup_RenderStart) -- boom. -- 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
[Bug 2516] some rasterization fallbacks cause segfaults
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2516 --- Additional Comments From [EMAIL PROTECTED] 2005-03-09 15:11 --- Created an attachment (id=2067) -- (https://bugs.freedesktop.org/attachment.cgi?id=2067action=view) possible fix for rasterization fallbacks this patch fixes the segfaults (tested with gl-117 and texdown), however I'm not sure if it actually is really correct. I can't quite follow the command flow of the tnl pipeline, what should and what actually is executed, validated and what not is hard to understand. Someone with a more thourough understanding of the tnl pipeline care to comment? -- 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: [PATCH] DRM texture dispatch using BITBLT_MULTI
On Thu, 2005-03-10 at 09:10 +1100, Paul Mackerras wrote:
Michel Dnzer writes:
Nice. It might also be interesting to experiment with copying the
texture data into the ring itself instead of into indirect buffers (and
use type 3 NOP packets to have the CP skip it), if someone feels so
inclined.
Just to avoid the overhead of allocating an indirect buffer?
Yes.
I think that could be worthwhile for smaller textures,
Not only; with large textures, you might avoid having to wait for an
indirect buffer to become available, the ring size might have to be
increased for that though.
although for smaller textures it would probably be just as fast, and a
lot simpler, to write the texture directly to the framebuffer.
Possibly, but that has the disadvantage of not being synchronized with
the GPU.
I assumed that the indirect buffer would be at least 1kB-aligned
(indirect buffers seem to be page-aligned, from what I could see in
the code that creates them). This means that I didn't have to worry
about losing bits when shifting buf-offset right 10 bits. We
wouldn't have that guarantee if we were putting the texture in the
ring buffer, which might make calculation of suitable x and y values
interesting. :)
The data can be aligned in the ring as well, but that's indeed an issue.
I'm really not sure this would be worth it though, hence my choice of
words: 'might be interesting to experiment'... :)
+ OUT_RING((texpitch 22) | (offset 10));
+ OUT_RING((texpitch 22) | (tex-offset 10));
Are source and destination pitch always the same?
I found it quite hard to understand what was going on with tex-width,
tex-height and tex-pitch vs. image-width and image-height, since
they seem to be used inconsistently. It turns out that in fact
tex-pitch isn't actually the pitch of the texture image - it can be a
power of two multiple of the actual texture pitch.
I think tex-pitch is the value that will be written to the texture
pitch register. My (limited) understanding of the other fields is
tex-{width,height}: texture width/height
image-width: source data pitch
image-height: source data height
By the time the data gets to the indirect buffer it is laid out as we
want it in the framebuffer, though, [...]
Really? The texture pitch in the framebuffer is always a multiple of 1024
bytes AFAIK (I might be way off though :), so that would be a royal waste
of bandwidth in some cases.
I agree this is pretty confusing though, clues appreciated. :)
+ OUT_RING(0);
+ OUT_RING((image-x 16) | image-y);
+ OUT_RING((image-width 16) | height);
+ ADVANCE_RING();
+
radeon_cp_discard_buffer(dev, buf);
I think this needs a RADEON_WAIT_UNTIL_2D_IDLE(), or the indirect buffer
might get reused before the blit is complete.
Well, radeon_cp_dispatch_indirect doesn't seem to wait for the blit to
complete either, so I was just following what the old code did.
The difference is that for a hostdata blit, the CP writes the data to
the hostdata registers synchronously, whereas with your change, the 2D
engine will fetch the data asynchronously.
I must admit I don't yet understand how indirect buffers get recycled.
The DRM keeps track of a monotonously increasing 'buffer age'. When an
indirect buffer gets discarded, the DRM increments the buffer age and
associates the discarded buffer with the incremented age. It emits
commands for executing the indirect buffer to the ring buffer, followed
by a write to a reserved scratch register. The DRM knows it can reuse
indirect buffers whose associated age is smaller than or equal to the
age in that register.
Now with hostdata blits, this doesn't require special treatment, because
the scratch register is only written to after the CP is done feeding the
data to the hostdata registers. But with your change, the scratch
register will be written immediately after the 2D engine starts fetching
the data from the indirect buffer. There might still only be conflicts
rarely if ever in practice, but it's probably better not to take any
chances. :)
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 state save mechanism
As someone might of noticed, r300Clear calls r300ResetHwState as it tampers over states as there have been no good way to save the states that r300ClearBuffer needs to modify. I discussed about the possible aproaches of doing state saving with Vladimir. Implementing something like R200_DB_STATECHANGE doesnt look like a good alternative as cases where something like this would be needed seem rare. Hence functions that want to play with states should probably handle it by themselves if possible. Instead of saving the states we could write states that r300Clear needs to modify directly into command buffer and just dirty mark state atoms that have been altered. Any pros, cons, other ideas? -- Aapo Tahkola --- 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
