summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* st/mesa: add a winsys buffers list in st_contextCharmaine Lee2017-07-114-10/+81
| | | | | | | | | | | | | | | | | | | | | Commit a5e733c6b52e93de3000647d075f5ca2f55fcb71 fixes the dangling framebuffer object by unreferencing the window system draw/read buffers when context is released. However this can prematurely destroy the resources associated with these window system buffers. The problem is reproducible with Turbine Demo running with VMware driver. In this case, the depth buffer content was lost when the context is rebound to a drawable. To prevent premature destroy of the resources associated with window system buffers, this patch maintains a list of these buffers in the context, making sure the reference counts of these buffers will not reach zero until the associated framebuffer interface objects no longer exist. This also helps to avoid unnecessary destruction and re-construction of the resources associated with the framebuffer. Fixes VMware bug 1909807. Reviewed-by: Brian Paul <[email protected]>
* i965: Drop bogus pthread_mutex_unlock in map_gtt error path.Kenneth Graunke2017-07-121-1/+0
| | | | | | | | | | The locking was supposed to go away in commit 314647c4c206917ec01b7 (i965: Drop global bufmgr lock from brw_bo_map_* functions.), but this lone unlock remains. I'm guessing I messed this up when splitting up Chris's patch. Reviewed-by: Chris Wilson <[email protected]>
* intel: Move the DRM uapi headers to a non-Intel location.Eric Anholt2017-07-122-3/+3
| | | | | | | | | | | | I want to remove vc4's dependency on headers from libdrm as well, but storing multiple copies of drm_fourcc.h in our tree would be silly. v2: Update Android.mk as well, move distcheck drm*.h references to top-level noinst_HEADERS. Reviewed-by: Lionel Landwerlin <[email protected]> (v1) Reviewed-by: Daniel Stone <[email protected]> (v1) Reviewed-by: Rob Herring <[email protected]>
* i965: Use VALGRIND_MAKE_MEM_x in place of MALLOCLIKE/FREELIKEChris Wilson2017-07-111-7/+27
| | | | | | | | | | | | | | | | | | | | | Valgrind doesn't actually implement VALGRIND_FREELIKE_BLOCK as the exact inverse of VALGRIND_MALLOCLIKE_BLOCK. It makes the block inaccessible, but still leaves it defined in its allocation tracker i.e. it will report the mmap as lost despite the call to FREELIKE! Instead of treating the mmap as an allocation, treat it as changing the access bits upon the memory, i.e. that it becomes defined (because of the buffer objects always contain valid content from the user's perspective) upon mmap and inaccessible upon munmap. This makes memcheck happy without leaving it thinking there is a very large leak. Finally for consistency, we treat all the mmap/munmap paths the same even though valgrind can intercept the regular mmap used for GTT. We could move this in the drm_mmap/drm_munmap macros, but that quickly looks ugly given the desire for those to support different OSes, but I didn't try that hard! Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Fix asynchronous mappings on !LLC platforms.Kenneth Graunke2017-07-111-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | When using a read-only CPU mapping, we may encounter stale buffer contents. For example, the Piglit primitive-restart test offers the following scenario: 1. Read data via a CPU map. 2. Destroy that buffer. 3. Create a new buffer - obtaining the same one via the BO cache. 4. Call BufferSubData, which does a GTT map with MAP_WRITE | MAP_ASYNC. (We avoid set_domain for async mappings, so no flushing occurs.) 5. Read data via a CPU map. (Without explicit clflushing, this will contain data from step 1!) Otherwise, everything ought to work, keeping in mind that we never use CPU maps for writing - just read-only CPU maps. This restores the performance gains after Matt's revert in commit 71651b3139c501f50e6547c21a1cdb816b0a9dde. v2: Do the invalidate later, and even when asking for a brand new map. v3: Add more comments from Chris. Reviewed-by: Chris Wilson <[email protected]>
* i965: Don't use PREAD for glGetBufferSubData().Kenneth Graunke2017-07-113-28/+10
| | | | | | | | | | | | | | | Just map the buffer and memcpy. This will do a CPU mmap, which should be reasonably efficient, and doing this gives us full control over the domains and caching instead of leaving it to the kernel. This prevents regressions on Braswell in the next commit. Specifically GL45-CTS.shader_atomic_counters.basic-buffer-operations. Because async maps start skipping set-domain, the pread thought everything was nicely still in the CPU domain, and returned stale data. v2: Use _mesa_error_no_memory() if the map fails instead of crashing. Reviewed-by: Chris Wilson <[email protected]>
* i965: perf: use new subslices numbers from device infoLionel Landwerlin2017-07-111-32/+17
| | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Ben Widawsky <[email protected]>
* i965: Use already existing eu_totalBen Widawsky2017-07-111-8/+1
| | | | | | | | Reduces IOCTL calls by 1, and provides a centralized place to override such configurations if we have a need to do so. Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: Resolve framebuffers before signaling the fenceChris Wilson2017-07-111-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From KHR_fence_sync: When the condition of the sync object is satisfied by the fence command, the sync is signaled by the associated client API context, causing any eglClientWaitSyncKHR commands (see below) blocking on <sync> to unblock. The only condition currently supported is EGL_SYNC_PRIOR_COMMANDS_COMPLETE_KHR, which is satisfied by completion of the fence command corresponding to the sync object, and all preceding commands in the associated client API context's command stream. The sync object will not be signaled until all effects from these commands on the client API's internal and framebuffer state are fully realized. No other state is affected by execution of the fence command. If clients are passing the fence fd (from EGL_ANDROID_native_fence_sync) to a compositor, that fence must only be signaled once the framebuffer is resolved and not before as is currently the case. v2: fixup assert to use GL_SYNC_GPU_COMMANDS_COMPLETE (Chad) Reported-by: Sergi Granell <[email protected]> Fixes: c636284ee8ee ("i965/sync: Implement DRI2_Fence extension") Signed-off-by: Chris Wilson <[email protected]> Cc: Sergi Granell <[email protected]> Cc: Rob Clark <[email protected]> Cc: Chad Versace <[email protected]> Cc: Daniel Stone <[email protected]> Cc: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Assert that we don't use CPU write maps to non-coherent buffers.cros-mesa-17.1.1-r3-vanillachadv/cros-mesa-17.1.1-r3-vanillaKenneth Graunke2017-07-101-0/+6
| | | | | | | | | Using CPU maps of non-coherent buffers can get us in a lot of trouble, and WC maps are a reasonable alternative anyway. Guard against shooting ourselves in the foot by adding an assert, and comment. Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Disable access to CPU mmap for async access on non-LLC machinesChris Wilson2017-07-101-4/+12
| | | | | | | | | | | | | | | | | If the user triggers an implicit batch flush while holding access to a CPU mapped buffer, that mmapping will be invalidated by the kernel for non-LLC devices. (The kernel when executing a batch will change the cache domain of the buffers in that batch, which for non-LLC CPU access will cause that buffer to be clflushed and any further CPU access to be discarded.) To prevent this, simply disallow any CPU async mmap access. The cases where async CPU access to a non-LLC buffer should continue to be allowed via their preferred snooping path. v2 (Ken): Reword the comment slightly. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Track when a bo is shared with an external clientChris Wilson2017-07-102-0/+9
| | | | | | | | | | | | | If the buffer is being shared with an external client, our own state tracking may be stale and in some cases we may wish to double check with the kernel/hw state. At the moment, this is synonymous with not being reusable, but the semantics between reusable and external are quite different and we will have more examples of non-reusable buffers in the near future. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* gallium: use "ull" number suffix to keep the QtCreator parser happyMarek Olšák2017-07-101-2/+2
| | | | | | | It can't parse "llu". Reviewed-by: Thomas Helland <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* i965: Use brw_bo_wait() for brw_bo_wait_rendering()Chris Wilson2017-07-105-8/+10
| | | | | | | | | | | | | | Currently, we use set_domain() to cause a stall on rendering. But the set-domain ioctl has the side-effect of changing the kernel's cache domain underneath the struct_mutex, which may perturb state if there was no rendering to wait upon and in general is much heavier than the lockless wait-ioctl. Historically libdrm used set-domain as we did not have an explicit wait-ioctl (and the patches to teach it to use wait if available were lost in the mists). Since mesa already depends upon a kernel support the wait-ioctl, we do not need to supply a fallback. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* st/mesa: Fix grabbing the wrong variant if glDrawPixels is calledMatias N. Goldberg2017-07-082-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | By design pixel shaders can have up to 3 variants: * The standard one. * glDrawPixels variant. * glBitmap variant. However "shader_has_one_variant" ignores this fact, and therefore st_update_fp would select the wrong variant if glDrawPixels or glBitmap was ever called. This patch fixes the problem. If the standard variant has been created, calling glDrawPixels or glBitmap will append the variant to the second entry of the linked list, so that st_update_fp still selects the right one if shader_has_one_variant is set. If the standard variant hasn't been created yet and glDrawPixel/Bitmap has been called, st_update_fp will will see this and take the slow path instead. The standard variant will then be added at the front of the linked list, so that the next time the fast path is taken. Blender in particular is hit by this bug. v2: Marek - cosmetic changes Fixes https://bugs.freedesktop.org/show_bug.cgi?id=101596 Signed-off-by: Marek Olšák <[email protected]>
* mesa: finish implementing glPrimitiveRestartNV() for display listsBrian Paul2017-07-071-1/+21
| | | | | | | | | | | | | If we try to build a display list with just a glPrimitiveRestartNV() call, we'd crash because of a null GLvertexformat::PrimitiveRestartNV pointer. This change fixes that case. The previous patch fixed the case of calling glPrimitiveRestartNV() inside a glBegin/End pair. v2: minor clean-up in save_PrimitiveRestartNV(), per Charmaine. Reviewed-by: Charmaine Lee <[email protected]>
* vbo: fix glPrimitiveRestartNV crash inside a display listOlivier Lauffenburger2017-07-071-5/+15
| | | | | | | | | | | | | | | | | | | | glPrimitiveRestartNV crashes when it is called during the compilation of a display list. There are two reasons: - ctx->Driver.CurrentSavePrimitive is not set to the current primitive - save_PrimitiveRestartNV() calls _save_Begin() which only sets an OpenGL error, instead of calling vbo_save_NotifyBegin(). This patch correctly calls vbo_save_NotifyBegin() but it detects the current primitive mode by looking at the latest saved primitive. Additional work by Brian Paul Signed-off-by: Olivier Lauffenburger <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101464 Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: remove unused st_framebuffer::Private fieldBrian Paul2017-07-071-1/+0
| | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Charmaine Lee <[email protected]>
* mesa: add some braces in _mesa_make_current()Brian Paul2017-07-071-1/+2
| | | | Slightly better readability.
* vbo: rename target->index in loopback codeBrian Paul2017-07-071-12/+12
| | | | | | Because it's a vertex attribute index. Reviewed-by: Charmaine Lee <[email protected]>
* vbo: whitespace/formatting fixes in vbo_save_loopback.cBrian Paul2017-07-071-52/+64
| | | | | | Trivial. Reviewed-by: Charmaine Lee <[email protected]>
* vbo: simplify vbo_save_NotifyBegin()Brian Paul2017-07-073-24/+3
| | | | | | | | | | | | | This function always returned GL_TRUE. Just make it a void function. Remove unreachable code following the call to vbo_save_NotifyBegin() in save_Begin() in dlist.c There were some stale comments that no longer applied since an earlier code refactoring. No Piglit regressions. Reviewed-by: Charmaine Lee <[email protected]>
* mesa: simplify get_tex_images_for_clear()Brian Paul2017-07-061-19/+14
| | | | | | Get rid of redundant code. Reviewed-by: Charmaine Lee <[email protected]>
* mesa: new comments, assertion related to glClearTexSubImageBrian Paul2017-07-061-0/+12
| | | | Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: find proper mipmap level in st_ClearTexSubImage()Brian Paul2017-07-061-4/+56
| | | | | | | | | | | | | | | | | | | | The Piglit arb_clear_texture-error test creates a texture with only a 1x1 image at level=1, then tries to clear level 0 (nonexistent) and level 1 (exists). The test only checks that the former generates an error but the later doesn't. The test passes, but when we try to clear the level=1 image we're passing an invalid level to pipe_context::clear_texture(). level=1, but since there's only one mipmap level in the texture, it should be zero. This fixes the code to search the gallium texture resource for the correct mipmap level. Also, add an assertion to make sure we're not passing an invalid level to pipe_context::clear_texture(). Fixes device errors with VMware driver. No Piglit regressions. v2: don't do the level search when using immutable textures. Reviewed-by: Charmaine Lee <[email protected]>
* st/mesa: whitespace fixes in st_cb_fbo.cBrian Paul2017-07-061-29/+19
| | | | Trivial.
* st/mesa: whitespace fixes in st_texture.cBrian Paul2017-07-061-13/+15
| | | | Trivial.
* build systems: move git_sha1_gen.sh to bin/Eric Engestrom2017-07-061-1/+1
| | | | | | | | | There was no reason for this script to live outside the scripts directory. Suggested-by: Brian Paul <[email protected]> Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: Move surface resolves back to draw/dispatch timeJason Ekstrand2017-07-054-121/+143
| | | | | | | | | | | | | | | | | This is effectively a revert of 388f02729bbf88ba104f4f8ee1fdf005a240969c though much code has been added since. Kristian initially moved it to try and avoid locking problems with meta-based resolves. Now that meta is gone from the resolve path (for good this time, we hope), we can move it back. The problem with having it in intel_update_state was that the UpdateState hook gets called by core mesa directly and all sorts of things will cause a UpdateState to get called which may trigger resolves at inopportune times. In particular, it gets called by _mesa_Clear and, if we have a HiZ buffer in the INVALID_AUX state, causes a HiZ resolve right before the clear which is pointless. By moving it back to try_draw_prims time, we know it will only get called right before a draw which is where we want it. Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Avoid set comprehension.Vinson Lee2017-07-051-1/+1
| | | | | | | | | | | | | | Fix build error on CentOS 6.9 with Python 2.6. GEN main/format_fallback.c File "./main/format_fallback.py", line 42 names = {fmt.name for fmt in formats} ^ SyntaxError: invalid syntax Fixes: a1983223d883 ("mesa: Add _mesa_format_fallback_rgbx_to_rgba() [v2]") Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* st/glsl_to_nir: fix edgeflag passthroughNicolai Hähnle2017-07-052-1/+6
| | | | | | | | | | We have to mark the additional shader input as used, otherwise it will be eliminated, and we have to setup its index correctly. This is a bit of a hack, but so is everything surrounding edgeflag passthrough. Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: use pipe_shader_type_from_mesaNicolai Hähnle2017-07-051-21/+2
| | | | Reviewed-by: Samuel Pitoiset <[email protected]>
* tgsi,st/mesa: move varying slot to semantic mapping into a helper for VSNicolai Hähnle2017-07-052-99/+8
| | | | | | | We will use this helper in radeonsi's NIR path. Reviewed-by: Samuel Pitoiset <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* glsl: simplify add_uniform_to_shader::visit_fieldNicolai Hähnle2017-07-051-6/+5
| | | | | | | Each field gets a distinct name, so we should never hit the case where the name already exists in the parameter list. Reviewed-by: Timothy Arceri <[email protected]>
* st/mesa: release EGLImage on EGLImageTarget* errorPhilipp Zabel2017-07-041-0/+1
| | | | | | | | | | | | | The smapi->get_egl_image() call in st_egl_image_get_surface() stores a reference to the EGLImage's texture in stimg.texture. That reference is released via pipe_resource_reference(&stimg.texture, NULL) before stimg goes out of scope at the end of the function, but not in the error path if !is_format_supported(). Fixes: 83e9de25f325 ("st/mesa: EGLImageTarget* error handling") Cc: [email protected] Signed-off-by: Philipp Zabel <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* st/mesa: fix tessellation shaders with no support for shareable shadersMarek Olšák2017-07-031-2/+2
| | | | | | | | Broken by: b43c887a9bf1e3fb99b0dc22bfea5db81375a06e Reported by Gert Wollny. Reviewed-by: Nicolai Hähnle <[email protected]>
* st/mesa: remove an obsolete commentNicolai Hähnle2017-07-031-1/+0
| | | | Reviewed-by: Timothy Arceri <[email protected]>
* mesa: remove unused parameter/member of add_uniform_to_shaderNicolai Hähnle2017-07-031-6/+3
| | | | | Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965: Print access flags in INTEL_DEBUG=buf output.Kenneth Graunke2017-07-011-3/+22
| | | | | | | | | | | | | | | | | Being able to see the access mode of various mappings is incredibly useful for debugging. With this patch, INTEL_DEBUG=buf now shows data such as: bo_create: buf 7 (bufferobj) 640b bo_map_gtt: 7 (bufferobj) -> 0x7fca1fae5000, WRITE ASYNC brw_bo_map_cpu: 7 (bufferobj) -> 0x7fca1fae4000, READ bo_map_gtt: 5 (bufferobj) -> 0x7fca1fad4000, WRITE ASYNC brw_bo_map_cpu: 7 (bufferobj) -> 0x7fca1fae4000, READ which makes it easy to see that there are async GTT writes with intervening CPU reads. Reviewed-by: Matt Turner <[email protected]>
* i965: Remove clearing of bo->map_gtt after failureChris Wilson2017-07-011-1/+0
| | | | | | | | | | | | With the conversion to storing the result of drm_mmap to a local and not directly to bo->map_gtt itself, we no longer should clear bo->map_gtt. In the best the operation is redundant as we know bo->map_gtt to already be NULL, but in the worst case we overwrite a concurrent thread that successfully mmaped the GTT. Fixes: 314647c4c206 ("i965: Drop global bufmgr lock from brw_bo_map_* functions.") Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add inline to brw_bo_unmapKenneth Graunke2017-06-301-1/+1
| | | | | I meant to do this in "i965: Make brw_bo_unmap a static inline." but botched the commit fixup.
* i965: Drop global bufmgr lock from brw_bo_map_* functions.Chris Wilson2017-06-301-14/+15
| | | | | | | | | | | | After removing the unusuable debugging code in the previous commit, we can also entirely remove the global mutex around mapping the buffer for the first time and replace it with a single atomic operation to update the cache once we retrieve the mmap. v2 (Ken): Split out from Chris's original commit. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Make brw_bo_unmap a static inline.Kenneth Graunke2017-06-302-7/+1
| | | | | | | | | | | With the broken debugging code gone, it doesn't do anything anymore. We could technically eliminate it, but I'd like to keep it around in case we want to add something there again someday. Otherwise we'd have to go all over the codebase adding unmap calls back again. Based on a patch by Chris Wilson. Reviewed-by: Matt Turner <[email protected]>
* i965: Discard bo->map_countChris Wilson2017-06-302-53/+3
| | | | | | | | | | | | | | | Supposedly we were keeping a reference count for the number of users of a mapping so that we could use valgrind to detect access to the map outside of the valid section. However, we were incrementing the counter only when first creating the cached mapping but decrementing on every unmap. The bo->map_count tracking was wrong and so the debugging code was completely useless. v2 (Ken): Separate out atomic compare and swap optimization. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Add a comment about not needing VALGRIND_MALLOCLIKE_BLOCK.Kenneth Graunke2017-06-301-1/+3
| | | | | | | | | At first glance this seems missing, since we handle it manually for CPU and WC maps. Although a bit inconsistent, it's actually not necessary. Thanks to Chris Wilson for explaining this to me. Reviewed-by: Matt Turner <[email protected]>
* st/mesa: fix texture image resource selection in st_render_texture()Brian Paul2017-06-301-1/+18
| | | | | | | | | | | | | | If we're rendering to an incomplete/inconsistent (cube) texture, the different faces/levels of the texture may be stored in different resources. Before, we always used the texture object resource. Now, we use the texture image resource. In normal circumstances, that's the same resource. But in some cases, such as the Piglit fbo-incomplete-texture-03 test, the cube faces are in different resources and we need to render to the texture image resource. Fixes fbo-incomplete-texture-03 with VMware driver. Reviewed-by: Roland Scheidegger <[email protected]>
* st/mesa: check for incomplete texture in st_finalize_texture()Brian Paul2017-06-301-0/+12
| | | | | | | | | | | | | | | | | | | | | | | Return early from st_finalize_texture() if we have an incomplete texture. This avoids trying to create a texture resource with invalid parameters (too many mipmap levels given the base dimension). Specifically, the Piglit fbo-incomplete-texture-03 test winds up calling pipe_screen::resource_create() with width0=32, height0=32 and last_level=6 because the first five cube faces are 32x32 but the sixth face is 64x64. Some drivers handle this, but others (like VMware svga) do not (generates device errors). Note that this code is on the path that's usually not taken (we normally build consistent textures). No Piglit regressions. v2: only need to check for base-level completeness since that's what has to be consistent in order to specify the dimensions for a new gallium texture. Per Roland. Reviewed-by: Roland Scheidegger <[email protected]>
* i965/i915: Add UYVY as the supported formatJohnson Lin2017-06-303-18/+31
| | | | | | Trigger the correct sampler options for it. Similar with YUYV Reviewed-by: Kristian H. Kristensen <[email protected]>
* build systems: uniformize git_sha1.h generationEric Engestrom2017-06-291-6/+1
| | | | | | Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* Android: i965: remove libdrm_intel dependencyRob Herring2017-06-291-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 7dd20bc3ee8f ("anv/i965: drop libdrm_intel dependency completely") removed the libdrm_intel dependency for automake, but Android builds still depended on it. Now the build requires a newer version of i915_drm.h and fails on Android builds: src/mesa/drivers/dri/i965/brw_performance_query.c:616:9: error: use of undeclared identifier 'I915_OA_FORMAT_A32u40_A4u32_B8_C8' case I915_OA_FORMAT_A32u40_A4u32_B8_C8: ^ src/mesa/drivers/dri/i965/brw_performance_query.c:1887:18: error: use of undeclared identifier 'I915_PARAM_SLICE_MASK' gp.param = I915_PARAM_SLICE_MASK; ^ src/mesa/drivers/dri/i965/brw_performance_query.c:1893:18: error: use of undeclared identifier 'I915_PARAM_SUBSLICE_MASK' gp.param = I915_PARAM_SUBSLICE_MASK; ^ Remove the libdrm_intel dependency for Android builds and add the necessary include paths for the local copy of i915_drm.h. Fixes: 7dd20bc ("anv/i965: drop libdrm_intel dependency completely") Signed-off-by: Rob Herring <[email protected]> Reviewed-by: Juan A. Suarez Romero <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 02:58:34 +0000