On Mon, Nov 15, 2010 at 09:40:14PM +0100, Thomas Hellstrom wrote:
> >Hence I think that drivers with extremely specific needs should roll their
> >own allocator. So I don't think we should anticipate different allocator
> >algorithms. I see driver-specific stuff more in the area of clever
> >evicti
On 11/15/2010 08:45 PM, Daniel Vetter wrote:
> Hi Thomas,
>
> On Mon, Nov 15, 2010 at 08:58:13AM +0100, Thomas Hellstrom wrote:
>
>> Nice work, although I have some comments about general applicability
>> that we perhaps need to think about.
>>
>> 1) The space representation and space allocatio
Hi Thomas,
On Mon, Nov 15, 2010 at 08:58:13AM +0100, Thomas Hellstrom wrote:
> Nice work, although I have some comments about general applicability
> that we perhaps need to think about.
>
> 1) The space representation and space allocation algorithm is
> something that is private to the aperture
On Mon, Nov 15, 2010 at 09:40:14PM +0100, Thomas Hellstrom wrote:
> >Hence I think that drivers with extremely specific needs should roll their
> >own allocator. So I don't think we should anticipate different allocator
> >algorithms. I see driver-specific stuff more in the area of clever
> >evicti
On 11/15/2010 08:45 PM, Daniel Vetter wrote:
Hi Thomas,
On Mon, Nov 15, 2010 at 08:58:13AM +0100, Thomas Hellstrom wrote:
Nice work, although I have some comments about general applicability
that we perhaps need to think about.
1) The space representation and space allocation algorithm is
Hi Thomas,
On Mon, Nov 15, 2010 at 08:58:13AM +0100, Thomas Hellstrom wrote:
> Nice work, although I have some comments about general applicability
> that we perhaps need to think about.
>
> 1) The space representation and space allocation algorithm is
> something that is private to the aperture
Hi Daniel,
I have tried a reduced patchset (w/o drm/i915 stuff) from [1] on a
RV250 with linux-next (next-20101115).
(See also P.S. for my full patchset)
# lspci -nnvv | grep "VGA compatible controller"
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon
RV250 [Mobility FireGL 9
On 11/12/2010 06:36 PM, Daniel Vetter wrote:
> Hi all,
>
> This patch-set changes the algorithm in drm_mm.c to not need additional
> allocations to track free space and adds an api to make embedding struct
> drm_mm_node possible. Benefits:
>
> - If struct drm_mm_node is provided, no allocations nee
Hi Daniel,
I have tried a reduced patchset (w/o drm/i915 stuff) from [1] on a
RV250 with linux-next (next-20101115).
(See also P.S. for my full patchset)
# lspci -nnvv | grep "VGA compatible controller"
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon
RV250 [Mobility FireGL 9
On 11/12/2010 06:36 PM, Daniel Vetter wrote:
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocations need to be do
On Sun, Nov 14, 2010 at 7:54 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
>> Hmm, I tried with your patches from ML plus missing patch and
>> extracted patches from ~danvet/drm/embed-gtt-space.
>> Sth. messed up
>>
>> Could be a "big.diff" is needed,
On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
> Hmm, I tried with your patches from ML plus missing patch and
> extracted patches from ~danvet/drm/embed-gtt-space.
> Sth. messed up
>
> Could be a "big.diff" is needed, *not* a chronological series.
> I will do a big.diff from 008
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
>> NOPE, linux-next is up-to-date what drm-next concerns.
>
> Sorry for wasting your time, I've totally forgotten about a patch in
> drm-intel-next
> (git://git.kernel.org/pub/scm/l
Found myself :-)
$ ls -l 0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
-rw-r--r-- 1 sd sd 3620 14. Nov 19:15
0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat D
On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
> NOPE, linux-next is up-to-date what drm-next concerns.
Sorry for wasting your time, I've totally forgotten about a patch in
drm-intel-next
(git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git),
namely:
commit d935cc61d46
On Sun, Nov 14, 2010 at 6:27 PM, Sedat Dilek
wrote:
> On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
>> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>>> Thanks in advance.
>>
>> Just drop patches
On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>> Thanks in advance.
>
> Just drop patches 5-9 (you can apply patch 8 without any problems, it's
> just
On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
> If you could geneate a patchset w/o i915 parts for testing would be cool.
> Thanks in advance.
Just drop patches 5-9 (you can apply patch 8 without any problems, it's
just not gonna do anything without patch 9 ;). After all, this patch
On Sun, Nov 14, 2010 at 5:13 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
>> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
>> Linus-tree is causing conflicts.
>
> I've just retested merging with drm-core-next / drm-next and the core
On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
> Linus-tree is causing conflicts.
I've just retested merging with drm-core-next / drm-next and the core
drm_mm parts merge without conflict. The i915 parts fail all
On Sun, Nov 14, 2010 at 3:38 PM, Chris Wilson
wrote:
> On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek googlemail.com> wrote:
>> [ Please CC me I am not subscribed to dri-devel ML ]
>>
>> [ QUOTE ]
>> As a proof of concept I've converted i915. Beware though, the drm/i915
>> patches depend on my
[ Please CC me I am not subscribed to dri-devel ML ]
[ QUOTE ]
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocati
On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek
wrote:
> [ Please CC me I am not subscribed to dri-devel ML ]
>
> [ QUOTE ]
> As a proof of concept I've converted i915. Beware though, the drm/i915
> patches depend on my direct-gtt patches (which are actually the reason for
> this series here).
>
On Sun, Nov 14, 2010 at 7:54 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
>> Hmm, I tried with your patches from ML plus missing patch and
>> extracted patches from ~danvet/drm/embed-gtt-space.
>> Sth. messed up
>>
>> Could be a "big.diff" is needed,
On Sun, Nov 14, 2010 at 07:31:24PM +0100, Sedat Dilek wrote:
> Hmm, I tried with your patches from ML plus missing patch and
> extracted patches from ~danvet/drm/embed-gtt-space.
> Sth. messed up
>
> Could be a "big.diff" is needed, *not* a chronological series.
> I will do a big.diff from 008
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
>> NOPE, linux-next is up-to-date what drm-next concerns.
>
> Sorry for wasting your time, I've totally forgotten about a patch in
> drm-intel-next
> (git://git.kernel.org/pub/scm/l
Found myself :-)
$ ls -l 0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
-rw-r--r-- 1 sd sd 3620 14. Nov 19:15
0001-drm_mm-add-support-for-range-restricted-fair-lru-sca.patch
On Sun, Nov 14, 2010 at 7:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat D
On Sun, Nov 14, 2010 at 06:52:35PM +0100, Sedat Dilek wrote:
> NOPE, linux-next is up-to-date what drm-next concerns.
Sorry for wasting your time, I've totally forgotten about a patch in
drm-intel-next
(git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git),
namely:
commit d935cc61d46
On Sun, Nov 14, 2010 at 6:27 PM, Sedat Dilek wrote:
> On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
>> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>>> Thanks in advance.
>>
>> Just drop patches
On Sun, Nov 14, 2010 at 6:14 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
>> If you could geneate a patchset w/o i915 parts for testing would be cool.
>> Thanks in advance.
>
> Just drop patches 5-9 (you can apply patch 8 without any problems, it's
> just
On Sun, Nov 14, 2010 at 05:56:04PM +0100, Sedat Dilek wrote:
> If you could geneate a patchset w/o i915 parts for testing would be cool.
> Thanks in advance.
Just drop patches 5-9 (you can apply patch 8 without any problems, it's
just not gonna do anything without patch 9 ;). After all, this patch
On Sun, Nov 14, 2010 at 5:13 PM, Daniel Vetter wrote:
> On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
>> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
>> Linus-tree is causing conflicts.
>
> I've just retested merging with drm-core-next / drm-next and the core
On Sun, Nov 14, 2010 at 04:52:43PM +0100, Sedat Dilek wrote:
> Pulling/Merging Daniel's GIT branch into drm-next (or linux-next) or
> Linus-tree is causing conflicts.
I've just retested merging with drm-core-next / drm-next and the core
drm_mm parts merge without conflict. The i915 parts fail all
On Sun, Nov 14, 2010 at 3:38 PM, Chris Wilson wrote:
> On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek
> wrote:
>> [ Please CC me I am not subscribed to dri-devel ML ]
>>
>> [ QUOTE ]
>> As a proof of concept I've converted i915. Beware though, the drm/i915
>> patches depend on my direct-gtt pat
On Sun, 14 Nov 2010 15:03:31 +0100, Sedat Dilek
wrote:
> [ Please CC me I am not subscribed to dri-devel ML ]
>
> [ QUOTE ]
> As a proof of concept I've converted i915. Beware though, the drm/i915
> patches depend on my direct-gtt patches (which are actually the reason for
> this series here).
>
[ Please CC me I am not subscribed to dri-devel ML ]
[ QUOTE ]
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocati
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocations need to be done anymore
in drm_mm. It looks like some dece
On Fri, 12 Nov 2010 18:36:32 +0100, Daniel Vetter
wrote:
> Hi all,
>
> This patch-set changes the algorithm in drm_mm.c to not need additional
> allocations to track free space and adds an api to make embedding struct
> drm_mm_node possible.
I like the end result for i915 in that it couples the
On Fri, 12 Nov 2010 18:36:32 +0100, Daniel Vetter
wrote:
> Hi all,
>
> This patch-set changes the algorithm in drm_mm.c to not need additional
> allocations to track free space and adds an api to make embedding struct
> drm_mm_node possible.
I like the end result for i915 in that it couples the
Hi all,
This patch-set changes the algorithm in drm_mm.c to not need additional
allocations to track free space and adds an api to make embedding struct
drm_mm_node possible. Benefits:
- If struct drm_mm_node is provided, no allocations need to be done anymore
in drm_mm. It looks like some dece
40 matches
Mail list logo
