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
12 matches
Mail list logo
