On Thu, Sep 20, 2012 at 10:57:01AM -0400, alexdeuc...@gmail.com wrote:
> From: Christian König
>
> Only increase the higher 32bits if we really detect a wrap around.
>
> v2: instead of increasing the higher 32bits just use the higher
> 32bits from the last emitted fence.
> v3: also use last
On Thu, Sep 20, 2012 at 10:57:01AM -0400, alexdeucher at gmail.com wrote:
> From: Christian K?nig
>
> Only increase the higher 32bits if we really detect a wrap around.
>
> v2: instead of increasing the higher 32bits just use the higher
> 32bits from the last emitted fence.
> v3: also use la
From: Christian K?nig
Only increase the higher 32bits if we really detect a wrap around.
v2: instead of increasing the higher 32bits just use the higher
32bits from the last emitted fence.
v3: also use last emitted fence value as upper limit.
The intention of this patch is to make fences as
From: Christian König
Only increase the higher 32bits if we really detect a wrap around.
v2: instead of increasing the higher 32bits just use the higher
32bits from the last emitted fence.
v3: also use last emitted fence value as upper limit.
The intention of this patch is to make fences as
Only increase the higher 32bits if we really detect a wrap around.
v2: instead of increasing the higher 32bits just use the higher
32bits from the last emitted fence.
v3: also use last emitted fence value as upper limit.
The intention of this patch is to make fences as robust as
they where be
On Thu, Sep 13, 2012 at 9:54 AM, Alex Deucher wrote:
> On Thu, Sep 13, 2012 at 4:33 AM, Christian K?nig
> wrote:
>> Only increase the higher 32bits if we really detect a wrap around.
>>
>> v2: instead of increasing the higher 32bits just use the higher
>> 32bits from the last emitted fence.
>
On Thu, Sep 13, 2012 at 4:33 AM, Christian K?nig
wrote:
> Only increase the higher 32bits if we really detect a wrap around.
>
> v2: instead of increasing the higher 32bits just use the higher
> 32bits from the last emitted fence.
> v3: also use last emitted fence value as upper limit.
>
> The
On Thu, Sep 13, 2012 at 9:54 AM, Alex Deucher wrote:
> On Thu, Sep 13, 2012 at 4:33 AM, Christian König
> wrote:
>> Only increase the higher 32bits if we really detect a wrap around.
>>
>> v2: instead of increasing the higher 32bits just use the higher
>> 32bits from the last emitted fence.
>
devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
From b6c778e5742da8eb337ef1e0074a07cb0b89d361 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?=
Date: Thu, 13 Sep 2012 10:33:47 +0200
Subject: [PATCH] drm/radeon: m
Only increase the higher 32bits if we really detect a wrap around.
v2: instead of increasing the higher 32bits just use the higher
32bits from the last emitted fence.
v3: also use last emitted fence value as upper limit.
The intention of this patch is to make fences as robust as
they where be
On Die, 2012-09-11 at 12:11 +0200, Christian K?nig wrote:
>
> How about this idea: Instead of increasing the upper 32bits we just use
> the upper 32bits of the last emitted fence value?
> E.g. see the attached patch. That both should handle random zero and out
> of order values more gracefully.
On 10.09.2012 18:07, Jerome Glisse wrote:
> On Mon, Sep 10, 2012 at 11:52 AM, Jerome Glisse wrote:
>> On Mon, Sep 10, 2012 at 11:38 AM, Michel D?nzer
>> wrote:
>>> On Mon, 2012-09-10 at 14:02 +0200, Christian K?nig wrote:
On 10.09.2012 13:12, Michel D?nzer wrote:
> On Mon, 2012-09-10 at
On Tue, Sep 11, 2012 at 6:23 AM, Michel D?nzer wrote:
> On Die, 2012-09-11 at 12:11 +0200, Christian K?nig wrote:
>>
>> How about this idea: Instead of increasing the upper 32bits we just use
>> the upper 32bits of the last emitted fence value?
>> E.g. see the attached patch. That both should hand
On Tue, Sep 11, 2012 at 6:23 AM, Michel Dänzer wrote:
> On Die, 2012-09-11 at 12:11 +0200, Christian König wrote:
>>
>> How about this idea: Instead of increasing the upper 32bits we just use
>> the upper 32bits of the last emitted fence value?
>> E.g. see the attached patch. That both should hand
>>>
>>>
It might be related to a hardware bug, or the algorithm is flawed in a
way I currently don't see. Anyway the old code we had wasn't so picky
about such problems and the patch just tries to make the current code as
robust as the old code was, which indeed seems to solve t
On Die, 2012-09-11 at 12:11 +0200, Christian König wrote:
>
> How about this idea: Instead of increasing the upper 32bits we just use
> the upper 32bits of the last emitted fence value?
> E.g. see the attached patch. That both should handle random zero and out
> of order values more gracefully.
4fae6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Christian=20K=C3=B6nig?=
Date: Sun, 9 Sep 2012 11:45:19 +0200
Subject: [PATCH] drm/radeon: make 64bit fences more robust v2
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Only increase the higher 32bits if we
On Mon, 2012-09-10 at 14:02 +0200, Christian K?nig wrote:
> On 10.09.2012 13:12, Michel D?nzer wrote:
> > On Mon, 2012-09-10 at 11:13 +0200, Christian K?nig wrote:
> >> Only increase the higher 32bits if we really detect a wrap around.
> >>
> >> Fixes:
> >> https://bugs.freedesktop.org/show_bug.cg
On Mon, Sep 10, 2012 at 5:10 PM, Jerome Glisse wrote:
> On Mon, Sep 10, 2012 at 4:13 PM, Dave Airlie wrote:
>
>
>> It might be related to a hardware bug, or the algorithm is flawed in a
>> way I currently don't see. Anyway the old code we had wasn't so picky
>> about such prob
On Mon, Sep 10, 2012 at 4:13 PM, Dave Airlie wrote:
> It might be related to a hardware bug, or the algorithm is flawed in a
> way I currently don't see. Anyway the old code we had wasn't so picky
> about such problems and the patch just tries to make the current code as
On Mon, Sep 10, 2012 at 5:10 PM, Jerome Glisse wrote:
> On Mon, Sep 10, 2012 at 4:13 PM, Dave Airlie wrote:
>
>
>> It might be related to a hardware bug, or the algorithm is flawed in a
>> way I currently don't see. Anyway the old code we had wasn't so picky
>> about such prob
On Mon, Sep 10, 2012 at 4:13 PM, Dave Airlie wrote:
> It might be related to a hardware bug, or the algorithm is flawed in a
> way I currently don't see. Anyway the old code we had wasn't so picky
> about such problems and the patch just tries to make the current code as
On 10.09.2012 13:12, Michel D?nzer wrote:
> On Mon, 2012-09-10 at 11:13 +0200, Christian K?nig wrote:
>> Only increase the higher 32bits if we really detect a wrap around.
>>
>> Fixes:
>> https://bugs.freedesktop.org/show_bug.cgi?id=54129
>> https://bugs.freedesktop.org/show_bug.cgi?id=54662
>>
>>
>>>
>>>
It might be related to a hardware bug, or the algorithm is flawed in a
way I currently don't see. Anyway the old code we had wasn't so picky
about such problems and the patch just tries to make the current code as
robust as the old code was, which indeed seems to solve t
On Mon, 2012-09-10 at 11:13 +0200, Christian K?nig wrote:
> Only increase the higher 32bits if we really detect a wrap around.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=54129
> https://bugs.freedesktop.org/show_bug.cgi?id=54662
>
> Possible fixes:
> https://bugzilla.redhat.com/sh
On Mon, Sep 10, 2012 at 11:52 AM, Jerome Glisse wrote:
> On Mon, Sep 10, 2012 at 11:38 AM, Michel D?nzer wrote:
>> On Mon, 2012-09-10 at 14:02 +0200, Christian K?nig wrote:
>>> On 10.09.2012 13:12, Michel D?nzer wrote:
>>> > On Mon, 2012-09-10 at 11:13 +0200, Christian K?nig wrote:
>>> >> Only in
On Mon, Sep 10, 2012 at 11:38 AM, Michel D?nzer wrote:
> On Mon, 2012-09-10 at 14:02 +0200, Christian K?nig wrote:
>> On 10.09.2012 13:12, Michel D?nzer wrote:
>> > On Mon, 2012-09-10 at 11:13 +0200, Christian K?nig wrote:
>> >> Only increase the higher 32bits if we really detect a wrap around.
>>
On Mon, Sep 10, 2012 at 8:02 AM, Christian K?nig
wrote:
> On 10.09.2012 13:12, Michel D?nzer wrote:
>>
>> On Mon, 2012-09-10 at 11:13 +0200, Christian K?nig wrote:
>>>
>>> Only increase the higher 32bits if we really detect a wrap around.
>>>
>>> Fixes:
>>> https://bugs.freedesktop.org/show_bug.cg
Only increase the higher 32bits if we really detect a wrap around.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54129
https://bugs.freedesktop.org/show_bug.cgi?id=54662
Possible fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=846505
https://bugzilla.redhat.com/show_bug.cgi?id=845639
Si
On Mon, Sep 10, 2012 at 11:52 AM, Jerome Glisse wrote:
> On Mon, Sep 10, 2012 at 11:38 AM, Michel Dänzer wrote:
>> On Mon, 2012-09-10 at 14:02 +0200, Christian König wrote:
>>> On 10.09.2012 13:12, Michel Dänzer wrote:
>>> > On Mon, 2012-09-10 at 11:13 +0200, Christian König wrote:
>>> >> Only in
On Mon, Sep 10, 2012 at 11:38 AM, Michel Dänzer wrote:
> On Mon, 2012-09-10 at 14:02 +0200, Christian König wrote:
>> On 10.09.2012 13:12, Michel Dänzer wrote:
>> > On Mon, 2012-09-10 at 11:13 +0200, Christian König wrote:
>> >> Only increase the higher 32bits if we really detect a wrap around.
>>
On Mon, 2012-09-10 at 14:02 +0200, Christian König wrote:
> On 10.09.2012 13:12, Michel Dänzer wrote:
> > On Mon, 2012-09-10 at 11:13 +0200, Christian König wrote:
> >> Only increase the higher 32bits if we really detect a wrap around.
> >>
> >> Fixes:
> >> https://bugs.freedesktop.org/show_bug.cg
On Mon, Sep 10, 2012 at 8:02 AM, Christian König
wrote:
> On 10.09.2012 13:12, Michel Dänzer wrote:
>>
>> On Mon, 2012-09-10 at 11:13 +0200, Christian König wrote:
>>>
>>> Only increase the higher 32bits if we really detect a wrap around.
>>>
>>> Fixes:
>>> https://bugs.freedesktop.org/show_bug.cg
On 10.09.2012 13:12, Michel Dänzer wrote:
On Mon, 2012-09-10 at 11:13 +0200, Christian König wrote:
Only increase the higher 32bits if we really detect a wrap around.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54129
https://bugs.freedesktop.org/show_bug.cgi?id=54662
Possible fixes:
ht
On Mon, 2012-09-10 at 11:13 +0200, Christian König wrote:
> Only increase the higher 32bits if we really detect a wrap around.
>
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=54129
> https://bugs.freedesktop.org/show_bug.cgi?id=54662
>
> Possible fixes:
> https://bugzilla.redhat.com/sh
Only increase the higher 32bits if we really detect a wrap around.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54129
https://bugs.freedesktop.org/show_bug.cgi?id=54662
Possible fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=846505
https://bugzilla.redhat.com/show_bug.cgi?id=845639
Si
36 matches
Mail list logo