On Fre, 2012-09-14 at 21:10 +0400, Dmitry Cherkassov wrote:
>
> > E.g. reflect from Mesa Demos wasn't able to sustain 60 fps in
> > fullscreen.
> >
>
> I've tried reflect with my patches on cayman and it sustained 60 fps
> in maximized window
> @ 1680x1080
>
> I'll test when i have tahiti machi
On Fre, 2012-09-14 at 21:10 +0400, Dmitry Cherkassov wrote:
>
> > E.g. reflect from Mesa Demos wasn't able to sustain 60 fps in
> > fullscreen.
> >
>
> I've tried reflect with my patches on cayman and it sustained 60 fps
> in maximized window
> @ 1680x1080
>
> I'll test when i have tahiti machi
Michel,
> E.g. reflect from Mesa Demos wasn't able to sustain 60 fps in
> fullscreen.
>
I've tried reflect with my patches on cayman and it sustained 60 fps
in maximized window
@ 1680x1080
I'll test when i have tahiti machine ready.
--
With best regards,
Dmitry
Michel,
> E.g. reflect from Mesa Demos wasn't able to sustain 60 fps in
> fullscreen.
>
I've tried reflect with my patches on cayman and it sustained 60 fps
in maximized window
@ 1680x1080
I'll test when i have tahiti machine ready.
--
With best regards,
Dmitry
> With that fixed, it seems to work on SI, but seems to slow things down
> significantly. Have you noticed that as well? Any idea what might be the
> reason?
>
Thanks I'll put it up to the patch.
I had everything running slow on cayman when having lots of debugging output,
removing it fixed the sl
ander; Dave Airlie; Dmitry
> Cherkasov
> Subject: Re: [PATCH] Add 2-level GPUVM pagetables support to radeon
> driver.
>
> On 13.09.2012 20:42, Jerome Glisse wrote:
> > On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher
> wrote:
> >> On Thu, Sep 13, 2012 at 2:17 PM, Jerom
On Fre, 2012-09-14 at 13:04 +0400, Dmitry Cherkassov wrote:
> > With that fixed, it seems to work on SI, but seems to slow things down
> > significantly. Have you noticed that as well? Any idea what might be the
> > reason?
> >
> Thanks I'll put it up to the patch.
>
> I had everything running sl
On 13.09.2012 20:42, Jerome Glisse wrote:
> On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher
> wrote:
>> On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse wrote:
>>> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
>>> wrote:
PDE/PTE update code uses CP ring for memory writes.
All page ta
On Don, 2012-09-13 at 18:13 +0400, Dmitry Cherkasov wrote:
> PDE/PTE update code uses CP ring for memory writes.
> All page table entries are preallocated for now in alloc_pt().
>
> It is made as whole because it's hard to divide it to several patches
> that compile and doesn't break anything bei
ave Airlie; Dmitry
> Cherkasov
> Subject: Re: [PATCH] Add 2-level GPUVM pagetables support to radeon
> driver.
>
> On 13.09.2012 20:42, Jerome Glisse wrote:
> > On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher
> wrote:
> >> On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glis
> With that fixed, it seems to work on SI, but seems to slow things down
> significantly. Have you noticed that as well? Any idea what might be the
> reason?
>
Thanks I'll put it up to the patch.
I had everything running slow on cayman when having lots of debugging output,
removing it fixed the sl
On Fre, 2012-09-14 at 13:04 +0400, Dmitry Cherkassov wrote:
> > With that fixed, it seems to work on SI, but seems to slow things down
> > significantly. Have you noticed that as well? Any idea what might be the
> > reason?
> >
> Thanks I'll put it up to the patch.
>
> I had everything running sl
On 13.09.2012 20:42, Jerome Glisse wrote:
On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher wrote:
On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse wrote:
On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
wrote:
PDE/PTE update code uses CP ring for memory writes.
All page table entries are preal
On Don, 2012-09-13 at 18:13 +0400, Dmitry Cherkasov wrote:
> PDE/PTE update code uses CP ring for memory writes.
> All page table entries are preallocated for now in alloc_pt().
>
> It is made as whole because it's hard to divide it to several patches
> that compile and doesn't break anything bei
Christian,
> as I already noted in our internal discussion, the first step to
> hierarchical page table support should be to cleanup the set_page interface.
> Please see the attached patch, it does exactly this. I suggest that you
> rebase on it and try to don't touch the chipset specific code in
Christian,
> as I already noted in our internal discussion, the first step to
> hierarchical page table support should be to cleanup the set_page interface.
> Please see the attached patch, it does exactly this. I suggest that you
> rebase on it and try to don't touch the chipset specific code in
Dropping David and kernel mailing list for now, they are probably not
immediately interested in such specific discussion.
On 13.09.2012 18:52, Dmitry Cherkassov wrote:
> Christian,
>
>> as I already noted in our internal discussion, the first step to
>> hierarchical page table support should be t
PDE/PTE update code uses CP ring for memory writes.
All page table entries are preallocated for now in alloc_pt().
It is made as whole because it's hard to divide it to several patches
that compile and doesn't break anything being applied separately.
Tested on cayman card.
Signed-off-by: Dmitry
Hi Dmitry,
as I already noted in our internal discussion, the first step to
hierarchical page table support should be to cleanup the set_page
interface. Please see the attached patch, it does exactly this. I
suggest that you rebase on it and try to don't touch the chipset
specific code in ni.c
On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher wrote:
> On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse wrote:
>> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
>> wrote:
>>> PDE/PTE update code uses CP ring for memory writes.
>>> All page table entries are preallocated for now in alloc_pt().
On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse wrote:
> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
> wrote:
>> PDE/PTE update code uses CP ring for memory writes.
>> All page table entries are preallocated for now in alloc_pt().
>>
>> It is made as whole because it's hard to divide it to
On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
wrote:
> PDE/PTE update code uses CP ring for memory writes.
> All page table entries are preallocated for now in alloc_pt().
>
> It is made as whole because it's hard to divide it to several patches
> that compile and doesn't break anything being
On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher wrote:
> On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse wrote:
>> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
>> wrote:
>>> PDE/PTE update code uses CP ring for memory writes.
>>> All page table entries are preallocated for now in alloc_pt().
On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse wrote:
> On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
> wrote:
>> PDE/PTE update code uses CP ring for memory writes.
>> All page table entries are preallocated for now in alloc_pt().
>>
>> It is made as whole because it's hard to divide it to
On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov
wrote:
> PDE/PTE update code uses CP ring for memory writes.
> All page table entries are preallocated for now in alloc_pt().
>
> It is made as whole because it's hard to divide it to several patches
> that compile and doesn't break anything being
Dropping David and kernel mailing list for now, they are probably not
immediately interested in such specific discussion.
On 13.09.2012 18:52, Dmitry Cherkassov wrote:
Christian,
as I already noted in our internal discussion, the first step to
hierarchical page table support should be to clea
PDE/PTE update code uses CP ring for memory writes.
All page table entries are preallocated for now in alloc_pt().
It is made as whole because it's hard to divide it to several patches
that compile and doesn't break anything being applied separately.
Tested on cayman card.
Signed-off-by: Dmitry
Hi Dmitry,
as I already noted in our internal discussion, the first step to
hierarchical page table support should be to cleanup the set_page
interface. Please see the attached patch, it does exactly this. I
suggest that you rebase on it and try to don't touch the chipset
specific code in ni.
28 matches
Mail list logo