The DRI and DRM websites are such a mess for a user point of view
WE will take the example of DRM
for example if a user comes here for installing DRM instead of
his distribution
he get lost
The first thing is that inside the kenrel there is DRM support
it is told that this DRM is for Xfree
so i su
Benjamin Herrenschmidt wrote:
It should probably be infinite if no hw lock is being held.
Lock should be dropped in case of longer waits so that user is given a chance
to stop the process.
Well, the current behaviour (i.e. return EBUSY after 3 seconds) would
make sense too, the user-space drive
> > It should probably be infinite if no hw lock is being held.
> > Lock should be dropped in case of longer waits so that user is given a
> > chance to stop the process.
> Well, the current behaviour (i.e. return EBUSY after 3 seconds) would
> make sense too, the user-space driver could simply r
Aapo Tahkola wrote:
On Sun, 28 May 2006 19:57:40 +0200
Roland Scheidegger <[EMAIL PROTECTED]> wrote:
Rune Petersen wrote:
Hmm, interesting. This problem does not appear to be r300 specific,
radeon/r200 use the same code (haven't seen problems with it, though).
That said, it looks to me like t
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=6429
--- Additional Comments From [EMAIL PROTECTED] 2006-05-29 06:30 ---
My co
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=6429
--- Additional Comments From [EMAIL PROTECTED] 2006-05-29 05:20 ---
I can
Roland Scheidegger wrote:
(e.g. while (ret && (errno == EINTR || errno == EBUSY));)
And by looking at it, does it make sense that the timeout value in
the kernel depends on the kernel-of-the-day HZ value, rather than
some hardware-dependant (probably fixed) value?
Isn't the timeout value dep
On Sun, May 28, 2006 at 06:36:27PM +0200, Thomas Hellström wrote:
>
> New semantics:
> The new manager always aligns to 16 bytes, except when it is bypassed by
> the SiS fb module.
This alarmed me; I don't want to see VIAs problem become a DRM wide
rule.
But it seems as if this alignment is en
On Sun, 28 May 2006 19:57:40 +0200
Roland Scheidegger <[EMAIL PROTECTED]> wrote:
> Rune Petersen wrote:
> >> Hmm, interesting. This problem does not appear to be r300 specific,
> >> radeon/r200 use the same code (haven't seen problems with it, though).
> >> That said, it looks to me like that io
Rune Petersen wrote:
Hmm, interesting. This problem does not appear to be r300 specific,
radeon/r200 use the same code (haven't seen problems with it, though).
That said, it looks to me like that ioctl will actually never return
EAGAIN, maybe the original intention was to just wait indefinitely
Hi!
I've created a branch drm-sman-branch with a new drm core version of the
memory manager used with the SiS and VIA drivers. This is to give the
hash table- and core memory manager algorithms implementation of the
drm-ttm-branch some testing (It's using the same code) and also to
improve t
Roland Scheidegger wrote:
Rune Petersen wrote:
The patch makes radeonWaitIrq() try again if -EBUSY is returned.
This fixes benchmark 3 & 4 in progs/demos/gltestperf
Benchmark: 3 - ZSmooth Tex Blend Triangles
Benchmark: 4 - ZSmooth Tex Blend TMesh Triangles
Not an important app, but other apps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lately, the 3D driver on my laptop (iBook 2001 dual usb, powerpc, Debian
GNU/Linux testing/unstable) has been slowing down in certain conditions.
glxgears runs fine, crack-attack has a good framerate until a red 'garbage
block' comes down and armagetr
13 matches
Mail list logo
