-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/02/2011 09:19 AM, Roland Scheidegger wrote:
> Am 02.05.2011 16:40, schrieb Marek Olšák:
>> On Mon, May 2, 2011 at 3:47 PM, Brian Paul <bri...@vmware.com> wrote:
>>> On 05/02/2011 07:03 AM, Marek Olšák wrote:
>>>>
>>>> ---
>>>> src/gallium/include/pipe/p_defines.h | 1 +
>>>> src/gallium/include/pipe/p_state.h | 1 +
>>>> src/mesa/state_tracker/st_atom_rasterizer.c | 6 +++++-
>>>> src/mesa/state_tracker/st_extensions.c | 4 ++++
>>>> 4 files changed, 11 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/src/gallium/include/pipe/p_defines.h
>>>> b/src/gallium/include/pipe/p_defines.h
>>>> index 431a7fb..176fee9 100644
>>>> --- a/src/gallium/include/pipe/p_defines.h
>>>> +++ b/src/gallium/include/pipe/p_defines.h
>>>> @@ -465,6 +465,7 @@ enum pipe_cap {
>>>> PIPE_CAP_VERTEX_ELEMENT_INSTANCE_DIVISOR = 44,
>>>> PIPE_CAP_FRAGMENT_COLOR_CLAMP_CONTROL = 45,
>>>> PIPE_CAP_MIXED_COLORBUFFER_FORMATS = 46,
>>>> + PIPE_CAP_SEAMLESS_CUBE_MAP = 47
>>>> };
>>>>
>>>> /* Shader caps not specific to any single stage */
>>>> diff --git a/src/gallium/include/pipe/p_state.h
>>>> b/src/gallium/include/pipe/p_state.h
>>>> index 0c1f509..26e8a8e 100644
>>>> --- a/src/gallium/include/pipe/p_state.h
>>>> +++ b/src/gallium/include/pipe/p_state.h
>>>> @@ -101,6 +101,7 @@ struct pipe_rasterizer_state
>>>> unsigned line_smooth:1;
>>>> unsigned line_stipple_enable:1;
>>>> unsigned line_last_pixel:1;
>>>> + unsigned seamless_cube_map:1;
>>>
>>> Shouldn't this be sampler state and not rasterizer state? The AMD extension
>>> lets this option be set per texture. Though, I don't know if non-AMD
>>> hardware supports that mode.
>>
>> r600 and r700 hardware has one enable bit that affects the entire
>> chip. There is no per-sampler enable bit.
>>
>> evergreen and later hardware indeed has a per-sampler enable bit.
>>
>> I wouldn't like to limit the extension to evergreen, so
>> pipe_rasterizer_state seemed to be the only choice.
>
> You can still do that if it's per-sampler (state tracker ensures it's
> the same in all sampler state), though it will make things more
> complicated for r600 and you'll need two caps (for implementing both
> extensions).
That seems like the right way to do it. That's basically how I had
planned to do it in the i965 driver. It's a bit tricky, though. I
believe it's possible for applications to use both modes. You have to
make sure that you get the right state if an app:
- turns on the global enable
- turns on the per-texture enable for one texture
- draw
- turn off the global enable
- draw
> I'm not sure how useful that AMD extension is, but since that extension
> was done after the ARB one (and it was implemented that way in hw) I
> guess that there is indeed some use for it. I believe intel chips could
> also do it per-sampler, not sure about nvidia. Of course, for d3d10 it
> isn't needed, since it's always enabled (not sure about d3d11 but I
> guess it's the same) globally anyway, and I don't know if we plan to
> support the AMD extension.
Adding the AMD extension is somewhere way, way, way down on my todo list...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2+5j8ACgkQX1gOwKyEAw93OQCgjnicH5m4P+uRzIguJKwnmkJY
QskAnj2fu4K9oeNb5y/+5WJSQEfAm++C
=RbgK
-----END PGP SIGNATURE-----
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
