aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* i965: make pull constant loads in gen6 start at MRFs 16/17Iago Toral Quiroga2015-10-082-3/+6
| | | | | | | So they do not conflict with our (un)spills (MRF 21..23) or our URB writes (MRF 1..15) Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Fix remove_duplicate_mrf_writes so it can handle 24 MRFs in gen6Iago Toral Quiroga2015-10-081-1/+1
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: include bad type in error string of _mesa_pack_depth_spanTapani Pälli2015-10-081-1/+2
| | | | | Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa: Correctly handle GL_BGRA_EXT in ES3 format_and_type checksJason Ekstrand2015-10-071-2/+19
| | | | | | | | | | | | | | | | | | | | | The EXT_texture_format_BGRA8888 extension (which mesa supports unconditionally) adds a new format and internal format called GL_BGRA_EXT. Previously, this was not really handled at all in _mesa_ex3_error_check_format_and_type. When the checks were tightened in commit f15a7f3c, we accidentally tightened things too far and GL_BGRA_EXT would always cause an error to be thrown. There were two primary issues here. First, is that _mesa_es3_effective_internal_format_for_format_and_type didn't handle the GL_BGRA_EXT format. Second is that it blindly uses _mesa_base_tex_format which returns GL_RGBA for GL_BGRA_EXT. This commit fixes both of these issues as well as adds explicit checks that GL_BGRA_EXT is only ever used with GL_BGRA_EXT and GL_UNSIGNED_BYTE. Signed-off-by: Jason Ekstrand <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92265 Reviewed-by: Ian Romanick <[email protected]> Cc: "11.0" <[email protected]>
* Revert "mesa: enable KHR_debug for ES contexts"Emil Velikov2015-10-071-1/+1
| | | | | | | This reverts commit b69cfbdf18fa64606a76761b20bc268f4ac731e5. This isn't quite baked yet. Seems that despite building the ES piglits, none of them got executed.
* mesa: Remove GL_ARB_sampler_object depth compare error checking.Stefan Dösinger2015-10-071-18/+10
| | | | | | | | | | | | | | | | | Version 3: Simplify the code comment, word wrap commit description. Version 2: Return GL_FALSE if ARB_shadow is unsupported instead of pretending to store the value as suggested by Brian Paul. This fixes a GL error warning on r200 in Wine. The GL_ARB_sampler_objects extension does not specify a dependency on GL_ARB_shadow or GL_ARB_depth_texture for setting the depth texture compare mode and function. Silently ignore attempts to change these settings. They won't matter without a depth texture being assigned anyway. Reviewed-by: Brian Paul <[email protected]>
* mesa: enable KHR_debug for ES contextsEmil Velikov2015-10-071-1/+1
| | | | Signed-off-by: Emil Velikov <[email protected]>
* main/get: make KHR_debug enums available everywhereMatthew Waters2015-10-071-9/+9
| | | | | | | | | | | | | | | Move all the enums but CONTEXT_FLAGS. The spec seems quite explicit about the latter (wrt OpenGL ES) "In OpenGL ES versions prior to and including ES 3.1 there is no CONTEXT_FLAGS state and therefore the CONTEXT_FLAG_DEBUG_BIT cannot be queried." v2 [Emil Velikov] Rebase. v3 [Emil Veliokv] Drop the CONTEXT_FLAGS hunk - not applicable for GLES Signed-off-by: Matthew Waters <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* glapi: add function pointers for KHR_debug for glesMatthew Waters2015-10-071-0/+25
| | | | | | | | | | v2 [Emil Velikov] - Rebase. - Correct version in gles11 dispatch_sanity. - Move the extension enable to a separate patch. Signed-off-by: Matthew Waters <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* mesa: remove unneeded #include of colormac.hMark Janes2015-10-061-1/+0
| | | | Reviewed-by: Matt Turner <[email protected]>
* radeon/r200: remove unneeded #include of colormac.hMark Janes2015-10-0611-11/+0
| | | | Reviewed-by: Matt Turner <[email protected]>
* i965: remove unneeded #include of colormac.hMark Janes2015-10-062-2/+0
| | | | Reviewed-by: Matt Turner <[email protected]>
* i915: remove unneeded #include of colormac.hMark Janes2015-10-062-2/+0
| | | | Reviewed-by: Matt Turner <[email protected]>
* i915: Drop broken front_buffer_reading/drawing optimizationVille Syrjälä2015-10-063-41/+15
| | | | | | | | | | | | | | | | | | | | | Bring the following commit over to i915: commit ec542d74578bbef6b55125dd6aba1dc7f5079e65 Author: Eric Anholt <[email protected]> Date: Mon Mar 3 10:43:10 2014 -0800 i965: Drop broken front_buffer_reading/drawing optimization. Not sure if it might fix anything, but since the i965 and i915 used to share a bunch of that code, it would seem reasonable the same problems could be present in the i915 code still, and the i965 approach is well tested by now so bringing it over seems fairly safe. No piglit regressions on 855. v2: Rebase on _mesa_is_front_buffer_* refactor. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa/i965: Refactor brw_is_front_buffer_{drawing,reading} to common codeIan Romanick2015-10-066-33/+37
| | | | | | | | | | There are multiple similar implementations of these functions, and a later patch was going to add another. v2: Move removing intel_framebuffer to a different patch. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* st/mesa: Don't override NewFramebuffer just to call _mesa_new_framebufferIan Romanick2015-10-061-12/+1
| | | | | | | | | v2: Since state_tracker does not call _mesa_init_driver_functions, we need to initialize the dd::NewFramebuffer pointer to _mesa_new_framebuffer here. Suggested by Brian. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* radeon: Don't override NewFramebuffer just to call _mesa_new_framebufferIan Romanick2015-10-061-7/+0
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
* i915: Don't override NewFramebuffer just to call _mesa_new_framebufferIan Romanick2015-10-062-15/+0
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: Don't override NewFramebuffer just to call _mesa_new_framebufferIan Romanick2015-10-062-16/+0
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i830: Fix culling with user fbos on gen2Ville Syrjälä2015-10-061-0/+2
| | | | | | | | | | | | Flip the cull bits when rendering to a user fbo on gen2. This was already done on gen3 (since before git history starts) but was missing from the gen2 code. Fixes rendering of the driver+kart model in supertuxkart kart selection screen. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915: Adjust line size limitsVille Syrjälä2015-10-061-2/+2
| | | | | | | | | | | | The hardware can draw lines 0.5 to 7.5 pixels wide. Adjust the limits to 1.0-7.0. The old limits seems to be from the era when i915 and i965 were sharing this code. Not really sure if 1.0-7.0 is correct. Maybe it could be 0.5.7.5 as those are the hw limits, or maybe some combination of the two? Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915: Enable intel_render path for pointsVille Syrjälä2015-10-061-5/+3
| | | | | | | | | | | | | | | | | | The sub-pixel adjustment for points was killed off in commit 60d762aa625095a8c1f9597d8530bb5a6fa61b4c Author: Xiang, Haihao <[email protected]> Date: Wed Jan 2 11:38:51 2008 +0800 i915: Needn't adjust pixel centers. fix #12944 so if we don't need it in intel_tris.c we don't need it in intel_render.c either, which means we can allow intel_render.c to render points. No apparent regressions on PNV in ES1 or ES2 conformance. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915: Use COPY_DWORDS for pointsVille Syrjälä2015-10-061-5/+1
| | | | | | | | | | | | | | The sub-pixel adjustment for points was killed off in commit 60d762aa625095a8c1f9597d8530bb5a6fa61b4c Author: Xiang, Haihao <[email protected]> Date: Wed Jan 2 11:38:51 2008 +0800 i915: Needn't adjust pixel centers. fix #12944 so we can just as well use COPY_DWORDS(). Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915: Use _tnl_RenderClippedPolygon and _tnl_RenderClippedLineVille Syrjälä2015-10-061-17/+2
| | | | | | | | _tnl_RenderClippedPolygon and _tnl_RenderClippedLine already do most of what we want so use them. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915: Handle provoking vertex in intelFastRenderClippedPoly()Ville Syrjälä2015-10-061-4/+12
| | | | | | | | | | | | | | intelFastRenderClippedPoly() renders the polygon using triangles. For polygons the provoking vertex is always the first one, and currently this function assumes that the provoking vertex for triangles is the last one. In case the user changed the provoking vertex convention, the hardware may be configured to treat the first vertex of triangles as the provoking vertex. So check the convention and emit the triangles in the appropriate order to avoid having to change the hardware provoking vertex convention for rendering polygons. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* t_dd_dmatmp: Check provoking vertex convention when rendering quadsVille Syrjälä2015-10-061-20/+26
| | | | | | | | | | When drawing quads using triangles we need to be careful to make the provoking vertices match when flat shading. v2: Major rebase on top of Ian's other t_dd_dmatmp.h work. Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Ian Romanick <[email protected]>
* t_dd_dmatmp: Disallow flat shading when rendering quad strips via tri stripsVille Syrjälä2015-10-061-5/+2
| | | | | | | | | | When rendering quad strips via tri strips we can't get the provoking vertex right, so disallow flat shading. v2: Major rebase on top of Ian's other t_dd_dmatmp.h work. Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Ian Romanick <[email protected]>
* t_dd_dmatmp: Allow flat shaded polygons with tri fansVille Syrjälä2015-10-061-2/+4
| | | | | | | | | | We can allow rendering flat shaded polygons using tri fans if we check the provoking vertex convention. v2 (idr): Remove _EXT suffixes from GL_FIRST_VERTEX_CONVENTION. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* t_dd_dmatmp: Replace fprintf with unreachableIan Romanick2015-10-061-12/+9
| | | | | | | | | | | | | | | | | | | | From http://lists.freedesktop.org/archives/mesa-dev/2015-May/084883.html: "There are no real error cases here, just dead code. validate_render() is supposed to make sure we never call these functions if the code can't actually render the primitives. The fprintf()+return branches should really just contain assert(0) or equivalent." I also rearranged the if-else-block in render_quad_strip_verts to look more like the other functions. A future patch is going to change a bunch of that code anyway. v2: Make "unreachable" message more descriptive. Suggested by Iago. Signed-off-by: Ian Romanick <[email protected]> Suggested-by: Ville Syrjälä <[email protected]> Reviewed-by: Iago Toral Quiroga <[email protected]>
* radeon: Use C99 initializers for primitive arraysIan Romanick2015-10-061-20/+20
| | | | | | | | | | Using C99 initializers for the primitive arrays makes things more readable. Signed-off-by: Ian Romanick <[email protected]> Suggested-by: Matt Turner <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Use C99 initializers for primitive arraysIan Romanick2015-10-061-24/+24
| | | | | | | | | Using C99 initializers for the primitive arrays makes things more readable. Signed-off-by: Ian Romanick <[email protected]> Suggested-by: Matt Turner <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i915: Use C99 initializers for primitive arraysVille Syrjälä2015-10-062-50/+50
| | | | | | | | | Using C99 initializers for the primitive arrays makes things more readable. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* main: array stride for unsized arrays of arrays are calculated like recordsSamuel Iglesias Gonsalvez2015-10-061-1/+1
| | | | | Signed-off-by: Samuel Iglesias Gonsalvez <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965: add EXT_polygon_offset_clamp support to gen4/gen5Ilia Mirkin2015-10-057-9/+30
| | | | | Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Ilia Mirkin <[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]>
* i965: Generalize predicated break pass for use in vec4 backend.Matt Turner2015-10-055-12/+16
| | | | | | | instructions in affected programs: 44204 -> 43762 (-1.00%) helped: 221 Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Use backend_instruction in predicated break peephole.Matt Turner2015-10-051-4/+4
| | | | | | | We're not using any fs_inst fields, and the next commit will make the peephole used by the vec4 backend. Reviewed-by: Jason Ekstrand <[email protected]>
* i965/fs: Remove SNB embedded-comparison support from optimizations.Matt Turner2015-10-052-32/+3
| | | | | | | | | We never emit IF instructions with an embedded comparison (lost in the switch to NIR), so this code is not used. If we want to readd support, we should have a pass that merges a CMP instruction with an IF or a WHILE instruction after other optimizations have run. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: Add missing _mm_mfence() before streaming loads.Matt Turner2015-10-051-0/+3
| | | | | | | | | | | | | | | | | According to the Intel Software Development Manual (Volume 1: Basic Architecture, 12.10.3 Streaming Load Hint Instruction): Streaming loads may be weakly ordered and may appear to software to execute out of order with respect to other memory operations. Software must explicitly use fences (e.g. MFENCE) if it needs to preserve order among streaming loads or between streaming loads and other memory operations. That is, a memory fence is needed to preserve the order between the GPU writing the buffer and the streaming loads reading it back. Reported-by: Joseph Nuzman <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: Fix intel_miptree_is_fast_clear_capable()Chad Versace2015-10-051-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | There are three types of fast clears: a. fast depth clears b. fast singlesample color clears c. fast multisample color clears Function intel_miptree_is_fast_clear_capable() checks if a miptree supports fast clears of type (b). Rename the function to disambiguate what it does: old: intel_miptree_is_fast_clear_capable new: intel_miptree_supports_non_msrt_fast_clear The functionally accidentally rejected multisampled color surfaces because it thought they were singlesample array surfaces. Fix that by explicitly rejecting surfaces with samples > 1. This fix would have been needed before we enabled layered fast singlesample color clears (introduced in gen8), which we want to do eventually. For now, though, this patch changes no behavior; it just fixes how the driver chooses its behavior. Reviewed-by: Anuj Phogat <[email protected]>
* i965/mt: Declare some functions as staticChad Versace2015-10-052-7/+3
| | | | | | | | intel_tiling_supports_non_msrt_mcs() and intel_miptree_is_fast_clear_capable() are not used outside of intel_mipmap_tree.c. Reviewed-by: Anuj Phogat <[email protected]>
* i965: Make vec4_visitor's destructor virtualIago Toral Quiroga2015-10-051-1/+1
| | | | | | | | | | | | | | | | | | We need a virtual destructor when at least one of the class' methods is virtual. Failure to do so might lead to undefined behavior when destructing derived classes. Fixes the following warning: brw_vec4_gs_visitor.cpp: In function 'const unsigned int* brw::brw_gs_emit(brw_context*, gl_shader_program*, brw_gs_compile*, void*, unsigned int*)': brw_vec4_gs_visitor.cpp:703:11: warning: deleting object of polymorphic class type 'brw::vec4_gs_visitor' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] delete gs; Curro: This shouldn't be causing any actual bugs at the moment because gen6_gs_visitor is the only subclass of vec4_visitor destroyed through a pointer of a base class (vec4_gs_visitor *) and its destructor is basically the same as its parent's. Anyway it seems sensible to change this so it doesn't bite us in the future. Reviewed-by: Francisco Jerez <[email protected]>
* i965: Assert on the number of combined UBO and SSBO binding table entriesIago Toral Quiroga2015-10-052-0/+4
| | | | | | | | In theory we can't break this assertion since the compiler frontend checks that we don't exceed any of the individual limits, but it does not hurt to be extra safe. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Reserve binding table space for SSBO surfacesIago Toral Quiroga2015-10-051-0/+1
| | | | | | | These share the space with UBO surfaces but we need to make sure we allocate enough space for both sets (12 of each) Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Define BRW_MAX_SSBOIago Toral Quiroga2015-10-052-7/+10
| | | | | | Instead of using hard-coded values. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Define BRW_MAX_UBOIago Toral Quiroga2015-10-052-3/+6
| | | | | | Instead of using hard-coded values. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Remove more dead visitor/vertex program code.Matt Turner2015-10-043-23/+0
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Don't print line numbers with INTEL_DEBUG=optimizer.Matt Turner2015-10-041-2/+4
| | | | | | | The thing you want to do with the output files is diff them, which is made more difficult by line numbers changing. Reviewed-by: Alejandro Piñeiro <[email protected]>
* glsl: reduce memory footprint of uniform_storage structTimothy Arceri2015-10-055-10/+11
| | | | | | | | The uniform will only be of a single type so store the data for opaque types in a single array. Cc: Francisco Jerez <[email protected]> Cc: Ilia Mirkin <[email protected]>
* i965: Remove shader_prog from vec4_gs_visitor.Kenneth Graunke2015-10-043-9/+9
| | | | | | | Unfortunately it has to stay in gen6_gs_visitor. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 17:26:18 +0000