From: Marek O. <ma...@gm...> - 2010-04-04 20:43:45
|
On Sun, Apr 4, 2010 at 10:28 PM, Luca Barbieri <luc...@gm...>wrote: > > 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). > I've tried to do it this way, it locks up (unless I am missing something). 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). > You're right. -Marek |