summaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* i965: Allocate just enough space for user clip planes in uniform arrays.Kenneth Graunke2013-08-281-2/+4
| | | | | | | | | | | | | | | | | | | | | | Previously, we allocated space in brw_vs_prog_data's params and pull_params arrays for MAX_CLIP_PLANES vec4s---even when it wasn't necessary. On a 64-bit architecture, this used 0.5 kB of space (8 clip planes * 4 floats per plane * 8 bytes per float pointer * 2 arrays of pointers = 512 bytes). Since this cost was per-vertex shader, it added up. Conveniently, we already store the number of clip plane constants in the program key. By using that, we can allocate the exact amount of space needed. For the common case where user clipping is disabled, this means 0 bytes. While we're here, mention exactly what code requires this extra space, since it wasn't obvious. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Silence unused variable warning in release buildChad Versace2013-08-281-1/+1
| | | | | | | | | | | Use `(void) success;` to silence this warning: i965/brw_vs.c:481:12: warning: unused variable 'success' [-Wunused-variable] bool success = do_vs_prog(brw, ctx->Shader.CurrentVertexProgram, Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa/main: Check for 0 size draws after validation.Fabian Bieler2013-08-272-21/+42
| | | | | | | | | | | | | | | | | | | When validating draw parameters move check for 0 draw count last (drawing with count 0 is not an error), so that other parameters (e.g.: the primitive type) are validated and the correct errors (if applicable) are generated. >From the OpenGL 3.3 spec page 33 (page 48 of the PDF): "[Regarding DrawArraysOneInstance, in terms of which other draw operations are defined:] If count is negative, an INVALID_VALUE error is generated." This patch also changes the bahavior of MultiDrawElements to perform the draw operation if some primitive's index counts are zero. Signed-off-by: Fabian Bieler <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/vs: Add support for translating ir_triop_fma into MAD.Matt Turner2013-08-272-0/+12
| | | | | Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/fs: Add support for translating ir_triop_fma into MAD.Matt Turner2013-08-274-0/+10
| | | | Reviewed-by: Ian Romanick <[email protected]>
* i965/fs: Assert that ir_expressions are usable by 3-src instructions.Matt Turner2013-08-271-0/+1
| | | | | | | MAD will be generated directly from ir_triop_fma, so this assertion checks that all ir_expressions are usable. Reviewed-by: Paul Berry <[email protected]>
* glsl: Add support for new fma built-in in ARB_gpu_shader5.Matt Turner2013-08-272-0/+2
| | | | | | v2: Add constant folding support. Reviewed-by: Paul Berry <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i915: Optimize SEQ and SNE when two operands are uniformsIan Romanick2013-08-261-12/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SEQ and SNE are not native i915 instructions, so they each generate at least 3 instructions. If both operands are uniforms or constants, we get 5 instructions like: U[1] = MOV CONST[1] U[0].xyz = SGE CONST[0].xxxx, U[1] U[1] = MOV CONST[1].-x-y-z-w R[0].xyz = SGE CONST[0].-x-x-x-x, U[1] R[0].xyz = MUL R[0], U[0] This code is stupid. Instead of having the individual calls to i915_emit_arith generate the moves to utemps, do it in the caller. This results in code like: U[1] = MOV CONST[1] U[0].xyz = SGE CONST[0].xxxx, U[1] R[0].xyz = SGE CONST[0].-x-x-x-x, U[1].-x-y-z-w R[0].xyz = MUL R[0], U[0] This allows fs-temp-array-mat2-index-col-wr and fs-temp-array-mat2-index-row-wr to fit in hardware limits (instead of falling back to software rasterization). NOTE: Without pending patches to the piglit tests, these tests will now fail. This is an unrelated, pre-existing issue. v2: Copy most of the body of the commit message into comments in the code. Suggested by Eric. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* swrast: init i0, i1 values to silence warningsBrian Paul2013-08-261-0/+1
| | | | Reviewed-by: Chad Versace <[email protected]>
* mesa: init dst values in COPY_CLEAN_4V_TYPE_AS_FLOAT()Brian Paul2013-08-261-1/+2
| | | | | | to silence gcc 4.8.1 warnings. And improve the ASSERT(0) call. Reviewed-by: Chad Versace <[email protected]>
* i965/vs: Allocate register set once at context creation.Kenneth Graunke2013-08-263-4/+6
| | | | | | | | | | Now that we use a fixed set of register classes, we can set up the register set and conflict graphs once, at context creation, rather than on every VS compile. This is obviously less expensive, and also what we already do in the FS backend. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/vs: Move base_reg_count computation to brw_alloc_reg_set().Kenneth Graunke2013-08-261-3/+4
| | | | | | | | We're soon going to be calling brw_alloc_reg_set() from outside of the visitor, where we don't have the precomputed "max_grf" variable handy. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/vs: Expose the payload registers to the register allocator.Kenneth Graunke2013-08-262-6/+36
| | | | | | | | | | | | | | | For now, nothing else can get allocated over them. That may change at some point in the future. This also means that base_reg_count can be computed without knowing the number of registers used for the payload, which is required if we want to allocate the register set once at context creation time. See commit 551e1cd44f6857f7e29ea4c8f892da5a97844377, which implemented virtually identical code in the FS backend. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/vs: Use a fixed set of register classes.Kenneth Graunke2013-08-261-37/+13
| | | | | | | | | | | Arrays, structures, and matrices use large VGRFs of arbitrary sizes. However, split_virtual_grfs() breaks those down into VGRFs of size 1. For reference, commit 5d90b988791e51cfb6413109271ad102fd7a304c is the analogous change to the FS backend. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Allow C++ type safety in the use of enum brw_urb_write_flags.Paul Berry2013-08-267-11/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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: Remove redundant (and uninitialized) field vec4_generator::ctx.Paul Berry2013-08-262-3/+2
| | | | | | | | | | | | | We never noticed that this field was uninitialized because it is only used in an error path that reports internal Mesa errors. But it's silly to have it around anyway because &brw->ctx is equivalent. Should fix Coverity defect CID 1063351: Uninitialized pointer field (UNINIT_CTOR) /src/mesa/drivers/dri/i965/brw_vec4_emit.cpp: 148 Reviewed-by: Ian Romanick <[email protected]>
* i965: Don't try to fall back when creating unrecognized program targets.Paul Berry2013-08-261-1/+2
| | | | | | | | | | | | | | If brwNewProgram is asked to create a program for an unrecognized target, don't bother falling back on _mesa_new_program(). That just hides bugs. Reviewed-by: Matt Turner <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> v2: Use assert() rather than _mesa_problem(). Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* mesa: Set query->EverBound in glQueryCounter().Kenneth Graunke2013-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | | glIsQuery is supposed to return false for names returned by glGenQueries until their first use. BeginQuery is a use, but QueryCounter is also a use. From the ARB_timer_query spec: "A timer query object is created with the command void QueryCounter(uint id, enum target); [...] If <id> is an unused query object name, the name is marked as used [...]" Fixes Piglit's spec/ARB_timer_query/query-lifetime. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]> Cc: [email protected]
* i965/gs: Add a data structure for tracking VS output VUE map.Paul Berry2013-08-232-1/+16
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Make a function for setting up vec4 program key clip info.Paul Berry2013-08-232-6/+24
| | | | | | | | This functionality will need to be reused by geometry shaders. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Make prim_to_hw_prim accessible outside brw_draw.c.Paul Berry2013-08-232-1/+3
| | | | | | | | | We will need access to this array in order to configure the geometry shader. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: add GS visitors.Paul Berry2013-08-233-0/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces the vec4_gs_visitor class, which translates geometry shaders from GLSL IR to back-end opcodes. This class is derived from vec4_visitor (which is also the base class for vec4_vs_visitor), so as a result most of the back end code is shared. The only parts that differ are: - Geometry shaders use a different input payload organization, since the inputs need to match up with the outputs of the previous pipeline stage (vec4_gs_visitor::setup_payload() and vec4_gs_visitor::setup_varying_inputs()). - Geometry shader input array dereferences need a special stride computation, since all geometry shader inputs are interleaved into one giant array (vec4_gs_visitor::compute_array_stride()). - There are no geometry shader system values (vec4_gs_visitor::make_reg_for_system_value()). - At the beginning of a geometry shader, extra data in R0 needs to be zeroed out, and a vertex counter needs to be initialized (vec4_gs_visitor::emit_prolog()). - When EmitVertex() appears in the shader, the current contents of output variables need to be emitted to the URB, and the vertex counter needs to be incremented (vec4_gs_visitor::visit(ir_emit_vertex *)). - When generating a URB_WRITE message to output vertex data, the current state of the vertex counter needs to be used to store a write offset in the message header (vec4_gs_visitor::emit_urb_write_header()). - The URB_WRITE message that outputs vertex data needs to be sent using GS_OPCODE_URB_WRITE, since VS_OPCODE_URB_WRITE would overwrite the offsets in the message header (vec4_gs_visitor::emit_urb_write_opcode()). - At the end of a geometry shader, the final vertex count needs to be delivered using a URB WRITE message (vec4_gs_visitor::emit_thread_end()). - EndPrimitive() functionality is not implemented yet (vec4_gs_visitor::visit(ir_end_primitive *)). - There is no support for assembly shaders (vec4_gs_visitor::emit_program_code()). v2: Make num_input_vertices const. Refer to registers as rN rather than gN, for consistency with the PRM. Fix misspelling. Improve comment in the ir_emit_vertex visitor explaining why we emit vertices inside a conditional. Enclose the conditional code in the ir_emit_vertex visitor between curly braces. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add GS_OPCODE_SET_DWORD_2_IMMED.Paul Berry2013-08-234-0/+28
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add GS_OPCODE_SET_VERTEX_COUNT.Paul Berry2013-08-234-0/+45
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add GS_OPCODE_SET_WRITE_OFFSET.Paul Berry2013-08-234-0/+57
| | | | | | | | v2: Added a comment to vec4_generator::generate_gs_set_write_offset(). Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add GS_OPCODE_THREAD_END.Paul Berry2013-08-235-0/+32
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add GS_OPCODE_URB_WRITE.Paul Berry2013-08-235-4/+38
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add a flag allowing URB write messages to use a per-slot offset.Paul Berry2013-08-232-2/+8
| | | | | | | | | | This will be used by geometry shaders to implement the EmitVertex() function, since it requires writing data to a dynamically-determined offset within the geometry shader's URB entry. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Combine 4 boolean args of brw_urb_WRITE into a flags bitfield.Paul Berry2013-08-2312-71/+76
| | | | | | | | | | | | 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/gs: Add a case to brwNewProgram() for geometry shaders.Paul Berry2013-08-231-0/+11
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Create structs for use by GS program compilation.Paul Berry2013-08-231-0/+23
| | | | | | | | v2: Make id "unsigned" rather than "GLuint". Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add a case to brwBindProgram() for geometry shaders.Paul Berry2013-08-231-0/+3
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/gs: Add brw->geometry_program.Paul Berry2013-08-232-0/+8
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Virtualize setup_payload instead of setup_attributes.Paul Berry2013-08-233-6/+5
| | | | | | | | | | | | | | | | | | | When I initially generalized the vec4_visitor class in preparation for geometry shaders, I assumed that the setup_attributes() function would need to be different between vertex and geometry shaders, but its caller, setup_payload(), could be shared. So I made setup_attributes() a virtual function. It turns out this isn't true; setup_payload() needs to be different too, since the geometry shader payload sometimes includes an extra register (primitive ID) that has to come before uniforms. So setup_payload() needs to be the virtual function instead of setup_attributes(). Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Allow for dispatch_grf_start_reg to vary.Paul Berry2013-08-237-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both 3DSTATE_VS and 3DSTATE_GS have a dispatch_grf_start_reg control, which determines the register where the hardware delivers data sourced from the URB (push constants followed by per-vertex input data). For vertex shaders, we always set dispatch_grf_start_reg to 1, since R1 is always the first register available for push constants in vertex shaders. For geometry shaders, we'll need the flexibility to set dispatch_grf_start_reg to different values depending on the behvaiour of the geometry shader; if it accesses gl_PrimitiveIDIn, we'll need to set it to 2 to allow the primitive ID to be delivered to the thread in R1. This patch eliminates the assumption that dispatch_grf_start_reg is always 1. In vec4_visitor, we record the regnum that was passed to vec4_visitor::setup_uniforms() in prog_data for later use. In vec4_generator, we consult this value when converting an abstract UNIFORM register to a concrete hardware register. And in the code that emits 3DSTATE_VS, we set dispatch_grf_start_reg based on the value recorded in prog_data. This will allow us to set dispatch_grf_start_reg to the appropriate value when compiling geometry shaders. Vertex shaders will continue to always use a dispatch_grf_start_reg of 1. v2: Make dispatch_grf_start_reg "unsigned" rather than "GLuint". Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965/vec4: Move vec4 data structures and functions to brw_vec4.{cpp,h}.Paul Berry2013-08-234-64/+72
| | | | | | | | | | | | | | | | This patch moves the following things into brw_vec4.{cpp,h}: - struct brw_vec4_compile - struct brw_vec4_prog_key - brw_vec4_prog_data_compare() - brw_vec4_prog_data_free() This will allow us to avoid having to include brw_vs.h in geometry-shader-specific files. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Make brw_{shader,vec4}.h safe to include from C.Paul Berry2013-08-232-2/+15
| | | | | | | | | | | | | | The patch that follows will move the definition of struct brw_vec4_prog_key from brw_vs.h to brw_vec4.h, making it necessary for brw_vs.h to include brw_vec4.h (because brw_vs.h defines struct brw_vs_prog_key, which contains brw_vec4_prog_key as a member). Since brw_vs.h is included from C source files, that means that brw_vec4.h will need to be safe to include from C. Same for brw_shader.h, since it is included by brw_vec4.h. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Stop including brw_vs.h from brw_vec4.h.Paul Berry2013-08-236-1/+9
| | | | | | | | | | | | | | | | This is backwards from what we are going to want in the long term, which is: - brw_vec4.h declares general-purpose vec4 infrastructure needed by both VS and GS - brw_vs.h includes brw_vec4.h and adds VS-specific parts. - brw_gs.h includes brw_vec4.h and adds GS-specific parts. Note that at the moment brw_vec.h contains a fair amount of VS-specific declarations--I plan to address that in a later patch. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Initialize all elements of ctx->ShaderCompilerOptions.Paul Berry2013-08-231-1/+1
| | | | | | | | | Otherwise any GS that requires lowering (e.g. one that uses gl_ClipDistance as an input or output) will fail to work. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* i965: Make brw_{program,vs}.h safe to include from C++.Paul Berry2013-08-233-1/+17
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* mesa/program: Make prog_instruction.h and program.h safe to include from C++.Paul Berry2013-08-232-0/+16
| | | | | | Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* glsl: Refactor handling of gl_ClipDistance/gl_ClipVertex linkage rules for GS.Paul Berry2013-08-232-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch extracts the following logic from validate_vertex_shader_executable(): (a) Generate an error if the shader writes to both gl_ClipDistance and gl_ClipVertex. (b) Record whether the shader writes to gl_ClipDistance in gl_shader_program for use by the back-end. (c) Record the size of gl_ClipDistance in gl_shader_program for use by transform feedback logic. And moves it into a function that is shared between vertex and geometry shaders. Strictly speaking we only need to have shared logic for (b) and (c) right now (since (a) only matters in compatibility contexts, and we're only implementing geometry shaders in core contexts right now). But the three are closely related enough that it seems sensible to keep them together. Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Matt Turner <[email protected]>
* mesa: Fix assertion error with glDebugMessageControlTimothy Arceri2013-08-231-13/+2
| | | | | | | | | | | enums were being converted twice resulting in incorrect values. The extra conversion has been removed and the redundant assert is removed also. Cc: 9.2 <[email protected]> Signed-off-by: Timothy Arceri <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Specify a better GL_MAX_SERVER_WAIT_TIMEOUT limit.Kenneth Graunke2013-08-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The previous value of (GLuint64) ~0 has some problems: GL_MAX_SERVER_WAIT_TIMEOUT is supposed to be a GLuint64 value, but has to be queried via GetInteger64v(), which returns a GLint64. This means that some applications are likely to treat it as a signed integer, where ~0 means -1. Negative values are nonsensical and problematic. When interpreted correctly, ~0 translates to about 0.58 million years, which seems rather excessive. This patch changes it to 0x1fff7fffffff, which is about 1.11 years. This is still plenty long, and is the same as both an int64 and uint64. Applications that accidentally store it in a 32-bit int/unsigned also get a non-negative value, which is again the same as both int and unsigned. This value was suggested by Ian Romanick. v2: Add the ULL prefix on the constant (suggested by Ian). Fixes Piglit's spec/!OpenGL 3.2/get-integer-64v. Signed-off-by: Kenneth Graunke <[email protected]> Cc: [email protected]
* meta: Set correct viewport and projection in decompress_texture_image.Kenneth Graunke2013-08-221-0/+5
| | | | | | | | | | | | | | | | _mesa_meta_begin() sets up an orthographic project and initializes the viewport based on the current drawbuffer's width and height. This is likely the window size, since it occurs before the meta operation binds any temporary buffers. decompress_texture_image needs the viewport to be the size of the image it's trying to draw. Otherwise, it may only draw part of the image. v2: Actually set the projection properly too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68250 Signed-off-by: Kenneth Graunke <[email protected]> Cc: Mak Nazecic-Andrlon <[email protected]>
* i965: Fix misapplication of gles3 srgb workaroundChad Versace2013-08-221-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes inconsistent failure of gles2conform/GL2Tests/glUniform/glUniform.test under gnome-shell. What follows is a description of the bug and its fix. When intel_update_renderbuffers() allocates a miptree for a winsys renderbuffer, it propagates the renderbuffer's format to become also the miptree's format. If the winsys color buffer format is SARGB, then, in the first call to eglMakeCurrent, intel_gles3_srgb_workaround() changes the renderbuffer's format to ARGB. That is, it changes the format from sRGB to non-sRGB. However, it changes the renderbuffer's format *after* intel_update_renderbuffers() has allocated the renderbuffer's miptree. Therefore, when eglMakeCurrent returns, the miptree format (SARGB) differs from the renderbuffer format (ARGB). If the X server reallocates the color buffer, intel_update_renderbuffers() will create a new miptree for the renderbuffer. The new miptree's format (ARGB) will differ from old miptree's format (SARGB). This mismatch between old and new miptrees causes bugs. Fix the bug by moving intel_gles3_srgb_workaround() to occur *before* intel_update_renderbuffers(). CC: "9.2" <[email protected]> Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67934 Signed-off-by: Chad Versace <[email protected]>
* i965/fs: Add code to print out global copy propagation sets.Kenneth Graunke2013-08-211-0/+30
| | | | | | | | | This was invaluable when debugging the global copy propagation algorithm. We may as well commit it in case someone needs to print out the sets in the future. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* osmesa: Symlink shared library to LIB_DIRArmin K2013-08-211-0/+1
| | | | | | Cc: 9.2 <[email protected]> Tested-by: Brian Paul <brianp at vmware.com> Reviewed-by: Brian Paul <brianp at vmware.com>
* i965/gen7: Set MOCS L3 cacheability for IVB/BYT (v2)Ville Syrjälä2013-08-218-17/+12
| | | | | | | | | | | | | | | | IVB/BYT also has the same L3 cacheability control in MOCS as HSW, so let's make use of it. pts/xonotic and pts/reaction @ 1920x1080 gain ~4% on my IVB GT2. Most other things show less gains/no regressions, except furmark which loses some 10 points. I didn't have a BYT at hand for testing. v2: Don't check (brw->gen == 7) in gen7 functions. (chadv) Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965/hsw: Populate MOCS for STATE_BASE_ADDRESS (v2)Ville Syrjälä2013-08-212-3/+11
| | | | | | | | | | | Just spotted these unpopulated MOCS fields when comparing the code against BSpec. Set the MOCS to the same as everywhere else in Haswell: L3-cacheable. v2: Annotate state packet fields (chadv). Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Chad Versace <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 10:58:25 +0000