summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/common
Commit message (Collapse)AuthorAgeFilesLines
* meta/generate_mipmap: Work-around GLES 1.x problem with GL_DRAW_FRAMEBUFFERIan Romanick2015-12-141-4/+13
| | | | | | | | | | | | | | | | | | GL_DRAW_FRAMEBUFFER does not exist in OpenGL ES 1.x, and since _mesa_meta_begin hasn't been called yet, we have to work-around API difficulties. The whole reason that GL_DRAW_FRAMEBUFFER is used instead of GL_FRAMEBUFFER is that the read framebuffer may be different. This is moot in OpenGL ES 1.x. I have another patch series that would also fix this (by removing the calls to _mesa_BindFramebuffer and friends), but it's not quite ready yet... and I think it may be a bit heavy for some stable branches. Consider this a stop-gap fix. Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93215 Cc: "11.0 11.1" <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: clear_state structure cleanupTapani Pälli2015-12-142-20/+12
| | | | | | | | | Remove unused variables from clear_state and use a hardcoded location for color uniform to get rid of 2 more variables. Modify shaders to use explicit location for vertex attribute too as extension is enabled. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]>
* meta: Fix a typo in a print messageAndreas Boll2015-12-091-1/+1
| | | | | | | s/Unkown/Unknown/ Signed-off-by: Andreas Boll <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* meta: Don't save or restore the active client textureIan Romanick2015-11-242-4/+0
| | | | | | | | | This setting is only used by glTexCoordPointer and related glEnable calls. Since the preceeding commits removed all of those, it is not necessary to save, reset to default, or restore this state. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Don't save or restore the VBO bindingIan Romanick2015-11-242-7/+0
| | | | | | | | Nothing left in meta does anything with the VBO binding, so we don't need to save or restore it. The VAO binding is still modified. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta/TexSubImage: Don't pollute the buffer object namespaceIan Romanick2015-11-241-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Anuj Phogat <[email protected]>
* meta: Don't pollute the buffer object namespace in _mesa_meta_DrawTexIan Romanick2015-11-244-38/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Anuj Phogat <[email protected]>
* meta: Use internal functions for buffer object and VAO access in ↵Ian Romanick2015-11-241-12/+20
| | | | | | | _mesa_meta_DrawTex Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Track VBO using gl_buffer_object instead of GL API object handle in ↵Ian Romanick2015-11-242-6/+19
| | | | | | | _mesa_meta_DrawTex Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Partially convert _mesa_meta_DrawTex to DSAIan Romanick2015-11-241-6/+6
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Don't pollute the buffer object namespace in ↵Ian Romanick2015-11-241-14/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | _mesa_meta_setup_vertex_objects 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. Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92363 Reviewed-by: Anuj Phogat <[email protected]>
* meta: Use internal functions for buffer object and VAO accessIan Romanick2015-11-241-33/+43
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Use DSA functions for VBOs in _mesa_meta_setup_vertex_objectsIan Romanick2015-11-241-19/+24
| | | | | | | | | | The fixed-function attribute paths don't get the DSA treatment because there are no DSA entry-points for fixed-function attributes. These could have been added, but this is a temporary patch intended to make later patches easier to review. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Track VBO using gl_buffer_object instead of GL API object handleIan Romanick2015-11-244-44/+67
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Don't leave the VBO bound after _mesa_meta_setup_vertex_objectsIan Romanick2015-11-244-20/+37
| | | | | | | | | Meta currently does this, but future changes will make this impossible. Explicitly do it as a step in the patch series now to catch any possible kinks. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Use _mesa_NamedBufferData and _mesa_NamedBufferSubData for users of ↵Ian Romanick2015-11-243-10/+8
| | | | | | | _mesa_meta_setup_vertex_objects Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Use DSA functions for PBO in create_texture_for_pboIan Romanick2015-11-241-19/+11
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta/generate_mipmap: Don't leak the framebuffer objectIan Romanick2015-11-181-0/+5
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Cc: "10.6 11.0" <[email protected]>
* meta/generate_mipmap: Only modify the draw framebuffer binding in ↵Ian Romanick2015-11-161-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | fallback_required Previously GL_FRAMEBUFFER was used. However, if GL_EXT_framebuffer_blit is supported (note: it is supported by every Mesa driver), this is *sometimes* an alias for GL_DRAW_FRAMEBUFFER (getters) and *sometimes* an alias for *both* GL_DRAW_FRAMEBUFFER and GL_READ_FRAMEBUFFER (setters). As a result, the code saved one binding but modified both. If the bindings were different, the GL_READ_FRAMEBUFFER would be incorrect on exit. Fixes the piglit fbo-generatemipmap-versus-READ_FRAMEBUFFER test. Ideally this function would use DSA functions and not modify the binding at all. However, that would be a much more intrusive change because _mesa_meta_bind_fbo_image would also need to be modified. _mesa_meta_bind_fbo_image has a lot of callers. Much of this code is about to get a major rework due to bug #92363, so I don't think it matters too much. In fact, I discovered this bug while working on the other bug. Le bon temps! Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Cc: "10.6 11.0" <[email protected]>
* meta/generate_mipmap: Don't leak the sampler objectIan Romanick2015-11-131-0/+2
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Cc: "10.6 11.0" <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* mesa: In helpers, only check driver capability for metaNanley Chery2015-11-122-0/+12
| | | | | | | | | | | Make API context and version checks done by the helper functions pass unconditionally while meta is in progress. This transparently makes extension checks solely dependent on struct gl_extensions while in meta. v2: Use an 8-bit data type instead of a GLuint Signed-off-by: Nanley Chery <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* mesa/meta: Use interpolateAtOffset for 16x MSAA copy blitNeil Roberts2015-11-051-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | Previously there was a problem in i965 where if 16x MSAA is used then some of the sample positions are exactly on the 0 x or y axis. When the MSAA copy blit shader interpolates the texture coordinates at these sample positions it was possible that it would jump to a neighboring texel due to rounding errors. It is likely that these positions would be used on 16x MSAA because that is where they are defined to be in D3D. To fix that this patch makes it use interpolateAtOffset in the blit shader whenever 16x MSAA is used and the GL_ARB_gpu_shader5 extension is available. This forces it to interpolate the texture coordinates at the pixel center to avoid these problematic positions. This fixes ext_framebuffer_multisample-unaligned-blit and ext_framebuffer_multisample-clip-and-scissor-blit with 16x MSAA on SKL+. v2: Use interpolateAtOffset instead of interpolateAtSample v3: Always try to enable GL_ARB_gpu_shader5 in the shader [Ian Romanick] Reviewed-by: Anuj Phogat <[email protected]>
* meta/blit: Always try to enable GL_ARB_sample_shadingNeil Roberts2015-11-051-14/+2
| | | | | | | | | | | Previously this extension was only enabled when blitting between two multisampled buffers. However I don't think it does any harm to just enable it all the time. The ‘enable’ option is used instead of ‘require’ so that the shader will still compile if the extension isn't available in the cases where it isn't used. This will make the next patch simpler because it wants to add another optional extension. Reviewed-by: Anuj Phogat <[email protected]>
* meta: Support 16x MSAA in the multisample scaled blit shaderNeil Roberts2015-11-052-10/+21
| | | | | | v2: Fix the x_scale in the shader. Remove the doubts in the commit message. Reviewed-by: Anuj Phogat <[email protected]>
* drivers/common: use _mesa_RasterPos instead of _tnl_RasterPosBrian Paul2015-10-221-1/+2
| | | | Reviewed-by: Roland Scheidegger <[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]>
* meta: Update comment about unsupported texture types.Matt Turner2015-10-051-2/+1
| | | | | | | Ken added support for 2DArray (commit ec23d5197e) and 1DArray (commit 14ca61125) last year. Reviewed-by: Anuj Phogat <[email protected]>
* mesa: remove Driver.EndCallListMarek Olšák2015-10-031-3/+0
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.BeginCallListMarek Olšák2015-10-031-1/+0
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.EndListMarek Olšák2015-10-031-1/+0
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.NewListMarek Olšák2015-10-031-1/+0
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.NotifySaveBeginMarek Olšák2015-10-031-1/+0
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.SaveFlushVerticesMarek Olšák2015-10-031-1/+0
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.FlushVerticesMarek Olšák2015-10-031-1/+0
| | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]>
* mesa: remove Driver.BindArrayObjectMarek Olšák2015-10-031-6/+0
| | | | | | | Nothing sets it. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove Driver.DeleteArrayObjectMarek Olšák2015-10-031-1/+0
| | | | | | | Nothing reimplements it. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove Driver.NewArrayObjectMarek Olšák2015-10-031-1/+0
| | | | | | | Nothing reimplements it. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove Driver.HintMarek Olšák2015-10-031-1/+0
| | | | | | | Nothing sets it. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove Driver.ColorMaskIndexedMarek Olšák2015-10-031-17/+5
| | | | | | | Nothing sets it. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove Driver.AccumMarek Olšák2015-10-031-1/+0
| | | | | | | Nothing calls it. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: remove Driver.ResizeBuffersMarek Olšák2015-10-031-1/+0
| | | | | | | Nothing overrides it. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* meta: Handle array textures in scaled MSAA blitsIan Romanick2015-09-301-15/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old code had some significant problems with respect to sampler2DArray textures. The biggest problem was that some of the code would use vec3 for the texture coordinate type, and other parts of the code would use vec2. The resulting shader would not even compile. Since there were not tests for this path, nobody noticed. The input to the fragment shader is always treated as a vec3. If the source data is only vec2, the vertex puller will supply 0 for the .z component. The texture coordinate passed to the fragment shader is always a vec2 that comes from the .xy part of the vertex shader input. The layer, taken from the .z of the vertex shader input is passed separately as a flat integer. If the generated fragment shader does not use the layer integer, the GLSL linker will eliminate all the dead code in the vertex shader. Fixes the new piglit tests "blit-scaled samples=2 with gl_texture_2d_multisample_array", etc. on i965. Note for stable maintainer: This patch may depend on 46037237, and that patch should be safe for stable. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Cc: Topi Pohjolainen <[email protected]> Cc: Jordan Justen <[email protected]> Cc: "10.6 11.0" <[email protected]>
* mesa: rework Driver.CopyImageSubData() and related codeBrian Paul2015-09-242-8/+97
| | | | | | | | | | | | | | | | | | | | | | | | 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: Abort meta pbo path if TexSubImage need signed unsigned conversionAnuj Phogat2015-09-141-18/+25
| | | | | | | | | See similar fix for Readpixels in mesa commit 0d20790. Jason suggested we need that for TexSubImage as well. Cc: <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* meta: Use result of texture coordinate clamping operationIan Romanick2015-09-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously the result of the complicated clamp() expression just dropped on the floor: clamp does not modify any of its parameters. Looking at the surrounding code, I believe this is supposed to modify the value of tex_coord. This change (along with a change to avoid the use of brw_blorp_framebuffer) does not affect any existing piglit tests. I'm not sure what this clamp is trying to accomplish, so I'm not sure how to write a test to exercise this path. I also noticed another bug in this code. There is no way the array texture case could possibly work. This will generate code for the TEXEL_FETCH macro like: #define TEXEL_FETCH(coord) texelFetch(texSampler, ivec3(coord), sample_map[int(2 * fract(coord.x))]); Since the coord parameter of this macro is a vec2 at all invocations, no expansion of this macro will even compile. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Cc: Topi Pohjolainen <[email protected]> Cc: Jordan Justen <[email protected]>
* meta: Always bind the textureIan Romanick2015-09-101-3/+6
| | | | | | | | | | | | | | | | We may have been called from glGenerateTextureMipmap with CurrentUnit still set to 0, so we don't know when we can skip binding the texture. Assume that _mesa_BindTexture will be fast if we're rebinding the same texture. v2: Remove currentTexUnitSave because it is now unused. Suggested by both Neil and Anuj. Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91847 Cc: "11.0" <[email protected]> Reviewed-by: Neil Roberts <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Save/restore compute shadersJordan Justen2015-09-021-2/+4
| | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Compute correct buffer size with SkipRows/SkipPixelsChris Wilson2015-09-021-15/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user is specifying a subregion of a buffer using SKIP_ROWS and SKIP_PIXELS, we must compute the buffer size carefully as the end of the last row may be much shorter than stride*image_height*depth. The current code tries to memcpy from beyond the end of the user data, for example causing: ==28136== Invalid read of size 8 ==28136== at 0x4C2D94E: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:915) ==28136== by 0xB4ADFE3: brw_bo_write (brw_batch.c:1856) ==28136== by 0xB5B3531: brw_buffer_data (intel_buffer_objects.c:208) ==28136== by 0xB0F6275: _mesa_buffer_data (bufferobj.c:1600) ==28136== by 0xB0F6346: _mesa_BufferData (bufferobj.c:1631) ==28136== by 0xB37A1EE: create_texture_for_pbo (meta_tex_subimage.c:103) ==28136== by 0xB37A467: _mesa_meta_pbo_TexSubImage (meta_tex_subimage.c:176) ==28136== by 0xB5C8D61: intelTexSubImage (intel_tex_subimage.c:195) ==28136== by 0xB254AB4: _mesa_texture_sub_image (teximage.c:3654) ==28136== by 0xB254C9F: texsubimage (teximage.c:3712) ==28136== by 0xB2550E9: _mesa_TexSubImage2D (teximage.c:3853) ==28136== by 0x401CA0: UploadTexSubImage2D (teximage.c:171) ==28136== Address 0xd8bfbe0 is 0 bytes after a block of size 1,024 alloc'd ==28136== at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==28136== by 0x402014: PerfDraw (teximage.c:270) ==28136== by 0x402648: Draw (glmain.c:182) ==28136== by 0x8385E63: ??? (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0) ==28136== by 0x83896C8: fgEnumWindows (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0) ==28136== by 0x838641C: glutMainLoopEvent (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0) ==28136== by 0x8386C1C: glutMainLoop (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0) ==28136== by 0x4019C1: main (glmain.c:262) ==28136== ==28136== Invalid read of size 8 ==28136== at 0x4C2D940: memcpy@@GLIBC_2.14 (vg_replace_strmem.c:915) ==28136== by 0xB4ADFE3: brw_bo_write (brw_batch.c:1856) ==28136== by 0xB5B3531: brw_buffer_data (intel_buffer_objects.c:208) ==28136== by 0xB0F6275: _mesa_buffer_data (bufferobj.c:1600) ==28136== by 0xB0F6346: _mesa_BufferData (bufferobj.c:1631) ==28136== by 0xB37A1EE: create_texture_for_pbo (meta_tex_subimage.c:103) ==28136== by 0xB37A467: _mesa_meta_pbo_TexSubImage (meta_tex_subimage.c:176) ==28136== by 0xB5C8D61: intelTexSubImage (intel_tex_subimage.c:195) ==28136== by 0xB254AB4: _mesa_texture_sub_image (teximage.c:3654) ==28136== by 0xB254C9F: texsubimage (teximage.c:3712) ==28136== by 0xB2550E9: _mesa_TexSubImage2D (teximage.c:3853) ==28136== by 0x401CA0: UploadTexSubImage2D (teximage.c:171) ==28136== Address 0xd8bfbe8 is 8 bytes after a block of size 1,024 alloc'd ==28136== at 0x4C28C20: malloc (vg_replace_malloc.c:296) ==28136== by 0x402014: PerfDraw (teximage.c:270) ==28136== by 0x402648: Draw (glmain.c:182) ==28136== by 0x8385E63: ??? (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0) ==28136== by 0x83896C8: fgEnumWindows (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0) ==28136== by 0x838641C: glutMainLoopEvent (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0) ==28136== by 0x8386C1C: glutMainLoop (in /usr/lib/x86_64-linux-gnu/libglut.so.3.9.0) ==28136== by 0x4019C1: main (glmain.c:262) ==28136== Fixes regression from commit 7f396189f073d626c5f7a2c232dac92b65f5a23f Author: Jason Ekstrand <[email protected]> Date: Mon Jan 5 18:17:04 2015 -0800 meta: Add a BlitFramebuffers-based implementation of TexSubImage v2: However, the teximage we create does need to be width x full_height x 1 Signed-off-by: Chris Wilson <[email protected]> Cc: Jason Ekstrand <[email protected]> Cc: Neil Roberts <[email protected]> Reviewed-by Neil Roberts <[email protected]>
* Delete duplicate function is_power_of_two() and use _mesa_is_pow_two()Anuj Phogat2015-07-291-3/+3
| | | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Tapani Pälli <[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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-29 13:31:54 +0000