On 12/18/18 11:18 AM, Ilia Mirkin wrote:
> Nv_image_formats adds all the core formats to gles.
>
> It's pretty easy to add them all in, so I don't see why not.
>
Ok, I didn't know about that extension, thanks for the pointer.
It then makes sense to support all these formats, yes. I will submit
Nv_image_formats adds all the core formats to gles.
It's pretty easy to add them all in, so I don't see why not.
On Tue, Dec 18, 2018, 03:17 Eduardo Lima Mitev
>
> On 12/18/18 9:05 AM, Eduardo Lima Mitev wrote:
> > On 12/17/18 10:02 PM, Ilia Mirkin wrote:
> >> Note that the format may not be kno
On 12/18/18 9:05 AM, Eduardo Lima Mitev wrote:
> On 12/17/18 10:02 PM, Ilia Mirkin wrote:
>> Note that the format may not be known. I suspect that falls into your
>> "default" case.
>>
>
> Hi Ilia,
>
> while on GLES profiles the format qualifier must be declared for all
> image variables, it is
On 12/17/18 10:02 PM, Ilia Mirkin wrote:
> Note that the format may not be known. I suspect that falls into your
> "default" case.
>
Hi Ilia,
while on GLES profiles the format qualifier must be declared for all
image variables, it is true that core profiles allow to omit it for
writeonly-qualifie
Note that the format may not be known. I suspect that falls into your
"default" case.
On Mon, Dec 17, 2018 at 3:41 PM Eduardo Lima Mitev wrote:
>
> emit_intrinsic_store_image() is always using 4 components when
> collecting registers for the value. When image has less than
> 4 components (e.g, r32
emit_intrinsic_store_image() is always using 4 components when
collecting registers for the value. When image has less than
4 components (e.g, r32f, r32i, r32ui) this results in extra mov
instructions.
This patch uses the actual number of components from the image format.
For example, in a shader
