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?
> 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
----------------------------------------------------------------------------
Bringing you mounds of caffeinated joy
>>> http://thinkgeek.com/sf <<<
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
