On Thu, Nov 16, 2017 at 6:26 PM, Ilia Mirkin wrote:
> On Thu, Nov 16, 2017 at 7:15 AM, Wladimir wrote:
>>> I think it would be reasonable to re-emit the shader state (or maybe
>>> just the varyings) when the primitive type changes from points to
>>> non-points. It virtually never happens that the
On Thu, Nov 16, 2017 at 01:38:32PM -0500, Ilia Mirkin wrote:
> > Which is annoying as it means that shader state now depends on either the
> > kind
> > of primitive (which is per-draw), or the shading model (which is part of
> > rasterizer state).
>
> I take it your hardware doesn't support sett
On Thu, Nov 16, 2017 at 1:20 PM, Wladimir J. van der Laan
wrote:
> On Thu, Nov 16, 2017 at 12:26:05PM -0500, Ilia Mirkin wrote:
>> On Thu, Nov 16, 2017 at 7:15 AM, Wladimir wrote:
>
>> The point of the texcoord semantics is precisely point sprite
>> replacement. NVIDIA hardware (Fermi+) can only
On Thu, Nov 16, 2017 at 12:26:05PM -0500, Ilia Mirkin wrote:
> On Thu, Nov 16, 2017 at 7:15 AM, Wladimir wrote:
> The point of the texcoord semantics is precisely point sprite
> replacement. NVIDIA hardware (Fermi+) can only do point sprite
> replacement on certain specially-located varyings, hen
On Thu, Nov 16, 2017 at 7:15 AM, Wladimir wrote:
>> I think it would be reasonable to re-emit the shader state (or maybe
>> just the varyings) when the primitive type changes from points to
>> non-points. It virtually never happens that the same shader combo is
>> used for points and non-points.
>
> I think it would be reasonable to re-emit the shader state (or maybe
> just the varyings) when the primitive type changes from points to
> non-points. It virtually never happens that the same shader combo is
> used for points and non-points.
Thinking about it, this might even simplify some conto
>> What if the PS doesn't use the point coordinate, e.g. to render solid
>> points?
>>
>> I thought about that, but I don't think it's general enough.
>>
>> Could we make the blitter label texture coordinates properly?
>
> We could do that, but still most texcoord varyings from actual GLSL
> shader
Am Donnerstag, den 16.11.2017, 11:36 +0100 schrieb Wladimir:
> On Thu, Nov 16, 2017 at 11:29 AM, Lucas Stach > wrote:
>
> > Or maybe we can just scan the input
> > varyings and if we find a PCOORD varying assume that we are going
> > to
> > render points, but I don't know if this assumption holds
On Thu, Nov 16, 2017 at 11:29 AM, Lucas Stach wrote:
> Or maybe we can just scan the input
> varyings and if we find a PCOORD varying assume that we are going to
> render points, but I don't know if this assumption holds for all cases.
What if the PS doesn't use the point coordinate, e.g. to ren
Am Mittwoch, den 15.11.2017, 19:55 +0100 schrieb Wladimir J. van der
Laan:
> > Sorry for noticing before, but this breaks glmark2 texture. I
> > didn't
> > yet dig into the issue but it's definitely caused by this commit.
> >
> > To reproduce, simply run
> > glmark2-es2-drm -b texture:texture-filt
> Sorry for noticing before, but this breaks glmark2 texture. I didn't
> yet dig into the issue but it's definitely caused by this commit.
>
> To reproduce, simply run
> glmark2-es2-drm -b texture:texture-filter=mipmap
That's weird, as that neither uses point sprites nor flat shading.
I'll have
Hi Wladimir,
Am Mittwoch, den 15.11.2017, 18:03 +0100 schrieb Wladimir J. van der Laan:
> A recent commit (see below) fixed flat shading but at the same time
> broke the use of point sprites with multiple varyings. This resulted in
> particle systems rendering wrongly.
>
> The reason for this is
A recent commit (see below) fixed flat shading but at the same time
broke the use of point sprites with multiple varyings. This resulted in
particle systems rendering wrongly.
The reason for this is that it set VARYING_COMPONENT_USE_POINTCOORD_[XY]
for all non-color varyings, causing them to be re
13 matches
Mail list logo
