On Thu, Oct 13, 2016 at 5:35 PM, Nicolai Hähnle wrote:
> On 13.10.2016 17:15, Ilia Mirkin wrote:
>>
>> Anyone else have opinions on this? Should st/mesa be adding
>> PIPE_BIND_RENDER_TARGET for all textures of the internal formats
>> listed in table 8.12? (Which would, in this case, force RGBA8 to
On 13.10.2016 17:15, Ilia Mirkin wrote:
Anyone else have opinions on this? Should st/mesa be adding
PIPE_BIND_RENDER_TARGET for all textures of the internal formats
listed in table 8.12? (Which would, in this case, force RGBA8 to be
used since RGBA4 is non-renderable.) Or is it perfectly legal fo
Anyone else have opinions on this? Should st/mesa be adding
PIPE_BIND_RENDER_TARGET for all textures of the internal formats
listed in table 8.12? (Which would, in this case, force RGBA8 to be
used since RGBA4 is non-renderable.) Or is it perfectly legal for a
format to be not renderable when used
Right, but it'd break st/nine which doesn't (didn't?) support
fallbacks like st/mesa does.
I'm trying to better understand what the required logic is based on
the spec, not how to fix this particular application's rendering with
nouveau (which I'm much less concerned about, tbh).
-ilia
On Wed,
Dropping texturing support for RGBA4 would resolve that issue.
Marek
On Wed, Sep 7, 2016 at 5:43 PM, Ilia Mirkin wrote:
> Hello,
>
> Is there a concept in OpenGL that certain internal formats *must* be
> supported for rendering? An issue we're running into is that NVIDIA
> hardware supports samp
Hello,
Is there a concept in OpenGL that certain internal formats *must* be
supported for rendering? An issue we're running into is that NVIDIA
hardware supports sampling from RGBA4 textures, but does not support
that as a render format. So if you create a tex image with GL_RGBA4,
we use that as t
