summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* i915g: fixup clear params emissionDaniel Vetter2011-10-071-1/+8
| | | | | | | | | | | | | | | | | Docs say that default shader input color input need to be spec as ARGB8888. And a clear rect prim essentially uses this value instead of default diffuse. Depth on the other hands is an ieee 32 bit float. Clear stencil is U8. Completely different are the clear values for zone init prims. These are speced in the actual output pixel layout (and need to be repeated for 16 bit formats). Clear up the confusion by adding some comments. v2: Retain the target swizzling support added by Stephan Marchesin. Signed-off-by: Daniel Vetter <[email protected]>
* i915g: make fixup swizzle into a real hw stateDaniel Vetter2011-10-073-41/+45
| | | | | | This way it can be reused in the fastclear path. Signed-off-by: Daniel Vetter <[email protected]>
* glsl: Remove version check when looking for identifiers containing "__".Jason Wood2011-10-061-2/+1
| | | | Signed-off-by: Kenneth Graunke <[email protected]>
* i915g: Announce GL 2.0.Stéphane Marchesin2011-10-061-1/+1
| | | | We leave the debug code in place to troubleshoot issues while we complete the transition. That code might be removed after that.
* i965 Gen6+: De-compact clip planes.Paul Berry2011-10-067-68/+56
| | | | | | | | | | | | | | | | | | | Previously, if the user enabled a non-consecutive set of clip planes (e.g. 0, 1, and 3), the driver would compact them down to a consecutive set starting at 0. This optimization was of dubious value, and complicated the implementation of gl_ClipDistance. This patch changes the driver so that with Gen6 and later chipsets, we no longer compact the clip planes. However, we still discard any clip planes beyond the highest number that is in use, so performance should not be affected for applications that use clip planes consecutively from 0. With chipsets previous to Gen6, we still compact the clip planes, since the pre-Gen6 clipper thread relies on this behavior. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965 VS: Change nr_userclip to nr_userclip_planes.Paul Berry2011-10-064-13/+16
| | | | | | | | | | The only remaining uses of brw_vs_prog_key::nr_userclip only occurred when using clip planes (as opposed to gl_ClipDistance). This patch renames the value to nr_userclip_planes and sets it to zero when gl_ClipDistance is in use. This avoids unnecessary VS recompiles. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Make brw_compute_vue_map's userclip dependency a boolean.Paul Berry2011-10-0613-25/+32
| | | | | | | | | | | | | Previously, brw_compute_vue_map required an argument indicating the number of clip planes in use, but all it did with it was check if it was nonzero. This patch changes brw_compute_vue_map to take a boolean instead. This allows us to avoid some unnecessary recompilation of the Gen4/5 GS and SF threads. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Move ClipPlanesEnabled state to VS cache key.Paul Berry2011-10-063-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | Previous to this patch, setup_uniform_clipplane_values() was setting up clip plane uniforms based on ctx->Transform.ClipPlanesEnabled, a piece of state not stored in the vertex shader cache key. As a result, a change to this piece of state might not trigger a necessary vertex shader recompile. The patch adds a field to the vertex shader cache key, userclip_planes_enabled, to store the current value of ctx->Transform.ClipPlanesEnabled. Also, it changes setup_uniform_clipplane_values() to read from this new field, so that it's manifestly clear that the vertex shader isn't depending on state not stored in the cache key. Note: when the vertex shader uses gl_ClipDistance, the VS backend doesn't need to know which clip planes are in use, so we leave the field as zero in that case to avoid unnecessary recompiles. Fixes Piglit test vs-clip-vertex-enables. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Rearrange VS cache key struct.Paul Berry2011-10-061-1/+11
| | | | | | | | | | | No functional change. This patch rearranges the struct brw_vs_prog_key so that the two fields related to clipping are together, and documents those fields. This should make the patches that follow easier to comprehend, since they add additional clipping-related fields to this structure. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Create _mesa_bitcount_64() to replace i965's brw_count_bits()Paul Berry2011-10-0613-21/+30
| | | | | | | | | | | | | | | | The i965 driver already had a function to count bits in a 64-bit uint (brw_count_bits()), but it was buggy (it only counted the bottom 32 bits) and it was clumsy (it had a strange and broken fallback for non-GCC-like compilers, which fortunately was never used). Since Mesa already has a _mesa_bitcount() function, it seems better to just create a _mesa_bitcount_64() function rather than special-case this in the i965 driver. This patch creates the new _mesa_bitcount_64() function and rewrites all of the old brw_count_bits() calls to refer to it. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa/es: Allow GL_CLIP_PLANE0+6 and GL_CLIP_PLANE0+7.Kenneth Graunke2011-10-061-8/+6
| | | | | | | | | | Fixes the ES1 conformance 'userclip' test, which broke when we increased MAX_CLIP_PLANES to 8. Core Mesa already validates incoming values against MAX_CLIP_PLANES; we just need the ES wrapper to pass everything through. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* mesa/get: Move MAX_LIGHTS from GL/ES2 to GL/ES1.Kenneth Graunke2011-10-061-2/+1
| | | | | | | | | | It's required for ES 1.0 and 1.1, and isn't specified for ES 2. While the comment says Mesa depends on it internally, removing it from ES2 doesn't seem to regress any Piglit or ES2 conformance tests. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* meta: Don't enable TEXTURE_RECTANGLE when it's unsupported.Kenneth Graunke2011-10-061-1/+2
| | | | | | | | | In particular, drivers don't enable this in ES 1.1 contexts. Prior to this, none of the OpenGL ES 1.1 conformance tests passed. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915g: Silence warning.Stéphane Marchesin2011-10-061-1/+1
| | | | We still need to investigate LIS7 though.
* i915g: Fix comment.Stéphane Marchesin2011-10-051-1/+1
|
* mesa: remove some unneeded forward struct declarationsBrian Paul2011-10-051-3/+0
|
* st/mesa: fix commentBrian Paul2011-10-051-1/+1
|
* mesa: remove unused _mesa_rescale_teximage2d() functionBrian Paul2011-10-052-84/+0
| | | | It was only used by the old tdfx driver, IIRC.
* mesa: remove unused gl_texture_image::DriverData fieldBrian Paul2011-10-052-8/+0
| | | | Was only used by some older/removed DRI drivers.
* st/mesa: don't use gl_texture_image::RowStrideBrian Paul2011-10-051-5/+7
| | | | It's always the same as the texture width.
* st/mesa: completely stop using gl_texture_image::DataBrian Paul2011-10-052-14/+19
| | | | | Instead, use the new st_texture_image::TexData field to hold texture images that don't fit the parent object's mipmap buffer.
* st/mesa: stop using gl_texture_image::Data when mapping/unmapping texturesBrian Paul2011-10-052-33/+35
| | | | | | | Since core Mesa no longer depends on gl_texture_image::Data pointing to mapped texture buffers we don't have to mess with it all over the place in the state tracker. Now Data is only used to point to malloc'd memory that holds images which don't fit in the texture object's mipmap buffer.
* mesa: get rid of imageOffsets arrays in texstore codeBrian Paul2011-10-0510-380/+232
| | | | | | | | | | | These were used to find the start of a 3D image slice (or 2D array texture slice) given a base address. Instead, use a simple array of address of image slices instead. This is a step toward getting rid of the gl_texture_image::ImageOffsets field. Reviewed-by: Eric Anholt <[email protected]>
* st/glx: remove the duplicated Drawable member.Stéphane Marchesin2011-10-053-7/+6
| | | | If you want to access it, you should use the Drawable in xlib_drawable instead.
* glsl: Consider "__" in identifers as reserved.Eric Anholt2011-10-051-0/+13
| | | | | | Fixes double-underscore-*.frag. Reviewed-by: Kenneth Graunke <[email protected]>
* swrast: update texfetch_funcs table for new int/uint formatsBrian Paul2011-10-051-0/+325
| | | | | This only adds dummy entries to the table to fix failed assertions. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41491
* i965 Gen6: Implement gl_ClipVertex.Paul Berry2011-10-056-10/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements proper support for gl_ClipVertex by causing the new VS backend to populate the clip distance VUE slots using VERT_RESULT_CLIP_VERTEX when appropriate, and by using the untransformed clip planes in ctx->Transform.EyeUserPlane rather than the transformed clip planes in ctx->Transform._ClipUserPlane when a GLSL-based vertex shader is in use. When not using a GLSL-based vertex shader, we use ctx->Transform._ClipUserPlane (which is what we used prior to this patch). This ensures that clipping is still performed correctly for fixed function and ARB vertex programs. A new function, brw_select_clip_planes() is used to determine whether to use _ClipUserPlane or EyeUserPlane, so that the logic for making this decision is shared between the new and old vertex shaders. Fixes the following Piglit tests on i965 Gen6: - vs-clip-vertex-const-accept - vs-clip-vertex-const-reject - vs-clip-vertex-different-from-position - vs-clip-vertex-equal-to-position - vs-clip-vertex-homogeneity - vs-clip-based-on-position - vs-clip-based-on-position-homogeneity - clip-plane-transformation clipvert_pos - clip-plane-transformation pos_clipvert - clip-plane-transformation pos Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* mesa: Add a gl_vert_result for gl_ClipVertex.Paul Berry2011-10-052-22/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, clip planes didn't work properly in Mesa when using vertex shaders, because Mesa assigned both gl_ClipVertex and gl_Position to the same gl_vert_result (VERT_RESULT_HPOS). As a result, backends couldn't distinguish between the two variables, so any shader that wrote different values to them would fail to work properly. This patch paves the way for proper support of gl_ClipVertex by creating a new enumerated value in gl_vert_result for it (VERT_RESULT_CLIP_VERTEX). After this patch, a back-end may add support for gl_ClipVertex using the following algorithm: - If using a user-supplied GLSL vertex shader: - If the bit corresponding to VERT_RESULT_CLIP_VERTEX is set in gl_program::OutputsWritten: - Clip using the vertex shader output VERT_RESULT_CLIP_VERTEX and the clip planes defined in gl_context::Transform.EyeUserPlane. - Else: - Clip using the vertex shader output VERT_RESULT_HPOS and the clip planes defined in gl_context::Transform.EyeUserPlane. - Else (either using fixed function or an ARB vertex program): - Clip using the vertex shader output VERT_RESULT_HPOS and the clip planes defined in gl_context::Transform._ClipUserPlane (*) where (*) represents the normal Mesa behavior before this patch. An example of implementing the above algorithm can be found in the patch that follows this one, which implements gl_ClipVertex in i965 Gen6. Reviewed-by: Kenneth Graunke <[email protected]>
* llvmpipe: Fix the 4 planes (lines) case properly.José Fonseca2011-10-052-16/+33
| | | | | | | | The previous change was not effective for lines, because there is no 4 planes 4x4 block rasterization path: it is handled by the 16x16 block case too, and the 16x16 block was not being budged as it should. This fixes assertion failures on line rasterization.
* llvmpipe: Ensure the 16x16 special rasterization path does not touch outside ↵José Fonseca2011-10-054-5/+31
| | | | | | | | | | | | | | the tile. llvmpipe has a few special rasterization paths for triangles contained in 16x16 blocks, but it allows the 16x16 block to be aligned only to a 4x4 grid. Some 16x16 blocks could actually intersect the tile if the triangle is 16 pixels in one dimension but 4 in the other, causing a buffer overflow. The fix consists of budging the 16x16 blocks back inside the tile.
* mesa: update fbo format tablet for integer types.Dave Airlie2011-10-051-1/+61
| | | | | | This updates the fbo format table for the integer types. Signed-off-by: Dave Airlie <[email protected]>
* mesa/texstore: add texstore paths for all the integer types.Dave Airlie2011-10-051-12/+104
| | | | | | | | | This just adds the entries to the table and fixes the asserts up. The int32 one is definitely wrong, since it uses a float temp which will lose precision, but its no worse than now. Signed-off-by: Dave Airlie <[email protected]>
* mesa/texformat: update choose_tex_format for integer types.Dave Airlie2011-10-051-4/+79
| | | | | | This adds the integer types to the tex format chooser. Signed-off-by: Dave Airlie <[email protected]>
* mesa/formats: add rest of integer formats.Dave Airlie2011-10-052-2/+562
| | | | | | | | | | | | | | | | This is taken from reading EXT_texture_integer + EXT_texture_rg in combination, Comments on necessity of each format, naming of formats and bugs in the formats tables please. Is there any formats I've missed? Eric looked over this to make sure its consistent at least. As I've changed the ordering of things in the format table, the follow patches are required to avoid regression. Signed-off-by: Dave Airlie <[email protected]>
* texstore: create texstore table on first access.Dave Airlie2011-10-051-149/+120
| | | | | | | | As per Brian's suggestion we can generate this table at first start to make sure its correct. This is a sad workaround for compilers which don't support named initialiser. (its 2011). Signed-off-by: Dave Airlie <[email protected]>
* glsl: Remove unneeded headers.Stéphane Marchesin2011-10-042-2/+0
|
* egl: restore missing \ in MakefileBrian Paul2011-10-041-1/+1
|
* r200/r300/r600: remove dangling radeon_tex_getimage.c symlinks.Paul Berry2011-10-043-3/+0
| | | | | | | | | | | | Commit d1fda903 (radeon: Drop mapping we were doing around glGetTexImage()) removed the common Radeon source file radeon_tex_getimage.c, and pulled it out of the r200, r300, r600, and radeon makefiles. But it left behind the symlinks that were being used to share that file among the four directories. This patch removes the dangling symlinks. Reviewed-by: Brian Paul <[email protected]>
* glapi: Enclose glapi.h in an extern "C" block when included by C++.Kenneth Graunke2011-10-041-0/+6
| | | | | | | | Fixes a build failure introduced in commit b7fa0d0727a3a9e1f64d3cfc7a0f157b35dec09e. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-and-tested-by: Paul Berry <[email protected]>
* scons: add new files to src/mesa/SConscriptBrian Paul2011-10-041-0/+2
|
* softpipe: fix Z interpolation invariance bugBrian Paul2011-10-041-1/+10
| | | | | | | | | We want quad/pixel Z values to be interpolated exactly the same for multi-pass algorithms. Because of how the optimized Z-test code is written, we can't cull the first quad in a run even if it's totally killed. See the comment for more info. NOTE: This is a candidate for the 7.11 branch.
* softpipe: add check for DO_PSTIPPLE_IN_HELPER_MODULEBrian Paul2011-10-041-0/+2
| | | | | We only want to generate the fragment shader variant that does stippling if DO_PSTIPPLE_IN_HELPER_MODULE is being used.
* mesa: Remove unused gl_program::AttributesIan Romanick2011-10-045-34/+0
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Determine GL_ACTIVE_ATTRIBUTE_MAX_LENGTH by walking the GLSL IR.Ian Romanick2011-10-045-33/+32
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Determine GL_ACTIVE_ATTRIBUTES by walking the GLSL IR.Ian Romanick2011-10-043-1/+30
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Remove unused gl_shader_program::AttributesIan Romanick2011-10-043-14/+2
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Make _mesa_GetActiveAttribARB use the attributes in the shader IRIan Romanick2011-10-041-13/+38
| | | | | | | | | Instead of relying on the mirror in the Mesa IR assembly shader, just use the variables actually stored in the GLSL IR. This will be a bit slower, but nobody cares about the performance of glGetActiveAttrib. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Move _mesa_GetActiveAttribARB to shader_query.cppIan Romanick2011-10-042-42/+32
| | | | | | | | | This just folds get_active_attrib into _mesa_GetActiveAttribARB and moves the resulting function function to the other source file. More changes are coming soon. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* linker: Use gl_shader_program::AttributeBindings for attrib locationsIan Romanick2011-10-041-74/+64
| | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Add gl_shader_program::AttributeBindingsIan Romanick2011-10-043-1/+24
| | | | | | | | | This currently mirrors the state tracking gl_shader_program::Attributes, but I'm working towards eliminating that. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-26 03:22:04 +0000