Re: RFC: TTM extra bo space

Hi Jerome
On 4 nov 2009, at 15.58, Jerome Glisse wrote:
> Hi,
>
> Have got an issue which needs some extra space at end of a bo,
> space unvisible to the userspace. So i was wondering if anyone
> else would have a need for function which allow to add some more
> page at the end of a bo (could also allow to put it at the begining
> of the bo).
>
> Before i start doing code i wanted to get feeback on that as this
> would need a bit of change to ttm to get this feature. (mostly
> decoupling the num of pages the user ask from the num of page the
> driver wants, and then changing place in ttm to use one or the
> others number depending on what they achieve).
>
> Cheers,
> Jerome Glisse
>
> Note: For reference my issue is with cursor on old radeon hw,
> cursor must be in the next 128M from the crtc scanout buffer. We
> got issue when someone start to resize their screen at which
> point the scanout buffer can endup after the cursor in vram.
> Other solution would be to add multiple bo adjacent validation
> function to ttm (likely less ttm change).
Can you solve your problem by being able to place the buffer at
certain location? We had the same need but managed to work around it
with a quick and dirty hack.
Implementing that would mostly be about changing drm_mm.c to handle
placing buffers at certain locations. And in TTM core being able to
evict buffers that are in that place.
Cheers Jakob.

Thread view

Hi,
Have got an issue which needs some extra space at end of a bo,
space unvisible to the userspace. So i was wondering if anyone
else would have a need for function which allow to add some more
page at the end of a bo (could also allow to put it at the begining
of the bo).
Before i start doing code i wanted to get feeback on that as this
would need a bit of change to ttm to get this feature. (mostly
decoupling the num of pages the user ask from the num of page the
driver wants, and then changing place in ttm to use one or the
others number depending on what they achieve).
Cheers,
Jerome Glisse
Note: For reference my issue is with cursor on old radeon hw,
cursor must be in the next 128M from the crtc scanout buffer. We
got issue when someone start to resize their screen at which
point the scanout buffer can endup after the cursor in vram.
Other solution would be to add multiple bo adjacent validation
function to ttm (likely less ttm change).

Hi Jerome
On 4 nov 2009, at 15.58, Jerome Glisse wrote:
> Hi,
>
> Have got an issue which needs some extra space at end of a bo,
> space unvisible to the userspace. So i was wondering if anyone
> else would have a need for function which allow to add some more
> page at the end of a bo (could also allow to put it at the begining
> of the bo).
>
> Before i start doing code i wanted to get feeback on that as this
> would need a bit of change to ttm to get this feature. (mostly
> decoupling the num of pages the user ask from the num of page the
> driver wants, and then changing place in ttm to use one or the
> others number depending on what they achieve).
>
> Cheers,
> Jerome Glisse
>
> Note: For reference my issue is with cursor on old radeon hw,
> cursor must be in the next 128M from the crtc scanout buffer. We
> got issue when someone start to resize their screen at which
> point the scanout buffer can endup after the cursor in vram.
> Other solution would be to add multiple bo adjacent validation
> function to ttm (likely less ttm change).
Can you solve your problem by being able to place the buffer at
certain location? We had the same need but managed to work around it
with a quick and dirty hack.
Implementing that would mostly be about changing drm_mm.c to handle
placing buffers at certain locations. And in TTM core being able to
evict buffers that are in that place.
Cheers Jakob.

On Wed, 2009-11-04 at 17:42 +0000, Jakob Bornecrantz wrote:
> Hi Jerome
>
> On 4 nov 2009, at 15.58, Jerome Glisse wrote:
> > Hi,
> >
> > Have got an issue which needs some extra space at end of a bo,
> > space unvisible to the userspace. So i was wondering if anyone
> > else would have a need for function which allow to add some more
> > page at the end of a bo (could also allow to put it at the begining
> > of the bo).
> >
> > Before i start doing code i wanted to get feeback on that as this
> > would need a bit of change to ttm to get this feature. (mostly
> > decoupling the num of pages the user ask from the num of page the
> > driver wants, and then changing place in ttm to use one or the
> > others number depending on what they achieve).
> >
> > Cheers,
> > Jerome Glisse
> >
> > Note: For reference my issue is with cursor on old radeon hw,
> > cursor must be in the next 128M from the crtc scanout buffer. We
> > got issue when someone start to resize their screen at which
> > point the scanout buffer can endup after the cursor in vram.
> > Other solution would be to add multiple bo adjacent validation
> > function to ttm (likely less ttm change).
>
> Can you solve your problem by being able to place the buffer at
> certain location? We had the same need but managed to work around it
> with a quick and dirty hack.
>
> Implementing that would mostly be about changing drm_mm.c to handle
> placing buffers at certain locations. And in TTM core being able to
> evict buffers that are in that place.
>
> Cheers Jakob.
>
This is what i mean by multiple bo adjacent validation :) it's an
easiest solution, i will take a look at it.
Cheers,
Jerome

