Re: Xserver freezes with radeon.ko loaded

2005-07-15 Thread Tino Keitel
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

2005-07-15 Thread Rune Petersen
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

2005-07-15 Thread Egbert Eich

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

2005-07-15 Thread Sander Sweers
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

2005-07-15 Thread Egbert Eich

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

2005-07-15 Thread Egbert Eich

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

2005-07-15 Thread Jon Smirl
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

2005-07-15 Thread Brian Paul

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

2005-07-15 Thread bugzilla-daemon
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

2005-07-15 Thread Vladimir Dergachev


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

2005-07-15 Thread bugzilla-daemon
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

2005-07-15 Thread Ian Romanick
-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

2005-07-15 Thread bugme-daemon
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

2005-07-15 Thread Brian Paul

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..

2005-07-15 Thread Dave Airlie

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..

2005-07-15 Thread Dave Airlie
 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