On Sat, 2 Jul 2005 08:57:17 -0400 (EDT)
Vladimir Dergachev [EMAIL PROTECTED] wrote:
we may not be able to prevent all such cases doesn't mean we shouldn't
prevent the ones we can.
Without VPU recovery, it is very likely that the prices would be too high
to stand.
I really mean 'the
Aapo Tahkola wrote:
On Sat, 2 Jul 2005 08:57:17 -0400 (EDT)
Vladimir Dergachev [EMAIL PROTECTED] wrote:
we may not be able to prevent all such cases doesn't mean we shouldn't
prevent the ones we can.
Without VPU recovery, it is very likely that the prices would be too high
to stand.
I
elementary operation and construct a model that would describe performance ?
This is not a trivial task as we access the card through, essentially,
a batch interface which would make it hard to time elementary
operations by themselves with good precision (say 5% ?).
Need to get past Mesas
On Mon, 04 Jul 2005 17:12:17 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
Aapo Tahkola wrote:
On Sat, 2 Jul 2005 08:57:17 -0400 (EDT)
Vladimir Dergachev [EMAIL PROTECTED] wrote:
we may not be able to prevent all such cases doesn't mean we shouldn't
prevent the ones we can.
On Mon, 4 Jul 2005 12:12:05 -0400 (EDT)
Vladimir Dergachev [EMAIL PROTECTED] wrote:
elementary operation and construct a model that would describe performance
?
This is not a trivial task as we access the card through, essentially,
a batch interface which would make it hard to time
On Fri, 01 Jul 2005 10:51:23 -0400
Michel Dänzer [EMAIL PROTECTED] wrote:
On Fri, 2005-07-01 at 03:24 +0300, Aapo Tahkola wrote:
On Sun, 26 Jun 2005 23:48:11 -0400
Michel Dänzer [EMAIL PROTECTED] wrote:
On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote:
On Mon, 2005-06-27 at
we may not be able to prevent all such cases doesn't mean we shouldn't
prevent the ones we can.
Without VPU recovery, it is very likely that the prices would be too high
to stand.
I really mean 'the ones we can'. All I'm saying is that we should try to
prevent it whenever reasonably possible
On Fri, 2005-07-01 at 03:24 +0300, Aapo Tahkola wrote:
On Sun, 26 Jun 2005 23:48:11 -0400
Michel Dänzer [EMAIL PROTECTED] wrote:
On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote:
On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote:
Disagree also about axing the comment - its
On Sun, 26 Jun 2005 23:48:11 -0400
Michel Dänzer [EMAIL PROTECTED] wrote:
On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote:
On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote:
Disagree also about axing the comment - its useful to know why something
is being done.
Wait, the
On Mon, 2005-06-27 at 01:42 -0400, Vladimir Dergachev wrote:
I was just looking at r300 code today for my own system. A few things
that I think ought to happen for the merge:
- Clean up style. Unindented blocks of code, weird whitespace (closing
brackets on the same column as the
On 6/27/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
And something I've wondered about for a while:
- Is the __user annotation supposed to mean this is a value from
userland that should be checked for use or this is a pointer to
somewhere in userland that needs to be copy_from_usered
On Mon, 2005-06-27 at 09:09 -0400, Jon Smirl wrote:
On 6/27/05, Vladimir Dergachev [EMAIL PROTECTED] wrote:
And something I've wondered about for a while:
- Is the __user annotation supposed to mean this is a value from
userland that should be checked for use or this is a pointer to
Hi all,
I have fixed known issues with r300 DRM driver:
* r300_emit_unchecked_state properly fallbacks to
r300_emit_carefully_checked_state() when asked to set
touchy registers (i.e. those with offsets).
* r300_emit_raw properly checks LOAD_VBPNTR packet that
On Sun, 2005-06-26 at 18:54 -0400, Vladimir Dergachev wrote:
Hi all,
I have fixed known issues with r300 DRM driver:
* r300_emit_unchecked_state properly fallbacks to
r300_emit_carefully_checked_state() when asked to set
touchy registers (i.e. those with offsets).
On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote:
I was just looking at r300 code today for my own system. A few things
that I think ought to happen for the merge:
- Clean up style. Unindented blocks of code, weird whitespace (closing
brackets on the same column as the block containing it,
On Sun, 2005-06-26 at 19:53 -0400, Jon Smirl wrote:
On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote:
I was just looking at r300 code today for my own system. A few things
that I think ought to happen for the merge:
- Clean up style. Unindented blocks of code, weird whitespace (closing
On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote:
The code in DRM CVS has been run through the kernel 'scripts/Lindent'
program. There has been recent discussion on lkml about changing the
script from 80 char lines to something more modern like 120. I'd
definitely vote for 120. You will
On Llu, 2005-06-27 at 01:02, Eric Anholt wrote:
definitely vote for 120. You will need to do some manual touch up
after Lindent. It will mess up formatting of C99 initializers and some
constant blocks.
Please, 80 is standard.
Not for most code I've looked at. 80 generates horrible
On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote:
On Llu, 2005-06-27 at 01:02, Eric Anholt wrote:
definitely vote for 120. You will need to do some manual touch up
after Lindent. It will mess up formatting of C99 initializers and some
constant blocks.
Please, 80 is standard.
Not
On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote:
Are you saying this:
if ((offset=dev_priv-fb_location)
(offsetdev_priv-gart_vm_start)) return 0;
is more readable than:
if ((offset = dev_priv-fb_location)
(offset dev_priv-gart_vm_start))
On Sun, 2005-06-26 at 21:25 -0400, Jon Smirl wrote:
On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote:
Are you saying this:
if ((offset=dev_priv-fb_location)
(offsetdev_priv-gart_vm_start)) return 0;
is more readable than:
if ((offset = dev_priv-fb_location)
On Sunday 26 June 2005 21:51, Eric Anholt wrote:
Heh. One of the suggestions of BSD style is that when 80 columns
becomes too little, you probably need another function. In the diff I'm
currently testing for cleaning up map handling (which net removes 200
lines), I've removed that if
On Sun, 2005-06-26 at 18:05 -0700, Eric Anholt wrote:
On Mon, 2005-06-27 at 01:19 +0100, Alan Cox wrote:
Disagree also about axing the comment - its useful to know why something
is being done.
Wait, the comment says TODO: Remove this; we can't afford to let
userspace control something
I was just looking at r300 code today for my own system. A few things
that I think ought to happen for the merge:
- Clean up style. Unindented blocks of code, weird whitespace (closing
brackets on the same column as the block containing it, rather than the
surrounding block), lack of wrapping
24 matches
Mail list logo
