> On 11/14/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
>>
>>
>> > 1) max texture size was 512. is this a limitation of the chip or of
>> the
>> > driver? if this is a limitation of the driver, what needs to be done
>> to
>> fix
>> > it?
>>
>> Most likely a limitation of the amount of available texture memory. The
>> 3D
>> driver will only report texture sizes that it can be sure will fit in
>> texture memory. If it can't fit a 1024x1024x24-bit texture for each
>> texture
>> unit (2 on Unichrome), it will only advertise 512x512.
>
>
> Well, I had 64Megs reserved for graphics. That should be more than enough
> :)
> I think I remember a post a while back possibly linking the max texture
> size
> to the maximum number of mip levels the chip supports...Actually, after
> doing a quick search, this seems to be bug #3130. Looks like a patch
> exists,
> but no reply as to whether it can get merged into the main tree. The bug
> is
> still marked as new. I guess it didn't make it in?
>
The problem is that it violates OpenGL standard as it discards the lowest
resolution mipmap, (which probably isn't really useful anyway at these
texture resolutions), but IIRC we agreed that there should be a configure
option (preferrably using driconf) to switch back to the
standard-conforming behaviour.
Nobody has yet come forward with a patch that implements this and I
haven't had time.
Regarding the speed transferring data from system to framebuffer,
depending on hardware and method, these are roughly the speeds you should
expect from the different unichromes (MB /s)
memcpy (3) sse_memcpy
CLE266 150 300
KM400 133 133
CN400 110 220
PM800 150 150
K8M800 50 50
PCI DMA is available but not implemented in the 3D driver. Throughput is
about 90MB/s and it also takes some time to perform the mappings, so it is
not really worthwile for system to frame-buffer transfer except in
situations where low CPU usage may be of interest. Xv for example.
For frame-buffer to system transfer,PCI DMA is also available but not
implemented and it is also about 90MB/s plus mapping time. However, here,
processor reading from frame-buffer memory is probably an order of
magnitude slower.
/Thomas
>
> -tom
>
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev