currently, driCalculateMaxTextureLevels will set the max texture sizes so that the textures always will fit into the texture heap(s). This means worst case, i.e. all texture units have a texture bound, with no texture compression, maximum width and height, maximum bit depth, and all mipmaps. It would probably be better to announce larger sizes (maybe hw max or at least something less strict, i.e. only 1 texture with otherwise worst-case needs to fit). For instance, on my r200 with 64MB (and some ddx hack so a bit less ram is wasted for 2d), max cube map size is 256. It turns out that quake4 absolutely needs cube maps with a size of 1024, otherwise the outdoor scenes (sky) will look pretty black (even with low quality, this is probably an app error, it fails to check the limits, it might be possible to tweak this via console, though I've yet to figure out how to get a console in the q4 demo...). And the actual ram quake4 needs for these cube maps isn't _that_ much, as they are compressed probably only around 9MB (haven't checked what dxt format) for all faces.
The texture size limits advertised by all of the drivers is very conservative. This is an issue that has come up a few times before. There's a trade off. We can advertise the actual hardware limits or we can advertise the limits that we can guarantee will work. We're stuck with either having to fallback to software if an app tries to use too much texture memory at once or artificially limit the available texture sizes. This technique was introduced back in the Quake 2 days. There were some low-memory cards that could end up on a software path with Quake 2's default settings when the full texture sizes were advertised. With the new memory manager that Keith is writing, this won't be an issue. We should always be able to map any texture into the GART, so the allocations will never fail. In the mean time, it might be best to add a config option "Conservative Texture Limits" that defaults to on.
(In reply to comment #1) > With the new memory manager that Keith is writing, this won't be an issue. We > should always be able to map any texture into the GART, so the allocations will > never fail. I'm not sure that this solves this completely. Or is it possible to map any ram to GART? The maximum size could get pretty big (for instance, on the r200, with cubemaps you'd need about 720MB to map everything in the worst case).
Also keep in mind that the size of the GART table may be limited so that you may not be able to map all physical memory into the GART. Basically the GART table size is determined at kernel/2D driver initialization time. I'm not sure if there are any physical hardware limitations to the GART table size (depending on the AGP chipset or PCI(e) SG implementation).
Created attachment 4544 [details] [review] patch for announcing larger texture sizes Does this look reasonable? It replaces the old (quite limited) texture level hack of the radeon / r200 with something a bit more broad. driconf translations are missing currently, and although there is nothing radeon / r200 specific to it only these drivers use it (since they are the only ones using the old texture level hack). In fact other drivers won't even compile though I'd certainly fix that. As a side note, I just noticed r300 doesn't bother with calculating maximum texture sizes at all and just uses mesa's default values (which are luckily reasonably close to the hw), so it certainly doesn't limit sizes according to available memory.
(In reply to comment #4) > Created an attachment (id=4544) [edit] > patch for announcing larger texture sizes > > Does this look reasonable? It looks pretty much okay. I'm wondering about the change to get_max_size (and the associated changes to SET_MAX and SET_MAX_RECT). Removing the '+ 1' allows get_max_size to return 0 in non-error cases. I don't think that's a particularly a problem, though. ACK.
(In reply to comment #5) > It looks pretty much okay. I'm wondering about the change to get_max_size (and > the associated changes to SET_MAX and SET_MAX_RECT). That's just a cheap way out to not have to handle the case separately when the hw limits are used directly. You're right though it would set non-null sizes if one sort of texture isn't supported, though as far as I can tell it will never return 0 since currently it looks like the smallest number it will ever return is 2. I'll find a nicer solution.
commited. driconf translations except german are missing. I've added this to the intel driver too, since it already used a hack to only calculate the limits so that one texture always fits (though this driver seems to use driconf differently, it looks like it never parses the config file? YMMV), which I've left as default there. radeon/r200 still default to calculate the limits so all texture units can bind a worst-case texture. IMHO I think this default is a bit too conservative.
Mass version move, cvs -> git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.