aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/common/meta_copy_image.c
Commit message (Collapse)AuthorAgeFilesLines
* meta: Avoid random memory access on errorJuha-Pekka Heikkila2016-04-261-1/+1
| | | | | | | | | | Initialize drawFb to NULL in _mesa_meta_CopyImageSubData_uncompressed() if getting readFb fails uninitialized drawFb will cause randomness on cleanup. Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* meta: Make BlitFramebuffer() do sRGB encoding in ES 3.x.Kenneth Graunke2016-03-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | According to the ES 3.0 and GL 4.4 specifications, glBlitFramebuffer is supposed to perform sRGB decoding and encoding whenever sRGB formats are in use. The ES 3.0 specification is completely clear, and has always stated this. However, the GL specification has changed behavior in 4.1, 4.2, and 4.4. The original behavior stated that no sRGB encoding should occur. The 4.4 behavior matches ES 3.0's wording. However, implementing the new behavior appears to break applications such as Left 4 Dead 2. This patch changes Meta to apply the ES 3.x rules in ES 3.x, but leaves OpenGL alone for now, to avoid breaking applications. Meta implements several other functions in terms of BlitFramebuffer, and many of those explicitly do not perform sRGB encoding. So, this patch explicitly disables sRGB encoding in those other functions, preserving the existing (correct) behavior. If you're from the future and are reading this, hi! Welcome to the "fun" of debugging sRGB problems! Best of luck! Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* meta: Don't pollute the framebuffer namespaceIan Romanick2016-03-011-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tl;dr: For many types of GL object, we can *NEVER* use the Gen function. In OpenGL ES (all versions!) and OpenGL compatibility profile, applications don't have to call Gen functions. The GL spec is very clear about how you can mix-and-match generated names and non-generated names: you can use any name you want for a particular object type until you call the Gen function for that object type. Here's the problem scenario: - Application calls a meta function that generates a name. The first Gen will probably return 1. - Application decides to use the same name for an object of the same type without calling Gen. Many demo programs use names 1, 2, 3, etc. without calling Gen. - Application calls the meta function again, and the meta function replaces the data. The application's data is lost, and the app fails. Have fun debugging that. Fixes piglit tests: - object-namespace-pollution glGetTexImage-compressed framebuffer - object-namespace-pollution glGenerateMipmap framebuffer Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Topi Pohjolainen <[email protected]>
* meta: Use _mesa_bind_framebuffers instead of _mesa_BindFramebufferIan Romanick2016-03-011-2/+9
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* meta: Use _mesa_CreateFramebuffers instead of _mesa_GenFramebuffersIan Romanick2016-03-011-1/+1
| | | | | | | | | | | | | This enables later patches that will stop calling _mesa_GenFramebuffers or _mesa_CreateFramebuffers which pollute the framebuffer namespace. For framebuffers, the Bind call is still necessary. sed -i -e 's/_mesa_GenFramebuffers/_mesa_CreateFramebuffers/' \ src/mesa/drivers/common/*.c Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* meta: Use _mesa_check_framebuffer_status instead of _mesa_CheckFramebufferStatusIan Romanick2016-03-011-2/+2
| | | | | | | | | | | | sed -i -e 's/_mesa_CheckFramebufferStatus(GL_DRAW_FRAMEBUFFER/_mesa_check_framebuffer_status(ctx, ctx->DrawBuffer/' \ -e 's/_mesa_CheckFramebufferStatus(GL_FRAMEBUFFER[^)]*/_mesa_check_framebuffer_status(ctx, ctx->DrawBuffer/' \ -e 's/_mesa_CheckFramebufferStatus(GL_READ_FRAMEBUFFER/_mesa_check_framebuffer_status(ctx, ctx->ReadBuffer/' \ $(grep -rl _mesa_CheckFramebufferStatus src/mesa/drivers) The second expression catches both GL_FRAMEBUFFER and GL_FRAMEBUFFER_EXT. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* meta: Convert _mesa_meta_bind_fbo_image to take a gl_framebuffer instead of ↵Ian Romanick2016-03-011-4/+4
| | | | | | | | | | | | | | | | a GL API handle Also change the name of the function to _mesa_meta_framebuffer_texture_image. The function is basically a wrapper around _mesa_framebuffer_texture (which is used to implement glFramebufferTexture1D and friends), so it makes sense for it's name to be similar to that. The next patch will clean _mesa_meta_framebuffer_texture_image up considerably. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* meta/copy_image: use precomputed dst_internal_format to avoid segfaultIlia Mirkin2016-02-191-1/+1
| | | | | | | | | If the destination is a renderbuffer, dst_tex_image will be NULL. This fixes the *to_renderbuffer dEQP copy image tests. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Cc: [email protected]
* meta: Use internal functions for renderbuffer accessIan Romanick2016-02-101-8/+4
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta/copy_image: Fix typo in commentIan Romanick2016-01-251-1/+1
| | | | | | | Trivial. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* mesa,meta: move gl_texture_object::TargetIndex initializationsBrian Paul2015-10-081-1/+4
| | | | | | | | | | | | | | | Before, we were unconditionally assigning the TargetIndex field in _mesa_BindTexture(), even if it was already set properly. Now we initialize TargetIndex wherever we initialize the Target field, in _mesa_initialize_texture_object(), finish_texture_init(), etc. v2: also update the meta_copy_image code. In make_view() the view_tex_obj->Target field was set, but not the TargetIndex field. Also, remove a second, redundant assignment to view_tex_obj->Target. Add sanity check assertions too. Reviewed-by: Anuj Phogat <[email protected]> Tested-by: Mark Janes <[email protected]>
* mesa: rework Driver.CopyImageSubData() and related codeBrian Paul2015-09-241-8/+95
| | | | | | | | | | | | | | | | | | | | | | | | Previously, core Mesa's _mesa_CopyImageSubData() created temporary textures to wrap renderbuffer sources/destinations. This caused a bit of a mess in the Mesa/gallium state tracker because we had to basically undo that wrapping. Instead, change ctx->Driver.CopyImageSubData() to take both gl_renderbuffer and gl_texture_image src/dst pointers (one being null, the other non-null) so the driver can handle renderbuffer vs. texture as needed. For the i965 driver, we basically moved the code that wrapped textures around renderbuffers from copyimage.c down into the met and driver code. The old code in copyimage.c also made some questionable calls to _mesa_BindTexture(), etc. which weren't undone at the end. v2 (Jason Ekstrand): Rework the intel bits v3 (Brian Paul): Update the temporary st_CopyImageSubData() function. Reviewed-by: Topi Pohjolainen <[email protected]> Tested-by: Kai Wasserbäch <[email protected]> Tested-by: Nick Sarnie <[email protected]>
* meta/copy_image: Stash off the scissorJason Ekstrand2015-07-281-2/+2
| | | | | | | | | | | The meta CopyImageSubData path uses BlitFramebuffers to do the actual copy. The only thing that can affect BlitFramebuffers other than the currently bound framebuffers is the scissor so we need to save that off and reset it. If we don't do this, applications that use a scissor together with CopyImageSubData will get accidentally scissored copies. Tested-by: Markus Wick <markus at selfnet.de> Reviewed-by: Anuj Phogat <[email protected]>
* DD: Refactor BlitFramebuffer.Laura Ekstrand2015-02-021-1/+2
| | | | | | | | | In preparation for glBlitNamedFramebuffer, the DD table function BlitFramebuffer needs to accept two arbitrary framebuffer objects rather than assuming ctx->ReadBuffer and ctx->DrawBuffer. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* meta: Fix error paths in meta_copy_image.cJuha-Pekka Heikkila2014-09-231-0/+9
| | | | | | | | If _mesa_get_tex_image() return NULL there is already error set in context. Other error pats free allocated texture. Signed-off-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta/copy_image: Use the correct texture level when creating viewsJason Ekstrand2014-09-031-1/+1
| | | | | | | | | | | | | | Previously, we were accidentally assuming that the level of both textures was 0. Now we actually use the correct level in our hacked texture view. This doesn't 100% fix the meta path because the texture type is getting lost somewhere in the pipeline. However, it actually copies to/from the correct layer now. Signed-off-by: Jason Ekstrand <[email protected]> Cc: "10.3" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82804 Tested-by: Tapani Pälli <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* mesa/meta: Add a partial implementation of CopyImageSubDataJason Ekstrand2014-08-111-0/+199
This provides an implementation of CopyImageSubData that works if both textures are uncompressed. This implementation works by using a combination of texture views and BlitFramebuffer. If one of the textures is compressed, it returns false and the driver is expected to provide a fallback. v2: Don't leak fbo's Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Juha-Pekka Heikkila <[email protected]> Reviewed-by: Neil Roberts <[email protected]> v3: Change glGen/DeleteTextures to _mesa_Gen/DeleteTextures
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 04:29:44 +0000