Don't apply textures that are currently bound to the framebuffer.
Includes cherry pick of patch by jamdill to add texture serial getters to the render buffer classes.
BUG=496
On 2013/10/28 20:51:09, Geoff Lang wrote: > PTAL (master) If we render black for the ...
10 years, 5 months ago
(2013-10-30 15:41:02 UTC)
#2
On 2013/10/28 20:51:09, Geoff Lang wrote:
> PTAL (master)
If we render black for the textures that are doubly-bound, is there any way for
the user to tell what is going on? It would be nice if the user had some means
to know there was a behind-the-scenes error going on, via us generating a
GLerror (seems valid, as undefined behaviour could include generating errors, or
doing whatever we like).
Same goes for the es3proto CL.
On 2013/10/30 15:41:02, Jamie Madill wrote: > On 2013/10/28 20:51:09, Geoff Lang wrote: > > ...
10 years, 5 months ago
(2013-10-30 16:46:26 UTC)
#3
On 2013/10/30 15:41:02, Jamie Madill wrote:
> On 2013/10/28 20:51:09, Geoff Lang wrote:
> > PTAL (master)
>
> If we render black for the textures that are doubly-bound, is there any way
for
> the user to tell what is going on? It would be nice if the user had some means
> to know there was a behind-the-scenes error going on, via us generating a
> GLerror (seems valid, as undefined behaviour could include generating errors,
or
> doing whatever we like).
>
> Same goes for the es3proto CL.
The WebGL working group is currently discussing whether to define an error for
this case; some are hesitant to issue an error even at the WebGL level, for some
understandable reasons (performance implication of error-checking at draw time,
low likelihood that developers will actually check errors on draw calls for the
same reason). It sounds like browsers will probably choose to issue a warning,
though, so the WebGL case is likely covered.
The spec says specifically that the values of the fragments rendered while a
feedback loop is present are undefined-- but I don't think that that means that
behavior of the GL is completely undefined. I don't think it would be either
prudent or spec-compliant to issue an error in this case.
On 2013/10/30 16:46:26, Shannon Woods wrote: > On 2013/10/30 15:41:02, Jamie Madill wrote: > > ...
10 years, 5 months ago
(2013-10-30 17:00:47 UTC)
#4
On 2013/10/30 16:46:26, Shannon Woods wrote:
> On 2013/10/30 15:41:02, Jamie Madill wrote:
> > On 2013/10/28 20:51:09, Geoff Lang wrote:
> > > PTAL (master)
> >
> > If we render black for the textures that are doubly-bound, is there any way
> for
> > the user to tell what is going on? It would be nice if the user had some
means
> > to know there was a behind-the-scenes error going on, via us generating a
> > GLerror (seems valid, as undefined behaviour could include generating
errors,
> or
> > doing whatever we like).
> >
> > Same goes for the es3proto CL.
>
> The WebGL working group is currently discussing whether to define an error for
> this case; some are hesitant to issue an error even at the WebGL level, for
some
> understandable reasons (performance implication of error-checking at draw
time,
> low likelihood that developers will actually check errors on draw calls for
the
> same reason). It sounds like browsers will probably choose to issue a
warning,
> though, so the WebGL case is likely covered.
>
> The spec says specifically that the values of the fragments rendered while a
> feedback loop is present are undefined-- but I don't think that that means
that
> behavior of the GL is completely undefined. I don't think it would be either
> prudent or spec-compliant to issue an error in this case.
Ah, didn't see the part about 'rendered fragments'. So, in this case, LGTM. I
would agree with the WebGL WG making it an error case, as I don't think there
are peformance implications for error checking (there are already errors that we
generate during DrawElements, etc?)
On 2013/10/30 17:00:47, Jamie Madill wrote: > On 2013/10/30 16:46:26, Shannon Woods wrote: > > ...
10 years, 5 months ago
(2013-10-30 21:35:05 UTC)
#5
On 2013/10/30 17:00:47, Jamie Madill wrote:
> On 2013/10/30 16:46:26, Shannon Woods wrote:
> > On 2013/10/30 15:41:02, Jamie Madill wrote:
> > > On 2013/10/28 20:51:09, Geoff Lang wrote:
> > > > PTAL (master)
> > >
> > > If we render black for the textures that are doubly-bound, is there any
way
> > for
> > > the user to tell what is going on? It would be nice if the user had some
> means
> > > to know there was a behind-the-scenes error going on, via us generating a
> > > GLerror (seems valid, as undefined behaviour could include generating
> errors,
> > or
> > > doing whatever we like).
> > >
> > > Same goes for the es3proto CL.
> >
> > The WebGL working group is currently discussing whether to define an error
for
> > this case; some are hesitant to issue an error even at the WebGL level, for
> some
> > understandable reasons (performance implication of error-checking at draw
> time,
> > low likelihood that developers will actually check errors on draw calls for
> the
> > same reason). It sounds like browsers will probably choose to issue a
> warning,
> > though, so the WebGL case is likely covered.
> >
> > The spec says specifically that the values of the fragments rendered while a
> > feedback loop is present are undefined-- but I don't think that that means
> that
> > behavior of the GL is completely undefined. I don't think it would be either
> > prudent or spec-compliant to issue an error in this case.
>
> Ah, didn't see the part about 'rendered fragments'. So, in this case, LGTM. I
> would agree with the WebGL WG making it an error case, as I don't think there
> are peformance implications for error checking (there are already errors that
we
> generate during DrawElements, etc?)
LGTM, but would like to give a heads up to zmo@ and others Chrome-side before
landing, since they may see an increase in bugs filed if this behavior changes
(since it'd change behavior for people without the D3D11 flag enabled), and
might wish for the WebGL warning/error decision to get hashed out first.
On 2013/10/30 21:35:05, Shannon Woods wrote: > On 2013/10/30 17:00:47, Jamie Madill wrote: > > ...
10 years, 5 months ago
(2013-10-31 19:46:45 UTC)
#6
Message was sent while issue was closed.
On 2013/10/30 21:35:05, Shannon Woods wrote:
> On 2013/10/30 17:00:47, Jamie Madill wrote:
> > On 2013/10/30 16:46:26, Shannon Woods wrote:
> > > On 2013/10/30 15:41:02, Jamie Madill wrote:
> > > > On 2013/10/28 20:51:09, Geoff Lang wrote:
> > > > > PTAL (master)
> > > >
> > > > If we render black for the textures that are doubly-bound, is there any
> way
> > > for
> > > > the user to tell what is going on? It would be nice if the user had some
> > means
> > > > to know there was a behind-the-scenes error going on, via us generating
a
> > > > GLerror (seems valid, as undefined behaviour could include generating
> > errors,
> > > or
> > > > doing whatever we like).
> > > >
> > > > Same goes for the es3proto CL.
> > >
> > > The WebGL working group is currently discussing whether to define an error
> for
> > > this case; some are hesitant to issue an error even at the WebGL level,
for
> > some
> > > understandable reasons (performance implication of error-checking at draw
> > time,
> > > low likelihood that developers will actually check errors on draw calls
for
> > the
> > > same reason). It sounds like browsers will probably choose to issue a
> > warning,
> > > though, so the WebGL case is likely covered.
> > >
> > > The spec says specifically that the values of the fragments rendered while
a
> > > feedback loop is present are undefined-- but I don't think that that means
> > that
> > > behavior of the GL is completely undefined. I don't think it would be
either
> > > prudent or spec-compliant to issue an error in this case.
> >
> > Ah, didn't see the part about 'rendered fragments'. So, in this case, LGTM.
I
> > would agree with the WebGL WG making it an error case, as I don't think
there
> > are peformance implications for error checking (there are already errors
that
> we
> > generate during DrawElements, etc?)
>
> LGTM, but would like to give a heads up to zmo@ and others Chrome-side before
> landing, since they may see an increase in bugs filed if this behavior changes
> (since it'd change behavior for people without the D3D11 flag enabled), and
> might wish for the WebGL warning/error decision to get hashed out first.
Landed at 4b48845f74fb54052a6b693c62d269d0952d4289.
Issue 18690043: Don't apply textures that are currently bound to the framebuffer.
(Closed)
Created 10 years, 5 months ago by Geoff Lang
Modified 10 years, 5 months ago
Reviewers: Jamie Madill, Shannon Woods
Base URL: https://code.google.com/p/angleproject/@master
Comments: 0