Anuj Phogat <anuj.pho...@gmail.com> writes:
> Changes in fbobject.c fix a case when blitting to a framebuffer with
> renderbuffers/textures attached to GL_COLOR_ATTACHMENT{i} (where i!=0).
> Earlier it skips color blitting if nothing is found attached to
> GL_COLOR_ATTACHMENT0.
>
> Changes in swrast/s_blit.c fix a blitting case when drawAttachment->Texture
> == readAttachment->Texture. This was causing an assertion failure
> intel_miptree_attach_map() with gles3 conformance test case:
> framebuffer_blit_functionality_minifying_blit
> Number of changes in this file look scary. But most of them are caused by
> introducing a big for loop to support rendering to multiple color draw
> buffers.
>
> V2: Fixed a case when number of draw buffer attachments are zero.
> V3: Do compatible_color_datatypes() check for all the draw renderbuffers
> in fbobject.c. Put a for loop in blit_nearest() and blit_linear()
> functions in swrast/s_blit.c to support blitting to multiple color
> draw buffers.
> V4: Remove variable declaration in for loop to avoid MSVC compilation issues.Do any drivers actually want to do anything other than loop over referenced renderbuffers, and blit them? I'm thinking the loop and read/draw rb choice should happen in mesa core and the dd.h blitframebuffer interface should be one renderbuffer pair at a time.
pgptgRiwOS0Ah.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
