On Mon, 2004-09-20 at 15:00, Roland Scheidegger wrote:
Eric Anholt wrote:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying save the state at the next unlock, which means
memcpying
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=1220
--- Additional Comments From [EMAIL PROTECTED] 2004-09-21 00:25 ---
It seems
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=1220
--- Additional Comments From [EMAIL PROTECTED] 2004-09-21 02:26 ---
hi,
you
I picked a very simple piece of code to start out with as a test case.
The I2C code is only a hundred lines and could be rewritten. But
what's the point, BSD doesn't have Linux's I2C driver system. This
code has no value anywhere but on Linux.
That's not a statement thats safe to make. BSD (or any
Le mardi 21 septembre 2004 00:58 -0700, Kean Johnston a crit :
I picked a very simple piece of code to start out with as a test case.
The I2C code is only a hundred lines and could be rewritten. But
what's the point, BSD doesn't have Linux's I2C driver system. This
code has no value
Le mar 21/09/2004 09:58, Kean Johnston a crit :
I picked a very simple piece of code to start out with as a test case.
The I2C code is only a hundred lines and could be rewritten. But
what's the point, BSD doesn't have Linux's I2C driver system. This
code has no value anywhere but on
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=1220
[EMAIL PROTECTED] changed:
What|Removed |Added
On Maw, 2004-09-21 at 08:58, Kean Johnston wrote:
That's not a statement thats safe to make. BSD (or any other OS
that XOrg supports) may not have Linux's I2C driver system. TODAY.
What if, next week, BSD gets such a beast, or HP-UX does, or
Well they can't use the low level Linux code anyway,
I have began to study the GLX code, to see the best way of getting
Composite extension to support redirection of GLX. I will concentrate at
first on server side code (software rendering). this will be a key to go
afterwards to support DRI.
I would like to know if there is someone has began this
On Mon, 20 Sep 2004 13:38:15 -0400, Adam Jackson [EMAIL PROTECTED] wrote:
On Monday 20 September 2004 12:59, Jon Smirl wrote:
On Mon, 20 Sep 2004 12:29:30 -0400, Adam Jackson [EMAIL PROTECTED] wrote:
License compatibility != OS compatibility, please don't conflate the two.
X runs on more
Alan,
Please read, understand and comment on the license policy strawman I
posted both to dri-devel and the xorg list.
It is a strawman, a first draft, and as I understand my intent,
is specifically intended to make it possible to permit such
situations. Whether it actually says that clearly,
On Tuesday 21 September 2004 10:24, Alex Deucher wrote:
On Mon, 20 Sep 2004 13:38:15 -0400, Adam Jackson [EMAIL PROTECTED] wrote:
I would read it as since the code never forked, we're still BSD.
Inclusion is not conversion, in this case. All the copyright statements
in the DRM source
On Tue, 21 Sep 2004 14:45:07 +0200, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
1) user owns graphics devices
2) user sets mode with string (or similar) format using ioctl common to
all drivers.
3) driver is locked to prevent multiple mode sets
4) common code takes this string and 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://freedesktop.org/bugzilla/show_bug.cgi?id=1428
--- Additional Comments From [EMAIL PROTECTED] 2004-09-21 08:58 ---
This
On Maw, 2004-09-21 at 16:19, Jim Gettys wrote:
Please read, understand and comment on the license policy strawman I
posted both to dri-devel and the xorg list.
Oh I did, don't take my response as anything but throwing up the
logical conclusion to that policy. I'm not in favour of that
Am Montag, 20. September 2004 23:14 schrieb Eric Anholt:
On Mon, 2004-09-20 at 12:58, Dieter Ntzel wrote:
Am Montag, 20. September 2004 21:52 schrieb Dieter Ntzel:
Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt:
The attached patch removes the mandatory emits of all state which
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=1428
--- Additional Comments From [EMAIL PROTECTED] 2004-09-21 12:08 ---
Yes
Am Dienstag, 21. September 2004 00:00 schrieb Roland Scheidegger:
Eric Anholt wrote:
The attached patch removes the mandatory emits of all state which were
happening after each cmdbuf flush. Instead, we set a flag after a
cmdbuf flush saying save the state at the next unlock, which means
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=1428
[EMAIL PROTECTED] changed:
What|Removed |Added
_mesa_test_os_sse_exception, executed upon start of any OpenGL
application raises SIGFPE. Normally this is not a problem,
applications continue to execute normally.
However when using the jogl OpenGL Java binding programs exit.
I tried both with Java 1.4 from Sun and sablevm.
Philipp
Hi.
I am very happy to see that the more recent Radeons are being looked into.
A few questions:
1. Is the rv360 (9600xt) close enough to the developers hardware to
a) benefit from the 2d improvements already made w.r.t. CP acceleration
b) be of any use for testing purposes
If the answer to a)
Dieter Nützel wrote:
This gets about a 5% speedup for me in ipers (which I wish was more
accurate in its reporting), and doesn't touch glxgears. I didn't have
any interesting apps besides glxgears handy to benchmark with. Any
thoughts on this? If people think it's a good idea, I'll do it for
On Tue, 21 Sep 2004 10:18:01 -0800, Dag Bakke [EMAIL PROTECTED] wrote:
Hi.
I am very happy to see that the more recent Radeons are being looked into.
A few questions:
1. Is the rv360 (9600xt) close enough to the developers hardware to
a) benefit from the 2d improvements already made
Am Montag, 20. September 2004 22:13 schrieb Ian Romanick:
Eric Anholt wrote:
This gets about a 5% speedup for me in ipers (which I wish was more
accurate in its reporting), and doesn't touch glxgears. I didn't have
any interesting apps besides glxgears handy to benchmark with.
I should
On Maw, 2004-09-21 at 19:18, Dag Bakke wrote:
1. Is the rv360 (9600xt) close enough to the developers hardware to
a) benefit from the 2d improvements already made w.r.t. CP acceleration
b) be of any use for testing purposes
The 6.8.0 server supports 2D acceleration up to the PCI Express cards
Eric Anholt wrote:
Yeah, it was clear that we used to emit in whatever order, and that
would have been nicer. At this point I'm seeing about 5% CPU time in
EmitState for ipers, which seems pretty hefty for such a small bit
of code, but I didn't see much obvious for improvement.
That's indeed
On Maw, 2004-09-21 at 16:56, Jon Smirl wrote:
Driver decides to either do it itself in kernel, or call userspace
helper if that would be too complex.
It is
The driver almost always needs to go to user space to get the file of
mode line overrides that the user can create. But there is
- Original Message -
From: Alan Cox [EMAIL PROTECTED]
Date: Tue, 21 Sep 2004 21:40:54 +0100
To: Dag Bakke [EMAIL PROTECTED]
Subject: Re: [r300] - likely compatibility w rv360?
On Maw, 2004-09-21 at 19:18, Dag Bakke wrote:
1. Is the rv360 (9600xt) close enough to the developers
On Tue, 2004-09-21 at 10:41, Dieter Nützel wrote:
Am Montag, 20. September 2004 23:14 schrieb Eric Anholt:
On Mon, 2004-09-20 at 12:58, Dieter Nützel wrote:
Am Montag, 20. September 2004 21:52 schrieb Dieter Nützel:
Am Sonntag, 19. September 2004 11:21 schrieb Eric Anholt:
The
29 matches
Mail list logo
