aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* i915: Fork the shared code from i965.Eric Anholt2013-06-2643-25/+14731
| | | | | | | | | | | | | Of this 15000 lines of code in intel/, we've identified 4000 lines that are trivially unnecessary for i915, and another 1000 that are pointless for i965, and expect to find more as time goes on. Split the i915 driver off, so that we can continue active development on i965 without worrying about breaking i915. Acked-by: Kenneth Graunke <[email protected]> Acked-by: Chad Versace <[email protected]> Acked-by: Adam Jackson <[email protected]> (and I hear second hand that idr is OK with it, too)
* i915: Remove dead symlink.Eric Anholt2013-06-261-1/+0
|
* glx: Fix another missed glMultiDrawElementsEXT const change.Eric Anholt2013-06-261-1/+1
| | | | | The build was broken for me since b7d9478f36bde0f7b27321378c1bb799fdd4eaa1.
* glsl: Move all var decls to the front of the IR list in reverse orderIan Romanick2013-06-261-0/+18
| | | | | | | | | | | | | | | | | | This has the (intended!) side effect that vertex shader inputs and fragment shader outputs will appear in the IR in the same order that they appeared in the shader code. This results in the locations being assigned in the declared order. Many (arguably buggy) applications depend on this behavior, and it matches what nearly all other drivers do. Fixes the (new) piglit test attrib-assignments. NOTE: This is a candidate for stable release branches (and requires the previous commit to prevent a regression in OpenGL ES 2.0 conformance test stencil_plane_operation). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* i965: Be more careful with the interleaved user array upload optimizationIan Romanick2013-06-261-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | The checks to determine when the data can be uploaded in an interleaved fashion can be tricked by certain data layouts. For example, float data[...]; glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 16, &data[0]); glVertexAttribPointer(1, 4, GL_FLOAT, GL_FALSE, 16, &data[4]); glDrawArrays(GL_POINTS, 0, 1); will hit the interleaved path with an incorrect size (16 bytes instead of 32 bytes). As a result, the data for attribute 1 never gets uploaded. The single element draw case is the only sensible case I can think of for non-interleaved-that-looks-like-interleaved data, but there may be others as well. To fix this, make sure that the end of the element in the array being checked is within the stride "window." Previously the code would check that the begining of the element was within the window. NOTE: This is a candidate for stable branches. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Eric Anholt <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* mesa: add const qualifier to glMultiDrawElementsEXT() indices paramBrian Paul2013-06-263-3/+3
| | | | | | | | | | The 20130624 version of glext.h changed this to match the glMultiDrawElements() function which already had the extra const qualifier. Fixes warnings/errors that seem to vary from one compiler to the next. Reviewed-by: Jose Fonseca <[email protected]>
* mesa: remove const from glDebugMessageCallbackARB() function parameterBrian Paul2013-06-263-4/+4
| | | | | | | The new 20130624 version of glext.h removed the const qualifier on the 'userParam' parameter. Reviewed-by: Jose Fonseca <[email protected]>
* i965/vs: Combine code generation's inst->opcode switch statements.Kenneth Graunke2013-06-261-163/+166
| | | | | | | | | | | | | | | | | | | vec4_visitor::generate_code() switches on vec4_instruction::opcode and calls into the brw_eu_emit.c layer to generate code for some of them. It then has a default case which calls generate_vec4_instruction() to handle the rest...which switches on opcode and handles the rest of the cases. The split apparently is that generate_code() handles the actual hardware opcodes (BRW_OPCODE_*) while generate_vec4_instruction() handles the virtual opcodes (SHADER_OPCODE_* and VS_OPCODE_*). But this looks fairly arbitrary, and it makes more sense to combine the two switches. This patch moves the cases from generate_code() into the helper function so that generate_code() isn't as large. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* i965: Remove broken source type assertions from brw_alu3().Kenneth Graunke2013-06-261-14/+5
| | | | | | | | | | | | | | | | | | | Commit 526ffdfc033ab01cf133cb7e8290c65d12ccc9be attempted to generalize the source register type assertions to allow D and UD. However, the src1 and src2 assertions actually checked src0.type against D and UD due to a copy and paste bug. It also began setting the source and destination register types based on dest.type, ignoring src0/src1/src2.type completely. BFE and BFI2 may actually pass mixed D/UD types and expect them to be ignored, which is arguably a bit sloppy, but not too crazy either. This patch simply removes the source register assertions as those values aren't used anyway. It also clarifies the comment above the block that sets the register types. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965: Add back strict type assertions for MAD and LRP.Kenneth Graunke2013-06-261-2/+16
| | | | | | | | | | | | Commit 526ffdfc033ab01cf133cb7e8290c65d12ccc9be relaxed the type assertions in brw_alu3 to allow D/UD types (required by BFE and BFI2). This lost us the strict type checking for MAD and LRP, which require all four types to be float. This patch adds a new ALU3F wrapper which checks these once again. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* glsl: Streamline the built-in type handling code.Kenneth Graunke2013-06-266-694/+424
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Over the last few years, the compiler has grown to support 7 different language versions and 6 extensions that add new built-in types. With more and more features being added, some of our core code has devolved into an unmaintainable spaghetti of sorts. A few problems with the old code: 1. Built-in types are declared...where exactly? The types in builtin_types.h were organized in arrays by the language version or extension they were introduced in. It's factored out to avoid duplicates---every type only exists in one array. But that means that sampler1D is declared in 110, sampler2D is in core types, sampler3D is a unique global not in a list...and so on. 2. Spaghetti call-chains with weird parameters: generate_300ES_types calls generate_130_types which calls generate_120_types and generate_EXT_texture_array_types, which calls generate_110_types, which calls generate_100ES_types...and more Except that ES doesn't want 1D types, so we have a skip_1d parameter. add_deprecated also falls into this category. 3. Missing type accessors. Common types have convenience pointers (like glsl_type::vec4_type), but others may not be accessible at all without a symbol table (for example, sampler types). 4. Global variable declarations in a header file? #include "builtin_types.h" in two C++ files would break the build. The new code addresses these problems. All built-in types are declared together in a single table, independent of when they were introduced. The macro that declares a new built-in type also creates a convenience pointer, so every type is available and it won't get out of sync. The code to populate a symbol table with the appropriate types for a particular language version and set of extensions is now a single table-driven function. The table lists the type name and GL/ES versions when it was introduced (similar to how the lexer handles reserved words). A single loop adds types based on the language version. Explicit extension checks then add additional types. If they were already added based on the language version, glsl_symbol_table simply ignores the request to add them a second time, meaning we don't need to worry about duplicates and can simply list types where they belong. v2: Mark uvecs and shadow samplers as ES3 only, and 1DArrayShadow as unsupported in ES entirely. Add a touch more doxygen. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Don't use random pointers as an array of glsl_type objects.Kenneth Graunke2013-06-261-1/+1
| | | | | | | | | | | | Using a random glsl_type convenience pointer as an array is a really bad idea, for all the reasons mentioned in the previous commit. The new glsl_type::bvec() function is simpler anyway. Prevents breakage in the next commit. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Stop being clever with pointer arithmetic when fetching types.Kenneth Graunke2013-06-261-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Currently, vector types are linked together closely: the glsl_type objects for float, vec2, vec3, and vec4 are all elements of the same array, in that exact order. This makes it possible to obtain vector types via pointer arithmetic on the scalar type's convenience pointer. For example, float_type + (3 - 1) = vec3. However, relying on this is extremely fragile. There's no particular reason the underlying type objects need to be stored in an array. They could be individual class members, possibly with padding between them. Then the pointer arithmetic would break, and we'd get bad pointers to non-heap allocated data, causing subtle breakage that can't be detected by valgrind. Cue insanity. Or someone could simply reorder the type variables, causing us to get the wrong type entirely. Also cue insanity. Writing this explicitly is much safer. With the new helper functions, it's a bit less code even. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* glsl: Add simple vector type accessor helpers.Kenneth Graunke2013-06-262-0/+61
| | | | | | | | | | | | | | | | This patch introduces new functions to quickly grab a pointer to a vector type. For example: glsl_type::bvec(4) returns glsl_type::bvec4_type glsl_type::ivec(3) returns glsl_type::ivec3_type glsl_type::uvec(2) returns glsl_type::uvec2_type glsl_type::vec(1) returns glsl_type::float_type This is less wordy than glsl_type::get_instance(GLSL_TYPE_BOOL, 4, 1), which can help avoid extra word wrapping. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: update glext.h to version 20130624Brian Paul2013-06-262-10434/+8470
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In glapi_priv.h we always need the typedef for the GLclampx type since GL_OES_fixed_point is now defined in glext.h but the GLclampx type is not. GLclampx is not used by anything in glext.h but we need it for GL ES dispatch. This is a huge patch because the structure of the file has been changed. The following extensions are new, however: GL_AMD_interleaved_elements GL_AMD_shader_trinary_minmax GL_IBM_static_data GL_INTEL_map_texture GL_NV_compute_program5 GL_NV_deep_texture3D GL_NV_draw_texture GL_NV_shader_atomic_counters GL_NV_shader_storage_buffer_object GL_NVX_conditional_render GL_OES_byte_coordinates GL_OES_compressed_paletted_texture GL_OES_fixed_point GL_OES_query_matrix GL_OES_single_precision And these extensions were removed: GL_FfdMaskSGIX GL_INGR_palette_buffer GL_INTEL_texture_scissor GL_SGI_depth_pass_instrument GL_SGIX_fog_scale GL_SGIX_impact_pixel_texture GL_SGIX_texture_select Reviewed-by: José Fonseca <[email protected]>
* st/mesa: add casts to silence MSVC warningsBrian Paul2013-06-265-8/+8
|
* st/mesa: make rtt_level, face, slice unsigned to silence MSVC warningsBrian Paul2013-06-261-1/+1
|
* hud: add float casts to silence MSVC warningsBrian Paul2013-06-261-49/+49
|
* hud: include stdio.h since we use fprintf(), fscanf(), etcBrian Paul2013-06-261-0/+2
|
* hud: add cast to silence MSVC warningBrian Paul2013-06-261-1/+1
|
* os: add cast in os_time_sleep() to silence MSVC warningBrian Paul2013-06-261-1/+1
|
* vega: add some casts to silence MSVC warningsBrian Paul2013-06-262-11/+11
|
* util: int/unsigned changes to silence some MSVC warningsBrian Paul2013-06-262-3/+3
|
* util: add some casts to silence some MSVC warningsBrian Paul2013-06-261-2/+2
|
* util: s/int/unsigned/ to silence some MSVC warningsBrian Paul2013-06-261-2/+2
|
* nvc0: set rsvd_kick correctlyMaarten Lankhorst2013-06-261-0/+1
| | | | | | | | | This prevents trampling beyond the end of the command stream during flushes. NOTE: This is a candidate for the stable branches. Reported-by: Christoph Bumiller <[email protected]> Signed-off-by: Maarten Lankhorst <[email protected]>
* nvc0: fix push_space checks for video decodingMaarten Lankhorst2013-06-264-9/+10
|
* ilo: Remove max_threads dead code path.Vinson Lee2013-06-261-3/+0
| | | | | | | | | max_threads cannot be greater than 28. It is either 21 or 28. Fixes "Logically dead code" defect reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Chia-I Wu <[email protected]>
* winsys/intel: fix typo in "ETIMEOUT"Jean-Sébastien Pédron2013-06-261-1/+1
| | | | | | | | Should be "ETIMEDOUT". [olv: commit message slightly re-formatted] Reviewed-by: Chia-I Wu <[email protected]>
* ilo: use a bitmask for enabled constant buffersChia-I Wu2013-06-262-11/+14
| | | | | Looping over 4 * 13 constant buffers while in most cases only two are enabled is stupid.
* vl/mpeg12: handle mpeg-1 bitstreams more correctlyMaarten Lankhorst2013-06-261-5/+16
| | | | | Add support for D-frames. Add support for slices ending on a different horizontal row of macroblocks.
* ilo: support PIPE_CAP_USER_INDEX_BUFFERSChia-I Wu2013-06-269-36/+97
| | | | | | | | We want to access the user buffer, if available, when primitive restart is enabled and the restart index/primitive type is not natively supported. And since we are handling index buffer uploads in the driver with this change, we can also work around misalignment of index buffer offsets.
* ilo: make pipe_draw_info a context stateChia-I Wu2013-06-269-39/+33
| | | | | | Rename ilo_finalize_states() to ilo_finalize_3d_states(), and bind pipe_draw_info to the context when it is called. This saves us from having to pass pipe_draw_info around in several places.
* ilo: support PIPE_CAP_USER_CONSTANT_BUFFERSChia-I Wu2013-06-265-23/+88
| | | | We need it for HUD support, and will need it for push constants in the future.
* i915: Drop dead batch dumping code.Eric Anholt2013-06-263-860/+0
| | | | | | Batch dumping is now handled by shared code in libdrm. Acked-by: Kenneth Graunke <[email protected]>
* intel: Drop little bits of dead code.Eric Anholt2013-06-265-15/+0
| | | | | | I noticed these while building the fork-i915 branch. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Stop recomputing the miptree's size from the texture image.Eric Anholt2013-06-262-13/+7
| | | | | | | We've already computed what the dimensions of the miptree are, and stored it in the miptree. Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Drop unused argument to translate_tex_format().Eric Anholt2013-06-263-4/+0
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen4-5: Stop using bogus polygon_offset_scale field.Eric Anholt2013-06-263-20/+1
| | | | | | | | | | | | | | | | | | | | The polygon offset math used for triangles by the WM is "OffsetUnits * 2 * MRD + OffsetFactor * m" where 'MRD' is the minimum resolvable difference for the depth buffer (~1/(1<<16) or ~1/(1<<24)), 'm' is the approximated slope from the GL spec, and '2' is this magic number from the original i965 code dump that we deviate from the GL spec by because "it makes glean work" (except that it doesn't, because of some hilarity with 0.5 * approximately 2.0 != 1.0. go glean!). This clipper code for unfilled polygons, on the other hand, was doing "OffsetUnits * garbage + OffsetFactor * m", where garbage was MRD in the case of 16-bit depth visual (regardless the FBO's depth resolution), or 128 * MRD for 24-bit depth visual. This change just makes the unfilled polygons behavior match the WM's filled polygons behavior. Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Use the current drawbuffer's depth for polygon offset scale.Eric Anholt2013-06-261-1/+1
| | | | | | | There's no reason to care about the window system visual's depth for handling polygon offset in an FBO, and it could only lead to pain. Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Add perf debug for glCopyPixels() fallback checks.Eric Anholt2013-06-261-33/+39
| | | | | | | | | The separate function for the fallback checks wasn't particularly clarifying things, so I put the improved checks in the caller. (Note that the dropped _mesa_update_state() had already happened once at the start of the caller) Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Add debug to INTEL_DEBUG=blorp describing hiz/blit/clear ops.Eric Anholt2013-06-263-0/+39
| | | | | | | | | | | | | I think we've all added instrumentation at one point or another to see what's being called in blorp. Now you can quickly get output like: Testing glCopyPixels(depth). intel_hiz_exec depth clear to mt 0x16d9160 level 0 layer 0 intel_hiz_exec depth resolve to mt 0x16d9160 level 0 layer 0 intel_hiz_exec hiz ambiguate to mt 0x16d9160 level 0 layer 0 intel_hiz_exec depth resolve to mt 0x16d9160 level 0 layer 0 Reviewed-by: Kenneth Graunke <[email protected]>
* ra: Fix register spilling.Eric Anholt2013-06-261-5/+39
| | | | | | | | | | | | Commit 551c991606e543c3a264a762026f11348b37947e tried to avoid spilling registers that were trivially colorable. But since we do optimistic coloring, the top of the stack also contains nodes that are not trivially colorable, so we need to consider them for spilling (since they are some of our best candidates). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58384 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63674 NOTE: This is a candidate for the 9.1 branch.
* i965/fs: Dump IR when fatally not compiling due to bad register spilling.Eric Anholt2013-06-261-1/+2
| | | | | | It should never happen, but it does, and at this point, you're going to _mesa_problem() and abort() (unless it's just in precompile). Give the developer something to look at.
* xmlpool/build: Make sure to set mo properlyNaohiro Aota2013-06-251-1/+1
| | | | | | | | | | Some shells does not set variables sequentially in a statement i.e. "a=X b=${a}" won't set "b" to "X" but empty value. This patch introduce ";" to make sure "mo" is set properly before "lang" assignment. Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=471302
* i965: Remove the rest of brw_update_draw_buffer().Eric Anholt2013-06-251-27/+5
| | | | | | | | | | | The last piece of code with an effect was flagging _NEW_BUFFERS. Only, that is already flagged from everything that calls this function: Mesa GL state updates flag it before even calling down into the driver, and the calls from the DRI2 window system framebuffer update path end up flagging it as part of the ResizeBuffers() hook. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Stop updating FBO state on drawbuffers change.Eric Anholt2013-06-251-8/+0
| | | | | | | | The computed fields are updated appropriately as part of the normal draw call path due to _NEW_BUFFERS being set. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Stop recomputing drawbuffer bounds on drawbuffer change.Eric Anholt2013-06-251-2/+0
| | | | | | | | | For winsys FBOs, the bounds are appropriately updated immediately upon _mesa_resize_framebuffer(). For user FBOs, they're updated as part of the normal draw path state update due to _NEW_BUFFERS having been flagged. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Remove _NEW_DEPTH state flagging on drawbuffers change.Eric Anholt2013-06-252-3/+1
| | | | | | | | Of the places noting a _NEW_DEPTH dependency, all were already checking for _NEW_BUFFERS if appropriate. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* intel: Stop doing special _NEW_STENCIL state flagging on drawbuffers.Eric Anholt2013-06-254-10/+5
| | | | | | | | 2/3 packets depending on Stencil._Enabled already checked for _NEW_BUFFERS, so just add _NEW_BUFFERS to the remaining one. Reviewed-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 08:11:03 +0000