Am 13.10.2016 um 11:33 schrieb Marek Olšák:
> On Thu, Oct 13, 2016 at 2:09 AM, Roland Scheidegger <srol...@vmware.com>
> wrote:
>> Am 12.10.2016 um 15:29 schrieb Marek Olšák:
>>> From: Marek Olšák <marek.ol...@amd.com>
>>>
>>> For performance tuning in drivers. It filters out window system
>>> framebuffers and OpenGL renderbuffers.
>>>
>>> radeonsi will use this to guess whether a depth buffer will be read
>>> by a shader. There is no guarantee about what will actually happen.
>>>
>>> This is a departure from PIPE_BIND flags which are defined to be strict
>>> but they are useless in practice.
>>> ---
>>> src/gallium/include/pipe/p_defines.h | 1 +
>>> src/mesa/state_tracker/st_texture.c | 3 ++-
>>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/gallium/include/pipe/p_defines.h
>>> b/src/gallium/include/pipe/p_defines.h
>>> index db96c51..037ed92 100644
>>> --- a/src/gallium/include/pipe/p_defines.h
>>> +++ b/src/gallium/include/pipe/p_defines.h
>>> @@ -443,20 +443,21 @@ enum pipe_flush_flags
>>> #define PIPE_BIND_SCANOUT (1 << 19) /* */
>>> #define PIPE_BIND_SHARED (1 << 20) /* get_texture_handle ??? */
>>> #define PIPE_BIND_LINEAR (1 << 21)
>>>
>>>
>>> /**
>>> * Flags for the driver about resource behaviour:
>>> */
>>> #define PIPE_RESOURCE_FLAG_MAP_PERSISTENT (1 << 0)
>>> #define PIPE_RESOURCE_FLAG_MAP_COHERENT (1 << 1)
>>> +#define PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY (1 << 2)
>>> #define PIPE_RESOURCE_FLAG_DRV_PRIV (1 << 16) /* driver/winsys private
>>> */
>>> #define PIPE_RESOURCE_FLAG_ST_PRIV (1 << 24) /* state-tracker/winsys
>>> private */
>>>
>>> /**
>>> * Hint about the expected lifecycle of a resource.
>>> * Sorted according to GPU vs CPU access.
>>> */
>>> enum pipe_resource_usage {
>>> PIPE_USAGE_DEFAULT, /* fast GPU access */
>>> PIPE_USAGE_IMMUTABLE, /* fast GPU access, immutable */
>>> diff --git a/src/mesa/state_tracker/st_texture.c
>>> b/src/mesa/state_tracker/st_texture.c
>>> index a2c36ac..7b72ffd 100644
>>> --- a/src/mesa/state_tracker/st_texture.c
>>> +++ b/src/mesa/state_tracker/st_texture.c
>>> @@ -84,21 +84,22 @@ st_texture_create(struct st_context *st,
>>> memset(&pt, 0, sizeof(pt));
>>> pt.target = target;
>>> pt.format = format;
>>> pt.last_level = last_level;
>>> pt.width0 = width0;
>>> pt.height0 = height0;
>>> pt.depth0 = depth0;
>>> pt.array_size = layers;
>>> pt.usage = PIPE_USAGE_DEFAULT;
>>> pt.bind = bind;
>>> - pt.flags = 0;
>>> + /* only set this for OpenGL textures, not renderbuffers */
>>> + pt.flags = PIPE_RESOURCE_FLAG_TEXTURING_MORE_LIKELY;
>>> pt.nr_samples = nr_samples;
>>>
>>> newtex = screen->resource_create(screen, &pt);
>>>
>>> assert(!newtex || pipe_is_referenced(&newtex->reference));
>>>
>>> return newtex;
>>> }
>>>
>>>
>>>
>>
>> I guess, why not... I bet though there are apps which create everything
>> as a texture, regardless if they actually use it for sampling or not. So
>> you still need to try to not perform too bad if you got the hint wrong :-).
>> It's really GL which is useless there, not the PIPE_BIND flags ;-).
>
> But you have to admit that the new flag is very accurate - it
> represents OpenGL texture objects. That can't be said about most of
> the bind flags.
Yes, for GL that's true. Albeit being a GL texture object doesn't really
tell you anything about its usage. Which is why you have all the
guesswork in the driver in the first place.
The bind flags accurately represent what a resource can be used for.
This is all explicit, no guesswork required - but it requires a api
where this actually is known. And GL isn't that API... Obviously, this
was inspired by d3d10 because the model is so much cleaner. With the
hope that maybe some day GL would have something similar (though in all
fairness, it was probably impossible to change anyway while maintaining
backwards compatibility in a sane way).
Roland
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
