New acceleration architecture
Thomas Winischhofer
thomas at winischhofer.net
Wed Jun 29 09:10:21 PDT 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric Anholt wrote:
> On Wed, 2005-06-29 at 11:29 +0200, Thomas Winischhofer wrote:
>>- - offscreenByteAlign: Boundary for pixmap data, ie to what boundaries
>>data to be blitted is to be aligned to (in bytes)
>>
>>- - offscreenPitch: Alignment of pitch of pixmaps to be blitted/filled (in
>>bytes)
>
>
> Yep, got those right.
>
>
>>- - maxX, maxY = maximum width/height (and not strictly "coordinate
>>limitations", since in exaTryDriverComposite() you compare the
>>width/height to these values)? Haven't check all occurances of maxX/maxY
>>usage, but I would assume these values really mean
>>
>> maxX = min(card's maximum X coordinate, card's maximum width)
>>
>>and likewise for Y.
>
>
> I'm concerned about how maxX/maxY are handled. I definitely thought
> they should be the coordinate limitations: the maximum offset in X and Y
> from the beginning of a pixmap (the offset, aligned to
> offScreenByteAlign) for anything touched by an operation. Instead, they
> seem to be the maximum width/height requested for an operation, which
> isn't quite what we need.
>
> I imagined the maxX/maxY as slicing all pixmaps at those intervals
> (which should make POT alignment happy, assuming the limit is a power of
> 2 itself), and then doing composites with rectangles of those slices
> according to how the src/mask/dst x/y offsets fell. The driver would
> adjust its offset for rendering by intervals of maxX/maxY on these
> operations, not having to worry then about whether it would hit the
> coordinate restrictions. It didn't sound like fun to write, but at
> least a pretty sane way of going about it while respecting the various
> alignment restricitons on cards and without having your Render
> acceleration just stop accelerating on large screens (say, a MergedFB
> desktop).
Í . Í .. Í
Repository ÿË ÔEntries çË Ä Entries.Log ÿË °Entries.Backup 7bit
Subject: Re: New acceleration architecture
X-BeenThere: xorg at lists.freedesktop.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discuss issues related to the xorg tree <xorg.lists.freedesktop.org>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/listinfo/xorg>,
<mailto:xorg-request at lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/xorg>
List-Post: <mailto:xorg at lists.freedesktop.org>
List-Help: <mailto:xorg-request at lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/xorg>,
<mailto:xorg-request at lists.freedesktop.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2005 20:07:12 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas Winischhofer wrote:
> One more thing: PrepareCopy is supposed to be given boolean "reverse"
> and "upsidedown", but from CopyNtoN is called with some integer "dx" and
> "dy"...
>
> Can there be overlapping blits in this concept, requiring "reverse" and
> "upsidedown" (which specify the drawing direction I assume)?
Erm.. one more thing: The executing calls (Solid(), Copy(), etc) come
without any argument that would allow retrieving pScrn or the like....
just the coordinates. Hm...
Thomas
- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net http://www.winischhofer.net/
twini AT xfree86 DOT org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCwv+rzydIRAktyUcRAruyAKDSLJpUkuaHNVZPU9xWWKEWOnALbwCdF094
cEbnI35HlLQ51YFKLN5AfzA=
=iWyK
-----END PGP SIGNATURE-----
More information about the xorg
mailing list