From: "Thomas Hellström" <thomas-4+hqylr40dJg9hUCZPvPmw@public.gmane.org>
To: Jerome Glisse <glisse-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org>
Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
"dri-devel-TtF/mJH4Jtrk1uMJSBkQmQ@public.gmane.org"
<dri-devel-TtF/mJH4Jtrk1uMJSBkQmQ@public.gmane.org>
Subject: Re: RFC: TTM extra bo space
Date: Sat, 07 Nov 2009 21:08:59 +0100 [thread overview]
Message-ID: <4AF5D3DB.8000800@shipmail.org> (raw)
In-Reply-To: <1257455879.3546.3.camel@localhost>
Jerome Glisse wrote:
> On Thu, 2009-11-05 at 20:04 +0200, Pekka Paalanen wrote:
>
>> On Wed, 4 Nov 2009 17:42:26 +0000
>> Jakob Bornecrantz <jakob-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org> 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?
>>
>>
Sorry for the late response to this. I'm mostly changing diapers nowadays...
I think this would be excellent. There is a priv member of an mm block
that can be a bo reference if needed.
I think the semantics should be such that the call would fail with
-EBUSY if it can not succeed due to pinned buffers in the way, and
otherwise sleep until it succeeds.
/Thomas
> I am bit busy with bugs right now but i will look into doing
> the actual code soon (one my bug need this).
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> --
> _______________________________________________
> Dri-devel mailing list
> Dri-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
prev parent reply other threads:[~2009-11-07 20:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1257350332.2829.8.camel@localhost>
[not found] ` <53E09666-8D2D-4DFD-AE06-DCDD963B6114@vmware.com>
[not found] ` <53E09666-8D2D-4DFD-AE06-DCDD963B6114-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2009-11-05 18:04 ` RFC: TTM extra bo space Pekka Paalanen
[not found] ` <20091105200436.47e28b79-cxYvVS3buNOdIgDiPM52R8c4bpwCjbIv@public.gmane.org>
2009-11-05 21:17 ` Jerome Glisse
2009-11-07 20:08 ` Thomas Hellström [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AF5D3DB.8000800@shipmail.org \
--to=thomas-4+hqylr40djg9huczpvpmw@public.gmane.org \
--cc=dri-devel-TtF/mJH4Jtrk1uMJSBkQmQ@public.gmane.org \
--cc=glisse-CC+yJ3UmIYqDUpFQwHEjaQ@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.