Keith Whitwell wrote:
> Benjamin Herrenschmidt wrote:
>
>>> HOWEVER, if you tied the GART mapping to the DRM lock, you might be ok.
>>> That gives you the required system exclusion, and if you make it an
>>> explicit "get my GART context" function that is only called under
>>> the DRM
>>> lock _and_ only called when you actually need the AGP access, you also
>>> avoid the unnecessary context switches.
>>>
>>> You might still have some performance issues simply because you
>>> would do
>>> extra work when switching aperture mappings, but hopefully the GART
>>> switch
>>> wouldn't be a common operation.
>>>
>>> The flexibility you would get _might_ be worth it.
>>>
>>
>> Well, I would personally vote for the processes _not_ relying on having
>> the AGP aperture mapped directly, but instead, the various memory pages
>> making their AGP aperture. Several chipsets (Apple ones for sure, but it
>> seems others are hitting this too nowadays) don't support AGP aperture
>> accesses from the CPU.
>
>
> What are you actually saying, that pages mapped in agp can't be
> written by any means, or just that they can't be written through the
> agp address range?
>
> It sounds kindof broken to me in any case. How to mtrrs work in this
> world?
Actually we should go to this model eventually. However it needs me to
have time to finish the Page Attribute Table support I started on at
VA. This allows write combining to be set on a per page basis, and is
the direction we want to go even on x86.
>
>
>> That way, if you want several AGP contexts, you can have the processes
>> tapping their AGP buffers without lock, locking would only be required
>> once it's time to move one of these buffers in/out the physical GART
>> under the arbitration of the DRM.
>
>
> You don't need to lock to write to agp buffers in the current scheme.
>
> You also don't need to play with the gart table just to draw a
> 2-triangle strip. On some chipsets, particularly under smp,
> modifying the gart table is very slow. Ask Jeff about this.
>
> Keith
>
This is also true, but I've done alot of heavy think on this very
issue. The key is to manage the agp aperture and only swap out regions
when you absolutely have too. The big key to getting something like
this to work is a memory manager that every client uses, and is based on
some sort of sarea. It should be designed with a certain minimum block
size, and have a few different flags for what kind of usage that memory
block has. (I can go into more detail on design, but you probably have
a good idea what I mean here.) Then the next step is to create kernel
calls which can swap things to an from agp space and the card. One
cards that support it, another path (which prevents GART rewrites
entirely) is to add support to swap to normal cached memory.
This is what I envision making sense in the long run. A global
memory manager using an sarea (doesn't have to be the main one) and a
good aging mechanism get us most of the way there.
-Jeff
----------------------------------------------------------------------------
Bringing you mounds of caffeinated joy
>>> http://thinkgeek.com/sf <<<
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
