> Does it mean there will be format fallbacks? Because dword-unaligned but > still pretty common (i.e. GL1.1) vertex formats aren't supported by r300, > most often we hit R16G16B16. What will happen when is_format_supported says > NO to such a format? I hope it won't share the fate of PIPE_CAP_SM3, which > every in-tree state tracker ignores.
I'm not sure I understand correctly what you are saying. The idea is to do like you did in your patch, but instead of calling screen->get_param(screen, PIPE_CAP_HALF_FLOAT_VERTEX), calling screen->is_format_supported(screen, PIPE_FORMAT_R16G16B16G16, PIPE_BUFFER, ..., ...). The PIPE_BUFFER target is supported in gallium-resources, but I'm not sure whether this way of querying vertex formats is supported; it would probably need to be added first. If you mean that r300 doesn't support R16G16B16, I suppose you can just use R16G16B16A16 and ignore the extra fetched w element (the vertex buffer stride will make this work properly). However, if non-dword-aligned vertex buffer strides or vertex element offsets are not supported, I think you have a serious problem, which is however independent of half float vertices since I don't think OpenGL places any alignment constraints on those values (correct me if I'm wrong). ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
