aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_clip.h
Commit message (Collapse)AuthorAgeFilesLines
* 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 Gen4-5 interpolation stuff to brw_wm_prog_data.Kenneth Graunke2017-01-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes glxgears rendering, which had surprisingly been broken since late October! Specifically, commit 91d61fbf7cb61a44adcaae51ee08ad0dd6b. glxgears uses glShadeModel(GL_FLAT) when drawing the main portion of the gears, then uses glShadeModel(GL_SMOOTH) for drawing the Gouraud-shaded inner portion of the gears. This results in the same fragment program having two different state-dependent interpolation maps: one where gl_Color is flat, and another where it's smooth. The problem is that there's only one gen4_fragment_program, so it can't store both. Each FS compile would trash the last one. But, the FS compiles are cached, so the first one would store FLAT, and the second would see a matching program in the cache and never bother to compile one with SMOOTH. (Clearing the program cache on every draw made it render correctly.) Instead, move it to brw_wm_prog_data, where we can keep a copy for every specialization of the program. The only downside is bloating the structure a bit, but we can tighten that up a bit if we need to. This also lets us kill gen4_fragment_program entirely! Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Timothy Arceri <[email protected]>
* i965: rewrite brw_setup_vue_interpolation()Timothy Arceri2016-10-261-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here brw_setup_vue_interpolation() is rewritten not to use the InterpQualifier array in gl_fragment_program which will allow us to remove it. This change also makes the code which is only used by gen4/5 more self contained as it now has its own gen5_fragment_program struct rather than storing the map in brw_context. This means the interpolation map will only get processed once and will get stored in the in memory cache rather than being processed everytime the fs changes. Also by calling this from the fs compile code rather than from the upload code and using the interpolation assigned there we can get rid of the BRW_NEW_INTERPOLATION_MAP flag. It might not seem ideal to add a gen5_fragment_program struct however by the end of this series we will have gotten rid of all the brw_{shader_stage}_program structs and replaced them with a generic brw_program struct so there will only be two program structs which is better than what we have now. V2: Don't remove BRW_NEW_INTERPOLATION_MAP from dirty_bit_map until the following patch to fix build error. V3 - Suggestions by Jason: - name struct gen4_fragment_program rather than gen5_fragment_program - don't use enum with memset() - create interp mode set helper and simplify logic to call it - add assert when calling function to show prog will never be NULL for gen4/5 i.e. no Vulkan Reviewed-by: Jason Ekstrand <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: add EXT_polygon_offset_clamp support to gen4/gen5Ilia Mirkin2015-10-051-0/+1
| | | | | Reviewed-by: Matt Turner <[email protected]> Signed-off-by: Ilia Mirkin <[email protected]>
* i965: Rename brw_compile to brw_codegenJason Ekstrand2015-04-221-1/+1
| | | | | | | | | | | | This name better matches what it's actually used for. The patch was generated with the following command: for file in *; do sed -i -e s/brw_compile/brw_codegen/g $file done Signed-off-by: Jason Ekstrand <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* s/Tungsten Graphics/VMware/José Fonseca2014-01-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tungsten Graphics Inc. was acquired by VMware Inc. in 2008. Leaving the old copyright name is creating unnecessary confusion, hence this change. This was the sed script I used: $ cat tg2vmw.sed # Run as: # # git reset --hard HEAD && find include scons src -type f -not -name 'sed*' -print0 | xargs -0 sed -i -f tg2vmw.sed # # Rename copyrights s/Tungsten Gra\(ph\|hp\)ics,\? [iI]nc\.\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./g /Copyright/s/Tungsten Graphics\(,\? [iI]nc\.\)\?\(, Cedar Park\)\?\(, Austin\)\?\(, \(Texas\|TX\)\)\?\.\?/VMware, Inc./ s/TUNGSTEN GRAPHICS/VMWARE/g # Rename emails s/[email protected]/[email protected]/ s/[email protected]/[email protected]/g s/jrfonseca-at-tungstengraphics-dot-com/jfonseca-at-vmware-dot-com/ s/jrfonseca\[email protected]/[email protected]/g s/keithw\[email protected]/[email protected]/g s/[email protected]/[email protected]/g s/thomas-at-tungstengraphics-dot-com/thellstom-at-vmware-dot-com/ s/[email protected]/[email protected]/ # Remove dead links s@Tungsten Graphics (http://www.tungstengraphics.com)@Tungsten Graphics@g # C string src/gallium/state_trackers/vega/api_misc.c s/"Tungsten Graphics, Inc"/"VMware, Inc"/ Reviewed-by: Brian Paul <[email protected]>
* i965: Drop trailing whitespace from the rest of the driver.Kenneth Graunke2013-12-051-9/+9
| | | | | | | Performed via: $ for file in *; do sed -i 's/ *//g'; done Signed-off-by: Kenneth Graunke <[email protected]>
* i965: Allow C++ type safety in the use of enum brw_urb_write_flags.Paul Berry2013-08-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (From a suggestion by Francisco Jerez) If an enum represents a bitfield of flags, e.g.: enum E { A = 1, B = 2, C = 4, D = 8, }; then C++ normally prohibits statements like this: enum E x = A | B; because A and B are implicitly converted to ints before OR-ing them, and an int can't be stored in an enum without a type cast. C, on the other hand, allows an int to be implicitly converted to an enum without casting. In the past we've dealt with this situation by storing flag bitfields as ints. This avoids ugly casting at the expense of some type safety that C++ would normally have offered (e.g. we get no warning if we accidentally use the wrong enum type). However, we can get the best of both worlds if we override the | operator. The ugly casting is confined to the operator overload, and we still get the benefit of C++ making sure we don't use the wrong enum type. v2: Remove unnecessary comment and unnecessary use of "enum" keyword. Use static_cast. Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Francisco Jerez <[email protected]>
* i965: Combine 4 boolean args of brw_urb_WRITE into a flags bitfield.Paul Berry2013-08-231-2/+1
| | | | | | | | | | | | The arguments to brw_urb_WRITE() were getting pretty unwieldy, and we have to add more flags to support geometry shaders anyhow. Also plumb these flags through brw_clip_emit_vue(), brw_set_urb_message(), and the vec4_instruction class. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: allow 8 user clip planes on CTG+Chris Forbes2013-08-161-1/+5
| | | | | | | | | | | | | There's no need to use a clip flag for NEGW on these gens, so no reason we can't just enable 8 planes. V2: - Bump (and document!) MAX_VERTS in the clip code. - Fix clip flag masks in the clip unit state and in the shader prolog - Move this to the end of the series for less breakage. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/clip: Track offset into the vertex for clipdistanceChris Forbes2013-08-161-0/+3
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965 Gen4/5: clip: Add support for noperspective varyingsChris Forbes2013-08-011-0/+1
| | | | | | | | | | | | | | | | | | | Adds support for interpolating noperspective varyings linearly in screen space when clipping. Based on Olivier Galibert's patch from last year: http://lists.freedesktop.org/archives/mesa-dev/2012-July/024341.html At this point all -fixed and -vertex interpolation tests work. V5: Add brw_clip_compile.has_noperspective_shading rather than another key flag. V6: Real bools. [V1-2]: Signed-off-by: Olivier Galibert <galibert at pobox.com> Signed-off-by: Chris Forbes <[email protected]> Acked-by: Paul Berry <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965 Gen4/5: clip: correctly handle flat varyingsChris Forbes2013-08-011-3/+4
| | | | | | | | | | | | | | | | Previously we only gave special treatment to the builtin color varyings. This patch adds support for arbitrary flat-shaded varyings, which is required for GLSL 1.30. Based on Olivier Galibert's patch from last year: http://lists.freedesktop.org/archives/mesa-dev/2012-July/024340.html V5: Move key.do_flat_shading to brw_clip_compile.has_flat_shading V6: Real bools. [V1-2]: Signed-off-by: Olivier Galibert <galibert at pobox.com> Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965 Gen4/5: Introduce 'interpolation map' alongside the VUE mapChris Forbes2013-08-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | The interpolation map (in brw->interpolation_mode) is a new auxiliary structure alongside the post-GS VUE map, which describes the interpolation modes for each VUE slot, for use by the clip and SF stages. This patch introduces a new state atom to compute the interpolation map, and adjusts the program keys for the clip and SF stages, but it is not actually used yet. [V1-2]: Signed-off-by: Olivier Galibert <galibert at pobox.com> V3: Updated for vue_map changes, intel -> brw merge, etc. (Chris Forbes) V4: Compute interpolation map as a new state atom rather than tacking it on the front of the clip setup V5: Rework commit message, make interpolation_mode_map a struct. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove some dead code.Kenneth Graunke2013-07-031-2/+0
| | | | | | | A random smattering of things that just aren't used anymore. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/clip: Add support for gl_ClipVertexChris Forbes2013-06-071-0/+9
| | | | | | | | | | | When clipping triangles against a user clip plane, and gl_ClipVertex is provided in the vertex, use it instead of hpos. TODO: A similar change should be made at some point for line clipping. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Clarify nomenclature: vert_result -> varyingPaul Berry2013-03-231-4/+4
| | | | | | | | | | | | | | | | | | This patch removes the terminology "vert_result" from the i965 driver, replacing it with "varying". The old terminology, "vert_result", was confusing because (a) it referred to the enum gl_vert_result, which no longer exists (it was replaced with gl_varying_slot), and (b) it implied a vertex output, but with the advent of geometry shaders, it could be either a vertex or a geometry output, depending what shaders are in use. The generic term "varying" is less confusing. No functional change. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> v2: Whitespace fixes.
* intel: Convert from GLboolean to 'bool' from stdbool.h.Kenneth Graunke2011-10-181-4/+4
| | | | | | | | | | | | | | | | | I initially produced the patch using this bash command: for file in {intel,i915,i965}/*.{c,cpp,h}; do [ ! -h $file ] && sed -i 's/GLboolean/bool/g' $file && sed -i 's/GL_TRUE/true/g' $file && sed -i 's/GL_FALSE/false/g' $file; done Then I manually added #include <stdbool.h> to fix compilation errors, and converted a few functions back to GLboolean that were used in core Mesa's function pointer table to avoid "incompatible pointer" warnings. Finally, I cleaned up some whitespace issues introduced by the change. Signed-off-by: Kenneth Graunke <[email protected]> Acked-by: Chad Versace <[email protected]> Acked-by: Paul Berry <[email protected]>
* i965: Use 4 bits to store nr_userclip in brw_clip.h.Paul Berry2011-09-281-2/+1
| | | | | | | | | | | | | | | Since the i965 driver supports 8 clipping planes now, we need 4 bits to store the number of user clipping planes, not 3. In theory this isn't strictly necessary, since brw_clip.h is only used on pre-GEN6, and pre-GEN6 only advertises support for 6 clipping planes, but it seems wise to err on the safe side. In the process I removed the pad0 element of struct brw_clip_prog_key--it doesn't seem necessary because the compiler automatically inserts padding if needed. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove two_side_color from brw_compute_vue_map().Paul Berry2011-09-061-2/+1
| | | | | | | | | | | Since we now lay out the VUE the same way regardless of whether two-sided color is enabled, brw_compute_vue_map() no longer needs to know whether two-sided color is enabled. This allows the two-sided color flag to be removed from the clip, GS, and VS keys, so that fewer GPU programs need to be recompiled when turning two-sided color on and off. Reviewed-by: Eric Anholt <[email protected]>
* i965: clip: Remove no-longer-needed variables.Paul Berry2011-09-061-10/+1
| | | | | | | | The variables offset[], idx_to_attr[], nr_bytes, nr_attrs, and header_regs were all serving purposes which are now served by the VUE map. Reviewed-by: Eric Anholt <[email protected]>
* i965: clip: Add a function to determine whether a vert_result is in use.Paul Berry2011-09-061-0/+9
| | | | | | | | Previously we would examine the offset[] array (since an offset of 0 meant "not in use"). This paves the way for removing the offset[] array. Reviewed-by: Eric Anholt <[email protected]>
* i965: clip: Move header_regs into brw_clip_compile.Paul Berry2011-09-061-0/+1
| | | | | | This makes header_regs available for computing VUE offsets within clip code. Reviewed-by: Eric Anholt <[email protected]>
* i965: clip: Move hpos_offest and ndc_offset into local functions.Paul Berry2011-09-061-1/+0
| | | | | | | | | The offsets within the VUE of HPOS and NDC are needed only in a few auxiliary clipping functions. This patch moves computation of those offsets into the functions that need them, and does the computation using the VUE map. Reviewed-by: Eric Anholt <[email protected]>
* i965: clip: rename header_position_offset to the more correct ndc_offset.Paul Berry2011-09-061-1/+1
| | | | Reviewed-by: Eric Anholt <[email protected]>
* i965: clip: Add VUE map computation to clip stage for Gen4-5.Paul Berry2011-09-061-1/+4
| | | | Reviewed-by: Eric Anholt <[email protected]>
* i965: Reduce repeated calculation of the attribute-offset-in-VUE.Eric Anholt2010-07-191-1/+4
| | | | | | This cleans up some chipset dependency sprinkled around, and fixes a potential overflow of the attribute offset array for many vertex results.
* i965: remove disabled code for cycling through MRF registers in clipping.Eric Anholt2010-05-201-2/+0
| | | | | | | The idea would be that you could have multiple send messages going on if nothing depended on the previous message's results and you used a different send message. The problem is that the later send requires the VUE handle returned by the first send's allocate anyway.
* intel: Replace IS_IGDNG checks with intel->is_ironlake or needs_ff_sync.Eric Anholt2009-12-221-1/+0
| | | | Saves ~480 bytes of code.
* Merge branch 'outputswritten64'Ian Romanick2009-11-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Add a GLbitfield64 type and several macros to operate on 64-bit fields. The OutputsWritten field of gl_program is changed to use that type. This results in a fair amount of fallout in drivers that use programs. No changes are strictly necessary at this point as all bits used are below the 32-bit boundary. Fairly soon several bits will be added for clip distances written by a vertex shader. This will cause several bits used for varyings to be pushed above the 32-bit boundary. This will affect any drivers that support GLSL. At this point, only the i965 driver has been modified to support this eventuality. I did this as a "squash" merge. There were several places through the outputswritten64 branch where things were broken. I foresee this causing difficulties later for bisecting. The history is still available in the branch. Conflicts: src/mesa/drivers/dri/i965/brw_wm.h
* i965: fix EXT_provoking_vertex supportRoland Scheidegger2009-11-111-4/+3
| | | | | | | | This didn't work for quad/quadstrips at all, and for all other primitive types it only worked when they were unclipped. Fix up the former in gs stage (could probably do without these changes and instead set QuadsFollowProvokingVertexConvention to false), and the rest in clip stage.
* i965: Postpone ff_sync message in CLIP kernel on IGDNGXiang, Haihao2009-07-301-0/+3
| | | | In addition, it guarantees ff_sync message is issued
* i965: add support for new chipsetsXiang, Haihao2009-07-131-1/+2
| | | | | | | | | | 1. new PCI ids 2. fix some 3D commands on new chipset 3. fix send instruction on new chipset 4. new VUE vertex header 5. ff_sync message (added by Zou Nan Hai <[email protected]>) 6. the offset in JMPI is in unit of 64bits on new chipset 7. new cube map layout
* 965: Fix incorrect backface cullingKrzysztof Czurylo2008-08-211-0/+5
| | | | | Fix incorrect backface culling for OGL tunnel in wireframe and point mode.
* Initial 965 GLSL supportZou Nan hai2007-04-121-2/+2
|
* cleanup code, compiles with vbo changesKeith Whitwell2006-10-311-1/+1
|
* Add Intel i965G/Q DRI driver.Eric Anholt2006-08-091-0/+170
This driver comes from Tungsten Graphics, with a few further modifications by Intel.