Re: Xserver freezes with radeon.ko loaded
On Fri, Jul 15, 2005 at 09:50:42 +0200, Tino Keitel wrote: Hi folks, when the Xorg server is started, my machine will freeze completely if radeon.ko is loaded. I can not log into it via SSH, and I also don't see any kernel crash messages at the serial console. I played around with the r300 driver when this problem appeared, but I also reinstalled a radeon.ko and drm.ko from the vanilla kernel and the freeze still occurs. I attached the Xserver log and kernel config. radeon.log is I forgot to mention that this is kernel 2.6.12 and Xorg CVS from yesterday on a Radeon 9600. Regards, Tino --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ColorTiling issue on r420
Just to add that login (KDM) is more or less fine (cursor is corrupted untill its moved). Rune Petersen Aapo Tahkola wrote: On Thu, 14 Jul 2005 23:07:28 +0200 Rune Petersen [EMAIL PROTECTED] wrote: Hi, With ColorTiling enabled I get gradual corruption og the desktop/screen on my X800 XT (AGP). 3D applications games are fine. the corruption happends during popups (menus etc.). I'm using the late CVS og r300_driver and Xorg. Any idea where to start debugging this? Does changing resolution fix it? Any differences in RADEON_CRTC_OFFSET_CNTL or RADEON_SURFACEx_INFO regs? It might be that there are some new bits for compressed fb. Also, some of the aligns are probably not right for r300 and up, though so far I havent seen nothing worse than slight texture corruption when moving 3d apps out of visible screen area. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
32bit builds of Mesa on 64bit platforms
The patch below allows 32bit builds of Mesa on 64bit (especially x86_64) systems. The '-m32' option for gcc/g++ should work with all versions of gcc = 3.0 - also on ia32. Egbert. Index: configs/linux-dri-x86 === RCS file: /cvs/mesa/Mesa/configs/linux-dri-x86,v retrieving revision 1.9 diff -u -r1.9 linux-dri-x86 --- configs/linux-dri-x86 25 Sep 2004 07:11:12 - 1.9 +++ configs/linux-dri-x86 13 Jul 2005 14:36:27 - @@ -10,3 +10,5 @@ ASM_FLAGS = -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM ASM_SOURCES = $(X86_SOURCES) +CC = gcc -m32 +CXX = g++ -m32 Index: src/mesa/drivers/dri/Makefile.template === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/Makefile.template,v retrieving revision 1.23 diff -u -r1.23 Makefile.template --- src/mesa/drivers/dri/Makefile.template 28 May 2005 20:17:06 - 1.23 +++ src/mesa/drivers/dri/Makefile.template 13 Jul 2005 14:36:28 - @@ -80,7 +80,7 @@ $(LIBNAME): $(OBJECTS) $(MESA_MODULES) $(WINOBJ) Makefile $(TOP)/src/mesa/drivers/dri/Makefile.template rm -f $@ - gcc $(ARCH_FLAGS) -o $@ -shared $(OBJECTS) $(MESA_MODULES) $(WINOBJ) $(DRI_LIB_DEPS) + $(CC) $(ARCH_FLAGS) -o $@ -shared $(OBJECTS) $(MESA_MODULES) $(WINOBJ) $(DRI_LIB_DEPS) $(LIB_DIR)/$(LIBNAME): $(LIBNAME) --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
On 13/07/05, Lorenzo Colitti [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: atlantis -root -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps Changed this for atlantis and it gave me 23fps instead of 3, thanks. I get 120 fps with color tiling on pretty much same hw as you and 1280x1024 resolution. Youll need to use xorg cvs and ColorTiling option to enable it. Yep, color tiling is a big win here. When I turned it on, Well, it causing a lot of coruption with color tilling for me. My background is scewd as is my mouse pointer, buttons in gnome 2.10 dissapear and only reapear when i move my mouse over it. ./atlantis -whalespeed 458 -delay 0 -size 8350 -count 3 -gradient -fps (not fulscreen) went from 10 FPS to ~200 FPS. I also get 1000 FPS in glxgears while before I used to get ~500. This is on a rage mobility 9600 M10 (RV350) on a Pentium M 1.4 GHz. Blocktube will not go above 25fps, even with delay is 0. Only with -wireframe it will go to 32fps. For reference, I get ~26 FPS with wireframe and ~19 without (not full screen). With no HW acceleration I get 7 FPS. It seems that something is wrong here as increasing/decreasing window size doesnt affect framerates at all. My guess so far would be that the command buffer gets too fed up and causes this bottleneck. Why should increasing window size affect framerates? I thought that as far as the graphics chip was concerned, a triangle was just a triangle irrespective of size, and we're not hitting fill rate limits here... or is there something I'm missing? Cheers, Lorenzo I'll try my Fedora4 AMD64 test partition and build xc and Mesa from cvs. A'll report back if this makes any difference. I now have no closed source binary drivers running on my system (fglrx was the last one), thanks Regards Sander --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
making type of handles in libdrm more consistent
The following patches make the type of handles in libdrm
more consistent.
They allow us to later change the type of drm_handle_t
from unsigned long to unsigned int to allow 32bit and 64bit
clients and Xservers to share data structures.
Included are two patches: one for libdrm as part of DRM
and one for the libdrm parts (xf86drm.[ch]) in Mesa.
Once this has gotten accepted I will commit these files
in X myself.
Egbert.
Index: libdrm/xf86drm.c
===
RCS file: /cvs/dri/drm/libdrm/xf86drm.c,v
retrieving revision 1.51
diff -u -r1.51 xf86drm.c
--- libdrm/xf86drm.c4 Apr 2005 04:08:29 - 1.51
+++ libdrm/xf86drm.c15 Jul 2005 10:30:22 -
@@ -888,7 +888,7 @@
map.type= type;
map.flags = flags;
if (ioctl(fd, DRM_IOCTL_ADD_MAP, map)) return -errno;
-if (handle) *handle = (drm_handle_t)map.handle;
+if (handle) *handle = (drm_handle_t)(unsigned long)map.handle;
return 0;
}
@@ -896,7 +896,7 @@
{
drm_map_t map;
-map.handle = (void *)handle;
+map.handle = (void *)(unsigned long)handle;
if(ioctl(fd, DRM_IOCTL_RM_MAP, map)) return -errno;
return 0;
@@ -1499,7 +1499,7 @@
* arguments in a drm_agp_buffer structure.
*/
int drmAgpAlloc(int fd, unsigned long size, unsigned long type,
- unsigned long *address, unsigned long *handle)
+ unsigned long *address, drm_handle_t *handle)
{
drm_agp_buffer_t b;
@@ -1526,7 +1526,7 @@
* This function is a wrapper around the DRM_IOCTL_AGP_FREE ioctl, passing the
* argument in a drm_agp_buffer structure.
*/
-int drmAgpFree(int fd, unsigned long handle)
+int drmAgpFree(int fd, drm_handle_t handle)
{
drm_agp_buffer_t b;
@@ -1550,7 +1550,7 @@
* This function is a wrapper around the DRM_IOCTL_AGP_BIND ioctl, passing the
* argument in a drm_agp_binding structure.
*/
-int drmAgpBind(int fd, unsigned long handle, unsigned long offset)
+int drmAgpBind(int fd, drm_handle_t handle, unsigned long offset)
{
drm_agp_binding_t b;
@@ -1573,7 +1573,7 @@
* This function is a wrapper around the DRM_IOCTL_AGP_UNBIND ioctl, passing
* the argument in a drm_agp_binding structure.
*/
-int drmAgpUnbind(int fd, unsigned long handle)
+int drmAgpUnbind(int fd, drm_handle_t handle)
{
drm_agp_binding_t b;
@@ -1763,7 +1763,7 @@
return i.id_device;
}
-int drmScatterGatherAlloc(int fd, unsigned long size, unsigned long *handle)
+int drmScatterGatherAlloc(int fd, unsigned long size, drm_handle_t *handle)
{
drm_scatter_gather_t sg;
@@ -1775,7 +1775,7 @@
return 0;
}
-int drmScatterGatherFree(int fd, unsigned long handle)
+int drmScatterGatherFree(int fd, drm_handle_t handle)
{
drm_scatter_gather_t sg;
@@ -1942,7 +1942,7 @@
drm_ctx_priv_map_t map;
map.ctx_id = ctx_id;
-map.handle = (void *)handle;
+map.handle = (void *)(unsigned long)handle;
if (ioctl(fd, DRM_IOCTL_SET_SAREA_CTX, map)) return -errno;
return 0;
@@ -1955,7 +1955,7 @@
map.ctx_id = ctx_id;
if (ioctl(fd, DRM_IOCTL_GET_SAREA_CTX, map)) return -errno;
-if (handle) *handle = (drm_handle_t)map.handle;
+if (handle) *handle = (drm_handle_t)(unsigned long)map.handle;
return 0;
}
@@ -1972,7 +1972,7 @@
*size = map.size;
*type = map.type;
*flags = map.flags;
-*handle = (unsigned long)map.handle;
+*handle = (drm_handle_t)(unsigned long)map.handle;
*mtrr = map.mtrr;
return 0;
}
@@ -1995,7 +1995,7 @@
int drmGetStats(int fd, drmStatsT *stats)
{
drm_stats_t s;
-int i;
+unsigned int i;
if (ioctl(fd, DRM_IOCTL_GET_STATS, s)) return -errno;
Index: libdrm/xf86drm.h
===
RCS file: /cvs/dri/drm/libdrm/xf86drm.h,v
retrieving revision 1.6
diff -u -r1.6 xf86drm.h
--- libdrm/xf86drm.h1 Feb 2005 22:09:46 - 1.6
+++ libdrm/xf86drm.h15 Jul 2005 10:30:22 -
@@ -577,11 +577,11 @@
extern int drmAgpEnable(int fd, unsigned long mode);
extern int drmAgpAlloc(int fd, unsigned long size,
unsigned long type, unsigned long *address,
-unsigned long *handle);
-extern int drmAgpFree(int fd, unsigned long handle);
-extern int drmAgpBind(int fd, unsigned long handle,
+drm_handle_t *handle);
+extern int drmAgpFree(int fd, drm_handle_t handle);
+extern int drmAgpBind(int fd, drm_handle_t handle,
unsigned long offset);
-extern int drmAgpUnbind(int fd, unsigned long handle);
+extern int drmAgpUnbind(int fd, drm_handle_t handle);
/* AGP/GART info: authenticated client and/or X */
extern int drmAgpVersionMajor(int fd);
@@ -596,8 +596,8 @@
/* PCI scatter/gather support: X server (root) only */
extern int
Fixes to make DRI Device Info data machine size independent
The Mesa patch below helps to make the data passed between
the Xserver and an DRI client in the GetDeviceInfo request of
the DRI extension independ of the machine size - a prerequisite
to support mixing of 32 and 64bit DRI clients.
The patch eliminates the need to use of drmAddress in these
structures.
drmAddress is unsigned long and therefore machine size dependent.
Furthermore it fixes a bug in the MGA DRI module which makes the
assumption that a 'handle' is a base address of a mapped area.
Appearantly the affected code is not used any more with the latest
versions of DRM.
Like the patches to libdrm none of these fixes should raise any
compatibility issues.
I suggest to postpone the changes which eliminate drmAddress from
these structures and make drm_handle_t unsigned int until all
other things are in place and do them all at once as they will
change the ABI between the Xserver and DRI clients.
Egbert.
Index: src/mesa/drivers/dri/ffb/ffb_xmesa.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/ffb/ffb_xmesa.c,v
retrieving revision 1.8
diff -u -r1.8 ffb_xmesa.c
--- src/mesa/drivers/dri/ffb/ffb_xmesa.c4 May 2005 20:11:36 -
1.8
+++ src/mesa/drivers/dri/ffb/ffb_xmesa.c15 Jul 2005 09:48:05 -
@@ -61,6 +61,7 @@
{
ffbScreenPrivate *ffbScreen;
FFBDRIPtr gDRIPriv = (FFBDRIPtr) sPriv-pDevPriv;
+ drmAddress map;
if (getenv(LIBGL_FORCE_XSERVER))
return GL_FALSE;
@@ -74,59 +75,59 @@
if (drmMap(sPriv-fd,
gDRIPriv-hFbcRegs,
gDRIPriv-sFbcRegs,
- gDRIPriv-mFbcRegs)) {
+ map)) {
FREE(ffbScreen);
return GL_FALSE;
}
- ffbScreen-regs = (ffb_fbcPtr) gDRIPriv-mFbcRegs;
+ ffbScreen-regs = (ffb_fbcPtr) map;
/* Map ramdac registers. */
if (drmMap(sPriv-fd,
gDRIPriv-hDacRegs,
gDRIPriv-sDacRegs,
- gDRIPriv-mDacRegs)) {
- drmUnmap(gDRIPriv-mFbcRegs, gDRIPriv-sFbcRegs);
+ map)) {
+ drmUnmap((drmAddress)ffbScreen-regs, gDRIPriv-sFbcRegs);
FREE(ffbScreen);
return GL_FALSE;
}
- ffbScreen-dac = (ffb_dacPtr) gDRIPriv-mDacRegs;
+ ffbScreen-dac = (ffb_dacPtr) map;
/* Map Smart framebuffer views. */
if (drmMap(sPriv-fd,
gDRIPriv-hSfb8r,
gDRIPriv-sSfb8r,
- gDRIPriv-mSfb8r)) {
- drmUnmap(gDRIPriv-mFbcRegs, gDRIPriv-sFbcRegs);
- drmUnmap(gDRIPriv-mDacRegs, gDRIPriv-sDacRegs);
+ map)) {
+ drmUnmap((drmAddress)ffbScreen-regs, gDRIPriv-sFbcRegs);
+ drmUnmap((drmAddress)ffbScreen-dac, gDRIPriv-sDacRegs);
FREE(ffbScreen);
return GL_FALSE;
}
- ffbScreen-sfb8r = (volatile char *) gDRIPriv-mSfb8r;
+ ffbScreen-sfb8r = (volatile char *) map;
if (drmMap(sPriv-fd,
gDRIPriv-hSfb32,
gDRIPriv-sSfb32,
- gDRIPriv-mSfb32)) {
- drmUnmap(gDRIPriv-mFbcRegs, gDRIPriv-sFbcRegs);
- drmUnmap(gDRIPriv-mDacRegs, gDRIPriv-sDacRegs);
- drmUnmap(gDRIPriv-mSfb8r, gDRIPriv-sSfb8r);
+ map)) {
+ drmUnmap((drmAddress)ffbScreen-regs, gDRIPriv-sFbcRegs);
+ drmUnmap((drmAddress)ffbScreen-dac, gDRIPriv-sDacRegs);
+ drmUnmap((drmAddress)ffbScreen-sfb8r, gDRIPriv-sSfb8r);
FREE(ffbScreen);
return GL_FALSE;
}
- ffbScreen-sfb32 = (volatile char *) gDRIPriv-mSfb32;
+ ffbScreen-sfb32 = (volatile char *) map;
if (drmMap(sPriv-fd,
gDRIPriv-hSfb64,
gDRIPriv-sSfb64,
- gDRIPriv-mSfb64)) {
- drmUnmap(gDRIPriv-mFbcRegs, gDRIPriv-sFbcRegs);
- drmUnmap(gDRIPriv-mDacRegs, gDRIPriv-sDacRegs);
- drmUnmap(gDRIPriv-mSfb8r, gDRIPriv-sSfb8r);
- drmUnmap(gDRIPriv-mSfb32, gDRIPriv-sSfb32);
+ map)) {
+ drmUnmap((drmAddress)ffbScreen-regs, gDRIPriv-sFbcRegs);
+ drmUnmap((drmAddress)ffbScreen-dac, gDRIPriv-sDacRegs);
+ drmUnmap((drmAddress)ffbScreen-sfb8r, gDRIPriv-sSfb8r);
+ drmUnmap((drmAddress)ffbScreen-sfb32, gDRIPriv-sSfb32);
FREE(ffbScreen);
return GL_FALSE;
}
- ffbScreen-sfb64 = (volatile char *) gDRIPriv-mSfb64;
+ ffbScreen-sfb64 = (volatile char *) map;
ffbScreen-fifo_cache = 0;
ffbScreen-rp_active = 0;
@@ -147,11 +148,11 @@
ffbScreenPrivate *ffbScreen = sPriv-private;
FFBDRIPtr gDRIPriv = (FFBDRIPtr) sPriv-pDevPriv;
- drmUnmap(gDRIPriv-mFbcRegs,
EGL on radeon DRI
Is anyone interested in working on this while I'm at OLS next week? I have it all compiling and sort of working, but things are still not initialized totally right. Something is still messed up when setting up the DRM driver. I'll make up some diffs if anyone is interested. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 32bit builds of Mesa on 64bit platforms
Egbert Eich wrote: The patch below allows 32bit builds of Mesa on 64bit (especially x86_64) systems. The '-m32' option for gcc/g++ should work with all versions of gcc = 3.0 - also on ia32. Ok, I've checked in the fix, with minor changes. -Brian --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1746] Freelist issues in MGA DRM
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=1746 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2005-07-16 01:09 --- If there was a patch perhaps I could try it. Some g400 and g550 cards 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.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 DRI report
I'm planning to do some benchmarks when ATI update their driver to work with the new xorg release. Any sugestions for some benckmarks that I can run? I'll post the results to the mailing list if people are interested? glxgears is the easy one :) You could also try FlightGear as far as games go. There is also some general OpenGL benchmarking suite (forgot the name), it might be relatively easy to setup. Thanks Sander PS: Is this the correct list to be asking these kind of thing? The r300 website has no refference to a forum or other mailing list then this one. Yep, this is the right mailing list. best Vladimir Dergachev --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 3791] New: PCI DMA bitblt support for unichrome
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=3791 Summary: PCI DMA bitblt support for unichrome Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] Before going on vacation I'd like to post this patch for review. It adds PCI DMA bitblt support for unichrome and unichrome pro chips using the via drm. It's not totally finished but almost so. There are some security concerns that I have: The mechanism works as follows: 1) The userspace app submits a blit request and gets a sync handle. 2) The kernel locks relevant pages in memory. 3) The kernel performs a DMA mapping. 4) The request is queued pending blit engine idle. Up to 8 queue slots per engine. If the slots are all busy, the initial submission will block. 5) The blit is scheduled by the interrupt handler. 6) The kernel unmaps the DMA mapping using a workqueue task 7) The kernel unlocks the pages, and awakes any sync request from the user app, also in the workqueue task. Security concerns are 1) What happens if the application dies or frees up the memory while the blit is in the queue? If the kernel refcounts the number of times the page is locked than this shouldn't be a problem and the page is released when it is unlocked by the blit code. 2) As above, but a second blit referencing the same user pages is queued behind the first one. What happens when the pages for the first blit is unlocked. Again, if the kernel refcounts page locks then this is not a problem. 3) Same situation as 2. What happens when the DMA mapping for the first blit is released? Will this affect the DMA mapping for the second blit. Apparently unmapping a DMA mapping on x86 is a Noop, but not for all x86_64 configurations. Are DMA mappings refcounted? If not, this is not neat. If any of this is a concern, one might be better of using a big bounce buffer in the kernel, also considering the alignment constraints. Copying to and from a bounce buffer should be fairly fast also compared with PCI DMA. Judging from performance test PCI DMA BitBlt is fairly slow for copying data to the frame-buffer. About 75MB /s, and the same from the frame buffer. But in the latter direction it is a big improvement. Also it uses very little CPU for settimg up the mappings. On architectures with fast CPU and slow system-to-framebuffer bandwidth even copying to the frame-buffer should be a big gain in CPU usage. For example on a K8M800 Athlon 3400+, Xv playback of a DVD requires above 20% CPU for X just for copying data to the frame buffer. Using this PCI DMA code, I'm down to around 1%, but the theoretical maximum frame-rate should be less. Some Unichromes have broken IRQs. They generate about 30 spurious IRQs per second and the IRQs are disabled by the kernel, since nobody recognizes them. There's a low frequency polling scheme implemented for those, which is based on the looping frequency in the DRM_WAIT_ON() macro. -- 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.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 32bit builds of Mesa on 64bit platforms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Egbert Eich wrote: The patch below allows 32bit builds of Mesa on 64bit (especially x86_64) systems. The '-m32' option for gcc/g++ should work with all versions of gcc = 3.0 - also on ia32. Egbert. Index: configs/linux-dri-x86 === RCS file: /cvs/mesa/Mesa/configs/linux-dri-x86,v retrieving revision 1.9 diff -u -r1.9 linux-dri-x86 --- configs/linux-dri-x86 25 Sep 2004 07:11:12 - 1.9 +++ configs/linux-dri-x86 13 Jul 2005 14:36:27 - @@ -10,3 +10,5 @@ ASM_FLAGS = -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM ASM_SOURCES = $(X86_SOURCES) +CC = gcc -m32 +CXX = g++ -m32 Please don't do this. This is the purpose for which ARCH_FLAGS was created. I'm pretty sure there's even a comment in the Makefile to this effect. As was discussed about a week ago, trying to do this on gcc 2.96, for example, will fail. Instead just do 'make linux-dri-x86 ARCH_FLAGS=-m32' and everything will be fine. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC2BWfX1gOwKyEAw8RAkJuAKCZP1IQIbHVAUX+dfidYudVu1B77wCdGUUj g/J44ZS286j2q/COPuTLJ1U= =0J77 -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 4354] Intel's latest video driver is broken since kernel 2.6.1x
http://bugzilla.kernel.org/show_bug.cgi?id=4354 [EMAIL PROTECTED] changed: What|Removed |Added Owner|[EMAIL PROTECTED] |[EMAIL PROTECTED] |bugs.osdl.org | Status|NEW |ASSIGNED --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 32bit builds of Mesa on 64bit platforms
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Egbert Eich wrote: The patch below allows 32bit builds of Mesa on 64bit (especially x86_64) systems. The '-m32' option for gcc/g++ should work with all versions of gcc = 3.0 - also on ia32. Egbert. Index: configs/linux-dri-x86 === RCS file: /cvs/mesa/Mesa/configs/linux-dri-x86,v retrieving revision 1.9 diff -u -r1.9 linux-dri-x86 --- configs/linux-dri-x86 25 Sep 2004 07:11:12 - 1.9 +++ configs/linux-dri-x86 13 Jul 2005 14:36:27 - @@ -10,3 +10,5 @@ ASM_FLAGS = -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM ASM_SOURCES = $(X86_SOURCES) +CC = gcc -m32 +CXX = g++ -m32 Please don't do this. This is the purpose for which ARCH_FLAGS was created. I'm pretty sure there's even a comment in the Makefile to this effect. As was discussed about a week ago, trying to do this on gcc 2.96, for example, will fail. Instead just do 'make linux-dri-x86 ARCH_FLAGS=-m32' and everything will be fine. I added -m32 to the ARCH_FLAGS in linux-dri-x86. I guess I'm not as concerned about gcc 2.96 support for the DRI builds. -Brian --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
broken r128 ioctl..
Egbert pointed out one of the r128 ioctls (getparam) is declared IOW when it should be IOWR of course changing this would break userspace... I've commited a fix which makes the old ioctl GETPARAM_OLD and makes a new GETPARAM ioctl with the correct direction.. but after thinking about it this won't work either... Anyone want to give my poor brain a break? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: broken r128 ioctl..
Egbert pointed out one of the r128 ioctls (getparam) is declared IOW when it should be IOWR of course changing this would break userspace... I've commited a fix which makes the old ioctl GETPARAM_OLD and makes a new GETPARAM ioctl with the correct direction.. but after thinking about it this won't work either... Anyone want to give my poor brain a break? Thanks to Eric on IRC for setting my brain straight.. it doesn't braek things as we ignore the direction bits and just use the ioctl number bits to figure it out .. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
