On Dec 25, 2016 2:15 PM, "Mark Janes" wrote:
Jason Ekstrand writes:
> When shaders come in from SPIR-V, we handle continue blocks by placing
> the contents of the continue inside of a "if (!first_iteration)". We do
> this so that we can properly
Jason Ekstrand writes:
> When shaders come in from SPIR-V, we handle continue blocks by placing
> the contents of the continue inside of a "if (!first_iteration)". We do
> this so that we can properly handle the fact that continues in SPIR-V
> jump to the continue block at
On Wed, 2016-12-21 at 20:50 -0800, Jason Ekstrand wrote:
> On Dec 21, 2016 9:12 PM, "Timothy Arceri" om> wrote:
> On Mon, 2016-12-19 at 20:11 -0800, Jason Ekstrand wrote:
> > When shaders come in from SPIR-V, we handle continue blocks by
> > placing
> > the contents
On Dec 21, 2016 9:12 PM, "Timothy Arceri"
wrote:
On Mon, 2016-12-19 at 20:11 -0800, Jason Ekstrand wrote:
> When shaders come in from SPIR-V, we handle continue blocks by
> placing
> the contents of the continue inside of a "if (!first_iteration)". We
> do
> this
On Mon, 2016-12-19 at 20:11 -0800, Jason Ekstrand wrote:
> When shaders come in from SPIR-V, we handle continue blocks by
> placing
> the contents of the continue inside of a "if (!first_iteration)". We
> do
> this so that we can properly handle the fact that continues in SPIR-V
> jump to the
When shaders come in from SPIR-V, we handle continue blocks by placing
the contents of the continue inside of a "if (!first_iteration)". We do
this so that we can properly handle the fact that continues in SPIR-V
jump to the continue block at the end of the loop rather than jumping
directly to