> 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