Hi!
Yeah, setting the alignment to 64 byte was my first thought as well. But this
will break the BitBlit acceleration somehoe. So I need to align some other way.
What I did so far is the following:
--- DirectFB-1.1.1/src/core/gfxcard.c
/* Add extra space for optimized routines which are now allowed to
overrun, e.g. prefetching. */
length += 16;
+ length += 64;
+
if (device->limits.surface_byteoffset_alignment > 1) {
length += device->limits.surface_byteoffset_alignment - 1;
length -= length % device->limits.surface_byteoffset_alignment;
--- DirectFB-1.1.1/systems/fbdev/surfacemanager.c
/* calculate offsets and lengths of resulting chunks */
newchunk->offset = c->offset + c->length - length;
+ newchunk->offset = newchunk->offset & 0xffffffc0;
+
newchunk->length = length;
c->length -= newchunk->length;
The first patch will add 64 bytes to the required buffer size in
dfb_gfxcard_calc_buffer_size() so that I can align "my way". The second patch
in split_chunk() is to align the surface buffer at 64 bytes. This will correct
the alignment for BitBlit (16 bytes) as well. But to be honestly I didn't
understand the chunk mechanism so that the second patch (might) break the video
buffer allocation. Maybe you can comment my patches whether I'm on the right
way or point me to the correct location to align the surface buffers. :)
Thanks for your answer.
--
ffluw.h
Ville Syrjälä wrote:
> There's no really simple way to do that at the moment. The simplest
> thing to do is set the alignment limit to 64 bytes.
>
> It would be nice to have some mechanism to select the alignment based on
> the intended use of the surface. However that would require a new API so
> that the application could provide some hints to the allocator. The
> other option would be to reallocate when the alignment isn't sufficient
> but that could lead to some performance issues so the initial hint might
> be a good idea anyway.
>
> How this could be implemented with DirectFB >= 1.3 is by creating a
> custom surface pool that could allocate using different alignments.
> But a better solution would be to add something to the gfxdriver API
> that would allow asking the gfxdriver for the alignment. That could
> be used by the surface manager so that many of the already existing
> pool implementations would benefit from it.
>
> The gfxdriver would also need to check the alignment in CheckState() in
> case the hint was incorrect. How exactly the reallocation would happen
> after that I'm not sure yet.
>
> Something like this would be quite nice for the mach64 driver since it
> requires the texture pitch to be a power of two and currently it just
> aligns all allocations (well, actually only when the pitch and height
> are below 1024 pixels) to power of two values.
_________________________________________________________________________
Sensationsangebot nur bis 30.11: WEB.DE FreeDSL - Telefonanschluss + DSL
für nur 16,37 Euro/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K13805B7069a
_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
