aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i915
Commit message (Collapse)AuthorAgeFilesLines
* i915: On Gen <= 3 there are no array texturesIan Romanick2017-06-264-17/+0
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]>
* i915: On Gen <= 3 there is no W-tilingIan Romanick2017-06-264-29/+9
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]>
* i915: Remove unused fields intel_mipmap_tree::logical_(width|height|depth)0Ian Romanick2017-06-262-11/+0
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]>
* i915: Remove unused field intel_mipmap_tree::array_spacing_lod0Ian Romanick2017-06-261-9/+0
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]>
* i915: On Gen <= 3 there is no multisamplingIan Romanick2017-06-263-38/+9
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]>
* i915: Trivial code reformattingIan Romanick2017-06-261-56/+54
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]>
* i915,i965: Don't condition use of GLSL clear on the current APIIan Romanick2017-06-261-1/+1
| | | | | | | | | | | | | | Meta always sets the API to API_OPENGL_COMPAT, so the current API setting is irrelevant. text data bss dec hex filename 7154994 256860 37332 7449186 71aa62 32-bit i965_dri.so before 7154978 256860 37332 7449170 71aa52 32-bit i965_dri.so after 6788451 328056 50704 7167211 6d5ceb 64-bit i965_dri.so before 6788419 328056 50704 7167179 6d5ccb 64-bit i965_dri.so after Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]>
* i915: Fix gl_Fragcoord interpolationVille Syrjälä2017-06-225-16/+21
| | | | | | | | | | | | | | | | gl_FragCoord contains the window coordinates so it seems to me that we should not use perspective correct interpolation for it. At least now I get similar output as i965/swrast/llvmpipe produce. This fixes dEQP-GLES2.functional.shaders.builtin_variable.fragcoord_w. dEQP-GLES2.functional.shaders.builtin_variable.fragcoord_xyz was already passing, though I'm not quite sure how it managed to do that. v2: Add definitons for the S3 "wrap shortest" bits as well (Ian) Cc: [email protected] Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]>
* mesa: replace VP/FP/ATIfs _Enabled flags with helper functionsMarek Olšák2017-06-222-2/+2
| | | | | | | | These are only used in the GL compatibility profile. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: don't update draw buffer bounds in _mesa_update_stateMarek Olšák2017-06-222-0/+7
| | | | | | | | | | | | | | | | st/mesa doesn't need the draw bounds for draw calls. I've added the call where it's necessary in core Mesa and drivers, but I suspect that most drivers can just move the call to the right places. The core Mesa places aren't hot paths, so the call overhead doesn't matter there. For now, only st/mesa is made such that this function is invoked very rarely. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: replace ctx->Polygon._FrontBit with a helper functionMarek Olšák2017-06-221-0/+1
| | | | | | Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* mesa: replace _mesa_update_stencil() with helper functionsMarek Olšák2017-06-223-3/+5
| | | | | | | | | | | | | The idea is to remove the dependency on _mesa_update_state_locked, so that st/mesa can skip it for stencil state updates, and then stop setting _NEW_STENCIL in mesa/main if the driver is st/mesa. The main motivation is to stop invoking _mesa_update_state_locked for certain state groups. Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i915: Always emit W on gen3Ville Syrjälä2017-06-211-6/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Unlike the older gen2 hardware, gen3 performs perspective correct interpolation even for the primary/secondary colors. To do that it naturally needs us to emit W for the vertices. Currently we emit W only when at least one texture coordinate set gets emitted. This means the interpolation of color will change depending on whether texcoords/varyings are used or not. That's probably not what anyone would expect, so let's just always emit W to get consistent behaviour. Trying to avoid emitting W seems like more hassle than it's worth, especially as bspec seems to suggest that the hardware will perform the perspective division anyway. This used to be broken until it was accidentally fixed it in commit c349031c27b7 ("i915: Fix texcoord vs. varying collision in fragment programs") by introducing a bug that made the driver always emit W. After fixing that bug in commit c1eedb43f32f ("i915: Fix wpos_tex vs. -1 comparison") we went back to the old behaviour and caused an apparent regression. Fixes: c1eedb43f32f ("i915: Fix wpos_tex vs. -1 comparison") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101451 Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915: Fix wpos_tex vs. -1 comparisonVille Syrjälä2017-06-143-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | wpos_tex used to be a GLuint so assigning -1 to it and later comparing with -1 worked correctly, but commit c349031c27b7 ("i915: Fix texcoord vs. varying collision in fragment programs") changed wpos_tex to uint8_t and hence broke the comparison. To fix this define a more explicit invalid value for wpos_tex. gcc warns us: i915_fragprog.c:1255:57: warning: comparison is always true due to limited range of data type [-Wtype-limits] if (inputsRead & VARYING_BITS_TEX_ANY || p->wpos_tex != -1) { ^ And clang says: i915_fragprog.c:1255:57: warning: comparison of constant -1 with expression of type 'uint8_t' (aka 'unsigned char') is always true [-Wtautological-constant-out-of-range-compare] if (inputsRead & VARYING_BITS_TEX_ANY || p->wpos_tex != -1) { ~~~~~~~~~~~ ^ ~~ Cc: Chih-Wei Huang <[email protected]> Cc: Eric Anholt <[email protected]> Cc: Ian Romanick <[email protected]> Cc: [email protected] Fixes: c349031c27b7 ("i915: Fix texcoord vs. varying collision in fragment programs") Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* mesa: inline vbo_exec_invalidate_state() and call from mesa coreTimothy Arceri2017-06-092-2/+0
| | | | | | | | Rather than calling it indirectly in each driver. Reviewed-by: Samuel Pitoiset <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: stop passing state bitfield to UpdateState()Timothy Arceri2017-06-092-2/+5
| | | | | | | | | | | | | | | | | | The code comment which seems to have been added in cab974cf6c2db (from year 2000) says: "Set ctx->NewState to zero to avoid recursion if Driver.UpdateState() has to call FLUSH_VERTICES(). (fixed?)" As far as I can tell nothing in any of the UpdateState() calls should cause it to be called recursively. V2: add a wrapper around the osmesa update function so it can still be used internally. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Samuel Pitoiset <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* mesa: rename _mesa_add_renderbuffer* functionsTimothy Arceri2017-04-181-6/+5
| | | | | | | These names make it easier to understand what is going on in regards to references. Reviewed-by: Brian Paul <[email protected]>
* i915: take ownership rather than adding reference for new renderbuffersTimothy Arceri2017-04-101-4/+5
| | | | | | | | | This avoids locking in the reference calls and fixes a leak after the RefCount initialisation was change from 0 to 1. Fixes: 32141e53d1520 (mesa: tidy up renderbuffer RefCount initialisation) Reviewed-by: Emil Velikov <[email protected]>
* i915: remove BindProgramMarek Olšák2017-03-291-25/+0
| | | | | | | | | The same thing is done in i915_update_program called by i915InvalidateState. Why do it twice. Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Timothy Arceri <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* Android: drop Android 4.4 (KitKat) supportRob Herring2017-03-221-5/+0
| | | | | | | | | | | Any users of KitKat are likely using an older version of Mesa and KitKat support adds complexity to the make files. Dropping support allows removing the MESA_LOLLIPOP_BUILD make variable in various make files. Signed-off-by: Rob Herring <[email protected]> Reviewed-by: Tapani Pälli <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* i915: remove extern "C" guardsEmil Velikov2017-02-215-40/+0
| | | | | | | None of this code is used in C++ context. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i915: remove 'virtual' and extern C workaroundsEmil Velikov2017-02-211-9/+4
| | | | | | | Analogous to previous commit. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* Revert "i915: Always enable GL 2.0 support."Matt Turner2017-02-152-4/+25
| | | | | | | | | | This partially reverts commit 97217a40f97cdeae0304798b607f704deb0c3558. It leaves ES 2.0 support in place per Ian's suggestion, because ES 2.0 is designed to work on hardware like i915. Chrome only uses the GPU if you have GL >= 2.0, and using i915 (and prog_execute) actually hurt performance compared with the software paths.
* i915, i965: automake: remove NA include directiveEmil Velikov2017-01-271-1/+0
| | | | | | The path in question (... dri/intel/server) was removed years ago. Signed-off-by: Emil Velikov <[email protected]>
* i915: automake: include builddir prior to srcdirEmil Velikov2017-01-271-1/+1
| | | | | | | Analogous to previous commit. Cc: "12.0 13.0" <[email protected]> Signed-off-by: Emil Velikov <[email protected]>
* i915: Add XRGB8888 format to intel_screen_make_configsDerek Foreman2017-01-131-1/+2
| | | | | | | | | | | | | | | | | | This is a copy of commit 536003c11e4cb1172c540932ce3cce06f03bf44e except for i915. Original log for the i965 commit follows: Some application, such as drm backend of weston, uses XRGB8888 config as default. i965 doesn't provide this format, but before commit 65c8965d, the drm platform of EGL takes ARGB8888 as XRGB8888. Now that commit 65c8965d makes EGL recognize format correctly so weston won't start because it can't find XRGB8888. Add XRGB8888 format to i965 just as other drivers do. Signed-off-by: Derek Foreman <[email protected]> Acked-by: Boyan Ding <[email protected]> Tested-by: Mark Janes <[email protected]>
* st/mesa/glsl: add new is_arb_asm flag in gl_programTimothy Arceri2017-01-061-4/+6
| | | | | | | | | | | | | | | | Set the flag via the _mesa_init_gl_program() and NewProgram() helpers. In i965 we currently check for the existance of gl_shader_program to decide if this is an ARB assembly style program or not. Adding a flag makes the code clearer and will help removes a dependency on gl_shader_program in the i965 codegen functions. Also this will allow use to skip initialising sampler units for linked shaders, we currently memset it to zero again during linking. Reviewed-by: Eric Anholt <[email protected]>
* i915: remove unneeded #include "util/simple_list.h"Brian Paul2016-11-202-2/+0
| | | | | | Compile tested only. Reviewed-by: Vinson Lee <[email protected]>
* st/mesa/r200/i915/i965: move ARB program fields into a unionTimothy Arceri2016-11-172-14/+14
| | | | | | | | | | | It's common for games to compile 2000 programs or more so at 32bits x 2000 programs x 22 fields x 2 (at least) stages This should give us something like 352 kilobytes in savings once we add some more glsl only fields. Reviewed-by: Emil Velikov <[email protected]>
* st/mesa/r200/i915/i965: use rzalloc() to create gl_programTimothy Arceri2016-11-031-2/+2
| | | | | | | | | | | | | | | | | This allows us to use ralloc_parent() to see which data structure owns shader_info which allows us to fix a regression in nir_sweep(). This will also allow us to move some fields from gl_linked_shader to gl_program, which will allow us to do some clean-ups like storing gl_program directly in the CurrentProgram array in gl_pipeline_object enabling some small validation optimisations at draw time. Also it is error prone to depend on the gl_linked_shader for programs in current use because a failed linking attempt will free infomation about the current program. In i965 we could be trying to recompile a shader variant but may have lost some required fields. Reviewed-by: Eric Anholt <[email protected]>
* r200/i915/st/mesa/compiler: use common inputs read fieldTimothy Arceri2016-10-263-6/+6
| | | | | | | | | | | | And set set inputs_read directly in shader_info. To avoid regressions between changes this change is a squashed version of the following patches. st/mesa changes where: Reviewed-by: Marek Olšák <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* st/mesa/r200/i915/i965: eliminate gl_fragment_programTimothy Arceri2016-10-265-32/+32
| | | | | | | | | | Here we move OriginUpperLeft and PixelCenterInteger into gl_program all other fields have been replace by shader_info. V2: Don't use anonymous union/structs to hold vertex/fragment fields suggested by Ian. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa/i965/i915/r200: eliminate gl_vertex_programTimothy Arceri2016-10-261-2/+2
| | | | | | | Here we move the only field in gl_vertex_program to the ARB program fields in gl_program. Reviewed-by: Jason Ekstrand <[email protected]>
* mesa: remove gl_shader_compiler_options::EmitNoNoiseMarek Olšák2016-10-191-1/+0
| | | | | | | it's always true Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]>
* i915: workaround multiple intelFenceExtension definitionsEmil Velikov2016-10-141-0/+1
| | | | | | | | | | | | | Due to conflicting symbol names (between i915 and i965) in the megadriver, we use a set of defines in i915/intel_screen.h. With a recent commit we've introduced a symbol intelFenceExtension which has different implementation for each driver, yet we forgot to add the define. Fixes: d11515ff1b3 ("i915/sync: Implement DRI2_Fence extension") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98264 Signed-off-by: Emil Velikov <[email protected]>
* i915: store reference to the context within struct intel_fence (v2)Mauro Rossi2016-10-141-11/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Porting of the corresponding patch for i965. Here follows the original commit message by Tomasz Figa: "As the spec allows for {server,client}_wait_sync to be called without currently bound context, while our implementation requires context pointer. v2: Add a mutex and acquire it for the duration of brw_fence_client_wait() and brw_fence_is_completed() as suggested by Chad." NOTE: in i915 all references to 'brw' are replaced by 'intel' Marshmallow-x86 boots ok with the following results of Android CTS. Android CTS 6.0_r7 build:2906653 Session Pass Fail Not Executed 0(EGL) 1410 24 0 1(GLES2) 13832 82 0 I get the same results as per i965GM. [Emil Velikov: Include Mauro's test results] Signed-off-by: Emil Velikov <[email protected]>
* i915/sync: Implement DRI2_Fence extensionMauro Rossi2016-10-143-30/+152
| | | | | | | | | | | Here is the porting of corresponding patch for i965, i.e. commit c636284 i965/sync: Implement DRI2_Fence extension Here follows part of original commit message by Chad Versace: "This enables EGL_KHR_fence_sync and EGL_KHR_wait_sync." Signed-off-by: Emil Velikov <[email protected]>
* i915/sync: Replace prefix 'intel_sync' -> 'intel_gl_sync'Mauro Rossi2016-10-142-26/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | This is the porting of corresponding patch for i965, i.e. commit 2516d83 i965/sync: Replace prefix 'intel_sync' -> 'intel_gl_sync' The only difference compared to i965 one is that intel_check_sync() was renamed to intel_gl_check_sync() here, as it is more appropriate. Here follows original commit message by Chad Versace: "I'm about to implement DRI2_Fenc in intel_syncobj.c. To prevent madness, we need to prefix functions for GL_ARB_sync with 'gl' and functions for DRI2_Fence with 'dri'. Otherwise, the file will become a jumble of similiarly named functions. For example: old-name: intel_client_wait_sync() new-name: intel_gl_client_wait_sync() soon-to-come: intel_dri_client_wait_sync() I wrote this renaming commit separately from the commit that implements DRI2_Fence because I wanted the latter diff to be reviewable." [Emil Velikov: rename the outstanding intel_sync instances] Signed-off-by: Emil Velikov <[email protected]>
* i915/i965: remove commented out warningTimothy Arceri2016-10-011-3/+1
| | | | | | | The warning was also the wrong location, it should have been in the else. Reviewed-by: Ian Romanick <[email protected]>
* i915: Enable EGL_KHR_gl_texture_3D_imageAdam Jackson2016-09-231-0/+3
| | | | | Reviewed-by: Eric Anholt <[email protected]> Signed-off-by: Adam Jackson <[email protected]>
* i915: Check return value of screen->image.loader->getBuffersEmil Velikov2016-08-301-6/+9
| | | | | | | | | Ported from the i965 commit e7ab358e8186dd8651cf920d4db1500c60ccd2fc. Cc: 11.2 12.0 <[email protected]> Cc: Tomasz Figa <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Eric Engestrom <[email protected]>
* i915: remove unnecessary `if`Eric Engestrom2016-08-241-3/+1
| | | | | | | | | | | if (x) return true; else return false; can be simplified as: return x; since `x` is already a boolean expression. Signed-off-by: Eric Engestrom <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* dri: add a way to request that modes have matching color/zs depthsIlia Mirkin2016-08-231-2/+2
| | | | | | | | | | Some GPUs, notably nv3x/nv4x can't render to mismatched color/zs framebuffer depths. Fallbacks can be done by the driver, with shadow surfaces, but no reason to encourage applications to select non-matching glx visuals. Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Marek Olšák <[email protected]>
* i915: Avoid aliasing violation.Matt Turner2016-08-011-1/+3
| | | | Reviewed-by: Iago Toral Quiroga <[email protected]>
* mesa: Rename CoordReplaceBits back to CoordReplace.Mathias Fröhlich2016-06-161-1/+1
| | | | | | | | It used to be called like that and fits better with 80 columns. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* i915: Convert i915 to use CoordsReplaceBits.Mathias Fröhlich2016-06-161-10/+7
| | | | | | | | Switch over to use the CoordsReplaceBits bitmask. Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Mathias Fröhlich <[email protected]>
* prog: Delete all remains of OPCODE_SNE, OPCODE_SEQ, OPCODE_SGT, and OPCODE_SLEIan Romanick2016-05-101-148/+0
| | | | | | | | | There is nothing left that can generate them. These used to be generated by ir_to_mesa or by the assembler for various NV extensions that have been removed. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i915: limit extern "C" hack only for libdrm headersEmil Velikov2016-03-091-7/+6
| | | | Signed-off-by: Emil Velikov <[email protected]>
* program: Remove OPCODE_KIL_NV.Matt Turner2016-03-011-20/+0
| | | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Acked-by: Brian Paul <[email protected]>
* mesa: Remove EmitCondCodes.Matt Turner2016-03-011-1/+0
| | | | | | Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Acked-by: Brian Paul <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-10 08:15:33 +0000