summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965
Commit message (Collapse)AuthorAgeFilesLines
* i965: Warn about preliminary support for Gen11Matt Turner2018-02-281-0/+7
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965: use context priority definitions from gen_defines.hTapani Pälli2018-02-283-10/+10
| | | | | | Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* i965: Use gen_get_pci_device_id_overrideJordan Justen2018-02-271-52/+5
| | | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Scott D Phillips <[email protected]>
* glsl: Specify framebuffer fetch coherency mode in ↵Francisco Jerez2018-02-241-1/+2
| | | | | | | | | | | | | | | | | | | | | lower_blend_equation_advanced(). This requires passing an extra argument to the lowering pass because the KHR_blend_equation_advanced specification doesn't seem to define any mechanism for the implementation to determine at compile-time whether coherent blending can ever be used (not even an "#extension KHR_blend_equation_advanced_coherent" directive seems to be required in the shader source AFAICT). In the long run we'll probably want to do state-dependent recompiles based on the value of ctx->Color.BlendCoherent, but right now there would be no benefit from that because the only driver that supports coherent framebuffer fetch is i965 on SKL+ hardware, which are unable to support the non-coherent path for the moment because of texture layout issues, so framebuffer fetch coherency is always enabled for them. Reviewed-by: Plamena Manolova <[email protected]>
* mesa: Rename MESA_shader_framebuffer_fetch gl_extensions bits to EXT.Francisco Jerez2018-02-245-7/+7
| | | | | | | | The changes I had originally planned for the MESA_shader_framebuffer_fetch extension have been merged into the EXT spec, there's no point in keeping MESA_shader_framebuffer_fetch extension enables. Reviewed-by: Plamena Manolova <[email protected]>
* mesa: Rename dd_function_table::BlendBarrier to match latest EXT spec.Francisco Jerez2018-02-241-2/+2
| | | | | | | | This GL entry point was renamed to glFramebufferFetchBarrier() in the EXT extension on request from Khronos members. Update the Mesa codebase to match the latest spec. Reviewed-by: Plamena Manolova <[email protected]>
* i965: Fix KHR_blend_equation_advanced with some render targets.Francisco Jerez2018-02-241-1/+3
| | | | | | | | | | | | | | | | This reverts two bogus and seemingly useless changes from the commits referenced below, which broke KHR_blend_equation_advanced (and EXT_shader_framebuffer_fetch_non_coherent which wasn't exposed yet) for any kind of render target surface that would cause the get_isl_surf() call in brw_emit_surface_state() to do anything useful (notice how the result of get_isl_surf() is completely ignored by the caller right now), as was the case while using those extensions with 1D array or 3D framebuffers in particular. Fixes: f5859b45b1686e8116380d87 "i965/miptree: Switch remaining surfaces to isl" Fixes: bf24c3539e4b6989512968ca "i965/miptree: Clean-up unused" Cc: [email protected] Reviewed-by: Plamena Manolova <[email protected]>
* mesa: expose ARB_enhanced_layouts in the compatibility profileMarek Olšák2018-02-231-1/+2
| | | | | | | GLSL 1.40 is required. Tested-by: Dieter Nützel <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: perf: ensure reading config IDs from sysfs isn't interruptedLionel Landwerlin2018-02-231-1/+2
| | | | | | | Fixes: 458468c136e "i965: Expose OA counters via INTEL_performance_query" Signed-off-by: Lionel Landwerlin <[email protected]> Cc: <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* i965: Use finish_external instead of make_shareable in setTexBuffer2Jason Ekstrand2018-02-215-2/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The setTexBuffer2 hook from GLX is used to implement glxBindTexImageEXT which has tighter restrictions than just "it's shared". In particular, it says that any rendering to the image while it is bound causes the contents to become undefined. The GLX_EXT_texture_from_pixmap extension provides us with an acquire and release in the form of glXBindTexImageEXT and glXReleaseTexImageEXT. The extension spec says, "Rendering to the drawable while it is bound to a texture will leave the contents of the texture in an undefined state. However, no synchronization between rendering and texturing is done by GLX. It is the application's responsibility to implement any synchronization required." From the EGL 1.4 spec for eglBindTexImage: "After eglBindTexImage is called, the specified surface is no longer available for reading or writing. Any read operation, such as glReadPixels or eglCopyBuffers, which reads values from any of the surface’s color buffers or ancillary buffers will produce indeterminate results. In addition, draw operations that are done to the surface before its color buffer is released from the texture produce indeterminate results In other words, between the bind and release calls, we effectively own those pixels and can assume, so long as we don't crash, that no one else is reading from/writing to the surface. The GLX and EGL implementations call the setTexBuffer2 and releaseTexBuffer function pointers that the driver can hook. In theory, this means that, between BindTexImage and ReleaseTexImage, we own the pixels and it should be safe to track aux usage so we can avoid redundant resolves so long as we start off with the right assumption at the start of the bind/release pair. In practice, however, X11 has slightly different expectations. It's expected that the server may be drawing to the image at the same time as the compositor is texturing from it. In that case, the worst expected outcome should be tearing or partial rendering and not random corruption like we see when rendering races with scanout with CCS. Fortunately, the GEM rules about texture/render dependencies save us here. If X11 submits work to write to a pixmap after the compositor has submitted work to texture from it, GEM inserts a dependency between the compositor and X11. If X11 is using a high-priority context, this will cause the compositor to get a temporarily boosted priority while the batch from X11 is waiting on it. This means that we will never have an actual race between X11 and the compositor so no corruption can happen. Unfortunately, however, this means that X11 will likely be rendering to it between the compositor's BindTexImage and ReleaseTexImage calls. If we want to avoid strange issues, we need to be a bit careful about resolves because we can't really transition it away from the "default" aux usage. The only case where this would practically be a problem is with image_load_store where we have to do a full resolve in order to use the image via the data port. Even there it would only be a problem if batches were split such that X11's rendering happens between the resolve and the use of it as a storage image. However, the chances of this happening are very slim so we just emit a warning and hope for the best. This commit adds a new helper intel_miptree_finish_external which resets all aux state to whatever ISL says is the right worst-case "default" for the given modifier. It feels a little awkward to call it "finish" because it's actually an acquire from the perspective of the driver, but it matches the semantics of the other prepare/finish functions. This new helper gets called in intelSetTexBuffer2 instead of make_shareable. We also add an intelReleaseTexBuffer (we passed NULL to releaseTexBuffer before) and call intel_miptree_prepare_external in it. This probably does nothing most of the time but it means that the prepare/finish calls are properly matched. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/tex_image: Reference the renderbuffer miptree in setTexBuffer2Jason Ekstrand2018-02-211-14/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | The old code made a new miptree that referenced the same BO as the renderbuffer and just trusted in the memory aliasing to work. There are only two ways in which the new miptree is liable to differ from the one in the renderbuffer and neither of them matter: 1) It may have a different target. The only targets that we can ever see in intelSetTexBuffer2 are GL_TEXTURE_2D and GL_TEXTURE_RECTANGLE and the difference between the two doesn't matter as far as the miptree is concerned; genX(update_sampler_state) only looks at the gl_texture_object and not the miptree when determining whether or not to use normalized coordinates. 2) It may have a very slightly different format. Again, this doesn't matter because we've supported texture views for quite some time so we always look at the gl_texture_object format instead of the miptree format for hardware setup anyway. On the other hand, because we were recreating the miptree, we were using intel_miptree_create_for_bo which doesn't understand modifiers. We really want this function to work without doing a resolve so long as you have modifiers so we need to fix that. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/tex_image: Pull the tex format from the renderbuffer in intelSetTexBuffer2Jason Ekstrand2018-02-211-15/+19
| | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/miptree: Loosen the format check in miptree_match_imageJason Ekstrand2018-02-214-6/+8
| | | | | | | | | | This function is used to determine when we need to re-allocate a miptree. Since we do nothing different in miptree allocation for sRGB vs. linear, loosening this should be safe and may lead to less copying and reallocating in some odd cases. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/state: Ignore intel_obj->_Format for depth/stencil and ETC2Jason Ekstrand2018-02-211-1/+15
| | | | | | | | | | We're about to start letting the intel_obj->_Format be the "real" texture format. For depth/stencil textures, this may be a combined depth stencil format. For ETC2 on gen7 and earlier, this will be the actual ETC2 format. This makes a bit more GL sense but means we have to be careful in state upload. Reviewed-by: Chad Versace <[email protected]>
* i965: Enable disk shader cache by defaultJordan Justen2018-02-201-3/+0
| | | | | | | Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965: Use absolute addressing for constant buffer 0 on Kernel 4.16+.Kenneth Graunke2018-02-172-1/+32
| | | | | | | | | | | | | | | | | | | | | | | By default, 3DSTATE_CONSTANT_* Constant Buffer 0 is relative to dynamic state base address. This makes it unusable for pushing UBOs. There is a bit in the INSTPM register (or CS_DEBUG_MODE2 on Skylake) which controls whether buffer 0 is relative to dynamic state base address, or simply a normal pointer. Setting that gives us full flexibility. This lets us push up to 4 UBO ranges. We can't currently write this on Haswell and earlier, and will need to update the kernel command parser, and then do the whole version checking song and dance. We also need a brand new kernel that supports context isolation - on older kernels, newly created contexts inherit register state from whatever happened to be running. So, setting this would have catastrophic impact on other drivers such as libva, Beignet, or older Mesa. See commit 8ec5a4e4a4a32f4de351c5fc2bf0eb615b6eef1b where we did this once before, but had to revert it in commit 013d33122028f2492da90a03a. Reviewed-by: Francisco Jerez <[email protected]>
* i965: Stop restoring the default L3 configuration on Kernel 4.16+.Kenneth Graunke2018-02-173-2/+7
| | | | | | | | | | Kernel 4.16 has proper context isolation, which means we can change the L3 configuration without worrying about that leaking to other newly created contexts, breaking the assumptions of other userspace. So, disable our workaround to reprogram it back to the default. Reviewed-by: Francisco Jerez <[email protected]>
* i965: Fix aux-surface size checkDaniel Stone2018-02-172-3/+12
| | | | | | | | | | | | | | | | | | | The previous commit reworked the checks intel_from_planar() to check the right individual cases for regular/planar/aux buffers, and do size checks in all cases. Unfortunately, the aux size check was broken, and required the aux surface to be allocated with the correct aux stride, but full image height (!). As the ISL aux surface is not recorded in the DRIimage, we cannot easily access it to check. Instead, store the aux size from when we do have the ISL surface to hand, and check against that later when we go to access the aux surface. Signed-off-by: Daniel Stone <[email protected]> Fixes: c2c4e5bae3ba ("i965: Fix bugs in intel_from_planar") Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Implement GenerateMipmap directly, rather than using Meta.Kenneth Graunke2018-02-165-0/+135
| | | | | | | | | | | | | | | | | | Meta is awful and we'd like to stop using it. Implementing this using BLORP allows us to stop trashing a bunch of GL state every time. This follows the structure of st_generate_mipmap(). compute_num_levels is lifted directly from there. Improves performance in Gl41HdrBloom by about 11.794% +/- 1.01919% (n=3) on Kabylake GT2 at 1280x720 (the difference seems much smaller at higher resolutions). v2 (idr): Don't try depth or depth-stencil blorp blits on Gen4 or Gen5 because it's not implemented yet. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Topi Pohjolainen <[email protected]>
* i965/icl: Add render target flush after uploading binding tableAnuj Phogat2018-02-151-0/+14
| | | | | | | | | | | | | | | | | | From PIPE_CONTROL command description in gfxspecs: "Whenever a Binding Table Index (BTI) used by a Render Taget Message points to a different RENDER_SURFACE_STATE, SW must issue a Render Target Cache Flush by enabling this bit. When render target flush is set due to new association of BTI, PS Scoreboard Stall bit must be set in this packet." V2: Move the PIPE_CONTROL to update_renderbuffer_surfaces() in brw_wm_surface_state.c (Ken). Fixes a fulsim error and a GPU hang described in below JIRA. JIRA: MD5-322 Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/icl: Enable float blend optimization and Wa3DStateModeAnuj Phogat2018-02-151-1/+1
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/common/icl: Add has_sample_with_hiz flag in gen_device_infoAnuj Phogat2018-02-151-4/+1
| | | | | | | | | | | Sampling from hiz is enabled in i965 for GEN9+ but this feature has been removed from gen11. So, this new flag will be useful to turn the feature on/off for different gen h/w. It will be used later in a patch adding device info for gen11. Suggested-by: Kenneth Graunke <[email protected]> Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/icl: Add assertions to check dispatch mode is SIMD8Anuj Phogat2018-02-151-0/+5
| | | | | | | | | | SIMD4x2 dispatch mode has been removed in GEN11. We're not using it anyways in Mesa. Adding few asserts to make it explicit. Use GEN_GEN macro in place of devinfo->gen (Ken) Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/icl: Update switch statementsAnuj Phogat2018-02-152-0/+2
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/icl: Update the assert in brw_memory_barrier()Anuj Phogat2018-02-151-1/+1
| | | | | | | | Nothing is changed here from gen10 to gen11. So, just update the assert. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/icl: Define and use icl mocs settingsAnuj Phogat2018-02-153-1/+11
| | | | | | | Gen11 MOCS settings are duplicate of Gen10 MOCS settings. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/icl: Update the comment for maximum number of threads per PSDAnuj Phogat2018-02-151-4/+5
| | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/icl: Build and use gen11 functions for genxml state-upload and blorpAnuj Phogat2018-02-158-4/+43
| | | | | | Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Dylan Baker <[email protected]>
* i965/icl: Don't set ResetGatewayTimerAnuj Phogat2018-02-151-0/+2
| | | | | | | This field is removed in gen11+ Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Drop EXEC_OBJECT_CAPTURE defines.Kenneth Graunke2018-02-151-3/+0
| | | | | | | | These only existed to avoid making people update libdrm for new uABI headers. A while ago we imported those headers into the Mesa repo, so the dependency is gone and these are no longer useful. Reviewed-by: Jason Ekstrand <[email protected]>
* meson: use a custom target instead of a generator for i965 oaDylan Baker2018-02-141-11/+10
| | | | | | | | | | | | | | | | | | Generators really are never the thing you want. The problem in this case is that a generator must create a file that contains any file that the generated target depends on. Since brw_oa.py doesn't generate such a file the generated sources are not regenerated even if the xml files they should depend on changes. While we could change brw_oa.py to write such a file, that's silly, it depends on itself and the xml file. So we'll just use a custom target instead, which will have the correct dependency behavior and doesn't really add that much code. Fixes: 3218056e0eb3 ("meson: Build i965 and dri stack") CC: Ian Romanick <[email protected]> Signed-off-by: Dylan Baker <[email protected]> Acked-by: Lionel Landwerlin <[email protected]>
* i965: Add gl_state_index casts for PATCH_VERTICES_INJason Ekstrand2018-02-141-1/+2
| | | | | | | | This fixes the build in clang Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105088 Reviewed-by: Tapani Pälli <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/miptree: Initialize mcs with a linear mapScott D Phillips2018-02-141-1/+1
| | | | | | | When initializing mcs, map with MAP_RAW and fill in the linear map. Removes a place where gtt mapping is used. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/tiled_memcpy: change linear pointer from (0, 0) to (xt1, yt1)Scott D Phillips2018-02-143-11/+11
| | | | | | | In all current uses, the linear surface is only allocated starting at (xt1, yt1) anyway, so this improves the calling ergonomics. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/tiled_memcpy: linear_to_ytiled a cache line at a timeScott D Phillips2018-02-141-6/+66
| | | | | | | | | | | | | | | | | | TileY's low 6 address bits are: v1 v0 u3 u2 u1 u0 Thus a cache line in the tiled surface is composed of a 2d area of 16x4 bytes of the linear surface. Add a special case where the area being copied is 4-line aligned and a multiple of 4-lines so that entire cache lines will be written at a time. On Apollolake, this increases tiling throughput to wc maps by 84.0103% +/- 0.862818% v2: Split [y0, y1) and [y2, y3) loops apart for clarity (Jason Ekstrand) v3: Don't reset src var (Jason), Ensure y0 <= y1 <= y2 <= y3 Reviewed-by: Jason Ekstrand <[email protected]>
* i965/gen10: Remove warning message.Rafael Antognolli2018-02-141-7/+0
| | | | | | | | | | | | Gen10 seems pretty stable so far, so there's no reason to keep this message. Signed-off-by: Rafael Antognolli <[email protected]> Cc: Kenneth Graunke <[email protected]> Cc: "18.0" [email protected] Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: fix tessellation regressions with gl_state_index16Dave Airlie2018-02-121-1/+1
| | | | | | | | | Looks like one conversion was missed. Fixes: e149a0253 (mesa,glsl,nir: reduce gl_state_index size to 2 bytes) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105067 Signed-off-by: Dave Airlie <[email protected]> Tested-by: Mark Janes <[email protected]>
* mesa,glsl,nir: reduce gl_state_index size to 2 bytesMarek Olšák2018-02-133-4/+3
| | | | | | | | | Let's use the new gl_state_index16 type everywhere and remove the typecasts. This helps reduce the size of gl_program_parameter. Reviewed-by: Brian Paul <[email protected]>
* i965: Fix bugs in intel_from_planarDaniel Stone2018-02-121-27/+29
| | | | | | | | | | | | | | This commit fixes two bugs in intel_from_planar. First, if the planar format was non-NULL but only had a single plane, we were falling through to the planar case. If we had a CCS modifier and plane == 1, we would return NULL instead of the CCS plane. Second, if we did end up in the planar_format == NULL case and the modifier was DRM_FORMAT_MOD_INVALID, we would end up segfaulting in isl_drm_modifier_has_aux. Cc: [email protected] Fixes: 8f6e54c92966bb94a3f05f2cc7ea804273e125ad Signed-off-by: Daniel Stone <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* Revert "i965: prevent potentially null pointer access"Mark Janes2018-02-091-1/+1
| | | | | | | This reverts commit 712332ed54f14b5ee34c2990e351ca48992488b2, which caused over 90k failures in Mesa i965 CI. Reviewed-by: Dylan Baker <[email protected]>
* i965: prevent potentially null pointer accessLionel Landwerlin2018-02-091-1/+1
| | | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Alejandro Piñeiro <[email protected]> CID: 1418110
* intel/blorp: Use isl_aux_op instead of blorp_hiz_opJason Ekstrand2018-02-084-18/+18
| | | | | Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Nanley Chery <[email protected]>
* intel/blorp: Use isl_aux_op instead of blorp_fast_clear_opJason Ekstrand2018-02-083-20/+20
| | | | | Reviewed-by: Topi Pohjolainen <[email protected]> Reviewed-by: Nanley Chery <[email protected]>
* i965: perf: cleanup detection of kernel support for loadable configsLionel Landwerlin2018-02-081-15/+2
| | | | | | | | | | | | The initial revision of the patch adding loadable configs was testing the feature's availability by adding a new config successfully and then removing it. A second version tested the availability just by exercising the removal. But some unused code remained. Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* i965: perf: use drmIoctl() instead of ioctl()Lionel Landwerlin2018-02-081-2/+2
| | | | | | | | | | | ioctl() might be interrupted, use drmIoctl() instead as it'll retry automatically. Fixes: 27ee83eaf7e "i965: perf: add support for userspace configurations" Cc: "18.0" <[email protected]> Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Tested-by: Mark Janes <[email protected]>
* i965: perf: add debug messages for loaded configsLionel Landwerlin2018-02-081-0/+2
| | | | | | | | This helps figuring out potential problems when metrics don't show up on frameretrace for example. Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* i965: add __DRI2_BLOB support and set cache functionsTapani Pälli2018-02-071-0/+21
| | | | | | | | v2: adjust to change that moved cache from ctx to screen Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* i965: allocate a SGVS element when VertexID or InstanceID are readIago Toral Quiroga2018-02-071-15/+2
| | | | | | | | | | | | | | | | | | | | Although on gen8+ platforms we can in theory use 3DSTATE_VF_SGVS to put these beyond the last vertex element it seems that we still need to allocate the SVGS element, otherwise we have observed cases where we end up reading garbage. Specifically, the CTS test mentioned below was flaky with a fail rate of ~1% on some gen9+ platforms caused by reading garbage for the gl_InstanceID value. The flakyness goes away as soon as we start allocating the SVGS element. v2: - Do this for gen8+, not just gen9+, and pull the boolean outside the #if block (Jason) Fixes flaky test: KHR-GL45.vertex_attrib_64bit.limits_test Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104335 Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: change ctx->Color.ColorMask into a 32-bit bitmaskMarek Olšák2018-02-045-24/+16
| | | | | | | | 4 bits per draw buffer, 8 draw buffers in total --> 32 bits. This is easier to work with. Reviewed-by: Eric Anholt <[email protected]>
* i965: Create new program cache bo when clearing the program cacheJordan Justen2018-02-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | When the disk shader cache CI testing was enabled, we started noticing occasional failures on deqp test runs. (Mainly SNB, rarely HSW) Before this change, when we cleared the (in memory) program cache we reused the same bo. Since the disk shader cache quickly restores programs, it appears that this would lead to overwrites of the older program binaries in the in memory program cache that apparently were still executing in some cases. If these programs were still executing, this could cause a GPU hang. This issue is probably not disk shader cache specific, but may have been hidden due to the compiler taking time to recompile programs after the cache was cleared. v2: * Don't add `copy` param to brw_cache_new_bo (Ken) * Call from brw_program_cache_check_size (Ken) Cc: Kenneth Graunke <[email protected]> Cc: [email protected] Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 08:58:21 +0000