aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_context.c
Commit message (Collapse)AuthorAgeFilesLines
* i965: enable INTEL_blackhole_renderLionel Landwerlin2020-02-131-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | v2: condition the extension on context isolation support from the kernel (Chris) v3: (Lionel) The initial version of this change used a feature of the Gen7+ command parser to turn the primitive instructions into no-ops. Unfortunately this doesn't play well with how we're using the hardware outside of the user submitted commands. For example resolves are implicit operations which should not be turned into no-ops as part of the previously submitted commands (before blackhole_render is enabled) might not be disabled. For example this sequence : glClear(); glEnable(GL_BLACKHOLE_RENDER_INTEL); glDrawArrays(...); glReadPixels(...); glDisable(GL_BLACKHOLE_RENDER_INTEL); While clear has been emitted outside the blackhole render, it should still be resolved properly in the read pixels. Hence we need to be more selective and only disable user submitted commands. This v3 manually turns primitives into MI_NOOP if blackhole render is enabled. This lets us enable this feature on any platform. v4: Limit support to gen7.5+ (Lionel) v5: Enable Gen7.5 support again, requires a kernel update of the command parser (Lionel) v6: Disable Gen7.5 again... Kernel devs want these patches landed before they accept the kernel patches to whitelist INSTPM (Lionel) v7: Simplify change by never holding noop (there was a shortcoming in the test not considering fast clears) Only program register using MI_LRI (Lionel) v8: Switch to software managed blackhole (BDW hangs on compute batches...) v9: Simplify the noop state tracking (Lionel) v10: Don't modify flush function (Ken) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> (v8) Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2964>
* vbo: merge use_buffer_objects into vbo_CreateContext to skip the big mallocMarek Olšák2020-02-111-3/+1
| | | | | Reviewed-by: Mathias Fröhlich <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3766>
* vbo: remove immediate mode code that doesn't do anything and simplify stuffMarek Olšák2020-02-111-1/+0
| | | | | | | no change in behavior Reviewed-by: Mathias Fröhlich <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3766>
* i965: Do not set front_buffer_dirty if there is no front bufferDanylo Piliaiev2020-02-041-1/+3
| | | | | | | | | | | | | | | | | | Otherwise there will be a warning: "libEGL warning: FIXME: egl/x11 doesn't support front buffer rendering." Happens with EGL_KHR_surfaceless_context: eglMakeCurrent(egl_display, EGL_NO_SURFACE, EGL_NO_SURFACE, egl_context) eglMakeCurrent(egl_display, egl_surface, egl_surface, egl_context) glFlush() // Here will be a warning Cc: <[email protected]> Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1525 Signed-off-by: Danylo Piliaiev <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3628> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3628>
* i965: Enable INTEL_shader_integer_functions2 on Gen8+Ian Romanick2020-01-231-0/+1
| | | | | | | | | | | v2: Use new lower_hadd64 and lower_usub_sat64 flags. v3: Enable SPIR-V capability. v4: Move lowering options to COMMON_SCALAR_OPTIONS. Suggested by Caio. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/767>
* i965: Simplify brw_get_renderer_string()Kenneth Graunke2020-01-131-20/+10
| | | | | | | | | | | | | | This stops using driGetRendererString() in favor of a simple snprintf(). This should have the same functionality on 64-bit systems, but drops a "x86/MMX/SSE2" suffix on 32-bit systems. (People shouldn't be using the GL_RENDERER string to check for CPU features...) We also use gen_get_device_name() instead of PCI ID list munging. Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3371>
* mesa: Silence unused parameter warningIan Romanick2019-12-041-1/+1
| | | | | | | | | | | | | Unused since e4da8b9c331 ("mesa/compiler: rework tear down of builtin/types"). src/mesa/main/context.c: In function ‘_mesa_free_context_data’: src/mesa/main/context.c:1321:54: warning: unused parameter ‘destroy_compiler_types’ [-Wunused-parameter] 1321 | _mesa_free_context_data(struct gl_context *ctx, bool destroy_compiler_types) | ^ Reviewed-by: Pierre-Eric Pelloux-Prayer <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* driconfig: add a new engine name/version parameterLionel Landwerlin2019-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vulkan applications can register with the following structure : typedef struct VkApplicationInfo { VkStructureType sType; const void* pNext; const char* pApplicationName; uint32_t applicationVersion; const char* pEngineName; uint32_t engineVersion; uint32_t apiVersion; } VkApplicationInfo; This enables the Vulkan implementations to apply workarounds based off matching this description. Here we add a new parameter for matching the driconfig options with the following : <device driver="anv"> <application engine_name_match="MyOwnEngine.*" engine_versions="10:12,40:42"> <option name="blaaah" value="true" /> </application> </device> v2: switch engine name match to use regexps v3: Verify that the regexec returns REG_NOMATCH for match failure (Eric) v4: Add missing bit that went to the following commit (Eric) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]> Cc: 19.2 <[email protected]>
* intel/dri: finish proper glthreadSergii Romantsov2019-09-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | KWin was able to get NULL-context in the call intelUnbindContext. But a call _mesa_glthread_finish is not resistent to such case. Case can be catched with steps: 1. Create both glx and egl contexts 2. Make glx as current 3. Make egl as current 4. Reset glx context 5. Make egl as current Solution adds proper finishing of glthread-context (context will be taken from the requested dri-context for unbinding, but not from the saved current context). Piglit-test: https://gitlab.freedesktop.org/mesa/piglit/merge_requests/87 Cc: 19.1 19.2 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110814 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111271 Fixes: dca36d5516d0 (i965: Implement threaded GL support) Signed-off-by: Sergii Romantsov <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: initialize bo_reuse when creating brw_bufmgrTapani Pälli2019-08-291-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes a possible data race spotted while debugging on other EGL related failures where glFinish and eglCreateContext are going on at the same time: ==11558== Possible data race during read of size 1 at 0x5E78CD0 by thread #23 ==11558== Locks held: 1, at address 0x5E77CA8 ==11558== at 0x61B71D4: bo_alloc_internal (brw_bufmgr.c:639) ==11558== by 0x61B7328: brw_bo_alloc (brw_bufmgr.c:669) ==11558== by 0x61EF975: recreate_growing_buffer (intel_batchbuffer.c:231) ==11558== by 0x61EFAAE: intel_batchbuffer_reset (intel_batchbuffer.c:255) ==11558== by 0x61EFB85: intel_batchbuffer_reset_and_clear_render_cache (intel_batchbuffer.c:280) ==11558== by 0x61F0507: brw_new_batch (intel_batchbuffer.c:551) ==11558== by 0x61F12C1: _intel_batchbuffer_flush_fence (intel_batchbuffer.c:888) ==11558== by 0x61BDD6B: intel_glFlush (brw_context.c:296) ==11558== by 0x61BDDB9: intel_finish (brw_context.c:307) ==11558== by 0x623831B: _mesa_Finish (context.c:1906) ==11558== by 0x46D556: deqp::egl::GLES2ThreadTest::Operation::execute(tcu::ThreadUtil::Thread&) ==11558== by 0x721502: tcu::ThreadUtil::Thread::run() ==11558== ==11558== This conflicts with a previous write of size 1 by thread #26 ==11558== Locks held: 1, at address 0x5D09878 ==11558== at 0x61B98A9: brw_bufmgr_enable_reuse (brw_bufmgr.c:1541) ==11558== by 0x61BF09D: brw_process_driconf_options (brw_context.c:854) ==11558== by 0x61BF6CA: brwCreateContext (brw_context.c:993) ==11558== by 0x621181F: driCreateContextAttribs (dri_util.c:473) ==11558== by 0x53FE87B: dri2_create_context (egl_dri2.c:1388) ==11558== by 0x53EE7BE: eglCreateContext (eglapi.c:807) ==11558== by 0x5C8AB9: eglw::FuncPtrLibrary::createContext(void*, void*, void*, int const*) const ==11558== by 0x46E027: deqp::egl::GLES2ThreadTest::CreateContext::exec(tcu::ThreadUtil::Thread&) Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Use force_compat_profile driconf optionDanylo Piliaiev2019-08-101-2/+7
| | | | | Signed-off-by: Danylo Piliaiev <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/perf: make perf context privateMark Janes2019-08-071-0/+1
| | | | | | Encapsulate the details of this data structure. Reviewed-by: Kenneth Graunke <[email protected]>
* nir: Stop whacking gl_FrontFacing to a system valueJason Ekstrand2019-08-011-0/+1
| | | | | | | | | | We have a cap bit for gallium and a GLSL compiler flag to control this. Just trust what GLSL gives us and stop forcing it. In order for this to be safe, we have to advertise another cap in some of the gallium drivers. Reviewed-by: Alyssa Rosenzweig <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* intel: Use a system value for gl_FragCoordJason Ekstrand2019-07-291-0/+1
| | | | | | | | | | | | It's kind-of an anomaly that the Intel drivers are still treating gl_FragCoord as an input. It also makes zero sense because we have to special-case it in the back-end. Because ANV is the only user of nir_lower_wpos_center, we go ahead and just update it to look for nir_intrinsic_load_frag_coord as part of this patch. Reviewed-by: Kenneth Graunke <[email protected]>
* spirv_extensions: i965: initialize SPIR-V extensionsAlejandro Piñeiro2019-07-171-1/+10
| | | | | | v2: Rebase update after changes on previous patches. Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* mesa: Replace MaxTextureLevels with MaxTextureSize.Eric Anholt2019-05-131-2/+2
| | | | | | | | | | In most places (glGetInteger, max_legal_texture_dimensions), we wanted the number of pixels, not the number of levels. Number of levels is easily recovered with util_next_power_of_two() and ffs(). More importantly, for V3D we want to be able to expose a non-power-of-two maximum texture size to cover 2x4k displays on HW that can't quite do 8192 wide. Reviewed-by: Marek Olšák <[email protected]>
* anv,i965: Stop warning about incomplete gen11 supportJason Ekstrand2019-05-031-7/+0
| | | | | | | | Both drivers are feature-complete and should be running more-or-less at perf at this point. Drop the warning. Acked-by: Kenneth Graunke <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* st/mesa/radeonsi: fix race between destruction of types and shader compilationTimothy Arceri2019-04-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 624789e3708c moved the destruction of types out of atexit() and made use of a ref count instead. This is useful for avoiding a crash where drivers such as radeonsi are still compiling in a thread when the app exits and has not called MakeCurrent to change from the current context. While the above scenario is technically an app bug we shouldn't crash. However that change caused another race condition between the shader compilation tread in radeonsi and context teardown functions. This patch makes two changes to fix this new problem: First we explicitly call _mesa_destroy_shader_compiler_types() when destroying the st context rather than calling it indirectly via _mesa_free_context_data(). We do this as we must call it after st_destroy_context_priv() so that we don't destory the glsl types before the compilation threads finish. Next wait for the shader threads to finish in si_destroy_context() this also means we need to call context destroy before destroying the queues in si_destroy_screen(). Fixes: 624789e3708c ("compiler/glsl: handle case where we have multiple users for types") Reviewed-by: Marek Olšák <[email protected]>
* i965: Implement threaded GL support.Kenneth Graunke2019-03-051-0/+44
| | | | | | | | | | | | | | | | | | | Now i965 supports mesa_glthread=true like Gallium drivers do. According to Markus (degasus), the Citra emulator now runs ~30% faster. Emmanuel (linkmauve) also reported that the Dolphin emulator improved by 2.8x on one game. (Both of those still need to be added to drirc.) An Intel Mesa CI run with mesa_glthread=true appears to be happy. Bioshock Infinite's benchmark mode seems to be around 15-20% faster on my Skylake GT4 at 1920x1080. Tested-by: Markus Wick <[email protected]> Tested-by: Emmanuel Gil Peyrot <[email protected]> Tested-by: Kenneth Graunke <[email protected]> Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* spirv: Sort supported capabilitiesJason Ekstrand2019-01-071-5/+5
| | | | Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* Revert recent changes about not including compute in combined limits.Kenneth Graunke2018-08-241-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As far as I can tell, no one reviewed these changes, they made i965 assert fail on driver load, and I am not certain they are correct. (Hopefully reverting these does not break radeonsi too badly...) The uniform related changes seem fine and reasonable, but the texture image units change is possibly incorrect. According to the OES_tessellation_shader spec issue 5: (5) How are aggregate shader limits computed? RESOLVED: Following the GL 4.4 model, but we restrict uniform buffer bindings to 12/stage instead of 14, this results in MAX_UNIFORM_BUFFER_BINDINGS = 72 This is 12 bindings/stage * 6 shader stages, allowing a static partitioning of the bindings even though at most 5 stages can appear in a program object). MAX_COMBINED_UNIFORM_BLOCKS = 60 This is 12 blocks/stage * 5 stages, since compute shaders can't be mixed with other stages. MAX_COMBINED_TEXTURE_IMAGE_UNITS = 96 This is 16 textures/stage * 6 stages. which definitely is including compute shaders in that last limit. Not including compute shaders breaks the following test: dEQP-GLES31.functional.state_query.integer.max_combined_texture_image_units_getinteger There was enough breakage that I figured we should just send this back to the drawing board. Revert "i965: don't include compute resources in "Combined" limits" Revert "st/mesa: don't include compute resources in "Combined" limits" Revert "mesa: don't include compute resources in MAX_COMBINED_* limits" This reverts commit b03dcb1e5f507c5950d0de053a6f76e6306ee71f. This reverts commit cff290df4c09547cd2cb3b129ec59bdebdadba90. This reverts commit 45f87a48f94148b484961f18a4f1ccf86f066b1c.
* i965: don't include compute resources in "Combined" limitsKenneth Graunke2018-08-231-11/+11
| | | | | | | | | | | The combined limits should only include shader stages that can be active at the same time. We don't need to include compute. See also cff290df4c09547cd2cb3b129ec59bdebdadba90 for st/mesa. Unbreaks i965 from assert failing on driver load since Marek's 45f87a48f94148b484961f18a4f1ccf86f066b1c, which dropped the core Mesa capabilities before adjusting driver limits down to match.
* i965: Implement EGL_KHR_mutable_render_bufferChad Versace2018-08-211-2/+84
| | | | | | | | | | | | | | Testing: - Manually tested a low-latency handwriting demo that toggles EGL_RENDER_BUFFER. Toggling changed the display latency as expected. Used Android on Chrome OS, Kabylake GT2. - No change in dEQP-EGL.functional.* on Fedora 27, Wayland, Skylake GT2. Used deqp at tag android-p-preview-5. - No regressions in dEQP-EGL.functional.*, ran on Android on Chrome OS, Kabylake GT2. Some dEQP-EGL.functional.mutable_render_buffer.* test change from NotSupported to Pass. Reviewed-by: Tapani Pälli <[email protected]>
* i965: Advertise 8 bits subpixel precision for viewport bounds on gen6+Danylo Piliaiev2018-08-201-1/+1
| | | | | | | | | | We use floating-points for viewport bounds so VIEWPORT_SUBPIXEL_BITS should reflect this. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105975 Signed-off-by: Danylo Piliaiev <[email protected]> Reviewed-by: Lionel Landwerlin <[email protected]>
* xmlconfig: add kernel_driver device attributeQiang Yu2018-08-171-1/+2
| | | | | | | | | This attribute can be used by loader to apply different option to device use specific kernel driver. Signed-off-by: Qiang Yu <[email protected]> Acked-by: Michel Dänzer <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* i965: enable XFB and GeometryStreams for gen7+Alejandro Piñeiro2018-07-311-0/+2
| | | | Reviewed-by: Timothy Arceri <[email protected]>
* mesa: Add gl_shader_program param to ProgramBinarySerializeDriverBlobJordan Justen2018-07-091-1/+1
| | | | | | | | | | This might be required because some stages might generate different programs depending on the other stages in the program. For example, the i965 driver's tessellation control stage depends on the tessellation evaluation shader. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965: Use ShaderCacheSerializeDriverBlob driver functionJordan Justen2018-07-091-0/+4
| | | | | | | | This function is called just before the gl_program::driver_cache_blob is saved out as part of the gl_program serialization. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965: enable AtomicStorage capability for gen7+Alejandro Piñeiro2018-07-031-0/+1
| | | | | | That is the same gen requirement for ARB_shader_atomic_counters. Reviewed-by: Timothy Arceri <[email protected]>
* i965: Disable internal CCS for shadows of multi-sampled windowsJason Ekstrand2018-06-041-1/+10
| | | | | | | | | | | | | | If window system supports Y-tiling but not CCS_E, we currently create an internal CCS for any window system buffers and then resolve right before handing it off to X or Wayland. In the case of the single-sampled shadow of a multi-sampled window system buffer, this is pointless because the only thing we do with it is use it as a MSAA resolve target so we do MSAA resolve -> CCS resolve -> hand to the window system. Instead, just disable CCS for the shadow and then the MSAA resolve will write uncompressed directly into it. If the window system supports CCS_E, we will still use CCS_E, we just won't do internal CCS. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: silence unused variableLionel Landwerlin2018-05-091-1/+0
| | | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Fixes: 2dc29e095f9da ("i965: Don't leak blorp on Gen4-5.") Reviewed-by: Caio Marcelo de Oliveira Filho <[email protected]>
* i965: Use ISL for emitting depth/stencil/hiz state on gen6+Jason Ekstrand2018-05-081-9/+0
| | | | | | | | | | | | | | We leave gen4-5 alone because the ISL code hasn't really been well- tested on gen4-5 or with combined depth-stencil because we don't use BLORP for depth operations on gen4-5. Also, the gen4-5 code has to deal with intratile offsets for LOD hacks and ISL doesn't handle those yet. We could make ISL handle gen4-5 capable or we could just not bother. Among other things, this should make future platform enabling easier because it means we don't have to update multiple (or hand-rolled!) depth stencil emit paths. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Don't leak blorp on Gen4-5.Kenneth Graunke2018-05-071-2/+1
| | | | | | | | We used to only initialize BLORP on Gen6+. When we added it on Gen4-5, we forgot to destroy it unconditionally. Fixes: 752d7af77a52898cebf5597def4fdd38b1d6303e (i965: Add blorp support for gen4-5) Reviewed-by: Matt Turner <[email protected]>
* i965: Always try to create a logical contextChris Wilson2018-05-031-15/+14
| | | | | | | | | | | | | | | | | Always enable use of HW logical contexts to preserve GPU state between batches when the kernel supports such constructs, continuing to enforce the required support for gen6+. At runtime, this effectively removes the BRW_NEW_CONTEXT flag (and the upload of invariant state) from the start of every batch for any kernel supporting contexts. So long as the older atoms are correctly listening to the right flag (NEW_CONTEXT rather than NEW_BATCH) this should eliminate a few redundant state uploads for the older platforms. No piglits were harmed on ctg and ilk, both with and without logical contexts. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Push down the gl_vertex_array inputs into i965.Mathias Fröhlich2018-03-311-0/+1
| | | | | | | | | | Let the i965 backend have its own gl_vertex_array array and basically reimplement the way _vbo_draw works. Note that brw_draw_indirect_prims calls brw_draw_prims internally and gets its update to Array._DrawArray by this way. Reviewed-by: Brian Paul <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* i965: initialize SPIR-V capabilitiesAlejandro Piñeiro2018-03-301-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Needed for ARB_gl_spirv. Those are not the same that the Intel vulkan driver. From the ARB_spirv_extensions spec: "3. If a new GL extension is added that includes SPIR-V support via a new SPIR-V extension does it's SPIR-V extension also get enumerated by the SPIR_V_EXTENSIONS_ARB query?. RESOLVED. Yes. It's good to include it for consistency. Any SPIR-V functionality supported beyond the SPIR-V version that is required for the GL API version should be enumerated." So in addition to the core SPIR-V support, there is the possibility of specific GL extensions enabling specific SPIR-V extensions (so capabilities). That would mean that it is possible that OpenGL and Vulkan not having the same capabilities supported, even for the same driver. For this reason it is better to keep them separated. As an example: at the time of this patch writing Intel vulkan driver support multiview, but there isn't any OpenGL multiview GL extension supported. Note: we initialize SPIR-V capabilities at brwCreateContext instead of the usual brw_initialize_context_constants because we want to do that only if the extension is enabled. v2: * Rebase update (SpirVCapabilities not a pointer anymore) * Fill spirv capabilities for OpenGL >= 3.3 (Ian Romanick) v3: * Drop multiview support, as i965 doesn't support any multiview GL extension (Jason) * Fill spirv capabilities only if the extension is enabled (Jason) v4: Capabilities are supported only on gen7+. Added comment and assert (Jason)
* i965: Don't request GLSL IR lowering of gl_VertexIDIan Romanick2018-03-291-1/+0
| | | | | | | | | | | | | | | Let the lowering in NIR handle it instead. This hurts one shader that occurs twice in shader-db (SynMark GSCloth) on IVB and HSW. No other shaders or platforms were affected. total cycles in shared programs: 253438422 -> 253438426 (0.00%) cycles in affected programs: 412 -> 416 (0.97%) helped: 0 HURT: 2 Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Antia Puentes <[email protected]>
* i965: Generalize intel_upload.c to support multiple uploaders.Kenneth Graunke2018-03-021-0/+2
| | | | | | | | | | | | | I'd like to reuse the upload logic for a new program cache, but the buffers will need to have a different lifetime than the default uploader, and also some address space restrictions. So, we can't use a single uploader for both situations - we'll need two of them. This creates a public 'uploader' structure, and adjusts the interface to take an uploader rather than always using brw->upload. It should have no functional change at the moment. Reviewed-by: Chris Wilson <[email protected]>
* 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-281-3/+5
| | | | | | Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* i965: Implement GenerateMipmap directly, rather than using Meta.Kenneth Graunke2018-02-161-0/+2
| | | | | | | | | | | | | | | | | | 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/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: Call prepare_external after implicit window-system MSAA resolvesJason Ekstrand2018-02-011-0/+15
| | | | | | | | | This fixes some rendering corruption in a couple of Android apps that use window-system MSAA. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104741 Cc: [email protected] Reviewed-by: Tapani Pälli <[email protected]>
* i965: move disk cache from brw_context to intel_screenTapani Pälli2018-01-301-3/+1
| | | | | | | | | Now every context refers to same disk_cache instance in screen. Signed-off-by: Tapani Pälli <[email protected]> Suggested-by: Emil Velikov <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* i965: fix disk_cache leak when destroying contextTapani Pälli2018-01-291-0/+3
| | | | | | | | | | | | | | | | ==2780== 1,024 bytes in 1 blocks are possibly lost in loss record 180 of 205 ==2780== at 0x4C31A1E: calloc (vg_replace_malloc.c:711) ==2780== by 0x13F6467E: util_queue_init (u_queue.c:309) ==2780== by 0x13F5C9F6: disk_cache_create (disk_cache.c:369) ==2780== by 0x13F05406: brw_disk_cache_init (brw_disk_cache.c:428) ==2780== by 0x13F01E78: brwCreateContext (brw_context.c:1068) Fixes: 1a61a8b9a7c ("i965: Initialize disk shader cache if MESA_GLSL_CACHE_DISABLE is false") Signed-off-by: Tapani Pälli <[email protected]> Cc: [email protected] Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Reviewed-by: Jordan Justen <[email protected]>
* vbo: remove vbo_context.h and change includes to use vbo.h insteadBrian Paul2018-01-241-1/+1
| | | | | | Now vbo.h is the public interface to the VBO module. Reviewed-by: Roland Scheidegger <[email protected]>
* i965: Accept CONTEXT_ATTRIB_PRIORITY for brwCreateContextChris Wilson2018-01-221-1/+3
| | | | | | | | | | | | | | | | | The forward port of commit 6d87500fe12e ("dri: Change __DriverApiRec::CreateContext to take a struct for attribs") failed to adapt the set of allowed attributes for the earlier introduction of context priorities (commit 1617fca6d12e "i965: Pass the EGL/DRI context priority through to the kernel"). Fixes: 6d87500fe12e ("dri: Change __DriverApiRec::CreateContext to take a struct for attribs") Signed-off-by: Chris Wilson <[email protected]> Cc: Adam Jackson <[email protected]> Cc: Nicolai Hähnle <[email protected]> Cc: Emil Velikov <[email protected]> Cc: Kenneth Graunke <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Cc: [email protected]
* i965/miptree: Add an explicit tiling parameter to create_for_boJason Ekstrand2018-01-211-0/+4
| | | | | | | | Otherwise, create_for_bo will just grab the tiling from the BO which is not what we want when using modifiers. Reviewed-by: Kenneth Graunke <[email protected]> Cc: [email protected]
* Revert "i965: Enable flush control"Adam Jackson2018-01-151-19/+1
| | | | | | | This reverts commit 6ce9006d76c050663af0be61cc88c3215d6f8cea. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104490 Signed-off-by: Adam Jackson <[email protected]>
* glsl: remove Lower{TCS,TES}PatchVerticesInIago Toral Quiroga2018-01-101-2/+0
| | | | | | | | | | | | Intel was the only user and now NIR can do the lowering. v2: do not try to handle it as a system value directly for the SPIR-V path. In GL we rather handle it as a uniform like we do for the GLSL path (Jason). v3: drop LowerTESPatchVerticesIn as well (Jason) Reviewed-by: Jason Ekstrand <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 22:19:12 +0000