BTW - I found the matter of problem. I have 8M video RAM. And use
resolution 1280x1024 (I have LCD so lower resolutions look
bad). Even in
16bpp, all buffers take almost 8M - so only 192K remains for textures
(actually, on 32bpp the server does not start at all). When I
experimentally changed resolution to 800x600 (giving ~5M video RAM for
textures) - some textures appeared (but not all - for
example, half-life and celestia are still not working).
rough estimation:
800 pixels/line x 600 lines x 2 byte/pixel x 2 buffers = 1,9 MB
You should expect to have less than 6 MB for textures.
(some video memory might be occupied for other purposes like an
OpenGL depth buffer, stipple patterns, icons or other objects.)
So you observations meet the state that has to be expected.
So my question is - will at some point driver use system RAM
for buffers
and/or textures etc? I thought AGP technology can help here.
Correct me if I am wrong.
i dont know those specifics driver's state.
AGP means two things:
- high speed transfers (AGP 1x, 2x, 4x, sidebanding, fast writes, ...)
- a paging logic that does provide consecutive page ranges (GART)
built upon the systems main memory presented to CPU and grafics.
Those Grafics Aperture Range Table system just creates an un-scrambled
alias view of the main memory that typcially portraits parts of CPU
paging.
The first is often simply a question of switching on a few bits in
the northbridge and the grafics controller. The location of the
related bits in the integrated circuts do follow a standard.
The second thing was implemented because Intel(?) thougt that it
was a bad idea to have grafics adapters that are able to access
scattered pages from anywhere in the system memory (even if most
vendors already hat respective logic due to their PCI designs).
So Intel required all mainboard chipset vendors to add paging
shemes that were already present in CPU and grafics chips.
Concerning your comment on texture organisation and AGP i've
to comment, its just a question of program code in the driver.
Anytime a texture is used, it is best to have it on the grafics
adapter. As long as there is enough memory anything is fast.
You best compare it to swapping - anytime you use something
that is not present, the system hast to reload it with some
timing penalty. In worst case you will trash and reload anything
on any single frame, in worsest case you will do this multiple
times. Having not enough memory is a big performance issue.
Having a too dumb texture manager could be slowing down as well.
In short words - the texture manager in your driver doesnt
look like he is using all availabel resources for the purpose.
BTW, geometry data and screen-memory blits should be able
to use the GART paged memory pool as well and the high speed
AGP bus protocolls as well.
Regards Alex.
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
