summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* util: added pipe_surface_release() functionBrian Paul2012-11-301-0/+16
| | | | | | | | | To fix a pipe_context::surface_destroy() use-after-free problem. We previously added pipe_sampler_view_release() for similar reasons. Note: this is a candidate for the stable branches. Reviewed-by: Jose Fonseca <[email protected]>
* mesa: pass context parameter to gl_renderbuffer::Delete()Brian Paul2012-11-3015-24/+29
| | | | | | | | | | 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]>
* egl/wayland: Don't invalidate drawable on swap buffersAnder Conselvan de Oliveira2012-11-303-1/+27
| | | | | | | | | | | | | | | | | | | We used to invalidate the drawable after a call to eglSwapBuffers(), so that a wl_egl_window_resize() would take effect for the next frame. However, that leads to calling dri2_get_buffers() when eglMakeCurrent() is called with the current context and surface, and a later call to wl_egl_window_resize() would not take effect until the next buffer swap. Instead, add a callback from wl_egl_window_resize() back to the wayland egl platform, and invalidate the drawable only when it is resized. This solves a bug on wayland clients when going back to windowed mode from fullscreen when clicking a pop up menu, where the window size after this would be the fullscreen size. Note: this is a candidate for stable branches. CC: [email protected]
* egl: Only enable GLX backend if X11 EGL platform is enabledKristian Høgsberg2012-11-301-4/+4
| | | | | We don't want to compile in a bunch of X11 dependencies in libEGL if we can't run EGL on X11.
* llvmpipe: Remove remnants of lp_tile_soa from Makefile.José Fonseca2012-11-302-4/+0
| | | | | | Completely forgot about updating Makefile when removing it. Stephane already fixed the make build, but there were a few mentions of lp_tile_soa left in the tree.
* 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]>
* llvmpipe: Fix incorrect sizeof.Vinson Lee2012-11-291-2/+2
| | | | | | | Fixes sizeof not portable defects reported by Coverity. Signed-off-by: Vinson Lee <[email protected]> Reviewed-by: Brian Paul <[email protected]>
* llvmpipe: Fix build break from 75da95c50Stéphane Marchesin2012-11-291-2/+1
| | | | | | The Makefile looks for a file which is gone (lp_tile_soa.c) http://bugs.freedesktop.org/show_bug.cgi?id=57713
* mesa: Fix GL_LUMINANCE handling for textures in glGetTexImageAnuj Phogat2012-11-292-14/+41
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* r600g: mirror simplification of if/break opcodesVincent Lejeune2012-11-291-32/+12
| | | | Reviewed-by: Tom Stellard <thomas.stellard at amd.com>
* r600g: separate resource_id and sampler_id tex info in tgsi-to-llvmVincent Lejeune2012-11-291-0/+3
| | | | Reviewed-by: Tom Stellard <thomas.stellard at amd.com>
* glcpp: Update README for new support of __LINE__ and __FILE__.Carl Worth2012-11-291-3/+1
| | | | | | | | | Drop these from the known limitations list since support was recently added for these. Also, fix a typo while in the area, (and the oddly missing final newline). Reviewed-by: Matt Turner <[email protected]>
* glcpp: Add test involving token pasting of INTEGER tokens.Carl Worth2012-11-292-0/+15
| | | | | | | | | | | | | | | This test file is very similar to test 113-line-and-file-macros but uses token pasting for cleaner quiz answers (without spaces between the digits). This test passes thanks to the recent addition of support for pasting INTEGER tokens, (but would have failed without that). (Note that this test is distinct from test 059-token-pasting-integer which pastes integers parsed from the source. Those are parsed to INTEGER_STRING tokens and are already pasted correctly as verified by that test. The only way to generate the INTEGER tokens which currently fail to paste is with an internal define such as __LINE__ that results in an integer.) Reviewed-by: Matt Turner <[email protected]>
* glcpp: Add support for pasting of INTEGER tokens.Carl Worth2012-11-291-14/+47
| | | | | | | By generalizing the current code designed to paste string tokens of various types. Reviewed-by: Matt Turner <[email protected]>
* glcpp: Flag invalid pastes for integer followed by non-digitsCarl Worth2012-11-291-5/+13
| | | | | | | | | As recently tested in the additions to the invalid paste test, it is illegal to paste a non-digit sequence onto the end of an integer. The 082-invalid-paste test should now pass again. Reviewed-by: Matt Turner <[email protected]>
* glcpp: Extend the invalid-paste testCarl Worth2012-11-292-0/+20
| | | | | | | | The current code lets a few invalid pastes through, such as an string pasted onto the end of an integer. Extend the invalid-paste test to catch some of these. Reviewed-by: Matt Turner <[email protected]>
* glcpp: More factoring-out of common code to simplify things.Carl Worth2012-11-291-26/+20
| | | | | | | | This time creating a new _token_list_create_with_one_integer function modeled after the existing _token_list_create_with_one_space function (both implemented with new _token_list_create_with_one_ival). Reviewed-by: Matt Turner <[email protected]>
* glcpp: Factor out a tiny bit of repeated code.Carl Worth2012-11-291-4/+1
| | | | | | | This function is getting a little long too read. Simplify it by pulling up one assignment from every condition. Reviewed-by: Matt Turner <[email protected]>
* glcpp: Add support for __LINE__ and __FILE__ macrosCarl Worth2012-11-293-1/+45
| | | | | | | | | | | | | These tokens are easy to expand by just looking at the current, tracked location values, (and no need to look anything up in the hash table). Add a test which verifies __LINE__ with several values, (and verifies __FILE__ for the single value of 0). Our testing framework isn't sophisticated enough here to have a test with multiple file inputs. This commit fixes part of es3conform's preprocess16_frag test. Reviewed-by: Matt Turner <[email protected]>
* mesa: Rename API_OPENGL to API_OPENGL_COMPAT.Paul Berry2012-11-2950-261/+261
| | | | | | | | | | 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]>
* gallium/postprocess: share pipe_context and cso_context with the state trackerMarek Olšák2012-11-297-26/+71
| | | | | | | Using one context instead of two is more efficient and we can skip another context flush. Reviewed-by: Brian Paul <[email protected]>
* mesa: move some helper functions from fboobject.c to glformats.cMarek Olšák2012-11-293-119/+127
| | | | Reviewed-by: Brian Paul <[email protected]>
* android: include api_exec.c in generated files listTapani Pälli2012-11-291-0/+1
| | | | | Signed-off-by: Tapani Pälli <[email protected]> Reviewed-by: Chad Versace <[email protected]>
* gallivm: Fix lp_build_float_to_half.José Fonseca2012-11-291-30/+75
| | | | | | | | | | | The current implementation was close by not fully correct: several operations that should be done in floating point were being done in integer. Fixes piglit fbo-clear-formats GL_ARB_texture_float Reviewed-by: Brian Paul <[email protected]> Reviewed-by: Roland Scheidegger <[email protected]>
* gallivm: fix a trivial txq issue for 2d shadow and cube shadow samplersRoland Scheidegger2012-11-291-2/+2
| | | | | | | | | untested (couldn't get the piglit test to run even with version overrides) but seemed blatantly wrong. In any case it would only affect an error case which when it would happen probably all hope is lost anyway. Reviewed-by: José Fonseca <[email protected]>
* llvmpipe: support array texturesRoland Scheidegger2012-11-296-7/+32
| | | | | | | | | | This adds array (1d,2d) texture support to llvmpipe. Though probably should do something about 1d array textures requiring gobs of memory (this issue is not strictly limited to arrays but it is probably worse there). Initial code by Jakob Bornecrantz <[email protected]> Reviewed-by: José Fonseca <[email protected]>
* gallivm: support array texturesRoland Scheidegger2012-11-296-65/+103
| | | | | | | | | | | | | Support 1d and 2d array textures (including shadow samplers), and (as a side effect mostly) also shadow cube samplers. Seems to pass the relevant piglit tests both for sampling and rendering to (though some require version overrides). Since we don't support render target indices rendering to array textures is still restricted to a single layer at a time. Also, the min/max layer in the sampler view (which is unnecessary for GL) is ignored (always use all layers). Reviewed-by: José Fonseca <[email protected]>
* llvmpipe: Remove lp_build_blend_soa()José Fonseca2012-11-295-538/+37
| | | | | | No longer used/necessary, as we always blend in AoS now. Trivial.
* llvmpipe: Eliminate color buffer swizzling.José Fonseca2012-11-2917-1334/+30
| | | | | | | | | | | | Now dead code. Also had to remove the show_tiles/show_subtiles because now the color buffers are always stored in their native format, so there is no longer an easy way to paint the tile sizes. Depth-stencil buffers are still swizzled. Reviewed-by: Roland Scheidegger <[email protected]>
* llvmpipe: Only advertise unswizzled formats.José Fonseca2012-11-293-25/+17
| | | | | | | | | | | | | | Update llvmpipe_is_format_supported and llvmpipe_is_format_unswizzled so that only the formats that we can render without swizzling are advertised. We can still render all D3D10 required formats except PIPE_FORMAT_R11G11B10_FLOAT, which needs to be implemented in a future opportunity. Removal of rendertarget swizzling will be done in a subsequent change. Reviewed-by: Roland Scheidegger <[email protected]>
* util/u_format: Kill util_format_is_array().José Fonseca2012-11-294-53/+4
| | | | | | | | It is buggy (it was giving wrong results for some of the formats with padding), and util_format_description::is_array already does precisely what's intended. Reviewed-by: Roland Scheidegger <[email protected]>
* util/u_format: Tighten the meaning of is_array bit to exclude mixed type ↵José Fonseca2012-11-292-2/+11
| | | | | | | | | | | formats. This is what we want in practice. The only change is in PIPE_FORMAT_R8SG8SB8UX8U_NORM, which no longer is considered an array format. Reviewed-by: Roland Scheidegger <[email protected]>
* util/u_format: Fix format manipulation for big-endianAdhemerval Zanella2012-11-291-5/+5
| | | | | | | | This patch fixes various format manipulation for big-endian architectures. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Fix format manipulation for big-endianAdhemerval Zanella2012-11-295-12/+145
| | | | | | | | This patch fixes various format manipulation for big-endian architectures. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Add byte-swap construct callsAdhemerval Zanella2012-11-292-0/+89
| | | | | | | | | | | This patch adds two more functions in type conversions header: * lp_build_bswap: construct a call to llvm.bswap intrinsic for an element * lp_build_bswap_vec: byte swap every element in a vector base on the input and output types. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Fix vector constant for shuffleAdhemerval Zanella2012-11-291-1/+6
| | | | | | | | This patch fixes the vector constant generation used for vector shuffle for big-endian machines. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: clear Altivec NJ bitAdhemerval Zanella2012-11-291-0/+19
| | | | | | | | This patch enforces the clear of NJ bit in VSCR Altivec register so denormal numbers are handles as expected by IEEE standards. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Altivec floating-point roundingAdhemerval Zanella2012-11-291-23/+70
| | | | | | | | | This patch adds Altivec intrinsics for float vector types. It changes the SSE specific definitions to a platform neutral and adds the calls to Altivec intrinsic builder. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Altivec vector add/sub intrisicsAdhemerval Zanella2012-11-292-15/+27
| | | | | | | | | | | | | This patch add correct vector addition and substraction intrisics when using Altivec with PPC. Current code uses default path and LLVM backend ends up issuing carry-out arithmetic instruction while it is expected saturated ones. It also includes a fix for PowerPC where char are unsigned by default, resulting in bogus values for vector shifting. Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Altivec vector max/min intrisicsAdhemerval Zanella2012-11-291-2/+54
| | | | | | | | This patch adds the PPC Altivec instrics max/min instruction for supported Altivec vector types (16xi8, 8xi16, 4xi32, 4xf32). Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* gallivm: Altivec pack/unpack intrisicsAdhemerval Zanella2012-11-291-14/+30
| | | | | | | | This patch adds PPC Altivec support for pack/unpack operations using Altivec supported vector type (8xi8, 16xi16, 4xi32, 4xf32). Reviewed-by: Roland Scheidegger <[email protected]> Reviewed-by: Jose Fonseca <[email protected]>
* radeonsi: Bitcast result of packf16 intrinsic to float for export intrinsic.Michel Dänzer2012-11-291-1/+5
| | | | | | | Fixes 7 piglit tests, and prevents many more from crashing. Signed-off-by: Michel Dänzer <[email protected]> Reviewed-and-Tested-by: Christian König <[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]>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-17 20:17:25 +0000