   GPU Hard Texture Limits
  Hi guys!I've a fairly simple question that I hope you can answer. We're in the process of working out how we're going to handle materials on our terrain system - and boy are our requirements a bit higher than the average terrain implementation.Anyway, what I'd like to know is, does anyone know where I can find information regarding the hard texture limits on per GPU model (preferably GeForce 7 era onwards)?. I'm less worried about the limit to size of texture, and more about the actual physical number of textures we may be able to use on a per-material basis. I'm assuming that this may or may not also be restricted by shader model limitations on the number of texture samplers we can employ. We'll not be aiming for SM2 hardware, but I'm assuming SM3 poses a limit?Many thanks!Luke   
  SM2 SM3 and SM4 all pose their own limits, but the hardware itself can provide different limits in some configurations. You can typically ask the API for what each of these limits are (both DX and GL provide the functionality for them iirc)   ;  Like Exorcist said you can query the hw at runtime to find this information. If you want to know information ahead of time, the DirectX SDK includes a sample called "ConfigSystem". If you look in the folder for that sample, there's a spreadsheet with device caps for a whole range of hardware.   ;  At least 16 texture fetches of 8192x8192 is a kind of safe bet on reasonably modern cards. Usually even twice as many fetches (but no bigger sizes), but you can only be really sure if you query the caps as suggested by Exorcist.On all nVidia SM3 cards, vertex texture fetch is the same as pixel shader texture fetch (though on the first generation SM3 models, it's slow).On the earlier SM3 ATI cards, this is not true, although they call themselves SM3, they aren't really. Ok, the ATI lawyers will argue that it's perfectly legal to support "zero", according to the standard -- but it's still cheating in my opinion. The latest models do support vertex texture fetch just fine.   ;  To avoid a possible misunderstanding: When I say something like "16 is a safe bet, usually twice as many", we're talking about texture fetches from different textures.I don't know if there are any hard limits on fetches from the same texture, but I've done upwards of 1000 fetches per fragment from the same texture on my geforce 9800 with no problem at all before (although eventually it does get somewhat slow). So, for any "reasonable" number, there is no limit in that respect.   ;  Thanks Samoth, that's good to know. In our case we're somewhat plagued by these limits (although they're obviously also there in the interests of efficiency). The initial design in theory calls for as many as 36 discreet texture samples at worst case implementation, but thankfully with some cunning runtime optimisation, we could break that down to 12 at worst case (although 18 is still the desireable worst case even with optimisation).Quote:Original post by ExorcistSM2 SM3 and SM4 all pose their own limits, but the hardware itself can provide different limits in some configurations. You can typically ask the API for what each of these limits are (both DX and GL provide the functionality for them iirc)Quote:Original post by MJPLike Exorcist said you can query the hw at runtime to find this information. If you want to know information ahead of time, the DirectX SDK includes a sample called "ConfigSystem". If you look in the folder for that sample, there's a spreadsheet with device caps for a whole range of hardware.Not quite what I was after, but useful in future nevertheless. In our case we're largely working with much higher level libraries and aren't really touching the specific graphics APIs due to our multiplatform nature. I'll have a look for/at that ConfigSystem later, as I reckon that could be really useful - thanks![Edited by - ambershee on April 21, 2010 8:02:47 PM];  Maybe array textures can help on SM4 cards? An array texture could have 36 layers. You then index into them with the z coordinate. This is still the same texture unit, so no problem.   ;  Since we're targeting platforms that don't support SM4, and don't want to deal with two seperate versions of the material setup (it's also programming intensive due to game mechanic implementations), I think we're going to stick with using discrete texture samples.Judging by what I've managed to find on the hardware we're really aiming for, our absolute worst-case scenario after optimisations of 19 texture samples shouldn't pose a massive problem (although it is still undesireable) - and in all reality I'm genuinely not expecting us to exceed a healthy limit of 16.Nevertheless, many thanks - here's hoping everything works out swell and we have a nice shiny tech-demo in six-to-nine months time :)   