On Wed, 4 Nov 2009 17:42:26 +0000
Jakob Bornecrantz <jakob@...> wrote:
> Hi Jerome
>
> On 4 nov 2009, at 15.58, Jerome Glisse wrote:
> >
> > Note: For reference my issue is with cursor on old radeon hw,
> > cursor must be in the next 128M from the crtc scanout buffer. We
> > got issue when someone start to resize their screen at which
> > point the scanout buffer can endup after the cursor in vram.
> > Other solution would be to add multiple bo adjacent validation
> > function to ttm (likely less ttm change).
>
> Can you solve your problem by being able to place the buffer at
> certain location? We had the same need but managed to work around
> it with a quick and dirty hack.
>
> Implementing that would mostly be about changing drm_mm.c to
> handle placing buffers at certain locations. And in TTM core
> being able to evict buffers that are in that place.
That sounds like something that could solve an issue in Nouveau
with nv04 card family. The following is hearsay, but I try to
describe it.
Of 32 MB of VRAM, the scanout buffer must reside within the
first 16 MB. Any(?) other buffers do not have this limitation
e.g. textures. Setting up separate memory spaces for these
halves, say, TTM VRAM and TTM PRIV1, would be inconvenient,
because buffers could not be laid accross the boundary.
Does this make sense?
Nouveau people, did I get this right?
--
Pekka Paalanen
http://www.iki.fi/pq/

On Thu, 2009-11-05 at 20:04 +0200, Pekka Paalanen wrote:
> On Wed, 4 Nov 2009 17:42:26 +0000
> Jakob Bornecrantz <jakob@...> wrote:
>
> > Hi Jerome
> >
> > On 4 nov 2009, at 15.58, Jerome Glisse wrote:
> > >
> > > Note: For reference my issue is with cursor on old radeon hw,
> > > cursor must be in the next 128M from the crtc scanout buffer. We
> > > got issue when someone start to resize their screen at which
> > > point the scanout buffer can endup after the cursor in vram.
> > > Other solution would be to add multiple bo adjacent validation
> > > function to ttm (likely less ttm change).
> >
> > Can you solve your problem by being able to place the buffer at
> > certain location? We had the same need but managed to work around
> > it with a quick and dirty hack.
> >
> > Implementing that would mostly be about changing drm_mm.c to
> > handle placing buffers at certain locations. And in TTM core
> > being able to evict buffers that are in that place.
>
> That sounds like something that could solve an issue in Nouveau
> with nv04 card family. The following is hearsay, but I try to
> describe it.
>
> Of 32 MB of VRAM, the scanout buffer must reside within the
> first 16 MB. Any(?) other buffers do not have this limitation
> e.g. textures. Setting up separate memory spaces for these
> halves, say, TTM VRAM and TTM PRIV1, would be inconvenient,
> because buffers could not be laid accross the boundary.
>
> Does this make sense?
> Nouveau people, did I get this right?
>
Here is the API i was thinking of:
ttm_bo_validate_in_range(usualvalidateparameter,
unsigned long minoffset,
unsigned long maxoffset)
This function will try to validate the buffer at an offset
btw min & max. Will either fail of succeed and could return
-EINVAL if max-min < bo->size.
I think it's flexible enough and should full feel nouveau,
radeon & poulsbo needs.
Cheers,
Jerome
I am bit busy with bugs right now but i will look into doing
the actual code soon (one my bug need this).