aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa
Commit message (Collapse)AuthorAgeFilesLines
* mesa: GL_EXT_shadow_funcs is not optional with GL_ARB_shadowIan Romanick2013-06-288-26/+8
| | | | | | | | | Every driver left in Mesa that enables one also enables the other. There's no reason to let it be optional. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: GL_ARB_texture_storage_multisample is not optional with ↵Ian Romanick2013-06-284-5/+3
| | | | | | | | | | | | | | | | | | | GL_ARB_texture_multisample In Mesa, this extension is implemented purely in software. Drivers may *optionally* provide optimized paths. If a driver enables, GL_ARB_texture_multisample, it gets GL_ARB_texture_storage_multisample for free. NOTE: This has the side effect of enabling the extension in Gallium drivers that enable GL_ARB_texture_multisample. v2 (Ken): Still prevent multisample texture targets in TexParameter for implementations that don't support multisampling. Signed-off-by: Ian Romanick <[email protected]> Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: GL_ARB_texture_storage is not optionalIan Romanick2013-06-287-16/+3
| | | | | | | | | | | | | | In Mesa, this extension is implemented purely in software. Drivers may *optionally* provide optimized paths. NOTE: This has the side effect of enabling the extension in the radeon, r200, and nouveau drivers. v2: Minor whitespace tidying (suggested by Brian). Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: GL_ARB_shading_language_100 is not optionalIan Romanick2013-06-285-6/+1
| | | | | | | | | | | | | | This extension just provides some of the most basic software framework for GLSL. Without GL_ARB_vertex_shader or GL_ARB_fragment_shader, applications still cannot use GLSL. There's no value in conditionalizing support for this extension. NOTE: This has the side effect of enabling the extension in the radeon, r200, and nouveau drivers. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: GL_ARB_shader_objects is not optionalIan Romanick2013-06-2810-31/+16
| | | | | | | | | | | | | | This extension just provides some of the most basic software framework for GLSL. Without GL_ARB_vertex_shader or GL_ARB_fragment_shader, applications still cannot use GLSL. There's no value in conditionalizing support for this extension. NOTE: This has the side effect of enabling the extension in the radeon, r200, and nouveau drivers. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: GL_NV_blend_square is not optionalIan Romanick2013-06-289-11/+1
| | | | | | | | | Every driver left in Mesa enables this extension all the time. There's no reason to let it be optional. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: GL_EXT_fog_coord is not optionalIan Romanick2013-06-2814-29/+7
| | | | | | | | | Every driver left in Mesa enables this extension all the time. There's no reason to let it be optional. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: GL_EXT_secondary_color is not optionalIan Romanick2013-06-2813-33/+10
| | | | | | | | | Every driver left in Mesa enables this extension all the time. There's no reason to let it be optional. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: GL_EXT_framebuffer_object is not optionalIan Romanick2013-06-2813-35/+12
| | | | | | | | | Every driver left in Mesa enables this extension all the time. There's no reason to let it be optional. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Remove GL_MESA_resize_buffersIan Romanick2013-06-286-21/+0
| | | | | | | | | | | | Commit bab755a made the implementation a no-op, and it was only ever enabled by software rasterizers. v2: Move the spec into docs/specs/OLD since it's now obsolete (squashed patch from Andreas Boll) Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Remove _mesa_{enable, disable}_extension and _mesa_extension_is_enabledIan Romanick2013-06-282-51/+0
| | | | | | | | They're not used anywhere. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Just set extension flags instead of calling _mesa_enable_extensionIan Romanick2013-06-281-3/+2
| | | | | | Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Remove _mesa_enable_._._extensions functionsIan Romanick2013-06-282-87/+0
| | | | | | | | After the preceeding commits, they are not used. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* swrast: Don't call _mesa_enable_._._extensions and _mesa_enable_sw_extensionsIan Romanick2013-06-281-56/+0
| | | | | | | | | _mesa_enable_sw_extensions enables all the extensions (and more) that the others enable. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* osmesa: Don't call _mesa_enable_._._extensions and _mesa_enable_sw_extensionsIan Romanick2013-06-281-5/+0
| | | | | | | | | _mesa_enable_sw_extensions enables all the extensions (and more) that the others enable. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* wmesa: Don't call _mesa_enable_._._extensions and _mesa_enable_sw_extensionsIan Romanick2013-06-281-5/+0
| | | | | | | | | _mesa_enable_sw_extensions enables all the extensions (and more) that the others enable. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* x11: Don't call _mesa_enable_._._extensions and _mesa_enable_sw_extensionsIan Romanick2013-06-281-10/+1
| | | | | | | | | _mesa_enable_sw_extensions enables all the extensions (and more) that the others enable. Also, don't duplicate the DXTn checks. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* i965: Merge the two GEN >= 6 extension enable blocksIan Romanick2013-06-281-7/+6
| | | | | | | There's no reason for these blocks to be separate. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Move GEN >= 4 extensions into the "always on" listIan Romanick2013-06-281-43/+35
| | | | | | | | This copy of the source file is only used for GEN >= 4, so extensions that are enabled for GEN >= 4 are always enabled. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Move GEN >= 3 extensions into the "always on" listIan Romanick2013-06-281-17/+16
| | | | | | | | This copy of the source file is only used for GEN >= 4, so extensions that are enabled for GEN >= 3 are always enabled. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i915: Remove GEN >= 4 extension supportIan Romanick2013-06-281-76/+3
| | | | | | | | This copy of the source file is only used for GEN <= 3, so remove the dead code. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Split surface format code into a new file (brw_surface_formats.c).Kenneth Graunke2013-06-283-702/+732
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | brw_wm_surface_state.c has gotten rather large and unwieldy. At this point, it consists of two separate portions: 1. Surface format code This includes the giant table of surface formats and what features they support on each generation, as well as the code to translate between Mesa formats and hardware formats. This is used across all generations. 2. Binding table (SURFACE_STATE) related code. This is the code to generate SURFACE_STATE entries for renderbuffers, textures, transform feedback buffers, constant buffers, and so on, as well as the code to assemble them into binding tables. This is only used on Gen4-6; gen7_surface_state.c has Gen7+ code. Since the two are logically separate, and one is reused on every generation while the other is not, it makes a lot of sense to split them out. It should also make finding code easier. No code is changed by this patch. I simply copied the file then deleted portions of both. Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
* mesa: Return ZeroVec/dummyReg instead of NULL pointerAnuj Phogat2013-06-281-4/+2
| | | | | | | | | | | | Assertions are not sufficient to check for null pointers as they don't show up in release builds. So, return ZeroVec/dummyReg instead of NULL pointer in get_{src,dst}_register_pointer(). This should calm down the warnings from static analysis tool. Note: This is a candidate for the 9.1 branch. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* mesa: Fix build with older gcc since update of glext.hTom Stellard2013-06-281-4/+0
| | | | Reviewed-by: Brian Paul <[email protected]>
* mesa: Remove GL_EXT_clip_volume_hintIan Romanick2013-06-274-16/+0
| | | | | | | | | As far as I can tell, no driver has enabled this extension since c6499a7 back in 2007. Signed-off-by: Ian Romanick <[email protected]> Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965,i915: Return early if miptree allocation failsChad Versace2013-06-272-0/+4
| | | | | | | | | | | | If allocation fails in intel_miptree_create_layout(), don't proceed to dereference the miptree. Return an early NULL. Fixes static analysis error reported by Klocwork. Note: This is a candidate for the 9.1 branch. Reviewed-by: Ian Romanick <[email protected]> Reviewed-by: Anuj Phogat <[email protected]> Signed-off-by: Chad Versace <[email protected]>
* mesa: move declarations before codeBrian Paul2013-06-271-2/+3
| | | | Reviewed-by: Jose Fonseca <[email protected]>
* i965: Move the remaining intel code to the i965 directory.Eric Anholt2013-06-2667-11392/+11367
| | | | | | | | | Now that i915's forked off, they don't need to live in a shared directory. 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: 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
|
* 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-262-2/+2
| | | | | | | | | | 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-262-3/+3
| | | | | | | 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]>
* 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
|
* 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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 19:06:41 +0000