summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers
Commit message (Collapse)AuthorAgeFilesLines
* glx/dri2: add and use new driver hook flush_with_flagsMarek Olšák2012-12-023-3/+3
|
* radeon: Fix memory leak in radeonCreateScreen2.Vinson Lee2012-11-301-1/+3
| | | | | | | Fixes a memory leak defect reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* nouveau: Fix build.Brian Paul2012-11-301-1/+1
| | | | | | | | Fixes nouveau build failure introduced at c73245882c7ff1277b190b97f093f7b423a22f10. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57746 Signed-off-by: Vinson Lee <[email protected]>
* i965/fs: Add fs_reg::is_zero() and is_one(); use for opt_algebraic().Kenneth Graunke2012-11-302-7/+24
| | | | | | | | | | | | | | | | | | These helper macros save you from writing nasty expressions like: if ((inst->src[1].type == BRW_REGISTER_TYPE_F && inst->src[1].imm.f == 1.0) || ((inst->src[1].type == BRW_REGISTER_TYPE_D || inst->src[1].type == BRW_REGISTER_TYPE_UD) && inst->src[1].imm.u == 1)) { Instead, you simply get to write inst->src[1].is_one(). Simple. Also, this makes the FS backend match the VS backend (which has these). This patch also converts opt_algebraic to use the new helper functions. As a consequence, it will now also optimize integer-typed expressions. Reviewed-by: Eric Anholt <[email protected]>
* mesa: pass context parameter to gl_renderbuffer::Delete()Brian Paul2012-11-307-13/+13
| | | | | | | | | | We sometimes need a rendering context when deleting renderbuffers. Pass it explicitly instead of trying to grab a current context (which might be NULL). The next patch will make use of this. Note: this is a candidate for the stable branches. Reviewed-by: Jose Fonseca <[email protected]>
* i965/fp: Fix segfault on gen4 TXB instructions.Eric Anholt2012-11-291-0/+2
| | | | | | | | | | The gen4 simd16 workaround looks at ir->type to determine how much storage to allocate for the simd16 value. In fragment programs, texturing only ever returns float vec4s (unlike GLSL, which can also have scalar floats or vector integers), so this is the right type. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56962 Reviewed-by: Kenneth Graunke <[email protected]>
* mesa: Fix GL_LUMINANCE handling for textures in glGetTexImageAnuj Phogat2012-11-291-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | We need to rebase colors (ex: set G=B=0) when getting GL_LUMINANCE textures in following cases: 1. If the luminance texture is actually stored as rgba 2. If getting a luminance texture, but returning rgba 3. If getting an rgba texture, but returning luminance A similar fix was pushed by Brian Paul for uncompressed textures in commit: f5d0ced. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=47220 Observed no regressions in piglit and ogles2conform due to this fix. This patch will cause failures in intel oglconform pxconv-gettex, pxstore-gettex and pxtrans-gettex test cases. The cause of failures is a bug in test cases. Expected luminance value is calculted incorrectly in test cases: L = R+G+B. V2: Set G = 0 when getting a RG texture but returning luminance. Note: This is a candidate for stable branches. Signed-off-by: Anuj Phogat <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* Revert "meta: Don't try to glOrtho when the draw buffer isn't initialized."Kenneth Graunke2012-11-291-5/+3
| | | | | This reverts commit 9947470655bbf8f4a9c98fe6d93ff5c3486f1124. Apparently it caused a lot of Piglit regressions.
* mesa: Rename API_OPENGL to API_OPENGL_COMPAT.Paul Berry2012-11-2914-33/+33
| | | | | | | | | | This should help avoid confusion now that we're using the gl_api enum to distinguishing between core and compatibility API's. The corresponding enum value for core API's is API_OPENGL_CORE. Acked-by: Eric Anholt <[email protected]> Acked-by: Matt Turner <[email protected]> Acked-by: Kenneth Graunke <[email protected]>
* i965/vs: Move struct brw_compile (p) entirely inside vec4_generator.Kenneth Graunke2012-11-283-4/+3
| | | | | | | | | | | | | | The brw_compile structure contains the brw_instruction store and the brw_eu_emit.c state tracking fields. These are only useful for the final assembly generation pass; the earlier compilation stages doesn't need them. This also means that the code generator for future hardware won't have access to the brw_compile structure, which is extremely desirable because it prevents accidental generation of Gen4-7 code. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/vs: Split final assembly code generation out of vec4_visitor.Kenneth Graunke2012-11-284-53/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compiling shaders requires several main steps: 1. Generating VS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "vec4_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace vec4_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the vec4_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in vec4_visitor and create IR, while ADD() in vec4_generator() can create brw_instructions. (Patches for this upcoming.) Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/vs: Abort on unsupported opcodes rather than failing.Kenneth Graunke2012-11-281-3/+4
| | | | | | | | | | Final code generation should never fail. This is a bug, and there should be no user-triggerable cases where this could occur. Also, we're not going to have a fail() method after the split. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/vs: Move uses of brw_compile from do_vs_prog to brw_vs_emit.Kenneth Graunke2012-11-283-14/+19
| | | | | | | | | | | | The brw_compile structure is closely tied to the Gen4-7 hardware encoding. However, do_vs_prog is very generic: it just calls out to get a compiled program and then uploads it. This isn't ultimately where we want it, but it's a step in the right direction: it's now closer to the code generator. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/vs: Rework memory contexts for shader compilation data.Kenneth Graunke2012-11-285-8/+12
| | | | | | | | | | | | | | During compilation, we allocate a bunch of things: the IR needs to last at least until code generation...and then the program store needs to last until after we upload the program. For simplicity's sake, just keep it all around until we upload the program. After that, it can all be freed. This will also save a lot of headaches during the upcoming refactoring. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/vs: Pass the brw_context pointer into brw_compute_vue_map().Kenneth Graunke2012-11-281-3/+2
| | | | | | | | We used to steal it out of the brw_compile struct, but that won't be initialized in time soon (and is eventually going away). Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/vs: Pass the brw_context pointer into vec4_visitor and do_vs_prog.Kenneth Graunke2012-11-285-9/+14
| | | | | | | | We used to steal it out of the brw_compile struct...but vec4_visitor isn't going to have one of those in the future. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* i965/vs: Move some functions from brw_vec4_emit.cpp to brw_vec4.cpp.Kenneth Graunke2012-11-282-263/+265
| | | | | | | | | | | This leaves only the final code generation stage in brw_vec4_emit.cpp, moving the payload setup, run(), and brw_vs_emit functions to brw_vec4.cpp. The fragment shader backend puts these functions in brw_fs.cpp, so this patch also helps with consistency. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Anuj Phogat <[email protected]>
* meta: Don't try to glOrtho when the draw buffer isn't initialized.Kenneth Graunke2012-11-281-3/+5
| | | | | | | | | | | | | | | I ran across this while running a glGenerateMipmap() test. _meta_GenerateMipmap sets MESA_META_TRANSFORM, which causes _mesa_meta_begin to try and set a default orthographic projection. Unfortunately, if the drawbuffer isn't set up, ctx->DrawBuffer->Width and Height are 0, which just causes an GL_INVALID_VALUE error. Fixes oglconform's fbo/mipmap.automatic, mipmap.manual, and mipmap.manualIterateTexTargets. Reviewed-by: Brian Paul <[email protected]>
* i965/gen4-5: Fix segfaults with stencil-only depth/stencil setups.Eric Anholt2012-11-281-1/+3
| | | | | | | | Fixes a ton of piglit regressions since the depthstencil fixes for gen6+. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57309 Reviewed-by: Chad Versace <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Don't generate saturates over existing variable values.Eric Anholt2012-11-281-0/+1
| | | | | | | | | | | | Fixes a crash in http://workshop.chromeexperiments.com/stars/ on i965, and the new piglit test glsl-fs-clamp-5. We were trying to emit a saturating move into a uniform, which the code generator appropriately choked on. This was broken in the change in 32ae8d3b321185a85b73ff703d8fc26bd5f48fa7. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57166 NOTE: This is a candidate for the 9.0 branch. Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Add some minimal backend-IR dumping.Eric Anholt2012-11-282-0/+92
| | | | Reviewed-by: Kenneth Graunke <[email protected]>
* i965/fs: Move struct brw_compile (p) entirely inside fs_generator.Kenneth Graunke2012-11-266-6/+4
| | | | | | | | | | | | | | | | The brw_compile structure contains the brw_instruction store and the brw_eu_emit.c state tracking fields. These are only useful for the final assembly generation pass; the earlier compilation stages doesn't need them. This also means that the code generator for future hardware won't have access to the brw_compile structure, which is extremely desirable because it prevents accidental generation of Gen4-7 code. v2: rzalloc p, as suggested by Eric. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Split final assembly code generation out of fs_visitor.Kenneth Graunke2012-11-263-78/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compiling shaders requires several main steps: 1. Generating FS IR from either GLSL IR or Mesa IR 2. Optimizing the IR 3. Register allocation 4. Generating assembly code This patch splits out step 4 into a separate class named "fs_generator." There are several reasons for doing so: 1. Future hardware has a different instruction encoding. Splitting this out will allow us to replace fs_generator (which relies heavily on the brw_eu_emit.c code and struct brw_instruction) with a new code generator that writes the new format. 2. It reduces the size of the fs_visitor monolith. (Arguably, a lot more should be split out, but that's left for "future work.") 3. Separate namespaces allow us to make helper functions for generating instructions in both classes: ADD() can exist in fs_visitor and create IR, while ADD() in fs_generator() can create brw_instructions. (Patches for this upcoming.) Furthermore, this patch changes the order of operations slightly. Rather than doing steps 1-4 for SIMD8, then 1-4 for SIMD16, we now: - Do steps 1-3 for SIMD8, then repeat 1-3 for SIMD16 - Generate final assembly code for both modes together This is because the frontend work can be done independently, but final assembly generation needs to pack both into a single program store to feed the GPU. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Abort on unsupported opcodes rather than failing.Kenneth Graunke2012-11-261-1/+1
| | | | | | | | | | | | | Final code generation should never fail. This is a bug, and there should be no user-triggerable cases where this could occur. Also, we're not going to have a fail() method in a moment. v2: Just abort() rather than assert, to cover the NDEBUG case (suggested by Eric). Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Make it possible to create a cfg_t without a backend_visitor.Kenneth Graunke2012-11-262-3/+18
| | | | | | | | | | All we really need is a memory context and the instruction list; passing a backend_visitor is just convenient at times. This will be necessary two patches from now. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Move uses of brw_compile from do_wm_prog to brw_wm_fs_emit.Kenneth Graunke2012-11-263-14/+20
| | | | | | | | | | | | The brw_compile structure is closely tied to the Gen4-7 hardware encoding. However, do_wm_prog is very generic: it just calls out to get a compiled program and then uploads it. This isn't ultimately where we want it, but it's a step in the right direction: it's now closer to the code generator. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Pass the brw_context pointer into fs_visitor explicitly.Kenneth Graunke2012-11-263-5/+7
| | | | | | | | We used to steal it out of the brw_compile struct...but fs_visitor isn't going to have one of those in the future. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Move brw_wm_compile::fp to fs_visitor.Kenneth Graunke2012-11-268-17/+19
| | | | | | | | Also change it from a brw_fragment_program to a gl_fragment_program, since that seems to be what everything wants anyway. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Remove struct brw_shader * parameter to fs_visitor constructor.Kenneth Graunke2012-11-263-5/+8
| | | | | | | | | | We can easily recover it from prog, and this makes it clear that we aren't passing additional information in. v2: Use an if-statement rather than the ?: operator (suggested by Eric). Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Move brw_wm_compile::dispatch_width into fs_visitor.Kenneth Graunke2012-11-269-66/+64
| | | | | | | | | | | | | | Also, rather than having brw_wm_fs_emit poke at it directly, make it a parameter to the fs_visitor constructor. All other changes generated by search and replace (with occasional whitespace fixup). v2: Make dispatch_width const (as suggested by Paul); fix doxygen mistake (pointed out by Eric); update for rebase. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Move brw_wm_lookup_iz() to fs_visitor::setup_payload_gen4().Kenneth Graunke2012-11-265-85/+82
| | | | | | | This necessitates compiling brw_wm_iz.c as C++. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Move brw_wm_payload_setup() to fs_visitor::setup_payload_gen6()Kenneth Graunke2012-11-264-68/+63
| | | | | | | | Now that we only have the one backend, there's no real point in keeping this separate. Moving it should allow some future simplifications. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965/fs: Remove brw_wm_compile::computes_depth field.Kenneth Graunke2012-11-264-6/+1
| | | | | | | | | | Everybody determines this by checking if fp's OutputsWritten field contains the FRAG_RESULT_DEPTH bit. Rather than having payload setup check this and set the computes_depth flag, we can just do the check in the only place that actually used it: emit_fb_writes(). Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Paul Berry <[email protected]>
* i965: Enable ARB_vertex_type_2_10_10_10_rev on Gen4+.Chris Forbes2012-11-261-0/+1
| | | | | | | | v2 (Kayden): Move the enable into an existing intel->gen >= 4 block (as suggested by Ian). Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: emit w/a for packed attribute formats in VSChris Forbes2012-11-263-13/+126
| | | | | | | | | | | | | | | | Implements BGRA swizzle, sign recovery, and normalization as required by ARB_vertex_type_10_10_10_2_rev. V2: Ported to the new VS backend, since that's all that's left; fixed normalization. V3: Moved fixups out of the GLSL-only path, so it works for FF/VP too. V4 (Kayden): Rework ES3 normalization, don't heap allocate registers; tidy comments. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: set attribute w/a bits for packed formatsChris Forbes2012-11-261-4/+26
| | | | | | | | Flag the need for various workarounds to be applied by the vertex shader. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Generalize GL_FIXED VS w/a supportChris Forbes2012-11-263-14/+26
| | | | | | | | | | | Next few patches build on this to add other workarounds for packed formats. V2: rename BRW_ATTRIB_WA_COMPONENTS to BRW_ATTRIB_WA_COMPONENT_MASK; V3 (Kayden): remove separate bit for ES3 signed normalization Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: support 2_10_10_10 formats in get_surface_type.Chris Forbes2012-11-261-1/+19
| | | | | | | | | Always use R10G10B10A2_UINT; Most of the other formats we'd like don't actually work on the hardware. Will emit w/a for scaling, sign recovery and BGRA swizzle in the VS. Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: implement get_size for 2_10_10_10 formatsChris Forbes2012-11-261-0/+5
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965/vs: add support for emitting SHL, SHR, ASRChris Forbes2012-11-262-4/+10
| | | | | Signed-off-by: Chris Forbes <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Fix hangs with FP KIL instructions pre-gen6.Eric Anholt2012-11-251-0/+2
| | | | | | | | | We can't support IF statements in 16-wide on these. To get back to 16-wide for these shaders, we need to support predicate on discard instructions in the backend IR, which is something we've sort of got on the list to do anyway. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55828 Reviewed-by: Kenneth Graunke <[email protected]>
* i965/gen4: Fix memory leak each time compile_gs_prog() is called.Eric Anholt2012-11-251-1/+1
| | | | | | | | | Commit 774fb90db3e83d5e7326b7a72e05ce805c306b24 introduced a ralloc context to each user of struct brw_compile, but for this one a NULL context was used, causing the later ralloc_free(mem_ctx) to not do anything. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55175 NOTE: This is a candidate for the stable branches.
* i965/gen4: Fix LOD bias texturing since my fixed reg classes change.Eric Anholt2012-11-251-10/+18
| | | | | | | | | | We have a special case where non-shadow comparison with LOD requires using a SIMD16 vec4 in an 8-wide shader, which appears in the register allocator as a size 8 vgrf. Fixes assertions in various piglit tests and webgl conformance. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56521
* scons: Append x11 library path if linking x11 library.Vinson Lee2012-11-211-0/+1
| | | | Signed-off-by: Vinson Lee <[email protected]>
* i915: Fix wrong sizeof argument in i915_update_tex_unit.Vinson Lee2012-11-211-1/+1
| | | | | | | | | The bug was found by Coverity. NOTE: This is a candidate for the stable branches. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Ian Romanick <[email protected]>
* i965/fs: Add helper functions for IF and CMP and use them.Eric Anholt2012-11-204-85/+90
| | | | | v2: Rebase on gen6-if fix. Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* i965/fs: Add helper functions for generating ALU ops, like in the VS.Eric Anholt2012-11-204-209/+241
| | | | | | | | This gives us checking of our arguments (no more passing 1 operand to BRW_OPCODE_MUL!), at the cost of a couple of extra parens. v2: Rebase on gen6-if fix. Reviewed-by: Kenneth Graunke <[email protected]> (v1)
* i965/gen4: Fix crash with fragment programs and texture rectangle.Eric Anholt2012-11-191-1/+1
| | | | | | | | | | | | | This was a regression in the brw_fs_fp.cpp change. We just need to return something good enough to get the IR generation to the end without crashing, but ir->type isn't initialized and we wanted something of the coordinate's type anyway. Fixes around 30 piglit cases on my ilk system in drawpixels and framebuffer blit. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56962 Reviewed-by: Kenneth Graunke <[email protected]>
* i965: Disable the GB clip test when a limited viewport is set.Eric Anholt2012-11-192-3/+19
| | | | | | | | | | | | | | The theory of the guardband is that you extend the clip volume to avoid expensive clipping computation, and just let fragments outside the viewport get clipped by the drawable's bounds. But if a smaller-than-window-size viewport is set, and we don't also happen to have a scissor set, then rendering could incorrectly extend outside of the viewport when it should have been clipped to the viewport. Fixes the new piglit triangle-guardband-viewport test. Reviewed-by: Kenneth Graunke <[email protected]> NOTE: This is a candidate for the 9.0 branch.
* i965: Use fewer temporary variables in clip setup.Eric Anholt2012-11-192-28/+18
| | | | | | | | When you're comparing to the spec, you're trying to immediately see what numbered dword of the packet your bit ends up in. Reviewed-by: Kenneth Graunke <[email protected]> NOTE: This is a candidate for the 9.0 branch.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-13 08:32:48 +0000