Adam Jackson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 21 August 2004 13:11, Keith Whitwell wrote:
Adam Jackson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We're getting an extensive amount of Wiki spam recently, from one
particular host. I'd like to hack moin.cgi
Hi, Erdi.
This patch adds two new ioctl's to the VIA Unichrome/Pro DRM driver:
DRM_IOCTL_VIA_DMA_INIT
DRM_IOCTL_VIA_CMDBUFFER
The first call sets up an area in AGP memory that will be used as the
ring buffer. The second call copies a command buffer from user space
memory to
There must be a lock. I used to use a patch that I found somewhere (that
does conditional reschedules), but it triggers the scheduling while
lock held kernel oops if you enable that option in the kernel
configuration.
I can't find the lock from a quick code inspection.. I'll add the
I can't find the lock from a quick code inspection.. I'll add the
reschedule to a test drm and I'll build my kernel with all the debugging
on...
I'm running the attached patch to the DRM in CVS on 2.6.8.1 and I'm not
seeing any drm related xruns.. there are other places that can do with
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://freedesktop.org/bugzilla/show_bug.cgi?id=787
[EMAIL PROTECTED] changed:
What|Removed |Added
On Mon, Aug 23, 2004 at 12:15:34PM +0100, Dave Airlie wrote:
@@ -631,7 +631,15 @@
int slots = ( RADEON_READ( RADEON_RBBM_STATUS )
RADEON_RBBM_FIFOCNT_MASK );
if ( slots = entries ) return 0;
-DRM_UDELAY( 1 );
+
+
Hi,
I made a small patch to port Linux DRM module to FreeBSD. I'm wondering nobody
has made it before...
After patching the drm directory, go into drm/bsd directory and compile by
make depend savage.
The savage.ko module is built into the savage subdirectory.
Copy the file savage.ko into
* Dave Airlie [EMAIL PROTECTED] wrote:
I can't find the lock from a quick code inspection.. I'll add the
reschedule to a test drm and I'll build my kernel with all the
debugging on...
there doesnt seem to be any further lock other than the BKL:
0001 0.558ms (+0.000ms): delay_tsc
--- Lee Revell [EMAIL PROTECTED] wrote:
On Sun, 2004-08-22 at 22:09, Mike Mestnik wrote:
--- Jon Smirl [EMAIL PROTECTED] wrote:
Michel pointed out that all IOCTL calls hold the big kernel lock.
Releasing this lock is sure to case problems since the DRM code is
not
designed to be
John Lightsey wrote:
Once I have all the benchmarks together I'll make some pretty little graphs.
Soany suggestions, comments, feedback?
First off, great work! Hopefully you'll be willing to re-run those
tests to look for regressions in future releases. ;)
I have only two criticisms.
Thomas Hellström wrote:
I just noticed that you are using a 2d BITBLT to temporarily stall the
command regulator for a moment.
I believe the XAA implementation in all current via 2d X server drivers
out there assume that they are reasonably alone in using the 2d engine and
that they expext that
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
5:00PM EDT or 2:00PM PDT, if you prefer).
Time zone conversion available at:
http://www.timezoneconverter.com/cgi-bin/tzc.tzc
Logs of previous
i'll put the patch below into the -P8 patch. (change voluntary_resched()
to cond_resched() if you apply this to a vanilla kernel.)
Ingo
--- linux/drivers/char/drm/drm_os_linux.h.orig
+++ linux/drivers/char/drm/drm_os_linux.h
@@ -14,7 +14,7 @@
#define DRM_ERR(d)
Hi!
Erdi Chen wrote:
Thomas Hellström wrote:
I just noticed that you are using a 2d BITBLT to temporarily stall the
command regulator for a moment.
I believe the XAA implementation in all current via 2d X server drivers
out there assume that they are reasonably alone in using the 2d
engine and
Previously all of the IOCTL calls were protected by the Big Kernel
Lock. If we break that aren't we allowing multiple callers into the
IOCTL code on SMP machines that weren't allowed in before? Doesn't that
mean that we have to check everything to make sure it is SMP safe?
--- Ingo Molnar [EMAIL
* Jon Smirl [EMAIL PROTECTED] wrote:
Previously all of the IOCTL calls were protected by the Big Kernel
Lock. If we break that aren't we allowing multiple callers into the
IOCTL code on SMP machines that weren't allowed in before? Doesn't
that mean that we have to check everything to make
On Llu, 2004-08-23 at 18:46, Erdi Chen wrote:
I plan to clean up the unichrome 2D driver with respect to this, but I'm
not sure when this will happen.
DRI code also uses the 2D engine. How does that work?
The DRI layer wraps enough of the X driver code that the X server is
part of the DRI
* Mike Mestnik [EMAIL PROTECTED] wrote:
as Alan mentioned it before, the BKL did not protect much, since the DRM
code was freely doing copying from and to userspace, and hence dropping
the BKL at those places.
Add sleeping(usleep) to this list, no? The big Q I have is why are
IOCTL's
I just managed to compile and install an XOrg Xserver with your patch. I
tested it on the Savage4. It works ok with 3D accel. But I noticed a
regression that I saw with the 2D driver from VIA/S3's code drop last
time. The image on my 1280x1024 DFP looks like it's stretching 1279x1024
to 1280x1024.
Hi, list!
As some of you might have read on another thread, there is a discussion
how to handle the X server (and possibly other) 2d contexts in the via /
unichrome family of drivers that expects certain 2d engine register
values to stay the same even when other contexts or DMA commands have
Hi,
I modified the host.def from DRI CVS for a trimmed down build of the
X.Org tree for DRI developers. The file is attached. Ajax (aka Adam
Jackson) suggested on IRC to commit this under a different name in
config/cf. Users/developers would copy it to host.def and make any
necessary
On Mon, 2004-08-23 at 15:24, Ian Romanick wrote:
Thomas Hellström wrote:
As some of you might have read on another thread, there is a discussion
how to handle the X server (and possibly other) 2d contexts in the via /
unichrome family of drivers that expects certain 2d engine register
Previously all of the IOCTL calls were protected by the Big Kernel
Lock. If we break that aren't we allowing multiple callers into the
IOCTL code on SMP machines that weren't allowed in before? Doesn't
that mean that we have to check everything to make sure it is SMP
safe?
as Alan
I have begun with DRI project before a few weeks and I would to improve
my knowledge on it.
therefor I would like to port the nvidia driver from utah-glx to DRI, I
think it is not very simple but it is good for me to go inside DRI
(kernel and 3d driver). I know that this will not bring something
Thomas Hellström wrote:
I just noticed that you are using a 2d BITBLT to temporarily stall the
command regulator for a moment.
I believe the XAA implementation in all current via 2d X server drivers
out there assume that they are reasonably alone in using the 2d engine and
that they expext that
--- Eric Anholt [EMAIL PROTECTED] wrote:
On Mon, 2004-08-23 at 15:24, Ian Romanick wrote:
Thomas Hellström wrote:
As some of you might have read on another thread, there is a
discussion
how to handle the X server (and possibly other) 2d contexts in the
via /
unichrome family
On Monday 23 August 2004 12:36, Ian Romanick wrote:
John Lightsey wrote:
Once I have all the benchmarks together I'll make some pretty little
graphs.
Soany suggestions, comments, feedback?
First off, great work! Hopefully you'll be willing to re-run those
tests to look for
Erdi Chen wrote:
Thomas Hellström wrote:
I just noticed that you are using a 2d BITBLT to temporarily stall the
command regulator for a moment.
I believe the XAA implementation in all current via 2d X server drivers
out there assume that they are reasonably alone in using the 2d
engine and
that
28 matches
Mail list logo
