summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* mesa: call DrawBufferAllocate driver hook in update_framebuffer for ↵Boyan Ding2018-04-251-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | windows-system FB When draw buffers are changed on a bound framebuffer, DrawBufferAllocate() hook should be called. However, it is missing in update_framebuffer with window-system framebuffer, in which FB's draw buffer state should match context state, potentially resulting in a change. Note: This is needed because gallium delays creating the front buffer, i965 works fine without this change. V2 (Timothy Arceri): - Rebased on merged/simplified DrawBuffer driver function - Move DrawBuffer call outside fb->ColorDrawBuffer[0] != ctx->Color.DrawBuffer[0] check to make piglit pass. v3 (Timothy Arceri): - Call new DrawBuffaerAllocate() driver function. Tested-by: Dieter Nützel <[email protected]> (v2) Reviewed-by: Brian Paul <[email protected]> (v2) Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99116
* st/mesa: add new driver function DrawBufferAllocateTimothy Arceri2018-04-253-7/+11
| | | | | | | | | Unlike some of the classic drivers the st was only using DrawBuffer() to allocated some buffers on-demand. Creating a separate function will allow us to call it from update_framebuffer() in the following patch without regressing some of the older classic drivers. Reviewed-by: Marek Olšák <[email protected]>
* mesa: some C99 tidy ups for framebuffer.cTimothy Arceri2018-04-251-13/+5
| | | | | Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* meson: remove dummy_cppDylan Baker2018-04-243-3/+3
| | | | | | | | | | meson has gotten pretty smart about tracking C and C++ dependencies (internal and external), and using the right linker. This wasn't always the case and we created empty c++ files to force the use of the c++ linker. We don't need that any more. Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: allow empty sources when using link_wholeDylan Baker2018-04-241-8/+1
| | | | | | | | | meson used to get grumpy if the sources list was empty, even when using --whole-archive (link_whole). In more recent versions that's not true, so remove the workaround. Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: remove workaround for custom target creating .h and .c filesDylan Baker2018-04-241-13/+4
| | | | | | | | | In more modern versions of meson a custom_target returns an index-able object. This allows us to create accurate dependency models for targets that rely only on the header and not on the code from anv_entrypoints. Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: raise required version to 0.44.1Dylan Baker2018-04-241-6/+0
| | | | | | | | | | | | We have already required 0.44 for building clover and swr, so it was already partially required. This just makes it required across the board instead of just for clover and swr. There is a bug in 0.44 which makes it impossible to build mesa in some configurations, so require 0.44.1 which fixes this. Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: fix graw-xlib after auxiliary consolidationDylan Baker2018-04-241-2/+1
| | | | | | | | | | This one's completely my fault, I didn't do good enough testing after rebasing and this got missed. Fixes: d28c24650110c130008be3d3fe584520ff00ceb1 ("meson: build graw tests") Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: only build mesa_st tests when build-tests is trueDylan Baker2018-04-241-1/+3
| | | | | | | | | | Since we have an option to turn test building on and off, we should honor that. Fixes: 34cb4d0ebc14663113705beae63dd52b9d1b2d87 ("meson: build tests for gallium mesa state tracker") Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: don't build classic mesa tests without dri_driversDylan Baker2018-04-241-1/+1
| | | | | | | | | | Since mesa_classic is build-on-demand the tests will create a demand and add a bunch of extra compilation. Fixes: 43a6e84927e3b1290f6f211f5dfb184dfe5a719e ("meson: build mesa test.") Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965/meta_util: Re-enable sRGB-encoded fast-clears on CNLNanley Chery2018-04-241-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | The paths which sample with the clear color are now using a getter which performs the sRGB decode needed to enable this fast clear. This path can be exercised by fast-clearing a texture, then performing an operation which requires sRGB decoding. Test coverage for this feature is provided with the following tests: * Shader texture calls: - spec@ext_texture_srgb@tex-srgb * Shader texelfetch calls: - spec@arb_framebuffer_srgb@fbo-fast-clear - spec@arb_framebuffer_srgb@msaa-fast-clear * Blending: - spec@arb_framebuffer_srgb@arb_framebuffer_srgb-fast-clear-blend * Blitting: - spec@arb_framebuffer_srgb@blit texture srgb msaa enabled clear Reviewed-by: Jason Ekstrand <[email protected]>
* i965/miptree: Extend the sRGB-blending WA to future platformsNanley Chery2018-04-241-2/+2
| | | | | | The blending issue seems to be present on CNL as well. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Add and use a getter for the clear colorNanley Chery2018-04-244-11/+51
| | | | | | | | | | | | | | | It returns both the inline clear color and a clear address which points to the indirect clear color buffer (or NULL if unused/non-existent). This getter allows CNL to sample from fast-cleared sRGB textures correctly by doing the needed sRGB-decode on the clear color (inline) and making the indirect clear color buffer unused. v2 (Rafael): * Have a more detailed commit message. * Add a comment on the sRGB conversion process. Reviewed-by: Rafael Antognolli <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* util/srgb: Add a float sRGB -> linear helperJason Ekstrand2018-04-241-0/+14
| | | | | Reviewed-by: Nanley Chery <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965/wm_surface_state: Use the clear address if clear_bo is non-NULLNanley Chery2018-04-241-11/+6
| | | | | | | | | | We want to add and use a getter that turns off the indirect path by returning zero for the clear color bo and offset. v2: Fix usage of "clear address" in commit message (Jason). Reviewed-by: Rafael Antognolli <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Add and use a single miptree aux_buf fieldNanley Chery2018-04-2410-114/+96
| | | | | | | | | | | | | We want to add and use a function that accesses the auxiliary buffer's clear_color_bo and doesn't care if it has an MCS or HiZ buffer specifically. v2 (Jason Ekstrand): * Drop intel_miptree_get_aux_buffer(). * Mention CCS in the aux_buf field. Reviewed-by: Rafael Antognolli <[email protected]> (v1) Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Add and use a getter for the miptree aux bufferNanley Chery2018-04-244-41/+25
| | | | | | | | | Make the next patch easier to read by eliminating most of the would-be duplicate field accesses now. v2: Update the HiZ comment instead of deleting it (Rafael). Reviewed-by: Rafael Antognolli <[email protected]>
* gm107/ir/lib: fix sched in div u32 builtinKarol Herbst2018-04-242-4/+4
| | | | | | | | | | Imad needs to set a read barrier. With significant big work groups I was getting wrong results for div u32. Turns out the issue was with the sched opcodes. Signed-off-by: Karol Herbst <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* intel/compiler: Add scheduler deps for instructions that implicitly read g0Ian Romanick2018-04-242-0/+28
| | | | | | | | | | | | | Otherwise the scheduler can move the writes after the reads. Signed-off-by: Ian Romanick <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95009 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95012 Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Tested-by: Mark Janes <[email protected]> Cc: Clayton A Craft <[email protected]> Cc: [email protected]
* intel/compiler: Silence unused parameter warnings in empty ↵Ian Romanick2018-04-241-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | vec4_instruction_scheduler methods src/intel/compiler/brw_schedule_instructions.cpp: In member function ‘virtual void vec4_instruction_scheduler::count_reads_remaining(backend_instruction*)’: src/intel/compiler/brw_schedule_instructions.cpp:764:72: warning: unused parameter ‘be’ [-Wunused-parameter] vec4_instruction_scheduler::count_reads_remaining(backend_instruction *be) ^~ src/intel/compiler/brw_schedule_instructions.cpp: In member function ‘virtual void vec4_instruction_scheduler::setup_liveness(cfg_t*)’: src/intel/compiler/brw_schedule_instructions.cpp:769:51: warning: unused parameter ‘cfg’ [-Wunused-parameter] vec4_instruction_scheduler::setup_liveness(cfg_t *cfg) ^~~ src/intel/compiler/brw_schedule_instructions.cpp: In member function ‘virtual void vec4_instruction_scheduler::update_register_pressure(backend_instruction*)’: src/intel/compiler/brw_schedule_instructions.cpp:774:75: warning: unused parameter ‘be’ [-Wunused-parameter] vec4_instruction_scheduler::update_register_pressure(backend_instruction *be) ^~ src/intel/compiler/brw_schedule_instructions.cpp: In member function ‘virtual int vec4_instruction_scheduler::get_register_pressure_benefit(backend_instruction*)’: src/intel/compiler/brw_schedule_instructions.cpp:779:80: warning: unused parameter ‘be’ [-Wunused-parameter] vec4_instruction_scheduler::get_register_pressure_benefit(backend_instruction *be) ^~ src/intel/compiler/brw_schedule_instructions.cpp: In member function ‘virtual int vec4_instruction_scheduler::issue_time(backend_instruction*)’: src/intel/compiler/brw_schedule_instructions.cpp:1550:61: warning: unused parameter ‘inst’ [-Wunused-parameter] vec4_instruction_scheduler::issue_time(backend_instruction *inst) ^~~~ Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: Silence unused parameter warning in compile_cs_to_nirIan Romanick2018-04-241-4/+3
| | | | | | | | | | src/intel/compiler/brw_fs.cpp: In function ‘nir_shader* compile_cs_to_nir(const brw_compiler*, void*, const brw_cs_prog_key*, brw_cs_prog_data*, const nir_shader*, unsigned int)’: src/intel/compiler/brw_fs.cpp:7205:44: warning: unused parameter ‘prog_data’ [-Wunused-parameter] struct brw_cs_prog_data *prog_data, ^~~~~~~~~ Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel/compiler: Silence unused parameter warnings in generate_foo methodsIan Romanick2018-04-242-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since all of the fs_generator::generate_foo methods take a fs_inst * as the first parameter, just remove the name to quiet the compiler. src/intel/compiler/brw_fs_generator.cpp: In member function ‘void fs_generator::generate_barrier(fs_inst*, brw_reg)’: src/intel/compiler/brw_fs_generator.cpp:743:41: warning: unused parameter ‘inst’ [-Wunused-parameter] fs_generator::generate_barrier(fs_inst *inst, struct brw_reg src) ^~~~ src/intel/compiler/brw_fs_generator.cpp: In member function ‘void fs_generator::generate_discard_jump(fs_inst*)’: src/intel/compiler/brw_fs_generator.cpp:1326:46: warning: unused parameter ‘inst’ [-Wunused-parameter] fs_generator::generate_discard_jump(fs_inst *inst) ^~~~ src/intel/compiler/brw_fs_generator.cpp: In member function ‘void fs_generator::generate_pack_half_2x16_split(fs_inst*, brw_reg, brw_reg, brw_reg)’: src/intel/compiler/brw_fs_generator.cpp:1675:54: warning: unused parameter ‘inst’ [-Wunused-parameter] fs_generator::generate_pack_half_2x16_split(fs_inst *inst, ^~~~ src/intel/compiler/brw_fs_generator.cpp: In member function ‘void fs_generator::generate_shader_time_add(fs_inst*, brw_reg, brw_reg, brw_reg)’: src/intel/compiler/brw_fs_generator.cpp:1743:49: warning: unused parameter ‘inst’ [-Wunused-parameter] fs_generator::generate_shader_time_add(fs_inst *inst, ^~~~ src/intel/compiler/brw_vec4_generator.cpp: In function ‘void generate_set_simd4x2_header_gen9(brw_codegen*, brw::vec4_instruction*, brw_reg)’: src/intel/compiler/brw_vec4_generator.cpp:1412:52: warning: unused parameter ‘inst’ [-Wunused-parameter] vec4_instruction *inst, ^~~~ src/intel/compiler/brw_vec4_generator.cpp: In function ‘void generate_mov_indirect(brw_codegen*, brw::vec4_instruction*, brw_reg, brw_reg, brw_reg, brw_reg)’: src/intel/compiler/brw_vec4_generator.cpp:1430:41: warning: unused parameter ‘inst’ [-Wunused-parameter] vec4_instruction *inst, ^~~~ src/intel/compiler/brw_vec4_generator.cpp:1432:63: warning: unused parameter ‘length’ [-Wunused-parameter] struct brw_reg indirect, struct brw_reg length) ^~~~~~ Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* broadcom/vc5: Set up internal_format for imported resources.Eric Anholt2018-04-241-0/+2
| | | | | Without this, we'd assertion fail in u_transfer_helper when mapping an imported resource.
* broadcom/vc5: Assert that created BOs have offset != 0.Eric Anholt2018-04-241-0/+1
| | | | | The kernel shouldn't return a bo at NULL, and the HW special-cases NULL address values for things like OQs.
* broadcom/vc5: Don't allocate simulator BOs at offset 0.Eric Anholt2018-04-241-1/+5
| | | | | The kernel won't return us BOs at offset 0 (because things like OQs wouldn't work there), so we shouldn't in the simulator either.
* broadcom/vc5: Add sim support for the GET_BO_OFFSET ioctl.Eric Anholt2018-04-242-6/+21
| | | | | Otherwise we'd crash immediately upon importing a BO through EGL interfaces.
* broadcom/vc5: Treat imports of DRM_FORMAT_MOD_INVALID BOs as linear.Eric Anholt2018-04-241-0/+1
| | | | | We don't have any kernel metadata about BO tiling, so this probably is all we should do for the moment.
* i965: expose MESA_FORMAT_R8G8B8A8_SRGB visualTapani Pälli2018-04-241-3/+7
| | | | | | | | | | | | Exposing the visual makes following dEQP tests pass on Android: dEQP-EGL.functional.wide_color.window_8888_colorspace_srgb dEQP-EGL.functional.wide_color.pbuffer_8888_colorspace_srgb Visual is exposed only when DRI_LOADER_CAP_RGBA_ORDERING is set. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* dri: Add __DRI_IMAGE_FORMAT_SABGR8Tapani Pälli2018-04-243-0/+7
| | | | | | | | | | Add format definition and required plumbing to create images. Note that there is no match to drm_fourcc definition, just like with existing _DRI_IMAGE_FOURCC_SARGB8888. Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* Revert "st/dri: Fix dangling pointer to a destroyed dri_drawable"Marek Olšák2018-04-241-4/+0
| | | | | | | | | | This reverts commit dab02dea3411d325a5aee6cda5b581e61396ecc6. It causes crashes of qtcreator and firefox. Fixes: dab02de "st/dri: Fix dangling pointer to a destroyed dri_drawable" Cc: 18.0 18.1 <[email protected]>
* gallivm: dump bitcode before optimizationRoland Scheidegger2018-04-241-13/+20
| | | | | | | | | | | | | | | | | | If we dump the bitcode for off-line debug purposes, we really want the pre-optimized bitcode, otherwise it's useless in identifying problems with IR optimization (if you have a shader which takes an hour to do IR optimization, it's also nice you don't have to wait that hour...). Also, print out the function passes for opt which correspond to what was used for jit compilation (and also the opt level for codegen). Using opt/llc this way should then pretty much mimic what was done for jit. (When specifying something like -time-passes -debug-pass=[Structure|Arguments] (for either opt or llc) that also gives very useful information in which passes all the time was spent, and which passes are really run along with the order - llvm will add passes due to dependencies on its own, and of course -O2 for llc comes with a ~100 pass list.) Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: (trivial) do division by 1000 with int64Roland Scheidegger2018-04-241-1/+1
| | | | | | | Conversion to int can otherwise overflow if compile times are over ~71min. (Yes this can happen...) Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: remove LICM passRoland Scheidegger2018-04-241-1/+9
| | | | | | | | | | | | | | LICM is simply too expensive, even though it presumably can help quite a bit in some cases. It was definitely cheaper in llvm 3.3, though as far as I can tell with llvm 3.3 it failed to do anything in most cases. early-cse also actually seems to cause licm to be able to move things when it previously couldn't, which causes noticeable compile time increases. There's more loop passes in llvm, but I'm not sure which ones are helpful, and I couldn't find anything which would roughly do what the old licm in llvm 3.3 did, so ditch it. Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: add early cse passRoland Scheidegger2018-04-241-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This pass is quite cheap, and can simplify the IR quite a bit for our generated IR. In particular on a variety of shaders I've found the time saved by other passes due to the simplified IR more than makes up for the cost of this pass, and on top of that the end result is actually better. The only downside I've found is this enables the LICM pass to move some things out of the main shader loop (in the case I've seen, instanced vertex fetch (which is constant within the jit shader) plus the derived instructions in the shader) which it couldn't do before for some reason. This would actually be desirable but can increase compile time considerably (licm seems to have considerable cost when it actually can move things out of loops, due to alias analysis). But blaming early cse for this seems inappropriate. (Note that the first two sroa / earlycse passes are similar to what a standard llvm opt -O1/-O2 pipeline would do, albeit this has some more passes even before but I don't think they'd do much for us.) It also in particular helps some crazy shader used for driver verification (don't ask...) a lot (about factor of 6 faster in compile time) (due to simplfiying the ir before LICM is run). While here, also move licm behind simplifycfg. For some shaders there seems to be very significant compile time gains (we've seen a factor of 10000 albeit that was a really crazy shader you'd certainly never see in a real app), beause LICM is quite expensive and there's cases where running simplifycfg (along with sroa and early-cse) before licm reduces IR complexity significantly. (I'm not entirely sure if it would make sense to also run it afterwards.) Reviewed-by: Jose Fonseca <[email protected]>
* glsl/glcpp: Handle hex constants with 0X prefixVlad Golovkin2018-04-243-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GLSL 4.6 spec describes hex constant as: hexadecimal-constant: 0x hexadecimal-digit 0X hexadecimal-digit hexadecimal-constant hexadecimal-digit Right now if you have a shader with the following structure: #if 0X1 // or any hex number with the 0X prefix // some code #endif the code between #if and #endif gets removed because the checking is performed only for "0x" prefix which results in strtoll being called with the base 8 and after encountering the 'X' char the strtoll returns 0. Letting strtoll detect the base makes this limitation go away and also makes code easier to read. From the strtoll Linux man page: "If base is zero or 16, the string may then include a "0x" prefix, and the number will be read in base 16; otherwise, a zero base is taken as 10 (decimal) unless the next character is '0', in which case it is taken as 8 (octal)." This matches the behaviour in the GLSL spec. This patch also adds a test for uppercase hex prefix. Reviewed-by: Timothy Arceri <[email protected]>
* mesa: rename api_validate.{c,h} -> draw_validate.{c,h}Timothy Arceri2018-04-249-10/+10
| | | | | Reviewed-by: Mathias Fröhlich <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65422
* ac/radv/radeonsi: refactor harvest config register getters.Dave Airlie2018-04-244-206/+130
| | | | | | | | This refactors the code out to share it between radv and radeonsi. Reviewed-by: Bas Nieuwenhuizen <[email protected]> Acked-by: Nicolai Hähnle <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* radv: only set raster_config_1 outside the index registers.Dave Airlie2018-04-241-15/+16
| | | | | | | | | | This follows what radeonsi does. Ported from radeonsi: radeonsi: emit PA_SC_RASTER_CONFIG_1 only once Reviewed-by: Bas Nieuwenhuizen <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]>
* ac/radv/radeonsi: refactor max simd waves into common code.Dave Airlie2018-04-243-22/+18
| | | | | Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* ac/radv/radeonsi: refactor raster_config default values getters.Dave Airlie2018-04-244-165/+102
| | | | | | | This just makes this common code between the two drivers. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radeonsi: use common gs_table_depth codeDave Airlie2018-04-241-31/+2
| | | | | Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radv: use common gs_table_depth code.Dave Airlie2018-04-241-30/+2
| | | | Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* ac/info: move gs table depth to common code.Dave Airlie2018-04-242-0/+34
| | | | | Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radeonsi: don't runtime check gs table infoDave Airlie2018-04-241-7/+7
| | | | | | | | We can just unreachable here, this aligns with radv code, makes it easier to move to common code. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Bas Nieuwenhuizen <[email protected]>
* radv/gfx9: don't use gs_table_depth on gfx9.Dave Airlie2018-04-242-5/+6
| | | | | | | | Missed this on initial radeonsi port, we shouldn't use this value on gfx9, but also in gfx8 only for when we have a geom shader. Reviewed-by: Bas Nieuwenhuizen <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* i965/fs: Return mlen * 8 for size_read() for INTERPOLATE_AT_*Jason Ekstrand2018-04-231-0/+2
| | | | | | | | | They are send messages and this makes size_read() and mlen agree. For both of these opcodes, the payload is just a dummy so mlen == 1 and this should decrease register pressure a bit. Reviewed-by: Francisco Jerez <[email protected]> Cc: [email protected]
* ac: fix the number of coordinates for ac_image_get_lod and arraysSamuel Pitoiset2018-04-231-0/+14
| | | | | | | | | | | | | This fixes crashes for the following CTS: dEQP-VK.glsl.texture_functions.query.texturequerylod.* Cubemaps are the same as 2D arrays. Fixes: 625dcbbc456 ("amd/common: pass address components individually to ac_build_image_intrinsic") Cc: 18.1 <[email protected]> Signed-off-by: Samuel Pitoiset <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* i965: perf: enable GPA query statisticsLionel Landwerlin2018-04-233-1/+68
| | | | | | | | | | | | The combinaison of GPA/MDAPI components expects a particular name & layout for their pipeline statistics query. v2: Limit the query GPA/MDAPI statistics to gen7->9 (Lionel) v3: Add curly braces (Ken) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: perf: add support for raw queriesLionel Landwerlin2018-04-236-27/+474
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The INTEL_performance_query extension provides a list of queries that a user can select to monitor a particular workload. Each query reports different sets of counters (roughly looking at different parts of the hardware, i.e. caches/fixed functions/etc...). Each query has an associated configuration that we need to program into the hardware before using the query. Up to now, we provided predefined queries. This change allows the user to build its own query (and associated configuration) externally, and have the i965 driver use that configuration through a new query named : Intel_Raw_Hardware_Counters_Set_0_Query When this query is selected, the i965 driver will report raw counters deltas (meaning their values need to be interpreted by the user, as opposed to existing queries that provide human readable values). This change is also useful for debug purposes for building new pre-defined queries and verifying the underlying numbers make sense before writing equations for user readable output. This change's purpose is also to enable GPA. GPA uses a library called MDAPI that processes raw counter data. MDAPI expects raw data to have a certain layout (per generation which is a bit unfortunate...). This change also embeds the expected data layouts. v2: Enable raw queries on gen 7->11, v1 had 7->9 (Lionel) v3: Don't assert on cherryview for gen7... (Ken) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: perf: read slice/unslice frequencies from OA reportsLionel Landwerlin2018-04-232-0/+71
| | | | | | | | | | v2: Add comment breaking down where the frequency values come from (Ken) v3: More documentation (Ken/Lionel) Adjust clock ratio multiplier to reflect the divider's behavior (Lionel) Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-24 16:06:02 +0000