aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_vs.c
Commit message (Collapse)AuthorAgeFilesLines
* i965: Make brw_vs_outputs_written static.Kenneth Graunke2018-05-011-1/+1
| | | | Drop a prototype. Trivial.
* mesa: change gl_link_status enums to uppercaseBrian Paul2018-01-261-1/+1
| | | | | | follow the convention of other enums. Reviewed-by: Neha Bhende <[email protected]>
* i965: Drop support for the legacy SNORM -> Float equation.Kenneth Graunke2018-01-021-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Older OpenGL defines two equations for converting from signed-normalized to floating point data. These are: f = (2c + 1)/(2^b - 1) (equation 2.2) f = max{c/2^(b-1) - 1), -1.0} (equation 2.3) Both OpenGL 4.2+ and OpenGL ES 3.0+ mandate that equation 2.3 is to be used in all scenarios, and remove equation 2.2. DirectX uses equation 2.3 as well. Intel hardware only supports equation 2.3, so Gen7.5+ systems that use the vertex fetcher hardware to do the conversions always get formula 2.3. This can make a big difference for 10-10-10-2 formats - the 2-bit value can represent 0 with equation 2.3, and cannot with equation 2.2. Ivybridge and older were using equation 2.2 for OpenGL, and 2.3 for ES. Now that Ivybridge supports OpenGL 4.2, this is wrong - we need to use the new rules, at least in core profile. That would leave Gen4-6 doing something different than all other hardware, which seems...lame. With context version promotion, applications that requested a pre-4.2 context may get promoted to 4.2, and thus get the new rules. Zero cases have been reported of this being a problem. However, we've received a report that following the old rules breaks expectations. SuperTuxKart apparently renders the cars red when following equation 2.2, and works correctly when following equation 2.3: https://github.com/supertuxkart/stk-code/issues/2885#issuecomment-353858405 So, this patch deletes the legacy equation 2.2 support entirely, making all hardware and APIs consistently use the new equation 2.3 rules. If we ever find an application that truly requires the old formula, then we'd likely want that application to work on modern hardware, too. We'd likely restore this support as a driconf option. Until then, drop it. This commit will regress Piglit's draw-vertices-2101010 test on pre-Haswell without the corresponding Piglit patch to accept either formula (commit 35daaa1695ea01eb85bc02f9be9b6ebd1a7113a1): draw-vertices-2101010: Accept either SNORM conversion formula. Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chris Forbes <[email protected]>
* i965: Add shader cache support for vertex and fragment stagesTimothy Arceri2017-10-311-7/+13
| | | | | | | | | | | | | This enables the cache on vertex and fragment shaders only. v2: * Use MAYBE_UNUSED. (Matt) [[email protected]: reword subject] [[email protected]: *_cached_program => brw_disk_cache_*_program] Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Calculate thread_count in brw_alloc_stage_scratchJordan Justen2017-10-311-2/+1
| | | | | | | | | | Previously, thread_count was sent in from the stage after some stage specific calculations. Those stage specific calculations were moved into brw_alloc_stage_scratch, which will allow the shader cache to also use the same calculations. Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/compiler: Remove final_program_size from brw_compile_*Jordan Justen2017-10-311-6/+5
| | | | | | | | | The caller can now use brw_stage_prog_data::program_size which is set by the brw_compile_* functions. Cc: Jason Ekstrand <[email protected]> Signed-off-by: Jordan Justen <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* intel: Allocate prog_data::[pull_]param deeper inside the compilerJason Ekstrand2017-10-121-12/+5
| | | | | | | | | | | | | Now that we're always growing the param array as-needed, we can allocate the param array in common code and stop repeating the allocation everywere. In order to keep things sane, we ralloc the [pull_]param array off of the compile context and then steal it back to a NULL context later. This doesn't get us all the way to where prog_data::[pull_]param is purely an out parameter of the back-end compiler but it gets us a lot closer. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel/vs: Grow the param array for clip planesJason Ekstrand2017-10-121-5/+0
| | | | | | | | Instead of requiring the caller of brw_compile_vs to figure it out, just grow the param array on-demand. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Store image_param in brw_context instead of prog_dataJason Ekstrand2017-10-121-5/+0
| | | | | | | | | | This burns an extra 10k of memory or so in the case where you don't have any images. However, if you have several shaders which use images, this should be much less memory. It also gets rid of a part of prog_data that really has nothing to do with the compiler. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Rewrite the world of push/pull paramsJason Ekstrand2017-10-121-5/+2
| | | | | | | | | | | | | | | | | This moves us away to the array of pointers model and onto a model where each param is represented by a generic uint32_t handle. We reserve 2^16 of these handles for builtins that get generated by somewhere inside the compiler and have well-defined meanings. Generic params have handles whose meanings are defined by the driver. The primary downside to this new approach is that it moves a little bit of the work that we would normally do at compile time to draw time. On my laptop this hurts OglBatch6 by no more than 1% and doesn't seem to have any measurable affect on OglBatch7. So, while this may come back to bite us, it doesn't look too bad. Reviewed-by: Jordan Justen <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Convert brw->*_program into a brw->programs[i] array.Kenneth Graunke2017-09-261-3/+4
| | | | | | This makes it easier to loop over programs. Reviewed-by: Alejandro Piñeiro <[email protected]>
* i965: Compute VS/GS output VUE map from the NIR info.Kenneth Graunke2017-09-211-1/+1
| | | | | | | | | | unify_interfaces() only updates the NIR program info, not the copy in the gl_program itself. So, by using the old copy, we were missing out on these updates. The TCS/TES ones already did this correctly. Reviewed-by: Juan A. Suarez Romero <[email protected]>
* i965: drop brw->is_haswell in favor of devinfo->is_haswellLionel Landwerlin2017-08-301-1/+1
| | | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* i965: drop brw->gen in favor of devinfo->genLionel Landwerlin2017-08-301-3/+5
| | | | | | Signed-off-by: Lionel Landwerlin <[email protected]> Reviewed-by: Samuel Iglesias Gonsálvez <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* i965: Select ranges of UBO data to be uploaded as push constants.Kenneth Graunke2017-07-131-0/+2
| | | | | | | | | | | | | | | This adds a NIR pass that decides which portions of UBOS we should upload as push constants, rather than pull constants. v2: Switch to uint16_t for the UBO block number, because we may have a lot of them in Vulkan (suggested by Jason). Add more comments about bitfield trickery (requested by Matt). v3: Skip vec4 stages for now...I haven't finished wiring up support in the vec4 backend, and so pushing the data but not using it will just be wasteful. Reviewed-by: Matt Turner <[email protected]>
* intel/compiler/vs: Move inputs_read handling to generic codeJason Ekstrand2017-05-091-2/+0
| | | | | Reviewed-by: Alejandro Piñeiro <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vec4: Set VERT_BIT_EDGEFLAG based on the VUE mapJason Ekstrand2017-05-091-4/+0
| | | | | | | We also add a nice little comment to make it more clear exactly what happens with the edge flag copy. Reviewed-by: Kenneth Graunke <[email protected]>
* nir: Embed the shader_info in the nir_shader againJason Ekstrand2017-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit e1af20f18a86f52a9640faf2d4ff8a71b0a4fa9b changed the shader_info from being embedded into being just a pointer. The idea was that sharing the shader_info between NIR and GLSL would be easier if it were a pointer pointing to the same shader_info struct. This, however, has caused a few problems: 1) There are many things which generate NIR without GLSL. This means we have to support both NIR shaders which come from GLSL and ones that don't and need to have an info elsewhere. 2) The solution to (1) raises all sorts of ownership issues which have to be resolved with ralloc_parent checks. 3) Ever since 00620782c92100d77c660f9783504c6d80fa1d58, we've been using nir_gather_info to fill out the final shader_info. Thanks to cloning and the above ownership issues, the nir_shader::info may not point back to the gl_shader anymore and so we have to do a copy of the shader_info from NIR back to GLSL anyway. All of these issues go away if we just embed the shader_info in the nir_shader. There's a little downside of having to copy it back after calling nir_gather_info but, as explained above, we have to do that anyway. Acked-by: Timothy Arceri <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/drm: Rename drm_bacon_bo to brw_bo.Kenneth Graunke2017-04-101-2/+2
| | | | | | | | | | The bacon is all gone. This renames both the class and the related functions. We're about to run indent on the bufmgr code, so no need to worry about fixing bad indentation. Acked-by: Jason Ekstrand <[email protected]>
* i965/drm: Use our internal libdrm (drm_bacon) rather than the real one.Kenneth Graunke2017-04-101-2/+2
| | | | | | Now we can actually test our changes. Acked-by: Jason Ekstrand <[email protected]>
* i965: Move the back-end compiler to src/intel/compilerJason Ekstrand2017-03-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | Mostly a dummy git mv with a couple of noticable parts: - With the earlier header cleanups, nothing in src/intel depends files from src/mesa/drivers/dri/i965/ - Both Autoconf and Android builds are addressed. Thanks to Mauro and Tapani for the fixups in the latter - brw_util.[ch] is not really compiler specific, so it's moved to i965. v2: - move brw_eu_defines.h instead of brw_defines.h - remove no-longer applicable includes - add missing vulkan/ prefix in the Android build (thanks Tapani) v3: - don't list brw_defines.h in src/intel/Makefile.sources (Jason) - rebase on top of the oa patches [Emil Velikov: commit message, various small fixes througout] Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* i965: Move select_clip_planes to brw_vs.cJason Ekstrand2017-03-011-0/+26
| | | | Reviewed-by: Matt Turner <[email protected]>
* st/mesa/i965: create link status enumTimothy Arceri2017-02-091-1/+1
| | | | | | | | | | | | For the on-disk shader cache we want to be able to differentiate between a program that was linked and one that was loaded from cache. V2: - don't return the new enum directly to the application when queried, instead return GL_TRUE or GL_FALSE as required. Fixes google-chrome corruptions when using cache. Reviewed-by: Anuj Phogat <[email protected]>
* mesa/glsl: set {clip,cull}_distance_array_size directly in gl_programTimothy Arceri2017-01-231-1/+1
| | | | | | | There are some line wrapping violations here but those lines will get deleted in the following patch. Reviewed-by: Nicolai Hähnle <[email protected]>
* i965: get outputs_written from gl_programTimothy Arceri2017-01-191-2/+2
| | | | | | | There is no need to go via the pointer in nir_shader. This change is required for the shader cache as we don't create a nir_shader. Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: Make a helper for finding an existing shader variant.Kenneth Graunke2017-01-171-17/+5
| | | | | | | | | We had five copies of the same "walk the cache and look for an existing shader variant for this program" code. Now we have one helper function that returns the key. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eduardo Lima Mitev <[email protected]>
* i965: stop passing gl_shader_program to the precompile and codegen functionsTimothy Arceri2017-01-061-10/+4
| | | | | | | | We no longer need it. While we are at it we mark the vs, gs, and wm codegen functions as static. Reviewed-by: Eric Anholt <[email protected]>
* i965: make use of new is_arb_asm flagTimothy Arceri2017-01-061-6/+5
| | | | Reviewed-by: Eric Anholt <[email protected]>
* i965: stop passing gl_shader_program to brw_nir_setup_glsl_uniforms()Timothy Arceri2017-01-061-1/+1
| | | | | | | We can now just get the data needed from the gl_shader_program_data pointer in gl_program. Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: stop passing gl_shader_program to ↵Timothy Arceri2017-01-061-3/+2
| | | | | | | | | brw_assign_common_binding_table_offsets() We now get everything we need directly from gl_program so there is no need for this. Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: pass gl_program to the brw_*_debug_recompile() functionsTimothy Arceri2017-01-061-55/+54
| | | | | | | | | | | | | | Rather then passing gl_shader_program. The only field use was Name which is the same as the Id field in gl_program. For wm and vs we also make the functions static and move them before the codegen functions. This change reduces the codegen functions dependency on gl_shader_program. Reviewed-by: Lionel Landwerlin <[email protected]>
* i965: Print VS output VUE map in Vulkan too.Kenneth Graunke2017-01-051-3/+0
| | | | | | | We need to move this to the shared layer. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965: get InfoLog and LinkStatus via the shader program data pointer in ↵Timothy Arceri2017-01-031-2/+2
| | | | | | | | | gl_program This removes another dependency on gl_shader_program in the codegen functions. Reviewed-by: Eric Anholt <[email protected]>
* i965: update brw_get_shader_time_index() not to take gl_shader_programTimothy Arceri2017-01-031-2/+5
| | | | | | | | This removes another dependency on gl_shader_program in the codegen functions which will help allow us to use gl_program in the CurrentProgram array rather than gl_shader_program. Reviewed-by: Eric Anholt <[email protected]>
* i965: move compiled_once flag to brw_programTimothy Arceri2016-12-301-7/+3
| | | | | | | This allows us to delete brw_shader and removes the last use of gl_linked_shader in the codegen paths. Reviewed-by: Eric Anholt <[email protected]>
* i965: Don't force SSO layout for VS->TCS.Kenneth Graunke2016-12-061-3/+1
| | | | | | | | | | | | | | | | | | This was a hack which worked around the VS and TCS disagreeing on their shared interface due to the lack of varying packing. In particular, it was needed by Piglit's tcs-input-read-array-interface test. However, that was just one case where things could go awry, so the previous commit forcibly made interfaces match. This hack is no longer necessary. It also seems to be broken, though I'm not sure why. It fixes Piglit regressions in spec/arb_shader_image_load_store/semantics from commit ec1f159ac81ed964415d102eed4a0a29be8e7937. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98893 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965: Use shader_info for brw_vue_prog_data::cull_distance_mask.Kenneth Graunke2016-11-191-4/+0
| | | | | | | | This also allows us to move it from a GL specific location to a part of the compiler shared by both GL and Vulkan. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* st/mesa/glsl/nir/i965: make use of new gl_shader_program_data in ↵Timothy Arceri2016-11-191-2/+2
| | | | | | gl_shader_program Reviewed-by: Emil Velikov <[email protected]>
* i965: get num_images from shader_info rather than gl_linked_shaderTimothy Arceri2016-11-171-2/+1
| | | | | | This is a step towards freeing gl_linked_shader after linking. Reviewed-by: Emil Velikov <[email protected]>
* i965: only try print GLSL IR once when using INTEL_DEBUG to dump irTimothy Arceri2016-11-171-1/+2
| | | | | | | | Since we started releasing GLSL IR after linking the only time we can print GLSL IR is during linking. When regenerating variants only NIR will be available. Reviewed-by: Emil Velikov <[email protected]>
* i965/gen8: Fix vertex attrib upload for dvec3/4 shader inputsAntia Puentes2016-11-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The emission of vertex attributes corresponding to dvec3 and dvec4 vertex shader input variables was not correct when the <size> passed to the VertexAttribL* commands was <= 2. This was because we were using the vertex array size when emitting vertices to decide if we uploaded a 64-bit floating point attribute as 1 slot (128-bits) for sizes 1 and 2, or 2 slots (256-bits) for sizes 3 and 4. This caused problems when mapping the input variables to registers because, for deciding which registers contain the values uploaded for a certain variable, we use the size and type given to the variable in the shader, so we will be assigning 256-bits to dvec3/4 variables, even if we only uploaded 128-bits for them, which happened when the vertex array size was <= 2. The patch uses the shader information to only emit as 128-bits those 64-bit floating point variables that were declared as double or dvec2 in the vertex shader. Dvec3 and dvec4 variables will be always uploaded as 256-bits, independently of the <size> given to the VertexAttribL* command. From the ARB_vertex_attrib_64bit specification: "For the 64-bit double precision types listed in Table X.1, no default attribute values are provided if the values of the vertex attribute variable are specified with fewer components than required for the attribute variable. For example, the fourth component of a variable of type dvec4 will be undefined if specified using VertexAttribL3dv or using a vertex array specified with VertexAttribLPointer and a size of three." We are filling these unspecified components with zeros, which coincidentally is also what the GL44-CTS.vertex_attrib_binding.basic-inputL-case1 expects. v2: Do not use bitcount (Kenneth Graunke) Fixes: GL44-CTS.vertex_attrib_binding.basic-inputL-case1 test Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97287 Reviewed-by: Kenneth Graunke <[email protected]>
* i965: replace brw_vertex_program with new generic brw_programTimothy Arceri2016-10-261-6/+4
| | | | Reviewed-by: Jason Ekstrand <[email protected]>
* mesa/i965/i915/r200: eliminate gl_vertex_programTimothy Arceri2016-10-261-22/+18
| | | | | | | Here we move the only field in gl_vertex_program to the ARB program fields in gl_program. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: switch vs over to shared shader_infoTimothy Arceri2016-10-261-3/+2
| | | | | | | Note we access shader_info from the program struct rather than the nir_shader pointer because shader cache won't create a nir_shader. Reviewed-by: Jason Ekstrand <[email protected]>
* nir/i965/anv/radv/gallium: make shader info a pointerTimothy Arceri2016-10-261-4/+4
| | | | | | | | | | When restoring something from shader cache we won't have and don't want to create a nir_shader this change detaches the two. There are other advantages such as being able to reuse the shader info populated by GLSL IR. Reviewed-by: Jason Ekstrand <[email protected]>
* i965: get inputs read from nir infoTimothy Arceri2016-10-061-1/+1
| | | | | | | | | | This is a step towards dropping the GLSL IR version of do_set_program_inouts() in i965 and moving towards native nir support. This is important because we want to eventually convert to nir and use its optimisations passes before we can call this GLSL IR pass. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: get outputs written from nir infoTimothy Arceri2016-10-061-6/+9
| | | | | | | | | | This is a step towards dropping the GLSL IR version of do_set_program_inouts() in i965 and moving towards native nir support. This is important because we want to eventually convert to nir and use its optimisations passes before we can call this GLSL IR pass. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Eliminate brw->vs.prog_data pointer.Kenneth Graunke2016-10-051-5/+4
| | | | | | | | | | | | Just say no to: - brw->vs.base.prog_data = &brw->vs.prog_data->base.base; We'll just use the brw_stage_prog_data pointer in brw_stage_state and downcast it to brw_vs_prog_data as needed. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965: make vs and fs key generation helpers available to shader cacheCarl Worth2016-09-271-1/+1
| | | | | Signed-off-by: Timothy Arceri <[email protected]> Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>
* i965: get rid of duplicated values from gen_device_infoLionel Landwerlin2016-09-231-3/+4
| | | | | | | | Now that we have gen_device_info mutable, we can update its values and drop all copies we had in brw_context. 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-05 01:53:35 +0000