summaryrefslogtreecommitdiffstats
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* radeon/llvm: Make sure the LOAD_CONST def uses the isSI predicateTom Stellard2012-05-092-7/+7
|
* svga: implement CEIL opcode translationBrian Paul2012-05-091-0/+28
| | | | Reviewed-by: José Fonseca <[email protected]>
* glsl_to_tgsi: use TGSI_OPCODE_CEIL for ir_unop_ceilChristoph Bumiller2012-05-091-3/+1
| | | | | The implementation using FLR was buggy, the second negation could get lost.
* gallium/drivers: handle TGSI_OPCODE_CEILChristoph Bumiller2012-05-094-0/+28
|
* r600g: Handle TGSI_OPCODE_CEIL (v2)Kai Wasserbäch2012-05-091-3/+3
| | | | | | | v2: Enabled CEIL on Cayman too. Signed-off-by: Kai Wasserbäch <[email protected]> Reviewed-by: Tom Stellard <[email protected]>
* gallivm: implement iabs/issg opcode.Dave Airlie2012-05-092-1/+26
| | | | | | Reimplemented by Olivier Galibert <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
* i965: fix wrong cube/3D texture layoutYuanhan Liu2012-05-091-2/+3
| | | | | | | | | | | | | | | | | | | | | | Fix wrong cube/3D texture layout for the tailing levels whose width or height is smaller than the align unit. From 965 B-spec http://intellinuxgraphics.org/VOL_1_graphics_core.pdf at page 135: All of the LOD=0 q-planes are stacked vertically, then below that, the LOD=1 qplanes are stacked two-wide, then the LOD=2 qplanes are stacked four-wide below that, and so on. Thus we should always inrease pack_x_nr, which results to the pitch of LODn may greater than the pitch of LOD0. So we should refactor mt->total_width when needed. This would fix the following webgl test case on all gen4 platforms: conformance/textures/texture-size-cube-maps.html NOTE: This is a candidate for stable release branches. Signed-off-by: Yuanhan Liu <[email protected]>
* radeon/llvm: Remove AMDILUtilityFunctions.cppTom Stellard2012-05-0813-1041/+399
|
* radeon/llvm: Remove some unused functions from AMDILInstrInfoTom Stellard2012-05-082-164/+0
|
* radeon/llvm: Add some comments and fix coding styleTom Stellard2012-05-088-42/+41
|
* radeon/llvm: Remove the EXPORT_REG instructionTom Stellard2012-05-0810-117/+8
|
* radeon/llvm: Use a custom inserter to lower RESERVE_REGTom Stellard2012-05-0810-27/+83
|
* radeon/llvm: Use a custom inserter to lower STORE_OUTPUTTom Stellard2012-05-084-34/+23
|
* radeon/llvm: Remove AMDGPULowerShaderInstructions classTom Stellard2012-05-086-86/+4
| | | | It is no longer used.
* radeon/llvm: Use a custom inserter to lower LOAD_INPUTTom Stellard2012-05-084-39/+15
|
* radeon/llvm: Remove the ReorderPreloadInstructions passTom Stellard2012-05-089-100/+4
|
* radeon/llvm: Remove old comment from AMDIL.hTom Stellard2012-05-081-5/+0
|
* glsl: Change built-in constant expression evaluation to run the IR.Olivier Galibert2012-05-082-380/+156
| | | | | | | | This removes code duplication with ir_expression::constant_expression_value and builtins/ir/*. Signed-off-by: Olivier Galibert <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Add an origin pointer in the function signature object.Olivier Galibert2012-05-083-0/+5
| | | | | | | | This points to the object with the function body, allowing us to map from a built-in prototype to the actual body with IR code to execute. Signed-off-by: Olivier Galibert <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* glsl: Add methods to copy parts of one ir_constant into another.Olivier Galibert2012-05-082-0/+114
| | | | | | | | | | | | | | | - copy_masked_offset copies part of a constant into another, assign-like. - copy_offset copies a constant into (a subset of) another, funcall-return like. These methods are to be used to trace through assignments and function calls when computing a constant expression. Signed-off-by: Olivier Galibert <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> [v1]
* glsl: Add a constant_referenced method to ir_dereference*Olivier Galibert2012-05-082-0/+128
| | | | | | | | | | The method is used to get a reference to an ir_constant * within the context of evaluating an assignment when calculating a constant_expression_value. Signed-off-by: Olivier Galibert <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> [v1]
* glsl: Add a variable context to constant_expression_value().Olivier Galibert2012-05-083-31/+44
| | | | | | Signed-off-by: Olivier Galibert <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> [v1]
* glsl: Extend ir_constant::zero to handle more types.Olivier Galibert2012-05-081-1/+16
| | | | | | Signed-off-by: Olivier Galibert <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> [v1]
* glsl: Fix broken constant expression handling for <, <=, >, and >=.Kenneth Graunke2012-05-081-9/+9
| | | | | | | | | | | | | We were looping over all the vector components, but only dealing with the first one. This was masked by the fact that constant expression handling on built-ins went through custom code for the lessThan() /function/ rather than the ir_binop_less expression operator. NOTE: This is a candidate for all release branches. Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Olivier Galibert <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]>
* vbo: add some commentsBrian Paul2012-05-082-1/+7
|
* mesa: remove needless casts in save_EdgeFlag()Brian Paul2012-05-081-1/+1
|
* mesa: minor clean-ups in dlist material codeBrian Paul2012-05-081-7/+15
|
* mesa: fix error strings in dlist codeBrian Paul2012-05-081-4/+4
|
* mesa: add gl_context::NewDriverState and use it for vertex arraysMarek Olšák2012-05-0813-8/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vbo module recomputes its states if _NEW_ARRAY is set, so it shouldn't use the same flag to notify the driver. Since we've run out of bits in NewState and NewState is for core Mesa anyway, we need to find another way. This patch is the first to start decoupling the state flags meant only for core Mesa and those only for drivers. The idea is to have two flag sets: - gl_context::NewState - used by core Mesa only - gl_context::NewDriverState - used by drivers only (the flags are defined by the driver and opaque to core Mesa) It makes perfect sense to use NewState|=_NEW_ARRAY to notify the vbo module that the user changed vertex arrays, and the vbo module in turn sets a driver-specific flag to notify the driver that it should update its vertex array bindings. The driver decides which bits of NewDriverState should be set and stores them in gl_context::DriverFlags. Then, Core Mesa can do this: ctx->NewDriverState |= ctx->DriverFlags.NewArray; This patch implements this behavior and adapts st/mesa. DriverFlags.NewArray is set to ST_NEW_VERTEX_ARRAYS. Core Mesa only sets NewDriverState. It's the driver's responsibility to read it whenever it wants and reset it to 0. Reviewed-by: Brian Paul <[email protected]>
* mesa: move gl_client_array*[] from vbo_draw_func into gl_contextMarek Olšák2012-05-0818-31/+61
| | | | | | | | | | | | | | | | | | In the future we'd like to treat vertex arrays as a state and not as a parameter to the draw function. This is the first step towards that goal. Part of the goal is to avoid array re-validation for every draw call. This commit adds: const struct gl_client_array **gl_context::Array::_DrawArrays. The pointer is changed in: * vbo_draw_method * vbo_rebase_prims - unused by gallium * vbo_split_prims - unused by gallium * st_RasterPos Reviewed-by: Brian Paul <[email protected]>
* vbo: move vbo_draw_method into vbo_context.hMarek Olšák2012-05-085-40/+38
| | | | | | I'll need vbo_context in that function soon. Reviewed-by: Brian Paul <[email protected]>
* radeon/llvm: add suport for cube texturesVadim Girlin2012-05-082-23/+91
| | | | Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: add support for CUBE ALU instructionVadim Girlin2012-05-085-21/+63
| | | | Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: add support for some ALU instructionsVadim Girlin2012-05-084-13/+293
| | | | | | | | Add support for IABS, NOT, AND, XOR, OR, UADD, UDIV, IDIV, MOD, UMOD, INEG, I2F, U2F, F2U, F2I, USEQ, USGE, USLT, USNE, ISGE, ISLT, ROUND, MIN, MAX, IMIN, IMAX, UMIN, UMAX Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: add missing cases for BREAK/CONTINUEVadim Girlin2012-05-082-0/+3
| | | | Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: add support for AHSR/LSHR/LSHL instructionsVadim Girlin2012-05-084-0/+53
| | | | Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: add support for TXQ/TXF/DDX/DDY instructionsVadim Girlin2012-05-086-6/+43
| | | | Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: add support for VertexID, InstanceIDVadim Girlin2012-05-083-0/+50
| | | | Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: fix live-in handling for inputsVadim Girlin2012-05-082-2/+3
| | | | | | Set the input registers as live-in for entry basic block. Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: add support for v4i32Vadim Girlin2012-05-084-5/+20
| | | | Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: fix ABS_i32 instruction loweringVadim Girlin2012-05-081-2/+2
| | | | | | Swap source operands. Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: use integer comparison for IFVadim Girlin2012-05-081-2/+4
| | | | | | | Replacing "float equal to 1.0f" with "int not equal to 0". This should help for further optimization of boolean computations. Signed-off-by: Vadim Girlin <[email protected]>
* radeon/llvm: use bitcasts for integersVadim Girlin2012-05-083-5/+73
| | | | | | | | | We're using float as default type, so basically for every instruction that wants other types for dst/src operands we need to perform the bitcast to/from default float. Currently bitcast produces no-op MOV instruction, will be eliminated later. Signed-off-by: Vadim Girlin <[email protected]>
* r600g: Fix out of tree builds that use the LLVM backendTom Stellard2012-05-071-1/+1
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=49567
* radeon/llvm: Remove references to DebugFlag and isCurrentDebugType()Tom Stellard2012-05-074-22/+3
| | | | | | | These weren't being used at all and they were causing build failures when LLVM was built with NDEBUG defined and mesa was not. https://bugs.freedesktop.org/show_bug.cgi?id=49110
* i965/Gen7: Work around GPU hangs due to misaligned depth coordinate offsets.Paul Berry2012-05-072-0/+54
| | | | | | | | | | | | | | | | | | | | In i965 Gen7, Mesa has for a long time used the "depth coordinate offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to render to miplevels other than 0. Unfortunately, this doesn't work, because these offsets must be aligned to multiples of 8, and miplevels in the depth buffer are only guaranteed to be aligned to multiples of 4. When the offsets aren't aligned to a multiple of 8, the GPU sometimes hangs. As a temporary measure, to avoid GPU hangs, this patch smashes the 3 LSB's of "depth coordinate offset X/Y" to 0. This results in incorrect rendering to mipmapped depth textures, but that seems like a reasonable stopgap while we figure out a better solution. Avoids GPU hangs in piglit test "depthstencil-render-miplevels" at texture sizes that are not powers of 2. Reviewed-by: Chad Verace <[email protected]>
* i965/Gen6: Work around GPU hangs due to misaligned depth coordinate offsets.Paul Berry2012-05-072-0/+54
| | | | | | | | | | | | | | | | | | | | | | | In i965 Gen6, Mesa has for a long time used the "depth coordinate offset X/Y" settings (in 3DSTATE_DEPTH_BUFFER) to cause the GPU to render to miplevels other than 0. Unfortunately, this doesn't work, because these offsets must be aligned to multiples of 8, and miplevels in the depth buffer are only guaranteed to be aligned to multiples of 4. When the offsets aren't aligned to a multiple of 8, the GPU sometimes hangs. As a temporary measure, to avoid GPU hangs, this patch smashes the 3 LSB's of "depth coordinate offset X/Y" to 0. This results in incorrect rendering to mipmapped depth textures, but that seems like a reasonable stopgap while we figure out a better solution. (Note that we have only ever observed this GPU hang on Gen6 when HiZ is enabled, so another possible stopgap would be to disable HiZ). Avoids GPU hangs in piglit test "depthstencil-render-miplevels" at texture sizes that are not powers of 2. Reviewed-by: Chad Verace <[email protected]>
* fbo: Only reuse depth/stencil attachments if the parameters match.Paul Berry2012-05-071-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the user attaches a texture to one of the depth/stencil attachment points (GL_STENCIL_ATTACHMENT or GL_DEPTH_ATTACHMENT), we check to see if the same texture is also attached to the other attachment point, and if so, we re-use the existing texture attachment. This is necessary to ensure that if the user later queries what is attached to GL_DEPTH_STENCIL_ATTACHMENT, they will not receive an error. If, however, the user attaches buffers to the two different attachment points using different parameters (e.g. a different miplevel), then we can't re-use the existing texture attachment, because it is pointing to the wrong part of the texture. This might occur as a transitory condition if, for example, if the user attached miplevel zero of a texture to GL_STENCIL_ATTACHMENT and GL_DEPTH_ATTACHMENT, rendered to it, and then later attempted to attach miplevel one of the same texture to GL_STENCIL_ATTACHMENT and GL_DEPTH_ATTACHMENT. This patch causes Mesa to check that GL_STENCIL_ATTACHMENT and GL_DEPTH_ATTACHMENT use the same attachment parameters before attempting to share the texture attachment. On i965 Gen6, fixes piglit tests "texturing/depthstencil-render-miplevels 1024 depth_stencil_shared" and "texturing/depthstencil-render-miplevels 1024 stencil_depth_shared". Reviewed-by: Chad Versace <[email protected]>
* i965: Fix mipmap offsets for HiZ and separate stencil buffers.Paul Berry2012-05-078-60/+319
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When rendering to a miplevel other than 0 within a color, depth, stencil, or HiZ buffer, we need to tell the GPU to render to an offset within the buffer, so that the data is written into the correct miplevel. We do this using a coarse offset (in pages), and a fine adjustment (the so-called "tile_x" and "tile_y" values, which are measured in pixels). We have always computed the coarse offset and fine adjustment using intel_renderbuffer_tile_offsets() function. This worked fine for color and combined depth/stencil buffers, but failed to work properly when HiZ and separate stencil were in use. It failed to work because there is only one set of fine adjustment controls shared by the HiZ, depth, and stencil buffers, so we need to choose tile_x and tile_y values that are compatible with the tiling of all three buffers, and then compute separate coarse offsets for each buffer. This patch fixes the HiZ and separate stencil case by replacing the call to intel_renderbuffer_tile_offsets() with calls to two functions: intel_region_get_tile_masks(), which determines how much of the adjustment can be performed using offsets and how much can be performed using tile_x and tile_y, and intel_region_get_aligned_offset(), which computes the coarse offset. intel_region_get_tile_offsets() is still used for color renderbuffers, so to avoid code duplication, I've re-worked it to use intel_region_get_tile_masks() and intel_region_get_aligned_offset(). On i965 Gen6, fixes piglit tests "texturing/depthstencil-render-miplevels 1024 X" where X is one of (depth, depth_and_stencil, depth_stencil_single_binding, depth_x, depth_x_and_stencil, stencil, stencil_and_depth, stencil_and_depth_x). On i965 Gen7, the variants of "texturing/depthstencil-render-miplevels" that contain a stencil buffer still fail, due to another problem: Gen7 seems to ignore the 3 LSB's of the tile_y adjustment (and possibly also tile_x). v2: Removed spurious comments. Added assertions to check preconditions of intel_region_get_aligned_offset(). Reviewed-by: Chad Versace <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* intel: Disable ARB_framebuffer_object in ES contextsChad Versace2012-05-071-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes ARB_framebuffer_object from the GLES1 and GLES2 extension lists in intel_extensions_es.c. Fixes a crash in the Android browser on Ice Cream Sandwich. The Android browser crashed because it did the following, which is legal in GLES2 but not in ARB_framebuffer_object. glGenFramebuffers(1, &fb); glBindFramebuffer(GL_FRAMEBUFFER, fb); // render render render... glDeleteFramebuffers(1, &fb); // go do other stuff... glBindFramebuffer(GL_FRAMEBUFFER, fb); // This bind unexpectedly failed, and the app panics. The semantics of glBindFramebuffer specified by ARB_framebuffer_object (a desktop GL extension) and GLES2 specs are incompatible. The ideal solution to fix this is to create separate API entry points for glBindFramebuffer, one for GL and the other for GLES2. But, until that work is complete, disabling ARB_framebuffer_object in GLES2 contexts safely fixes the problem. Likewise, the semantics of glBindFramebuffer in ARB_framebuffer_object and of glBindFramebufferOES in OES_framebuffer_object (a GLES1 extension) are incompatible. Even though the functions have different names, the semantic difference still results in a bug because both API calls are implemented by a single function, _mesa_BindFramebufferEXT, which handles the semantic difference incorrectly. Again, disabling ARB_framebuffer_object in GLES1 contexts safely fixes this problem. According to the ARB_framebuffer_object spec, the extension is an amalgamation of EXT_framebuffer_object EXT_framebuffer_blit EXT_packed_depth_stencil EXT_framebuffer_multisample By disabling this extension, however, no functionality is removed from GLES1 and GLES2 contexts because 1) the first three extensions are explicitly enabled in Intel's ES extension lists and 2) no functionality of the last extension is exposed in an ES context. Note: This is a candidate for the 8.0 branch. See-also: http://www.mail-archive.com/[email protected]/msg21006.html CC: Charles Johnson <[email protected]> CC: Sean Kelley <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Signed-off-by: Chad Versace <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 06:01:33 +0000