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
|
