summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Enable gallium eglbaserock/10.0.4-galliumPedro Alvarez2014-04-162-2/+2
|
* Drop dri driver 'intel' also in mesa-xPedro Alvarez2014-04-161-1/+1
|
* Drop 'intel' dri driver, no longer existsbaserock/10.0.4Pedro Alvarez2014-04-021-1/+1
|
* Added mesa-x and mesa-wayland morphsBen Brewer2014-04-022-0/+16
|
* docs: Add release notes for 10.0.4mesa-10.0.4Carl Worth2014-03-121-0/+188
| | | | Just prior to release.
* Update version to 10.0.4Carl Worth2014-03-121-1/+1
| | | | In preparation for a stable-branch release.
* get-pick-list: Update to only find patches nominated for the 10.0 branchCarl Worth2014-03-111-1/+1
| | | | | In early February, the 10.1 branch was created. From then on, patches that don't specifically say "10.0" are intended for 10.1, not 10.0.
* mesa: don't define c99 math functions for MSVC >= 1800Hans2014-03-111-1/+1
| | | | | | Signed-off-by: Brian Paul <brianp@vmware.com> Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 837da9bdaec2b4496c6d25ea0379f8c2996ed697)
* util: don't define isfinite(), isnan() for MSVC >= 1800Hans2014-03-111-0/+4
| | | | | | Signed-off-by: Brian Paul <brianp@vmware.com> Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit bf2566032589e0c46dbd4ddef0d75d354d2a16b5)
* softpipe: use 64-bit arithmetic in softpipe_resource_layout()Brian Paul2014-03-111-3/+3
| | | | | | | | | To avoid 32-bit integer overflow for large textures. Note: we're already doing this in llvmpipe. Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Roland Scheidegger <sroland@vmware.com> (cherry picked from commit 465b2c42bca59f0f198aeb8543cfabd5989584b4)
* glx/dri2: fix build failure on HURDJulien Cristau2014-03-111-0/+5
| | | | | | | | Patch from Debian package. Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 6f0e2731e862d1c2d8d21927040bead5049a2d68)
* i965: Validate (and resolve) all the bound textures.Chris Forbes2014-03-112-2/+2
| | | | | | | | | | | | | | | | | | | | BRW_MAX_TEX_UNIT is the static limit on the number of textures we support per-stage, not in total. Core's `Unit` array is sized by MAX_COMBINED_TEXTURE_IMAGE_UNITS, which is significantly larger, and across the various shader stages, up to ctx->Const.MaxCombinedTextureImageUnits elements of it may be actually used. Fixes invisible bad behavior in piglit's max-samplers test (although this escalated to an assertion failure on HSW with texture_view, since non-immutable textures only have _Format set by validation.) Signed-off-by: Chris Forbes <chrisf@ijw.co.nz> Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org> Cc: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (cherry picked from commit befbda56a246f77797bdf13fc005353441db2879)
* dri/i9*5: correctly calculate the amount of system memoryEmil Velikov2014-03-112-2/+2
| | | | | | | | | | The variable name states megabytes, while we calculate the amount in kilobytes. Correct this by dividing with the correct amount. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit fc25956badb8e1932cc19d8c97b4be16e92dfc65)
* r600g/compute: PIPE_CAP_COMPUTE should be false for pre-evergreen GPUsTom Stellard2014-03-101-1/+3
| | | | | | | | | | This prevents clover from using unsupported devices. Reviewed-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> CC: "10.0 10.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit f61e382f0afc48bc09f21c50639f760acca85bc5)
* mesa: do depth/stencil format conversion in glGetTexImageBrian Paul2014-03-101-2/+9
| | | | | | | | | | | | | | | | | glGetTexImage(GL_DEPTH_STENCIL, GL_UNSIGNED_INT_24_8) was just using memcpy() instead of _mesa_unpack_uint_24_8_depth_stencil_row() to convert texels from the hardware format to the GL format. Fixes issue reported by David Meng at Intel. The new piglit ext_packed_depth_stencil-getteximage test checks for this bug. Also, add some format/type assertions. We don't yet handle the GL_FLOAT_32_UNSIGNED_INT_24_8_REV type. That should be fixed in a follow-on patch. Reviewed-by: Eric Anholt <eric@anholt.net> Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 43dee0295e5da42425f1a3b6a3b3108173f4b676)
* i965: Fix the region's pitch condition to use blitterAnuj Phogat2014-03-101-3/+3
| | | | | | | | | | intelEmitCopyBlit uses a signed 16-bit integer to represent buffer pitch, so it can only handle buffer pitches < 32k. Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit b3094d9927fe7aa5a84892262404aaad4d728724)
* glx: Fix the GLXFBConfig attrib sort prioritiesFredrik Höglund2014-03-101-7/+4
| | | | | | | | | | The sort priorites for GLX_SAMPLES and GLX_SAMPLE_BUFFERS are not defined in GL_ARB_multisample, but they are defined in the GLX 1.4 specification. Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 3616e862f29838d73fcb05134b1dc628da499fc2)
* glx: Fix the default values for GLXFBConfig attributesFredrik Höglund2014-03-101-7/+2
| | | | | | | | | | | | | The default values for GLX_DRAWABLE_TYPE and GLX_RENDER_TYPE are GLX_WINDOW_BIT and GLX_RGBA_BIT respectively, as specified in the GLX 1.4 specification. This fixes the glx-choosefbconfig-defaults piglit test. Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit f41c2f6c332ae9b9784ac924b718963a1086cb85)
* nv50: correctly calculate the number of vertical blocks during transfer mapEmil Velikov2014-03-101-1/+1
| | | | | | | Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> (cherry picked from commit 882070cc81588a133d81e3ef8790d7375f494eff)
* i965: Create a hardware context before initializing state module.Kenneth Graunke2014-03-041-6/+6
| | | | | | | | | | | | | | | | | | | | | | brw_init_state() calls brw_upload_initial_gpu_state(). If hardware contexts are enabled (brw->hw_ctx != NULL), this will upload some initial invariant state for the GPU. Without hardware contexts, we rely on this state being uploaded via atoms that subscribe to the BRW_NEW_CONTEXT bit. Commit 46d3c2bf4ddd227193b98861f1e632498fe547d8 accidentally moved the call to brw_init_state() before creating a hardware context. This meant brw_upload_initial_gpu_state would always early return. Except on Gen6+, we stopped uploading the initial GPU state via state atoms, so it never happened. Fixes a regression since 46d3c2bf4ddd227193b98861f1e632498fe547d8. Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> (cherry picked from commit 3663bbe773187dee341556ef29e58b1143ef2f5c)
* glsl: Only warn for macro names containing __Ian Romanick2014-03-041-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | From page 14 (page 20 of the PDF) of the GLSL 1.10 spec: "In addition, all identifiers containing two consecutive underscores (__) are reserved as possible future keywords." The intention is that names containing __ are reserved for internal use by the implementation, and names prefixed with GL_ are reserved for use by Khronos. Names simply containing __ are dangerous to use, but should be allowed. Per the Khronos bug mentioned below, a future version of the GLSL specification will clarify this. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Tested-by: Darius Spitznagel <d.spitznagel@goodbytez.de> Cc: Tapani Pälli <lemody@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870 Bugzilla: Khronos #11702 (cherry picked from commit 2c85fd5a964a78c9f7a93994fb79f1723c6f45b5)
* glcpp: Only warn for macro names containing __Ian Romanick2014-03-042-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Section 3.3 (Preprocessor) of the GLSL 1.30 spec (and later) and the GLSL ES spec (all versions) say: "All macro names containing two consecutive underscores ( __ ) are reserved for future use as predefined macro names. All macro names prefixed with "GL_" ("GL" followed by a single underscore) are also reserved." The intention is that names containing __ are reserved for internal use by the implementation, and names prefixed with GL_ are reserved for use by Khronos. Since every extension adds a name prefixed with GL_ (i.e., the name of the extension), that should be an error. Names simply containing __ are dangerous to use, but should be allowed. In similar cases, the C++ preprocessor specification says, "no diagnostic is required." Per the Khronos bug mentioned below, a future version of the GLSL specification will clarify this. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Tested-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> Tested-by: Darius Spitznagel <d.spitznagel@goodbytez.de> Cc: Tapani Pälli <lemody@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870 Bugzilla: Khronos #11702 (cherry picked from commit 0bd78926304e72ef3566e977d0cb5a959d86b809)
* glsl: Fix condition to generate shader link errorAnuj Phogat2014-03-041-4/+5
| | | | | | | | | | | | | | | | | | | | GL_ARB_ES2_compatibility doesn't say anything about shader linking when one of the shaders (vertex or fragment shader) is absent. So, the extension shouldn't change the behavior specified in GLSL specification. Tested the behavior on proprietary linux drivers of NVIDIA and AMD. Both of them allow linking a version 100 shader program in OpenGL context, when one of the shaders is absent. Makes following Khronos CTS tests to pass: successfulcompilevert_linkprogram.test successfulcompilefrag_linkprogram.test Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 03597cf802a7a89c4853794e6206ab8ab003898d)
* mesa: Add GL_TEXTURE_CUBE_MAP_ARRAY to legal_get_tex_level_parameter_target()Anuj Phogat2014-03-041-0/+3
| | | | | | | | | Fixes failing Khronos CTS test packed_depth_stencil_init.test Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 6bd2472a8b9a969d06dc110bd30ccd8daf713959)
* targets/vdpau: Always use c++ to linkKusanagi Kouichi2014-03-041-5/+1
| | | | | | | | | | | | If built without llvm, the following error occurs with mplayer: Failed to open VDPAU backend .../libvdpau_r600.so: undefined symbol: _ZTVN10__cxxabiv117__class_type_infoE [vo/vdpau] Error when calling vdp_device_create_x11: 1 Cc: <mesa-stable@lists.freedesktop.org> Signed-off-by: Kusanagi Kouichi <slash@ac.auone-net.jp> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit 61f6cddef72a49d87e2b31ed49cdbc941d3b1efc)
* main: Avoid double-free of shader LabelCarl Worth2014-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | As documented, the _mesa_free_shader_program_data function: "Frees all the data that hangs off a shader program object, but not the object itself." This means that this function may be called multiple times on the same object, (and has been observed to). Meanwhile, the shProg->Label field was not being set to NULL after its free(). This led to a second call to free() of the same address on the second call to this function. Fix this by setting this field to NULL after free(), (just as with all other calls to free() in this function). Reviewed-by: Brian Paul <brianp@vmware.com> CC: mesa-stable@lists.freedesktop.org (cherry picked from commit a92581acf2aba5e5e9fa199b778e649d5741754d)
* nouveau: fix chipset checks for nv1a by using the oclass insteadIlia Mirkin2014-03-043-7/+8
| | | | | | | | | | | | | Commit f4ebcd133b9 ("dri/nouveau: NV17_3D class is not available for NV1a chipset") fixed this partially by using the correct 3d class. However there were a lot of checks left over comparing against the chipset. Reported-and-tested-by: John F. Godfrey <jfgodfrey@gmail.com> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: 9.2 10.0 10.1 <mesa-stable@lists.freedesktop.org> Reviewed-by: Francisco Jerez <currojerez@riseup.net> (cherry picked from commit 0c8b165366d68291e3013c7308b8b1fdd5ade2a2)
* mesa: Preserve the NewArrays state when copying a VAOFredrik Höglund2014-03-041-0/+1
| | | | | | | | Cc: "10.1" "10.0" <mesa-stable@lists.freedesktop.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72895 Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit 9afbd04d892f96e7fc6b689ca57ea5da124f7560)
* dri/nouveau: Pass the API into _mesa_initialize_contextEmil Velikov2014-03-046-10/+16
| | | | | | | | | | | | Currently we create a OPENGL_COMPAT context regardless of what was requested by the program. Correct that by retaining the program's request and passing it into _mesa_initialize_context. Based on a similar commit for radeon/r200 by Ian Romanick. Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit 76d9f6d9729db1c999317a6b44818aa90c30a0b3)
* glsl: Add locking to builtin_builder singletonDaniel Kurtz2014-03-041-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider a multithreaded program with two contexts A and B, and the following scenario: 1. Context A calls initialize(), which allocates mem_ctx and starts building built-ins. 2. Context B calls initialize(), which sees mem_ctx != NULL and assumes everything is already set up. It returns. 3. Context B calls find(), which fails to find the built-in since it hasn't been created yet. 4. Context A finally finishes initializing the built-ins. This will break at step 3. Adding a lock ensures that subsequent callers of initialize() will wait until initialization is actually complete. Similarly, if any thread calls release while another thread is still initializing, or calling find(), the mem_ctx/shader would get free'd while from under it, leading to corruption or use-after-free crashes. Fixes sporadic failures in Piglit's glx-multithread-shader-compile. Bugzilla: https://bugs.freedesktop.org/69200 Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Cc: "10.1 10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit b47d231526821f5cff99546a984103a7222bc66c)
* nouveau/video: make sure that firmware is present when checking capsIlia Mirkin2014-03-043-4/+147
| | | | | | | | | | | | | Apparently some players are ill-prepared for us claiming that a decoder exists only to have creating it fail, and express this poor preparation with crashes (e.g. flash). Check that firmware is there to increase the chances of there being a high correlation between reported capabilities and ability to create a decoder. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: 10.0 10.1 <mesa-stable@lists.freedesktop.org> Tested-by: Emil Velikov <emil.l.velikov@gmail.com> (cherry picked from commit 40dd777b3307301e6580c5757c322a2ec99b5b37)
* nv30: report 8 maximum inputsIlia Mirkin2014-03-041-1/+1
| | | | | | | | | | | | | nvfx_fragprog_assign_generic only allows for up to 10/8 texcoords for nv40/nv30. This fixes compilation of the varying-packing tests. Furthermore it appears that the last 2 inputs on nv4x don't seem to work in those tests, so just report 8 everywhere for now. Tested on NV42, NV44. NV4B appears to have additional problems. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: 9.1 9.2 10.0 10.1 <mesa-stable@lists.freedesktop.org> (cherry picked from commit 356aff3a5c08be055d6befff99a72f5551b3ac2d)
* mesa: update assertion in detach_shader() for geom shadersBrian Paul2014-03-041-0/+1
| | | | | | | Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74723 Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org> Tested-by: Andreas Boll <andreas.boll.dev@gmail.com> (cherry picked from commit c325ec896545cc909f2f0e359f0bb0513a8a53b5)
* glsl: Don't lose precision qualifiers when encountering "centroid".Kenneth Graunke2014-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mesa fails to retain the precision qualifier when parsing: #version 300 es centroid in mediump vec2 v; Consider how the parser's type_qualifier production is applied. First, the precision_qualifier rule creates a new ast_type_qualifier: <precision: mediump> Then the storage_qualifier rule creates a second one: <flags: in> and calls merge_qualifier() to fold in any previous qualifications, returning: <flags: in, precision: mediump> Finally, the auxiliary_storage_qualifier creates one for "centroid": <flags: centroid> it then does $$ = $1 and $$.flags |= $2.flags, resulting in: <flags: centroid, in> Since precision isn't stored in the flags bitfield, it is lost. We need to instead call merge_qualifier to combine all the fields. Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reported-by: Kevin Rogovin <kevin.rogovin@intel.com> Reviewed-by: Matt Turner <mattst88@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 2062f40d81de4743758851b03dad506f9cb6f306)
* st/mesa: avoid sw fallback for getting/decompressing texturesBrian Paul2014-03-041-1/+3
| | | | | | | | | | | | If st_GetTexImage() is to decompress the texture, avoid the fallback path even if prefer_blit_based_texture_transfer = false. For drivers that returned PIPE_CAP_PREFER_BLIT_BASED_TEXTURE_TRANSFER = 0, we were always taking the fallback path for texture decompression rather than rendering a quad. The later is a lot faster. Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Marek Olšák <marek.olsak@amd.com> (cherry picked from commit f47e5962885d9f7de23a8c9c9ba035017e24ffd6)
* glsl: Initialize ubo_binding_mask flags to zero.Matt Turner2014-03-041-0/+1
| | | | | | | | | | Missed in commit e63bb298. Caused sporadic test failures, like incorrect-in-layout-qualifier-repeated-prim.geom. Cc: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (cherry picked from commit e2ef93cf94ee553e5de70a7c26fd0724d967d0b2)
* st/mesa: fix crash when a shader uses a TBO and it's not boundMarek Olšák2014-03-041-0/+6
| | | | | | | | | | This binds a NULL sampler view in that case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74251 Cc: "10.1" "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Brian Paul <brianp@vmware.com> (cherry picked from commit c6dbcf10dff1f8343a26081f5489ef732ebb5460)
* glsl: Fix continue statements in do-while loops.Paul Berry2014-03-041-9/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From the GLSL 4.40 spec, section 6.4 (Jumps): The continue jump is used only in loops. It skips the remainder of the body of the inner most loop of which it is inside. For while and do-while loops, this jump is to the next evaluation of the loop condition-expression from which the loop continues as previously defined. Previously, we incorrectly treated a "continue" statement as jumping to the top of a do-while loop. This patch fixes the problem by replicating the loop condition when converting the "continue" statement to IR. (We already do a similar thing in "for" loops, to ensure that "continue" causes the loop expression to be executed). Fixes piglit tests: - glsl-fs-continue-inside-do-while.shader_test - glsl-vs-continue-inside-do-while.shader_test - glsl-fs-continue-in-switch-in-do-while.shader_test - glsl-vs-continue-in-switch-in-do-while.shader_test Cc: mesa-stable@lists.freedesktop.org Acked-by: Carl Worth <cworth@cworth.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 7f5740899fe8ee2d7fecebf1b9622e06dbc78f43)
* glsl: Make condition_to_hir() callable from outside ast_iteration_statement.Paul Berry2014-03-042-7/+6
| | | | | | | | | | | | | | | | | In addition to making it public, we also need to change its first argument from an ir_loop * to an exec_list *, so that it can be used to insert the condition anywhere in the IR (rather than just in the body of the loop). This will be necessary in order to make continue statements work properly in do-while loops. Cc: mesa-stable@lists.freedesktop.org Acked-by: Carl Worth <cworth@cworth.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Matt Turner <mattst88@gmail.com> (cherry picked from commit 56790856b303ad5ba86d7eb261ade91edaa3ee0b)
* i965/blorp: do not use unnecessary hw-blending supportTopi Pohjolainen2014-03-041-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is really not needed as blorp blit programs already sample XRGB normally and get alpha channel set to 1.0 automatically by the sampler engine. This is simply copied directly to the payload of the render target write message and hence there is no need for any additional blending support from the pixel processing pipeline. The blending formula is anyway broken for color components, it multiplies the color component with itself (blend factor is the component itself). Alpha blending in turn would not fix the alpha to one independent of the source but simply used the source alpha as is instead (1.0 * src_alpha + 0.0 * dst_alpha). Quoting Eric: "If we want to actually make the no-alpha-bits-present thing work, we need to override the bits in the surface state or in the generated code. In the normal draw path, it's done for sampling by the swizzling code in brw_wm_surface_state.c, and the blending overrides is just to fix up the alpha blending stage which doesn't pay attention to that for the destination surface." If one modifies piglit test gl-3.2-layered-rendering-blit to use color component values other than zero or one, this change will kick in on IVB. No regressions on IVB. This is effectively revert of c0554141a9b831b4e614747104dcbbe0fe489b9d: i965/blorp: Support overriding destination alpha to 1.0. Currently, Blorp requires the source and destination formats to be equal. However, we'd really like to be able to blit between XRGB and ARGB formats; our BLT engine paths have supported this for a long time. For ARGB -> XRGB, nothing needs to occur: the missing alpha is already interpreted as 1.0. For XRGB -> ARGB, we need to smash the alpha channel to 1.0 when writing the destination colors. This is fairly straightforward with blending. For now, this code is never used, as the source and destination formats still must be equal. The next patch will relax that restriction. NOTE: This is a candidate for the 9.1 branch. Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com> (cherry picked from commit 933be19cdf97aed977cd656e5c15c99cbdb52b7f)
* radeon/uvd: fix feedback buffer handling v2Christian König2014-03-041-12/+28
| | | | | | | | | | | | Without the correct feedback buffer size UVD runs into an error on each frame, reducing the maximum FPS. v2: fixing Michels comments Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Cc: "10.1" "10.0" "9.2" <mesa-stable@lists.freedesktop.org> (cherry picked from commit c3c24c3accd1401cbe96098e44850bb1130d80b9)
* draw: fix incorrect color of flat-shaded clipped linesBrian Paul2014-03-041-1/+12
| | | | | | | | | | | | | When we clipped a line weren't copying the provoking vertex color to the second vertex. We also weren't checking for first vs. last provoking vertex. Fixes failures found with the new piglit line-flat-clip-color test. Cc: "10.0, 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> (cherry picked from commit fc3fcd1e01093e8ab8d06d95c53f875ace57ca7f)
* gallium/auxiliary/indices: replace free() with FREE()Brian Paul2014-03-041-1/+1
| | | | | | | | | To match the CALLOC_STRUCT() call. Cc: "10.0, 10.1" <mesa-stable@lists.freedesktop.org> Reviewed-by: Jose Fonseca <jfonseca@vmware.com> (cherry picked from commit 307fd76053da39242ada2701b0d32b2177fe3493)
* meta: Consistenly use non-Apple VAO functionsIan Romanick2014-03-041-4/+4
| | | | | | | | | | | For these objects, meta was already using the non-Apple function to delete the objects. Everywhere else in the file uses _mesa_GenVertexArrays and _mesa_BindVertexArrays. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit abfa65ca811099332c8683dada9a2ee44cc01dc9)
* meta: Fallback to software for GetTexImage of compressed ↵Ian Romanick2014-03-041-1/+2
| | | | | | | | | | | | | | GL_TEXTURE_CUBE_MAP_ARRAY The hardware decompression path isn't even close to being able to handle this. This converts the crash (assertion failure) in "EXT_texture_compression_s3tc/getteximage-targets S3TC CUBE_ARRAY" to a plain old failure. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 070f55d8935af6fee62506b54bc86c1bf5049a82)
* meta: Release resources used by _mesa_meta_DrawPixelsIan Romanick2014-03-041-0/+19
| | | | | | | | | | | _mesa_meta_DrawPixels creates a VAO and (potentially) two fragment programs, but none of them are ever released. Leaking piles of memory is generally frowned upon. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit fcb498302bff912ca4f3169d37cc04b58e77d0fa)
* meta: Release resources used by decompress_texture_imageIan Romanick2014-03-041-0/+21
| | | | | | | | | | | | decompress_texture_image creates an FBO, an RBO, a VBO, a VAO, and a sampler object, but none of them are ever released. Later patches will add program objects, exacerbating the problem. Leaking piles of memory is generally frowned upon. Signed-off-by: Ian Romanick <ian.d.romanick@intel.com> Reviewed-by: Brian Paul <brianp@vmware.com> Cc: "9.1 9.2 10.0" <mesa-stable@lists.freedesktop.org> (cherry picked from commit 2d3f92e881dbd9d1aff17bba0d182c8ef645a2ca)
* radeon: move driContextSetFlags(ctx) call after ctx var is initializedBrian Paul2014-03-041-2/+3
| | | | | | CC: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f51ca46f0c7c3b87b62f6047b266faeffbaae619)
* r200: move driContextSetFlags(ctx) call after ctx var is initializedBrian Paul2014-03-041-2/+3
| | | | | | | | Otherwise, ctx was a garbage value. CC: "10.0" <mesa-stable@lists.freedesktop.org> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2d6d69bab6c74d92514b81a68c6c8b1dc428182a)
* mesa: Generate correct error code in glDrawBuffers()Anuj Phogat2014-03-041-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | OpenGL 3.3 spec expects GL_INVALID_OPERATION: "For both the default framebuffer and framebuffer objects, the constants FRONT, BACK, LEFT, RIGHT, and FRONT AND BACK are not valid in the bufs array passed to DrawBuffers, and will result in the error INVALID OPERATION." But OpenGL 4.0 spec changed the error code to GL_INVALID_ENUM: "For both the default framebuffer and framebuffer objects, the constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not valid in the bufs array passed to DrawBuffers, and will result in the error INVALID_ENUM." This patch changes the behaviour to match OpenGL 4.0 spec Fixes Khronos OpenGL CTS draw_buffers_api.test. V2: Update the comment in code. Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> (cherry picked from commit 33034755583edfb7c5b773b8e38a9dfa8d317821)
View Lorry Controller Status