summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* travis: update libva required versionJuan A. Suarez Romero2018-04-251-1/+1
| | | | | | | | | Commit fa328456e8f29 added VP9 config support, but this needs a newer libva version, 1.7.0 or above. Fixes: fa328456e8f ("st/va: add VP9 config to enable profile2") CC: 18.1 <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* mesa: GL_EXT_texture_norm16 extension plumbingTapani Pälli2018-04-257-15/+84
| | | | | | | | | | | | | | | | | | | | | Patch enables use of short and unsigned short data for texture uploads, rendering and reading of framebuffers within the restrictions specified in GL_EXT_texture_norm16 spec. Patch also enables those 16bit format layout qualifiers listed in GL_NV_image_formats that depend on EXT_texture_norm16. v2: expose extension with dummy_true fix layout qualifier map changes (Ilia Mirkin) v3: use _mesa_has_EXT_texture_norm16, other fixes and cleanup (Ilia Mirkin) v4: fix rest of the issues found Signed-off-by: Tapani Pälli <[email protected]> Acked-by: Ilia Mirkin <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* meson: Fix with_intel_vk and with_amd_vk variablesJordan Justen2018-04-241-2/+2
| | | | | | | Fixes: 5608d0a2cee "meson: use array type options" Cc: Dylan Baker <[email protected]> Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Tapani Pälli <[email protected]>
* draw: fix different sign logic when clippingRoland Scheidegger2018-04-251-9/+8
| | | | | | | | | | | | | | | | | | | The logic was flawed, since mul(x,y) will be <= 0 (exactly 0) when the sign is the same but both numbers are sufficiently small (if the product is smaller than 2^-128). This could apparently lead to emitting a sufficient amount of additional bogus vertices to overflow the allocated array for them, hitting an assertion (still safe with release builds since we just aborted clipping after the assertion in this case - I'm however unsure if this is now really no longer possible, so that code stays). Not sure if the additional vertices could cause other grief, I didn't see anything wrong even when hitting the assertion. Essentially, both +-0 are treated as positive (the vertex is considered to be inside the clip volume for this plane), so integrate the logic determining different sign into the branch there. Reviewed-by: Jose Fonseca <[email protected]>
* draw: simplify clip null tri logicRoland Scheidegger2018-04-251-11/+9
| | | | | | | | | Simplifies the logic when to emit null tris (albeit the reasons why we have to do this remain unclear). This is strictly just logic simplification, the behavior doesn't change at all. Reviewed-by: Jose Fonseca <[email protected]>
* nvc0/ir: all short immediates are sign-extended, adjust LIMM testIlia Mirkin2018-04-243-19/+24
| | | | | | | | | | | | | | | | | | | | | | Some analysis suggests that all short immediates are sign-extended. The insnCanLoad logic already accounted for this, but we could still pick the wrong form when emitting actual instructions that support both short and long immediates (with the long form usually having additional restrictions that insnCanLoad should be aware of). This also reverses a bunch of commits that had previously "worked around" this issue in various emitters: 9c63224540ef: gm107/ir: make use of ADD32I for all immediates 83a4f28dc27b: gm107/ir: make use of LOP32I for all immediates b84c97587b4a: gm107/ir: make use of IMUL32I for all immediates d30768025a22: gk110/ir: make use of IMUL32I for all immediates as well as the original import for UMUL in the nvc0 emitter. Reported-by: Karol Herbst <[email protected]> Signed-off-by: Ilia Mirkin <[email protected]> Tested-by: Karol Herbst <[email protected]>
* 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: Fix no-rtti in llvm detectionDylan Baker2018-04-241-1/+1
| | | | | | | | | | Because I clearly wasn't thinking and clearly didn't do a good job testing. Sigh Fixes: c5a97d658ec19cc02719d7f86c1b0715e3d9ffc4 ("meson: fix builds against LLVM built without rtti") Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* meson: use new warning functionDylan Baker2018-04-241-1/+1
| | | | | | | Instead of emulating it with message. Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: use array type optionsDylan Baker2018-04-242-75/+88
| | | | | | | | | | This option type is nice since it involves less converting strings into lists, and because it validates the values that are provided. v2: - Set with_any_vk to true if any vulkan driver is built (Eric) Signed-off-by: Dylan Baker <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* meson: fix builds against LLVM built without rttiDylan Baker2018-04-241-0/+7
| | | | | | | | | | | Building without rtti is a frought with peril, but it's something that autotools supports so we need to support it too. Since we've moved to version 0.44 as a whole we can use the meson functionality for accessing random llvm-config options we can check for rtti and add -fno-rtti to all C++ code accordingly. Signed-off-by: Dylan Baker <[email protected]>
* meson: remove dummy_cppDylan Baker2018-04-244-11/+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-243-11/+2
| | | | | | | | | | | | 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-244-0/+9
| | | | | | | | | | 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-22 22:12:36 +0000