summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* Revert "i965/vec4: Use byte offsets for UBO pulls on Sandy Bridge"Emil Velikov2015-12-193-31/+10
| | | | | | | | | | This reverts commit 34cbde2e6320a55f54180e7f9f68db435b58e542. As mentioned in the beginning of this revert series - let's pull the lot out, as they cause regressions. Additionally they are bugfixes (as opposed to regression fixes), which if needed will need to be reworked.
* Revert "i965/fs: Use a stride of 1 and byte offsets for UBOs"Emil Velikov2015-12-193-13/+16
| | | | | | This reverts commit 0ae22b3ebde780c2c88b5bfceaf172e311bd4742. See the previous reverts.
* Revert "i965/vec4: Use a stride of 1 and byte offsets for UBOs"Emil Velikov2015-12-193-7/+27
| | | | | | This reverts commit 147c3fbdb3f779f5172304e3be10cc27e0e67be7. See the previous reverts.
* Revert "i965/state: Get rid of dword_pitch arguments to buffer functions"Emil Velikov2015-12-195-14/+30
| | | | | | This reverts commit 683d65dae3e673ee95d544008874edf1255e87cf. See previous commit.
* Revert "i965/nir: Remove unused indirect handling"Emil Velikov2015-12-191-11/+33
| | | | | | | | This reverts commit 4acb394f459b58725a2059a911b6236703c44eb2. As discussed with Jason on IRC. Earlier commit in the series, causes regression, and "there's no point in having the others in there, if we cannot get to the last patch."
* meta/generate_mipmap: Work-around GLES 1.x problem with GL_DRAW_FRAMEBUFFERIan Romanick2015-12-181-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]> (cherry picked from commit 96dc732ed81f48d8bbc7aa6fb4d9c2833b691189)
* i965: Add B8G8R8X8_SRGB to the alpha format overrideNeil Roberts2015-12-181-0/+4
| | | | | | | | | | | | brw_init_surface_formats overrides the render format for RGBX formats which aren't supported for rendering so that they internally use RGBA instead. However, B8G8R8X8_SRGB was missing so it wasn't marked as a renderable format. This patch just adds it. Cc: "11.0 11.1" <[email protected]> Cc: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit 43f4be5f06b7a96b96a3a7b43f5112139a1f423a)
* i965: Add MESA_FORMAT_B8G8R8X8_SRGB to brw_format_for_mesa_formatNeil Roberts2015-12-181-0/+1
| | | | | | | | | | This will be used in a subsequent patch as the format for RGB visuals. Cc: "11.0 11.1" <[email protected]> Cc: Ilia Mirkin <[email protected]> Suggested-by: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit c769efda939e06338d41e1046a5f954c690951d5)
* mesa/shader: return correct attribute location for double matrix arraysDave Airlie2015-12-181-3/+8
| | | | | | | | | | | | | | | | | | | | If we have a dmat2[4], then dmat2[0] is at 17, dmat2[1] at 19, dmat2[2] at 21 etc. The old code was returning 17,18,19. I think this code is also wrong for float matricies as well. There is now a piglit for the float case. This partly fixes: GL41-CTS.vertex_attrib_64bit.limits_test [airlied: update with Tapani suggestion to clean it up]. Cc: "11.0 11.1" <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Signed-off-by: Dave Airlie <[email protected]> (cherry picked from commit 18ad641c3b2e926b8b3e2bd1df31fa739624cbe4)
* mesa/varray: set double arrays to non-normalised.Dave Airlie2015-12-181-1/+1
| | | | | | | | | | | | Doesn't have any effect in practice I don't think, but CTS reads back using GetVertexAttrib. This fixes: GL41-CTS.vertex_attrib_64bit.get_vertex_attrib Cc: "11.0 11.1" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Dave Airlie <[email protected]> (cherry picked from commit 21abaad8fe7b5bf78737b9cf009548f41e4777b9)
* i965: Resolve color and flush for all active shader images in ↵Francisco Jerez2015-12-181-0/+18
| | | | | | | | | | | | | | | | | | intel_update_state(). Fixes arb_shader_image_load_store/execution/load-from-cleared-image.shader_test. Couldn't reproduce any significant FPS regression in CPU-bound benchmarks from the Finnish benchmarking system on neither VLV nor BSW after 30 runs with 95% confidence level. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92849 Cc: Chris Wilson <[email protected]> Cc: Jason Ekstrand <[email protected]> Cc: "11.0 11.1" <[email protected]> Tested-by: Jordan Justen <[email protected]> Reviewed-by: Kristian Høgsberg <[email protected]> (cherry picked from commit 595c8180714da1d97be445b9a66affa1dfea39f6)
* i965/nir: Remove unused indirect handlingJason Ekstrand2015-12-181-33/+11
| | | | | | | | | | | | | | | The one and only place where the FS backend allows reladdr is on uniforms. For locals, inputs, and outputs, we lower it away before the backend ever sees it. This commit gets rid of the dead indirect handling code. Cc: "11.0" <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit 22c273de2b97743587310f7bbf66767191bde866) [Emil Velikov: squash trivial conflicts] Signed-off-by: Emil Velikov <[email protected]> Conflicts: src/mesa/drivers/dri/i965/brw_fs_nir.cpp
* i965/state: Get rid of dword_pitch arguments to buffer functionsJason Ekstrand2015-12-185-30/+14
| | | | | | | | | | | | | Cc: "11.0" <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit abb569ca18db159ae3e4c4b51d01e5a8b3215e04) [Emil Velikov: drop hunks for missing functions, drop gen7_cs_state.c] Signed-off-by: Emil Velikov <[email protected]> Conflicts: src/mesa/drivers/dri/i965/brw_context.h src/mesa/drivers/dri/i965/brw_wm_surface_state.c src/mesa/drivers/dri/i965/gen7_cs_state.c
* i965/vec4: Use a stride of 1 and byte offsets for UBOsJason Ekstrand2015-12-183-27/+7
| | | | | | | | | | | | | Cc: "11.0" <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92909 Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit 05bdc21f84edc200a0b0a695b79d12f25cc00645) [Emil Velikov: s/brw_imm_ud/src_reg/g;s/brw_imm_d/src_reg/] Signed-off-by: Emil Velikov <[email protected]> Conflicts: src/mesa/drivers/dri/i965/brw_vec4_nir.cpp src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
* i965/fs: Use a stride of 1 and byte offsets for UBOsJason Ekstrand2015-12-183-16/+13
| | | | | | | | | | | | | | | Cc: "11.0" <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit 13ad8d03f201a4d09bf7ab9078b00807d61dfada) [Emil Velikov] - s/const_offset_reg.ud/const_offset_reg.fixed_hw_reg.dw1.ud/ - s/brw_imm_ud/fs_reg/ Signed-off-by: Emil Velikov <[email protected]> Conflicts: src/mesa/drivers/dri/i965/brw_fs.cpp src/mesa/drivers/dri/i965/brw_fs_nir.cpp
* i965/vec4: Use byte offsets for UBO pulls on Sandy BridgeJason Ekstrand2015-12-183-10/+31
| | | | | | | | | | | | | | Previously, the VS_OPCODE_PULL_CONSTANT_LOAD opcode operated on vec4-aligned byte offsets on Iron Lake and below and worked in terms of vec4 offsets on Sandy Bridge. On Ivy Bridge, we add a new *LOAD_GEN7 variant which works in terms of vec4s. We're about to change the GEN7 version to work in terms of bytes, so this is a nice unification. Cc: "11.0" <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit e3e70698c3cfa7e9acccd6eddfb37516c45d5ac2) [Emil Velikov: s/brw_imm_ud/src_reg/g ,s/offset.ud/offset.dw1.ud/ ] Signed-off-by: Emil Velikov <[email protected]>
* i965: use _Shader to get fragment program when updating surface stateTapani Pälli2015-12-181-2/+2
| | | | | | | | | | | | | | Atomic counters and Images were using ctx::Shader that does not take in to account program pipeline changes, ctx::_Shader must be used for SSO to work. Commit c0347705 already changed ubo's to use this. Fixes failures seen with following Piglit test: arb_separate_shader_object-atomic-counter Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Francisco Jerez <[email protected]> Cc: "11.0 11.1" <[email protected]> (cherry picked from commit 231db5869c2c0f32608f39100bffff569da21bea)
* i965: Fix scalar vertex shader struct outputs.Kenneth Graunke2015-12-182-6/+32
| | | | | | | | | | | | | | | | | | | | While we correctly set output[] for composite varyings, we set completely bogus values for output_components[], making emit_urb_writes() output zeros instead of the actual values. Unfortunately, our simple approach goes out the window, and we need to recurse into structs to get the proper value of vector_elements for each field. Together with the previous patch, this fixes rendering in an upcoming game from Feral Interactive. v2: Use pointers instead of pass-by-mutable-reference (Jason, Matt). Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]> (cherry picked from commit 3810c1561401aba336765d64d1a5a3e44eb58eb3)
* i965: Fix fragment shader struct inputs.Kenneth Graunke2015-12-183-82/+84
| | | | | | | | | | | | | | | | | | | | | | | | | Apparently we have literally no support for FS varying struct inputs. This is somewhat surprising, given that we've had tests for that very feature that have been passing for a long time. Normally, varying packing splits up structures for us, so we don't see them in the backend. However, with SSO, varying packing isn't around to save us, and we get actual structs that we have to handle. This patch changes fs_visitor::emit_general_interpolation() to work recursively, properly handling nested structs/arrays/and so on. (It's easier to read with diff -b, as indentation changes.) When using the vec4 VS backend, this fixes rendering in an upcoming game from Feral Interactive. (The scalar VS backend requires additional bug fixes in the next patch.) v2: Use pointers instead of pass-by-mutable-reference (Jason, Matt) Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]> (cherry picked from commit 3e9003e9cf55265ab1fb6522dc5cbb2f455ea1f9)
* xmlconfig: Add support for DragonFlyFrançois Tigeot2015-12-031-0/+3
| | | | | Signed-off-by: Emil Velikov <[email protected]> (cherry picked from commit 8a94ba5e0cb738c6b1a817ea54afc5816d2bb596)
* mesa: support GL_RED/GL_RG in ES2 contexts when driver support existsIlia Mirkin2015-12-034-4/+11
| | | | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93126 Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]> Cc: "11.0 11.1" <[email protected]> (cherry picked from commit 0396eaaf80c5d7955d7926c4e448f006c7682d2e)
* texgetimage: consolidate 1D array handling code.Dave Airlie2015-12-031-15/+11
| | | | | | | | | | | | | | This should fix the getteximage-depth test that currently asserts. I was hitting problem with virgl as well in this area. This moves the 1D array handling code to a single place. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ben Skeggs <[email protected]> Cc: "10.6 11.0 11.1" <[email protected]> Signed-off-by: Dave Airlie <[email protected]> (cherry picked from commit 237bcdbab529237a120e225c63f567934a955523)
* meta/generate_mipmap: Don't leak the framebuffer objectIan Romanick2015-12-031-0/+5
| | | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Cc: "10.6 11.0" <[email protected]> (cherry picked from commit 72e232374eda780a5dcd374b55d203d0e2a6d02b)
* 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]> (cherry picked from commit 58aa56d40bfc6ba54ad9172bf219d18eeb615a80)
* 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]> (cherry picked from commit 76cfe2bc4436186fd585be96c4f402c1b1c79bdf)
* 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]> (cherry picked from commit a222d4cbc3de49857aebbdf727e53c273abcc6c1)
* 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]> (cherry picked from commit b8a7369fb7e5773892d01fcb1140fe6569ee27eb)
* 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]> (cherry picked from commit d5225ee5d92f00958c54b425fe829c811149e889)
* 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]> (cherry picked from commit 37d11b13ce1db2ad867ff5433cb31bcd1d93c7bf)
* 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]> (cherry picked from commit b1b73a42c8f245d5bf6bbed04071b2c6519b2fb4)
* 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]> (cherry picked from commit 52921f8e089abbc6871060fc50f90b62aaf1e11b)
* meta: Track VBO using gl_buffer_object instead of GL API object handleIan Romanick2015-11-245-48/+72
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> (cherry picked from commit 1035e00a815f0babddac0c6c43d01fd34f7e8a94)
* meta: Don't leave the VBO bound after _mesa_meta_setup_vertex_objectsIan Romanick2015-11-245-21/+38
| | | | | | | | | | 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]> (cherry picked from commit 3b5a7d450dea9bfadf1d72338f4418c87340805b)
* i965: Use _mesa_NamedBufferSubData for users of _mesa_meta_setup_vertex_objectsIan Romanick2015-11-241-3/+3
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> (cherry picked from commit ed0bd6573b6ce83471e73d009dbab5220f9e80c0)
* 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]> (cherry picked from commit 7f2f3000716d994d94c53f4a0c8a211fb00a46a4)
* 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]> (cherry picked from commit 89a61afdd7346d6e36caccc4d6f2a2607dc4a1f6)
* i965: Don't pollute the buffer object namespace in brw_meta_fast_clearIan Romanick2015-11-241-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Abdiel Janulgue <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> (cherry picked from commit 4e6b9c11fc545cc570ea0042af93e61bfb525d34)
* i965: Use internal functions for buffer object accessIan Romanick2015-11-241-6/+18
| | | | | | | | | | | | | | | | Instead of going through the GL API implementation functions, use the lower-level functions. This means that we have to keep track of a pointer to the gl_buffer_object and the gl_vertex_array_object. This has two advantages. First, it avoids a bunch of CPU overhead in looking up objects and validing API parameters. Second, and much more importantly, it will allow us to stop calling _mesa_GenBuffers / _mesa_CreateBuffers and pollute the buffer namespace (next patch). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Abdiel Janulgue <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> (cherry picked from commit e62799bd4e7b7525995e465a4bdcf6df0b0a69a0)
* i965: Use DSA functions for VBOs in brw_meta_fast_clearIan Romanick2015-11-241-6/+7
| | | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Abdiel Janulgue <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> (cherry picked from commit 1c5423d3a074d50138e5ad7945024f9cf4d063ec)
* i965: Pass brw_context instead of gl_context to brw_draw_rectlistIan Romanick2015-11-241-4/+5
| | | | | | | | | | | Future patches will use the brw_context instead. Keeping this non-functional change separate should make the function changes easier to review. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Abdiel Janulgue <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> (cherry picked from commit dcadd855f14b0d3dcce04a16afdfed2d7159d4a8)
* mesa: Refactor enable_vertex_array_attrib to make ↵Ian Romanick2015-11-242-9/+22
| | | | | | | | | | | | | | | _mesa_enable_vertex_array_attrib Pulls the parts of enable_vertex_array_attrib that aren't just parameter validation out into a function that can be called from other parts of Mesa (e.g., meta). _mesa_enable_vertex_array_attrib can also be used to enable fixed-function arrays. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> (cherry picked from commit 4a644f1caadc6b3e26b5f0ac60ac855152e38e59)
* mesa: Refactor update_array_format to make _mesa_update_array_format_publicIan Romanick2015-11-242-19/+57
| | | | | | | | | | Pulls the parts of update_array_format that aren't just parameter validation out into a function that can be called from other parts of Mesa (e.g., meta). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> (cherry picked from commit a336fcd36a4743c1ea6f8549cb31b48277359717)
* mesa: Make bind_vertex_buffer avilable outside varray.cIan Romanick2015-11-242-14/+22
| | | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Abdiel Janulgue <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> (cherry picked from commit 8fae494df2813bfa38f1aabd6c9b3c1ba3a5e4ef)
* meta: Compute correct buffer size with SkipRows/SkipPixelsChris Wilson2015-11-241-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]> (cherry picked from commit f30cf3258e495a583e011e07d5b4a19031c5518f)
* r200: fix bgrx8/xrgb8 blitsRoland Scheidegger2015-11-181-0/+4
| | | | | | | | | | | | | | | | | | Since 779cabfc7d022de8b7b9bc7fdac0caffa8646c51 the same txformat table entries are used for "normal" texturing as well as for blits. However, I forgot to put in an entry for the bgrx8 (le) and xrgb8 (be) formats - the normal texturing path can't hit them because the radeon tex format chooser will never chose them, but we get that format from the dri buffers (at least I assume we got it from there). This is untested but essentially addressing the same bug as for radeon. (I don't think that the second entry per le/be table is actually necessary, but shouldn't hurt...) Tested-by: Ian Romanick <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Cc: "11.0" <[email protected]> (cherry picked from commit a2611ffe4b5f1852c59301f086b988233a1c62f3)
* radeon: fix bgrx8/xrgb8 blitsRoland Scheidegger2015-11-181-0/+2
| | | | | | | | | | | | | | | | | Since d21320f6258b2e1780a15c1ca718963d8a15ca18 the same txformat table entries are used for "normal" texturing as well as for blits. However, I forgot to put in an entry for the bgrx8 (le) and xrgb8 (be) formats - the normal texturing path can't hit them because the radeon tex format chooser will never chose them, but we get that format from the dri buffers (at least I assume we got it from there). This caused lots of piglit regressions (and probably lots of trouble outside piglit too). This fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=92900. Tested-by: Ian Romanick <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Cc: "11.0" <[email protected]> (cherry picked from commit 983614dbede7b94cba1bad9f3e8627fc5e14bb91)
* meta/generate_mipmap: Only modify the draw framebuffer binding in ↵Ian Romanick2015-11-181-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]> (cherry picked from commit c40a88b6c5a698e5297957e28cccf2ce23820caa)
* meta/generate_mipmap: Don't leak the sampler objectIan Romanick2015-11-181-0/+2
| | | | | | | Signed-off-by: Ian Romanick <[email protected]> Cc: "10.6 11.0" <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> (cherry picked from commit 758f12fd98dea9a9682becf2d496bd38ef3959e5)
* i965/skl/gt4: Fix URB programming restriction.Ben Widawsky2015-11-181-0/+9
| | | | | | | | | | | | | | | The comment in the code details the restriction. Thanks to Ken for having a very helpful conversation with me, and spotting the blurb in the link I sent him :P. There are still stability problems for me on GT4, but this definitely helps with some of the failures. v2: Comment fixes Cc: [email protected] Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (cherry picked from commit 55314c5be4cbf933ab7fbd20f6aa49207e04c946)
* mesa/copyimage: allow width/height to not be multiples of blockIlia Mirkin2015-11-181-3/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For compressed textures, the image size is not necessarily a multiple of the block size (e.g. the last mip levels). Section 18.3.2 (Copying Between Images) of the OpenGL 4.5 Core Profile spec says: An INVALID_VALUE error is generated if the dimensions of either subregion exceeds the boundaries of the corresponding image object, or if the image format is compressed and the dimensions of the subregion fail to meet the alignment constraints of the format. and Section 8.7 (Compressed Texture Images) says: An INVALID_OPERATION error is generated if any of the following conditions occurs: * width is not a multiple of four, and width + xoffset is not equal to the value of TEXTURE_WIDTH. * height is not a multiple of four, and height + yoffset is not equal to the value of TEXTURE_HEIGHT. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92860 Signed-off-by: Ilia Mirkin <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Cc: [email protected] (cherry picked from commit 912babba7bf1abd3caa49f6372d581ae1afe7e84) [Emil Velikov: resolve trivial conflicts] Signed-off-by: Emil Velikov <[email protected]> Conflicts: src/mesa/main/copyimage.c
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-01 18:03:00 +0000