Re: [Mesa-dev] [PATCH] swrast: Use integer value 1 for true
On 08/25/2014 07:19 PM, Eric Anholt wrote: Tapani Pälli tapani.pa...@intel.com writes: commit 4e64cfbb4 changed how gl_constant_value bool gets interpreted with drivers, for swrast driver true should be 1. Signed-off-by: Tapani Pälli tapani.pa...@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82978 Everywhere else in swrast, true is 1.0f. Pretty sure you want fui(1.0) here. OK, my goal was to restore old behavior which seems that it had either value 1 or 0, set by glUniform functions or a uniform initializer. Maybe conversion to float is happening when reading the values from the uniform storage? // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82585] geometry shader with optional out variable segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=82585 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org Component|Drivers/Gallium/r600|Mesa core --- Comment #4 from Michel Dänzer mic...@daenzer.net --- I'm hitting this assertion failure in the GLSL IR to TGSI translation code first: ../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:2157:visit: Assertion `var-data.location != -1' failed. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82585] geometry shader with optional out variable segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=82585 --- Comment #5 from pa...@klacansky.com --- Created attachment 105268 -- https://bugs.freedesktop.org/attachment.cgi?id=105268action=edit Valgrind output This is output from valgrind, mesa is from here https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82585] geometry shader with optional out variable segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=82585 --- Comment #6 from Michel Dänzer mic...@daenzer.net --- Created attachment 105270 -- https://bugs.freedesktop.org/attachment.cgi?id=105270action=edit GLSL dump and backtrace -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
Am 26.08.2014 um 03:54 schrieb Rob Clark: On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke kenn...@whitecape.org wrote: we've already had problems where distros refused to ship newer Mesa releases because radeon depended on a version of LLVM newer than the one they were shipping, [...] That's news to me, can you be more specific? That sounds like basically a distro issue though, since different LLVM versions can be installed in parallel (and the one used by default doesn't have to be the newest one). And it even works if another part of the same process uses a different version of LLVM. Yes, one can argue that it's a distribution issue - but it's an extremely painful problem for distributions. For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08 to 2014-03-22), and I was told this was because of LLVM versioning changes in the other drivers (primarily radeon, I believe, but probably also llvmpipe). Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we fixed that in Mesa 9.2.3. But we couldn't get people to actually ship it, and had to field tons of bug reports from upset users for several months. Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo Mesa package mantainer) can probably comment more. I've also heard stories from friends of mine who use radeonsi that they couldn't get new GL features or compiler fixes unless they upgrade both Mesa /and/ LLVM, and that LLVM was usually either not released or not available in their distribution for a few months. Those are the sorts of things I'd like to avoid. The compiler is easily the most crucial part of a modern graphics stack; splitting it out into a separate repository and project seems like a nightmare for people who care about getting new drivers released and shipped in distributions in a timely fashion. Or, looking at it the other way: today, everything you need as an Intel or (AFAIK) Nouveau 3D user is nicely contained within Mesa. Our community has complete control over when we do those releases. New important bug fixes, performance improvements, or features? Ship a new Mesa, and you're done. That's a really nice feature I'd hate to lose. tbh, it sounds a lot to me like if we start using LLVM more heavily/widely in mesa we should import LLVM (or at least the parts we need) into the mesa src tree.. as it is, the logistical/distro issues of LLVM have been what has scared me off the most about using it. Yes, agree totally. But I think we would always have that problem if we want to use a compiler infrastructure outside of mesa. Basically I see only two options: a) We do everything inside Mesa and so also need to maintain and develop it further by ourself. b) We use a compiler infrastructure outside of Mesa with the well known problems and advantages. Also what closed source drivers usually do is pulling a certain LLVM version into their code and so build the compiler infrastructure directly into their binaries. This obviously isn't such a good idea for distributions who seems to be concerned about the size of the resulting binaries, but completely avoids the version clash. But as far as I can see this could be avoid by maintaining both shared and static ways of compiling LLVM into Mesa. Using shared LLVM would mean that LLVM must be installed in one of the supported versions to use the resulting drivers. Using static LLVM can be used for somebody who just wants to build the drivers manually. We could even provide an option to download the necessary LLVM code, compile it locally and use it only for Mesa. Regards, Christian. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: Use integer value 1 for true
On 26/08/14 08:41, Tapani wrote: On 08/25/2014 07:19 PM, Eric Anholt wrote: Tapani Pälli tapani.pa...@intel.com writes: commit 4e64cfbb4 changed how gl_constant_value bool gets interpreted with drivers, for swrast driver true should be 1. Signed-off-by: Tapani Pälli tapani.pa...@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82978 Everywhere else in swrast, true is 1.0f. Pretty sure you want fui(1.0) here. OK, my goal was to restore old behavior which seems that it had either value 1 or 0, set by glUniform functions or a uniform initializer. Maybe conversion to float is happening when reading the values from the uniform storage? Would the final patch be nice to have in 10.3 or it's not something to worry about ? It seems like the issue was introduced in 10.3-dev. -Emil // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: Use integer value 1 for true
On 08/26/2014 02:29 PM, Emil Velikov wrote: On 26/08/14 08:41, Tapani wrote: On 08/25/2014 07:19 PM, Eric Anholt wrote: Tapani Pälli tapani.pa...@intel.com writes: commit 4e64cfbb4 changed how gl_constant_value bool gets interpreted with drivers, for swrast driver true should be 1. Signed-off-by: Tapani Pälli tapani.pa...@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82978 Everywhere else in swrast, true is 1.0f. Pretty sure you want fui(1.0) here. OK, my goal was to restore old behavior which seems that it had either value 1 or 0, set by glUniform functions or a uniform initializer. Maybe conversion to float is happening when reading the values from the uniform storage? Would the final patch be nice to have in 10.3 or it's not something to worry about ? It seems like the issue was introduced in 10.3-dev. It's a recent regression that starts with commits 6df0fd8 and 9e2e7c7 that take Const.UniformBooleanTrue in to use. I don't think this is urgent but a bug fix anyway. -Emil // Tapani ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Clamp/saturate optimizations v3
On 23.08.2014 02:57, Ian Romanick wrote: Patches 2, 3, 4, 5, 6, 9, 10, 11, 12, 15, and 17 are Reviewed-by: Ian Romanick ian.d.roman...@intel.com (Additional question below.) On 08/18/2014 05:17 AM, Abdiel Janulgue wrote: v3 of clamp and saturate optimizations Changes since v1: - Only remove the old try_emit_saturate operations after the new optimizations are in place. (Matt, Ian) - Output [min/max](saturate(x),b) instead of saturate([min/max](x,b)) as suggested by Ilia Mirkin. - The change above required some refactoring in the fs/vec4 backend to allow propagation of certain instructions with saturate flag to SEL. For other instructions, we don't propagate saturate instructions, similar to the previous behaviour. Since v2: - Fix comments to reflect we are doing a commutative operation, add missing conditions when optimizing clamp in opt_algebraic pass. - Refactor try_emit_saturate() in i965/fs instead of completely removing it. This fixed a a regression where the changes emitted an (extra) unnecessary saturated mov when the expression generating src can do saturate directly instead. - Fix regression in the i965/vec4 copy-propagate optimization caused by ignoring channels in the propagated instruction. - Count generated loops from the fs/vec4 generator. Results from our shader-db: total instructions in shared programs: 4538627 - 4560104 (0.47%) instructions in affected programs: 45144 - 66621 (47.57%) total loops in shared programs:887 - 711 (-19.84%) GAINED:0 LOST: 36 Can we try benchmarking the applications that have shaders that lost SIMD16 before pushing these changes? I'd hate to have an optimization that actually makes performance worse. :( There were a couple of games that lost simd16: heroes-of-newerth and savage2. However, it is interesting that the same games also reported an even higher amount of shaders that gained improvements (loop reductions and instruction count reduction) with the saturate optimizations switched on. I did a preliminary comparison on HoN: x Heroes_Of_Newearth_master + Heroes_Of_Newearth_sat_fixes N Min MaxMedian AvgStddev x 11 53.1 55.8 55.1 54.872727 0.83317574 + 11 54.256 55.1 55.036364 0.59375538 No difference proven at 95.0% confidence I'll post the results of savage2 as soon as I get it running. I modified shader-db a bit to catch loops unrolls. The shaders that show increase in instruction count are all due to the loop unroll pass triggered by this optimization on games that contain looped clamp/saturate operation. The unroll pass also resulted in a few shaders with looped clamp/sat skipping SIMD16 generation. ** No piglit regressions observed ** Abdiel Janulgue (17): i965/vec4/fs: Count loops in shader debug glsl: Add ir_unop_saturate glsl: Add constant evaluation of ir_unop_saturate glsl: Add a pass to lower ir_unop_saturate to clamp(x, 0, 1) ir_to_mesa, glsl_to_tgsi: lower ir_unop_saturate ir_to_mesa, glsl_to_tgsi: Add support for ir_unop_saturate i965/fs: Add support for ir_unop_saturate i965/vec4: Add support for ir_unop_saturate glsl: Implement saturate as ir_unop_saturate glsl: Optimize clamp(x, 0, 1) as saturate(x) glsl: Optimize clamp(x, 0.0, b), where b 1.0 as min(saturate(x),b) glsl: Optimize clamp(x, b, 1.0), where b 0.0 as max(saturate(x),b) i965/fs: Allow propagation of instructions with saturate flag to sel i965/vec4: Allow propagation of instructions with saturate flag to sel ir_to_mesa, glsl_to_tgsi: Remove try_emit_saturate i965/fs: Refactor try_emit_saturate i965/vec4: Remove try_emit_saturate src/glsl/ir.cpp | 2 + src/glsl/ir.h| 1 + src/glsl/ir_builder.cpp | 6 +- src/glsl/ir_constant_expression.cpp | 6 ++ src/glsl/ir_optimization.h | 1 + src/glsl/ir_validate.cpp | 1 + src/glsl/lower_instructions.cpp | 29 src/glsl/opt_algebraic.cpp | 98 ++ src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp | 1 + src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp| 18 - src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 6 +- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 27 --- src/mesa/drivers/dri/i965/brw_vec4.h | 2 +- src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 85 +++--- src/mesa/drivers/dri/i965/brw_vec4_generator.cpp | 6
[Mesa-dev] [Bug 75315] libglapi build failure with gcc -fsanitize=address
https://bugs.freedesktop.org/show_bug.cgi?id=75315 --- Comment #12 from Fabio Pedretti fabio@libero.it --- I tried the workaround in 1., adding -fsanitize=address to CC and CXX, now it links with it, however for some reason it still fails with the same error: https://launchpadlibrarian.net/183204096/buildlog_ubuntu-utopic-i386.mesa_10.4~git1408261422.018875%2Bgallium-nine~gd~u_FAILEDTOBUILD.txt.gz -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] draw: fix base instance handling in llvm path
Great find Roland.
Patch looks good.
Jose
On 25/08/14 21:05, srol...@vmware.com wrote:
From: Roland Scheidegger srol...@vmware.com
The base instance needs to be passed to the jited function, otherwise the
instanced data fetch will only work with the same start instance when the
jit function was created (and baking that into the key instead is not a viable
option).
This fixes piglit arb_base_instance-drawarrays (modulo some unrelated
core/compat context trouble I get for the test).
And fix the pipe cap bit in llvmpipe for it now that it actually works (it
already worked for softpipe).
---
src/gallium/auxiliary/draw/draw_llvm.c | 16 ++--
src/gallium/auxiliary/draw/draw_llvm.h | 6 --
.../auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c | 6 --
src/gallium/drivers/llvmpipe/lp_screen.c | 2 +-
src/gallium/drivers/softpipe/sp_screen.c | 2 +-
5 files changed, 20 insertions(+), 12 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index 2c6ca0d..467f074 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -645,7 +645,8 @@ generate_fetch(struct gallivm_state *gallivm,
struct pipe_vertex_element *velem,
LLVMValueRef vbuf,
LLVMValueRef index,
- LLVMValueRef instance_id)
+ LLVMValueRef instance_id,
+ LLVMValueRef start_instance)
{
const struct util_format_description *format_desc =
util_format_description(velem-src_format);
@@ -675,11 +676,11 @@ generate_fetch(struct gallivm_state *gallivm,
* index = start_instance + (instance_id / divisor)
*/
LLVMValueRef current_instance;
- index = lp_build_const_int32(gallivm, draw-start_instance);
current_instance = LLVMBuildUDiv(builder, instance_id,
lp_build_const_int32(gallivm,
velem-instance_divisor),
instance_divisor);
- index = lp_build_uadd_overflow(gallivm, index, current_instance, ofbit);
+ index = lp_build_uadd_overflow(gallivm, start_instance,
+ current_instance, ofbit);
}
stride = lp_build_umul_overflow(gallivm, vb_stride, index, ofbit);
@@ -1473,7 +1474,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
struct gallivm_state *gallivm = variant-gallivm;
LLVMContextRef context = gallivm-context;
LLVMTypeRef int32_type = LLVMInt32TypeInContext(context);
- LLVMTypeRef arg_types[10];
+ LLVMTypeRef arg_types[11];
unsigned num_arg_types =
elts ? Elements(arg_types) : Elements(arg_types) - 1;
LLVMTypeRef func_type;
@@ -1484,7 +1485,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
struct lp_type vs_type;
LLVMValueRef end, start;
LLVMValueRef count, fetch_elts, fetch_elt_max, fetch_count;
- LLVMValueRef vertex_id_offset;
+ LLVMValueRef vertex_id_offset, start_instance;
LLVMValueRef stride, step, io_itr;
LLVMValueRef io_ptr, vbuffers_ptr, vb_ptr;
LLVMValueRef zero = lp_build_const_int32(gallivm, 0);
@@ -1533,6 +1534,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
arg_types[i++] = get_vb_ptr_type(variant); /* pipe_vertex_buffer's */
arg_types[i++] = int32_type; /* instance_id */
arg_types[i++] = int32_type; /* vertex_id_offset */
+ arg_types[i++] = int32_type; /* start_instance */
func_type = LLVMFunctionType(int32_type, arg_types, num_arg_types, 0);
@@ -1556,6 +1558,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
vb_ptr= LLVMGetParam(variant_func, 6 + (elts ? 1 : 0));
system_values.instance_id = LLVMGetParam(variant_func, 7 + (elts ? 1 : 0));
vertex_id_offset = LLVMGetParam(variant_func, 8 + (elts ? 1 : 0));
+ start_instance= LLVMGetParam(variant_func, 9 + (elts ? 1 : 0));
lp_build_name(context_ptr, context);
lp_build_name(io_ptr, io);
@@ -1564,6 +1567,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
lp_build_name(vb_ptr, vb);
lp_build_name(system_values.instance_id, instance_id);
lp_build_name(vertex_id_offset, vertex_id_offset);
+ lp_build_name(start_instance, start_instance);
if (elts) {
fetch_elts= LLVMGetParam(variant_func, 3);
@@ -1712,7 +1716,7 @@ draw_llvm_generate(struct draw_llvm *llvm, struct
draw_llvm_variant *variant,
LLVMValueRef vb = LLVMBuildGEP(builder, vb_ptr, vb_index, 1, );
generate_fetch(gallivm, draw, vbuffers_ptr,
aos_attribs[j][i], velem, vb, true_index,
-
Re: [Mesa-dev] [PATCH libclc] Fix build against LLVM SVN = r216393
Wrong list(s)? I don't see libclc-dev on the cc list.
Also:
Tested-by: Aaron Watry awa...@gmail.com
On Mon, Aug 25, 2014 at 10:53 PM, Michel Dänzer mic...@daenzer.net wrote:
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
utils/prepare-builtins.cpp | 10 ++
1 file changed, 10 insertions(+)
diff --git a/utils/prepare-builtins.cpp b/utils/prepare-builtins.cpp
index 726866e..59f3999 100644
--- a/utils/prepare-builtins.cpp
+++ b/utils/prepare-builtins.cpp
@@ -95,6 +95,15 @@ int main(int argc, char **argv) {
return 1;
}
+#if LLVM_VERSION_MAJOR 3 || (LLVM_VERSION_MAJOR == 3 LLVM_VERSION_MINOR
= 6)
+ std::error_code EC;
+ UNIQUE_PTRtool_output_file Out
+ (new tool_output_file(OutputFilename.c_str(), EC, sys::fs::F_None));
+ if (EC) {
+errs() EC.message() '\n';
+exit(1);
+ }
+#else
std::string ErrorInfo;
UNIQUE_PTRtool_output_file Out
(new tool_output_file(OutputFilename.c_str(), ErrorInfo,
@@ -109,6 +118,7 @@ int main(int argc, char **argv) {
errs() ErrorInfo '\n';
exit(1);
}
+#endif // LLVM_VERSION_MAJOR 3 || (LLVM_VERSION_MAJOR == 3
LLVM_VERSION_MINOR = 6)
WriteBitcodeToFile(M.get(), Out-os());
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 75315] libglapi build failure with gcc -fsanitize=address
https://bugs.freedesktop.org/show_bug.cgi?id=75315 --- Comment #13 from Emil Velikov emil.l.veli...@gmail.com --- (In reply to comment #12) I tried the workaround in 1., adding -fsanitize=address to CC and CXX, now it links with it, however for some reason it still fails with the same error: https://launchpadlibrarian.net/183204096/buildlog_ubuntu-utopic-i386.mesa_10. 4~git1408261422.018875%2Bgallium-nine~gd~u_FAILEDTOBUILD.txt.gz Strange... from the above three suggestions 1 and 2 work like a charm on my Archlinux. If I have to speculate I would call it a gcc bug, yet it seem that we both have the same version - 4.9.1. Can you track it down if it's not a gcc/distro specific ? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80561] Incorrect implementation of some VDPAU APIs.
https://bugs.freedesktop.org/show_bug.cgi?id=80561 Christian König deathsim...@vodafone.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Christian König deathsim...@vodafone.de --- I've just pushed the fix upstream. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On 26/08/14 10:04, Christian König wrote: Am 26.08.2014 um 03:54 schrieb Rob Clark: On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke kenn...@whitecape.org wrote: we've already had problems where distros refused to ship newer Mesa releases because radeon depended on a version of LLVM newer than the one they were shipping, [...] That's news to me, can you be more specific? That sounds like basically a distro issue though, since different LLVM versions can be installed in parallel (and the one used by default doesn't have to be the newest one). And it even works if another part of the same process uses a different version of LLVM. Yes, one can argue that it's a distribution issue - but it's an extremely painful problem for distributions. For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08 to 2014-03-22), and I was told this was because of LLVM versioning changes in the other drivers (primarily radeon, I believe, but probably also llvmpipe). Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we fixed that in Mesa 9.2.3. But we couldn't get people to actually ship it, and had to field tons of bug reports from upset users for several months. Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo Mesa package mantainer) can probably comment more. I've also heard stories from friends of mine who use radeonsi that they couldn't get new GL features or compiler fixes unless they upgrade both Mesa /and/ LLVM, and that LLVM was usually either not released or not available in their distribution for a few months. Those are the sorts of things I'd like to avoid. The compiler is easily the most crucial part of a modern graphics stack; splitting it out into a separate repository and project seems like a nightmare for people who care about getting new drivers released and shipped in distributions in a timely fashion. Or, looking at it the other way: today, everything you need as an Intel or (AFAIK) Nouveau 3D user is nicely contained within Mesa. Our community has complete control over when we do those releases. New important bug fixes, performance improvements, or features? Ship a new Mesa, and you're done. That's a really nice feature I'd hate to lose. tbh, it sounds a lot to me like if we start using LLVM more heavily/widely in mesa we should import LLVM (or at least the parts we need) into the mesa src tree.. as it is, the logistical/distro issues of LLVM have been what has scared me off the most about using it. Yes, agree totally. But I think we would always have that problem if we want to use a compiler infrastructure outside of mesa. Not sure in what way would having LLVM in mesa's source tree be an improvement upon building and linking LLVM from an external repository. Just so we fool packagers into believing it is a single project? It's cumbersome and won't change anything. For example, Apitrace bundles several thirdparty libraries, so it statically links them into the wrappers shared objects to prevent symbol collision when tracing proprietary applications which sometimes also bundle their own dependencies. Yet I note most distros patch apitrace source tree to use the system's libraries instead of the bundled tree. I'm pretty sure they would do precisely the same with Mesa if LLVM was imported into Mesa tree. Basically I see only two options: a) We do everything inside Mesa and so also need to maintain and develop it further by ourself. b) We use a compiler infrastructure outside of Mesa with the well known problems and advantages. Also what closed source drivers usually do is pulling a certain LLVM version into their code and so build the compiler infrastructure directly into their binaries. This obviously isn't such a good idea for distributions who seems to be concerned about the size of the resulting binaries, but completely avoids the version clash. I think it is unreasonable for distros to expect to have both ways: either they package multiple versions of LLVM (or at least one suited to Mesa), or they accept upgrading LLVM whenever they upgrade Mesa. They can't expect us to not depend on LLVM just to make packaging easier... And I must say: basing the decision to use LLVM or any other compilation framework based on how easy it is to package is having priorities _completely_ backwards. If LLVM was a useless piece of junk, we wouldn't have any trouble adding it as a dependency, as we would be the sole user. But precisely because LLVM is successful in so many use cases, hence several packages depend on it, we shouldn't depend, so we can avoid the dealing with the oh-so-hard dependency issue!? I find it ridiculous: it's precisely because LLVM is potentially that good that it makes sense for us/distros/everybody to put up with the dependencies issues it may bring, and worth considering. And the same reasoning goes for using LLVM vs writing a compiler framework in-house. Deciding on technical legal
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
Am 26.08.2014 um 18:00 schrieb Jose Fonseca: On 26/08/14 10:04, Christian König wrote: Am 26.08.2014 um 03:54 schrieb Rob Clark: On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke kenn...@whitecape.org wrote: we've already had problems where distros refused to ship newer Mesa releases because radeon depended on a version of LLVM newer than the one they were shipping, [...] That's news to me, can you be more specific? That sounds like basically a distro issue though, since different LLVM versions can be installed in parallel (and the one used by default doesn't have to be the newest one). And it even works if another part of the same process uses a different version of LLVM. Yes, one can argue that it's a distribution issue - but it's an extremely painful problem for distributions. For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08 to 2014-03-22), and I was told this was because of LLVM versioning changes in the other drivers (primarily radeon, I believe, but probably also llvmpipe). Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we fixed that in Mesa 9.2.3. But we couldn't get people to actually ship it, and had to field tons of bug reports from upset users for several months. Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo Mesa package mantainer) can probably comment more. I've also heard stories from friends of mine who use radeonsi that they couldn't get new GL features or compiler fixes unless they upgrade both Mesa /and/ LLVM, and that LLVM was usually either not released or not available in their distribution for a few months. Those are the sorts of things I'd like to avoid. The compiler is easily the most crucial part of a modern graphics stack; splitting it out into a separate repository and project seems like a nightmare for people who care about getting new drivers released and shipped in distributions in a timely fashion. Or, looking at it the other way: today, everything you need as an Intel or (AFAIK) Nouveau 3D user is nicely contained within Mesa. Our community has complete control over when we do those releases. New important bug fixes, performance improvements, or features? Ship a new Mesa, and you're done. That's a really nice feature I'd hate to lose. tbh, it sounds a lot to me like if we start using LLVM more heavily/widely in mesa we should import LLVM (or at least the parts we need) into the mesa src tree.. as it is, the logistical/distro issues of LLVM have been what has scared me off the most about using it. Yes, agree totally. But I think we would always have that problem if we want to use a compiler infrastructure outside of mesa. Not sure in what way would having LLVM in mesa's source tree be an improvement upon building and linking LLVM from an external repository. I'm not talking about pulling LLVM into mesa, but rather giving the build system an option to download a known good version of LLVM and using that one to build mesa. This would for example simplify bisecting, since when you build a certain mesa version it would automatically build the known good LLVM version as well. Just so we fool packagers into believing it is a single project? It's cumbersome and won't change anything. For example, Apitrace bundles several thirdparty libraries, so it statically links them into the wrappers shared objects to prevent symbol collision when tracing proprietary applications which sometimes also bundle their own dependencies. Yet I note most distros patch apitrace source tree to use the system's libraries instead of the bundled tree. I'm pretty sure they would do precisely the same with Mesa if LLVM was imported into Mesa tree. Yeah, exactly what I suggested as well. Just that you don't need to patch it to build it separately, but rather provide an upstream compile time switch to do so. Basically I see only two options: a) We do everything inside Mesa and so also need to maintain and develop it further by ourself. b) We use a compiler infrastructure outside of Mesa with the well known problems and advantages. Also what closed source drivers usually do is pulling a certain LLVM version into their code and so build the compiler infrastructure directly into their binaries. This obviously isn't such a good idea for distributions who seems to be concerned about the size of the resulting binaries, but completely avoids the version clash. I think it is unreasonable for distros to expect to have both ways: either they package multiple versions of LLVM (or at least one suited to Mesa), or they accept upgrading LLVM whenever they upgrade Mesa. They can't expect us to not depend on LLVM just to make packaging easier... And I must say: basing the decision to use LLVM or any other compilation framework based on how easy it is to package is having priorities _completely_ backwards. If LLVM was a useless piece of junk, we wouldn't have any trouble adding it as a
Re: [Mesa-dev] [PATCH 1/2] st/vdpau: fix vlVdpOutputSurfaceRender(Output|Bitmap)Surface
On 15/08/14 19:33, Emil Velikov wrote:
On 14/08/14 10:59, Christian König wrote:
From: Christian König christian.koe...@amd.com
Correctly handle that the source_surface is only optional.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80561
Cc: mesa-sta...@lists.freedesktop.org
Would be nice to get this in stable :)
Hi Christian,
Did you miss my comments below, or am I miss-understanding the spec ?
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/vdpau/device.c| 43
+++-
src/gallium/state_trackers/vdpau/output.c| 42
+++
src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
3 files changed, 71 insertions(+), 15 deletions(-)
[snip]
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index caae50f..3248f76 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -639,12 +639,19 @@ vlVdpOutputSurfaceRenderOutputSurface(VdpOutputSurface
destination_surface,
if (!dst_vlsurface)
return VDP_STATUS_INVALID_HANDLE;
- src_vlsurface = vlGetDataHTAB(source_surface);
- if (!src_vlsurface)
- return VDP_STATUS_INVALID_HANDLE;
+ if (source_surface == VDP_INVALID_HANDLE) {
AFAICS the spec says If source_surface is NULL... whereas VDP_INVALID_HANDLE
is defined as 0xU.
Here
+ src_sv = dst_vlsurface-device-dummy_sv;
+
+ } else {
+ vlVdpOutputSurface *src_vlsurface = vlGetDataHTAB(source_surface);
+ if (!src_vlsurface)
+ return VDP_STATUS_INVALID_HANDLE;
- if (dst_vlsurface-device != src_vlsurface-device)
- return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
+ if (dst_vlsurface-device != src_vlsurface-device)
+ return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
+
+ src_sv = src_vlsurface-sampler_view;
+ }
pipe_mutex_lock(dst_vlsurface-device-mutex);
vlVdpResolveDelayedRendering(dst_vlsurface-device, NULL, NULL);
@@ -703,12 +710,19 @@ vlVdpOutputSurfaceRenderBitmapSurface(VdpOutputSurface
destination_surface,
if (!dst_vlsurface)
return VDP_STATUS_INVALID_HANDLE;
- src_vlsurface = vlGetDataHTAB(source_surface);
- if (!src_vlsurface)
- return VDP_STATUS_INVALID_HANDLE;
+ if (source_surface == VDP_INVALID_HANDLE) {
Ditto.
and here
Cheers,
Emil
I'm not sure if we correctly handle another case from the spec (see below) but
that can be tackled independently.
The surface is treated as having four components: red, green, blue and alpha.
Any missing components are treated as 1.0. For example, for an A8
VdpBitmapSurface, alpha will come from the surface but red, green and blue
will be treated as 1.0
With the two fixed, the patch
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On 08/25/2014 06:58 PM, Rob Clark wrote: On Fri, Aug 22, 2014 at 11:13 AM, Connor Abbott cwabbo...@gmail.com wrote: Importing/forking the llvm IR code with a different symbol set, and trying to not intentionally be incompatible with their llvm. That sounds like a huge amount of work, possibly even more work than going it on our own because the LLVM project moves really quickly and we'd have to import all of the changes. Also, it seems pretty ugly and I'm sure distro maintainers would just looove a solution like that /s. Just look at the situation with Chromium and Fedora now (or at least last I checked). but do the parts we want move quickly (and do we *want* them to move quickly)? A fast moving dependency is not really a good thing. I'm also not too thrilled about having to field bug reports with you have this bug / performance problem / whatever because you built with a too old / too new version of LLVM. Closed source projects avoid this sort of problem (and the ABI issues) by just importing a blessed version of LLVM into their project... and that seems to be the model that the LLVM project expects. This impedence mismatch between expected development models is fundamentally at the core of all my issues with using LLVM in Mesa. BR, -R ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/vdpau: fix vlVdpOutputSurfaceRender(Output|Bitmap)Surface
On Tue, Aug 26, 2014 at 12:50 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 15/08/14 19:33, Emil Velikov wrote:
On 14/08/14 10:59, Christian König wrote:
From: Christian König christian.koe...@amd.com
Correctly handle that the source_surface is only optional.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80561
Cc: mesa-sta...@lists.freedesktop.org
Would be nice to get this in stable :)
Hi Christian,
Did you miss my comments below, or am I miss-understanding the spec ?
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/vdpau/device.c| 43
+++-
src/gallium/state_trackers/vdpau/output.c| 42
+++
src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
3 files changed, 71 insertions(+), 15 deletions(-)
[snip]
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index caae50f..3248f76 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -639,12 +639,19 @@
vlVdpOutputSurfaceRenderOutputSurface(VdpOutputSurface destination_surface,
if (!dst_vlsurface)
return VDP_STATUS_INVALID_HANDLE;
- src_vlsurface = vlGetDataHTAB(source_surface);
- if (!src_vlsurface)
- return VDP_STATUS_INVALID_HANDLE;
+ if (source_surface == VDP_INVALID_HANDLE) {
AFAICS the spec says If source_surface is NULL... whereas
VDP_INVALID_HANDLE
is defined as 0xU.
Here
typedef uint32_t VdpOutputSurface
It doesn't make sense to check for NULL... I think that
VDP_INVALID_HANDLE is in the same spirit as 'NULL'. Although perhaps
they really meant 0 (is 0 some sort of otherwise-disallowed handle?).
Not sure what the nvidia vdpau libs do...
-ilia
+ src_sv = dst_vlsurface-device-dummy_sv;
+
+ } else {
+ vlVdpOutputSurface *src_vlsurface = vlGetDataHTAB(source_surface);
+ if (!src_vlsurface)
+ return VDP_STATUS_INVALID_HANDLE;
- if (dst_vlsurface-device != src_vlsurface-device)
- return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
+ if (dst_vlsurface-device != src_vlsurface-device)
+ return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
+
+ src_sv = src_vlsurface-sampler_view;
+ }
pipe_mutex_lock(dst_vlsurface-device-mutex);
vlVdpResolveDelayedRendering(dst_vlsurface-device, NULL, NULL);
@@ -703,12 +710,19 @@
vlVdpOutputSurfaceRenderBitmapSurface(VdpOutputSurface destination_surface,
if (!dst_vlsurface)
return VDP_STATUS_INVALID_HANDLE;
- src_vlsurface = vlGetDataHTAB(source_surface);
- if (!src_vlsurface)
- return VDP_STATUS_INVALID_HANDLE;
+ if (source_surface == VDP_INVALID_HANDLE) {
Ditto.
and here
Cheers,
Emil
I'm not sure if we correctly handle another case from the spec (see below)
but
that can be tackled independently.
The surface is treated as having four components: red, green, blue and
alpha.
Any missing components are treated as 1.0. For example, for an A8
VdpBitmapSurface, alpha will come from the surface but red, green and blue
will be treated as 1.0
With the two fixed, the patch
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On 08/25/2014 06:54 PM, Rob Clark wrote: tbh, it sounds a lot to me like if we start using LLVM more heavily/widely in mesa we should import LLVM (or at least the parts we need) into the mesa src tree.. as it is, the logistical/distro issues of LLVM have been what has scared me off the most about using it. While this is the development model that LLVM expects (and the only one they support)... Dear god, no! This would mean that we would have to take the responsibility for keeping our diverged copy of LLVM in sync with bug fixes, etc. from upstream. For a project the size of LLVM, I can expect that to be a significant amount of work. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/vdpau: fix vlVdpOutputSurfaceRender(Output|Bitmap)Surface
On 26/08/14 18:01, Ilia Mirkin wrote:
On Tue, Aug 26, 2014 at 12:50 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 15/08/14 19:33, Emil Velikov wrote:
On 14/08/14 10:59, Christian König wrote:
From: Christian König christian.koe...@amd.com
Correctly handle that the source_surface is only optional.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80561
Cc: mesa-sta...@lists.freedesktop.org
Would be nice to get this in stable :)
Hi Christian,
Did you miss my comments below, or am I miss-understanding the spec ?
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/vdpau/device.c| 43
+++-
src/gallium/state_trackers/vdpau/output.c| 42
+++
src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
3 files changed, 71 insertions(+), 15 deletions(-)
[snip]
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index caae50f..3248f76 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -639,12 +639,19 @@
vlVdpOutputSurfaceRenderOutputSurface(VdpOutputSurface destination_surface,
if (!dst_vlsurface)
return VDP_STATUS_INVALID_HANDLE;
- src_vlsurface = vlGetDataHTAB(source_surface);
- if (!src_vlsurface)
- return VDP_STATUS_INVALID_HANDLE;
+ if (source_surface == VDP_INVALID_HANDLE) {
AFAICS the spec says If source_surface is NULL... whereas
VDP_INVALID_HANDLE
is defined as 0xU.
Here
typedef uint32_t VdpOutputSurface
It doesn't make sense to check for NULL... I think that
VDP_INVALID_HANDLE is in the same spirit as 'NULL'. Although perhaps
they really meant 0 (is 0 some sort of otherwise-disallowed handle?).
Not sure what the nvidia vdpau libs do...
I'm inclined to go with if (!source_surface), and judging by the reporter
quotation of the spec, I guess that they'll do the same. Whereas for what
exact is meant in the spec design, that would be an interesting question
indeed :)
I'll bring it up with on the vdpau ML.
-Emil
-ilia
+ src_sv = dst_vlsurface-device-dummy_sv;
+
+ } else {
+ vlVdpOutputSurface *src_vlsurface = vlGetDataHTAB(source_surface);
+ if (!src_vlsurface)
+ return VDP_STATUS_INVALID_HANDLE;
- if (dst_vlsurface-device != src_vlsurface-device)
- return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
+ if (dst_vlsurface-device != src_vlsurface-device)
+ return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
+
+ src_sv = src_vlsurface-sampler_view;
+ }
pipe_mutex_lock(dst_vlsurface-device-mutex);
vlVdpResolveDelayedRendering(dst_vlsurface-device, NULL, NULL);
@@ -703,12 +710,19 @@
vlVdpOutputSurfaceRenderBitmapSurface(VdpOutputSurface destination_surface,
if (!dst_vlsurface)
return VDP_STATUS_INVALID_HANDLE;
- src_vlsurface = vlGetDataHTAB(source_surface);
- if (!src_vlsurface)
- return VDP_STATUS_INVALID_HANDLE;
+ if (source_surface == VDP_INVALID_HANDLE) {
Ditto.
and here
Cheers,
Emil
I'm not sure if we correctly handle another case from the spec (see below)
but
that can be tackled independently.
The surface is treated as having four components: red, green, blue and
alpha.
Any missing components are treated as 1.0. For example, for an A8
VdpBitmapSurface, alpha will come from the surface but red, green and blue
will be treated as 1.0
With the two fixed, the patch
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/vdpau: fix vlVdpOutputSurfaceRender(Output|Bitmap)Surface
On Tue, Aug 26, 2014 at 1:18 PM, Emil Velikov emil.l.veli...@gmail.com wrote:
On 26/08/14 18:01, Ilia Mirkin wrote:
On Tue, Aug 26, 2014 at 12:50 PM, Emil Velikov emil.l.veli...@gmail.com
wrote:
On 15/08/14 19:33, Emil Velikov wrote:
On 14/08/14 10:59, Christian König wrote:
From: Christian König christian.koe...@amd.com
Correctly handle that the source_surface is only optional.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80561
Cc: mesa-sta...@lists.freedesktop.org
Would be nice to get this in stable :)
Hi Christian,
Did you miss my comments below, or am I miss-understanding the spec ?
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/vdpau/device.c| 43
+++-
src/gallium/state_trackers/vdpau/output.c| 42
+++
src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
3 files changed, 71 insertions(+), 15 deletions(-)
[snip]
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index caae50f..3248f76 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -639,12 +639,19 @@
vlVdpOutputSurfaceRenderOutputSurface(VdpOutputSurface
destination_surface,
if (!dst_vlsurface)
return VDP_STATUS_INVALID_HANDLE;
- src_vlsurface = vlGetDataHTAB(source_surface);
- if (!src_vlsurface)
- return VDP_STATUS_INVALID_HANDLE;
+ if (source_surface == VDP_INVALID_HANDLE) {
AFAICS the spec says If source_surface is NULL... whereas
VDP_INVALID_HANDLE
is defined as 0xU.
Here
typedef uint32_t VdpOutputSurface
It doesn't make sense to check for NULL... I think that
VDP_INVALID_HANDLE is in the same spirit as 'NULL'. Although perhaps
they really meant 0 (is 0 some sort of otherwise-disallowed handle?).
Not sure what the nvidia vdpau libs do...
I'm inclined to go with if (!source_surface), and judging by the reporter
quotation of the spec, I guess that they'll do the same. Whereas for what
exact is meant in the spec design, that would be an interesting question
indeed :)
I'll bring it up with on the vdpau ML.
Well, what if you have a legitimate surface, whose handle is 0? I
don't know of anything that prevents that, although IIRC in practice
the nvidia vdpau-supplied handles start at 1.
-ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/vdpau: fix vlVdpOutputSurfaceRender(Output|Bitmap)Surface
Am 26.08.2014 um 18:50 schrieb Emil Velikov:
On 15/08/14 19:33, Emil Velikov wrote:
On 14/08/14 10:59, Christian König wrote:
From: Christian König christian.koe...@amd.com
Correctly handle that the source_surface is only optional.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80561
Cc: mesa-sta...@lists.freedesktop.org
Would be nice to get this in stable :)
Hi Christian,
Did you miss my comments below, or am I miss-understanding the spec ?
I've missed your comment and the spec is a bit flaky about this.
As far as I know zero is a perfectly valid handle and VDP_INVALID_HANDLE
needs to be used instead.
Getting the issue on the VDPAU list is probably a good idea,
Christian.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/state_trackers/vdpau/device.c| 43 +++-
src/gallium/state_trackers/vdpau/output.c| 42 +++
src/gallium/state_trackers/vdpau/vdpau_private.h | 1 +
3 files changed, 71 insertions(+), 15 deletions(-)
[snip]
diff --git a/src/gallium/state_trackers/vdpau/output.c
b/src/gallium/state_trackers/vdpau/output.c
index caae50f..3248f76 100644
--- a/src/gallium/state_trackers/vdpau/output.c
+++ b/src/gallium/state_trackers/vdpau/output.c
@@ -639,12 +639,19 @@ vlVdpOutputSurfaceRenderOutputSurface(VdpOutputSurface
destination_surface,
if (!dst_vlsurface)
return VDP_STATUS_INVALID_HANDLE;
- src_vlsurface = vlGetDataHTAB(source_surface);
- if (!src_vlsurface)
- return VDP_STATUS_INVALID_HANDLE;
+ if (source_surface == VDP_INVALID_HANDLE) {
AFAICS the spec says If source_surface is NULL... whereas VDP_INVALID_HANDLE
is defined as 0xU.
Here
+ src_sv = dst_vlsurface-device-dummy_sv;
+
+ } else {
+ vlVdpOutputSurface *src_vlsurface = vlGetDataHTAB(source_surface);
+ if (!src_vlsurface)
+ return VDP_STATUS_INVALID_HANDLE;
- if (dst_vlsurface-device != src_vlsurface-device)
- return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
+ if (dst_vlsurface-device != src_vlsurface-device)
+ return VDP_STATUS_HANDLE_DEVICE_MISMATCH;
+
+ src_sv = src_vlsurface-sampler_view;
+ }
pipe_mutex_lock(dst_vlsurface-device-mutex);
vlVdpResolveDelayedRendering(dst_vlsurface-device, NULL, NULL);
@@ -703,12 +710,19 @@ vlVdpOutputSurfaceRenderBitmapSurface(VdpOutputSurface
destination_surface,
if (!dst_vlsurface)
return VDP_STATUS_INVALID_HANDLE;
- src_vlsurface = vlGetDataHTAB(source_surface);
- if (!src_vlsurface)
- return VDP_STATUS_INVALID_HANDLE;
+ if (source_surface == VDP_INVALID_HANDLE) {
Ditto.
and here
Cheers,
Emil
I'm not sure if we correctly handle another case from the spec (see below) but
that can be tackled independently.
The surface is treated as having four components: red, green, blue and alpha.
Any missing components are treated as 1.0. For example, for an A8
VdpBitmapSurface, alpha will come from the surface but red, green and blue
will be treated as 1.0
With the two fixed, the patch
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca jfons...@vmware.com wrote: If LLVM was a useless piece of junk, we wouldn't have any trouble adding it as a dependency, as we would be the sole user. But precisely because LLVM is successful in so many use cases, hence several packages depend on it, we shouldn't depend, so we can avoid the dealing with the oh-so-hard dependency issue!? I find it ridiculous: it's precisely because LLVM is potentially that good that it makes sense for us/distros/everybody to put up with the dependencies issues it may bring, and worth considering. It sounds like there are enough people in the Mesa community that are familiar with LLVM and interested in using it in the GLSL compiler that there would be someone willing to start working on it. Hopefully that's the case. I tried going through the LLVM language frontend tutorial on LLVM.org and only had to get to chapter 4 (the first two chapters don't use LLVM) before the code didn't compile (and I couldn't figure out why) with LLVM 3.4 on my system. I found this [1] tiny example (not updated for 2 years) using the C API and thought it'd probably not work either, but was happily surprised that it compiled and worked fine. I see that the C API is used in radeonsi and gallivm in Mesa. Here's what I think would be compelling: Using the stable C API, translate from GLSL IR into LLVM IR. Call LLVM's optimizations. Give backends the option to consume LLVM IR. From here we can evaluate just how significant the improvement from LLVM's optimizer is. At least two people have written GLSL IR - LLVM translators in the past -- Luca Barbieri (what ever happened to him?!) and Vincent Lejeune (Cc'd). Their code is [2] and [3]. I think this plan would also fit nicely with existing LLVM backends, potentially avoiding a trip through TGSI. I think this is strictly superior to other ideas like throwing out the GLSL frontend and translating LLVM IR back up to the higher level GLSL IR. So, maybe some people experienced with LLVM from VMware and AMD are interested in taking the lead? [1] https://github.com/wickedchicken/llvm-c-example [2] http://cgit.freedesktop.org/~anholt/mesa/log/?h=llvm-4 (Eric's branch based on Luca's code) [3] http://cgit.freedesktop.org/~vlj/mesa/ (one of the glsl-to-llvm* branches) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/vdpau: fix vlVdpOutputSurfaceRender(Output|Bitmap)Surface
On 26/08/14 18:32, Christian König wrote: Am 26.08.2014 um 18:50 schrieb Emil Velikov: On 15/08/14 19:33, Emil Velikov wrote: On 14/08/14 10:59, Christian König wrote: From: Christian König christian.koe...@amd.com Correctly handle that the source_surface is only optional. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80561 Cc: mesa-sta...@lists.freedesktop.org Would be nice to get this in stable :) Hi Christian, Did you miss my comments below, or am I miss-understanding the spec ? I've missed your comment and the spec is a bit flaky about this. As far as I know zero is a perfectly valid handle and VDP_INVALID_HANDLE needs to be used instead. Indeed you and Ilia are absolutely correct. The spec should say VDP_INVALID_HANDLE, as confirmed by Stephen Warren [1]. Pardon for the noise. Emil [1] http://lists.freedesktop.org/archives/vdpau/2014-August/000180.html Getting the issue on the VDPAU list is probably a good idea, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: uniform sampler should occupy 1 location
On 08/23/2014 07:51 AM, Micael wrote: On second thought, the glsl_type::uniform_locations() method comment in the header file says: /** * Calculate the number of unique values from glGetUniformLocation for the * elements of the type. */ Which makes me believe that maybe we should return at least 1 for every case because this is only called for explicit locations and therefore will not make shaders failing to link unless they've explicitely used more locations than they should. Maybe glsl_type::uniform_locations() should be renamed to something that makes it clear it's only used for explicit locations too, or make it clear that it reflects the size for the API, not GPU memory (since it's only used to fill prog-UniformRemapTable). I spent some time this morning looking at this code a bit more closely, and I think you're right. The problem is that GL overloads locations both to mean the number of handles a uniform gets and to mean amount of storage space the uniform occupies. For some things this is the same (simple variables, arrays, structures), but for other things it is not (matrices, samplers, other opaque types). I think it's weird for uniform_locations to call component_slots at all. Looking at the OpenGL 4.2 spec, it seems that everything except atomic counters and subroutines (not yet supported by Mesa) should have at least one location per array element. Here's what I think would be better: have uniform_locations mirror the structure of component_slots. Eliminate the is_matrix() check at the top, and just have all the basic types (e.g., GLSL_TYPE_FLOAT) return 1. Keeping functions separate that count separate kinds of things seems like a good idea. On Sat, Aug 23, 2014 at 2:07 PM, Micael kam1k...@gmail.com mailto:kam1k...@gmail.com wrote: On Fri, Aug 22, 2014 at 9:23 PM, Ian Romanick i...@freedesktop.org mailto:i...@freedesktop.org wrote: I'm not sure this is correct, and I think we need a more complex fix. As Dave points out, bindless will make it even more complex. In a non-bindless, static-sampler-array-indexing world, applications assume that samplers will use zero uniform locations. The sampler information is baked into the instructions, and it isn't represented anywhere else in GPU memory. As a result, I would not be surprised to see previously working applications fail to link (due to using too many uniforms) with this change. It seems that the only time a sampler needs non-zero space is when it is part of any array samplers (or array of structures containing samplers, etc.) or is bindless. In the array cases, it is probably only necessary when the index is dynamic. I think the array splitting and structure splitting passes may make that moot. Did you miss the case of assigning an explicit location to a sampler, or did you ommit on purpose? I'm not very familiar with mesa source, but as far as I could analyze it, only reserve_explicit_locations() and validate_explicit_location() call glsl_type::uniform_locations(), everything else uses glsl_type::component_slots(). Now I agree with you that simply returning 1 from glsl_type::uniform_locations() for samplers can be misleading. How about if glsl_type::uniform_locations() takes a bool isExplicitLocation and return at least 1 for every type? I am aware that this won't solve the bindless textures issue, but it would fix this bug (and the integer underflows) for now, I think. The 82921 bug seems to be an orthognal issue. There is a difference between the API visible locations assigned to a uniform and the GPU visible locations where the uniform is stored. My guess is that we're using the same accounting for both in places where we should not. On 08/21/2014 04:25 PM, Micael Dias wrote: --- If samplers occupy zero locations we can run into a lot of issues. See #82921. I briefly tested this with my own code (which was previously crashing and misbehaving) and also ran other apps and everything seems to work fine. I'm not used to contributing code in this fashion, so please forgive me if I'm making some mistake. Thanks. src/glsl/glsl_types.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/glsl/glsl_types.cpp b/src/glsl/glsl_types.cpp index 66e9b13..cc05193 100644 --- a/src/glsl/glsl_types.cpp +++ b/src/glsl/glsl_types.cpp @@ -691,6 +691,8 @@ glsl_type::uniform_locations() const return size; case GLSL_TYPE_ARRAY: return this-length *
[Mesa-dev] Mesa release manager
Hello list, As you may have noticed there are some changes coming in Mesa's releases. Namely, I will be taking over from Ian and Carl as Mesa's major and stable release manager. This will allow us to have timely releases, and will give Ian and Carl more time to focus on other parts of Mesa. My intent is to keep the original release process and clear-up any outstanding confusions regarding the estimated release dates and patch nominations. That does not mean that I won't welcome your feedback and suggestions. I would like to thank Ian and Carl for their work so far, making Mesa such a successful and stable project. Regards, Emil P.S. The plan is to have 10.3-rc2 this Friday, 10.3-rc3 and 10.2.7 for next one. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH v4] winsys/radeon: fix nop packet padding for hawaii
On 06/08/14 17:16, Alex Deucher wrote:
On Mon, Aug 4, 2014 at 6:48 AM, Andreas Boll andreas.boll@gmail.com
wrote:
The initial firmware for hawaii does not support type3 nop packet.
Detect the new hawaii firmware with query RADEON_INFO_ACCEL_WORKING2.
If the returned value is 3, then the new firmware is used.
This patch uses type2 for the old firmware and type3 for the new firmware.
It fixes the cases when the old firmware is used and the user wants to
manually enable acceleration.
The two possible scenarios are:
- the kernel has no support for the new firmware.
- the kernel has support for the new firmware but only the old firmware
is available.
Additionaly this patch disables GPU acceleration on hawaii if the kernel
returns a value 2. In this case the kernel hasn't the required fixes
for proper acceleration.
v2:
- Fix indentation
- Use private struct radeon_drm_winsys instead of public struct radeon_info
- Rename r600_accel_working2 to accel_working2
v3:
- Use type2 nop packet for returned value 3
v4:
- Fail to initialize winsys for returned value 2
Cc: mesa-sta...@lists.freedesktop.org
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: Jérôme Glisse jgli...@redhat.com
Cc: Marek Olšák marek.ol...@amd.com
Cc: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Andreas Boll andreas.boll@gmail.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
Gents this patch does not apply cleanly on the 10.2 branch. Would be nice if
someone can backport rather than me butchering it.
Thanks
Emil
---
Unfortunately I can't test this patch myself since I don't own a hawaii card.
So I'd need someone to test this patch on kernel = 3.16-rc7 + these patches
[1-2].
This patch would bring us one step further for hawaii acceleration on kernel
3.16.
Finally we can enable hawaii acceleration if the query returns 2 [3].
Andreas.
[1] http://lists.freedesktop.org/archives/dri-devel/2014-August/065305.html
[2] http://lists.freedesktop.org/archives/dri-devel/2014-August/065306.html
[3] http://lists.x.org/archives/xorg-driver-ati/2014-August/026534.html
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 6 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 10 ++
src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index a06ecb2..dd109af 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
@@ -446,8 +446,12 @@ static void radeon_drm_cs_flush(struct radeon_winsys_cs
*rcs,
case RING_GFX:
/* pad DMA ring to 8 DWs to meet CP fetch alignment requirements
* r6xx, requires at least 4 dw alignment to avoid a hw bug.
+ * hawaii with old firmware needs type2 nop packet.
+ * accel_working2 with value 2 indicates the new firmware.
*/
-if (cs-ws-info.chip_class = SI) {
+if (cs-ws-info.chip_class = SI ||
+(cs-ws-info.family == CHIP_HAWAII
+ cs-ws-accel_working2 3)) {
while (rcs-cdw 7)
OUT_CS(cs-base, 0x8000); /* type2 nop packet */
} else {
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
index 910d06b..ecff0e7 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
@@ -395,6 +395,16 @@ static boolean do_winsys_init(struct radeon_drm_winsys
*ws)
radeon_get_drm_value(ws-fd, RADEON_INFO_MAX_SH_PER_SE, NULL,
ws-info.max_sh_per_se);
+radeon_get_drm_value(ws-fd, RADEON_INFO_ACCEL_WORKING2, NULL,
+ ws-accel_working2);
+if (ws-info.family == CHIP_HAWAII ws-accel_working2 2) {
+fprintf(stderr, radeon: GPU acceleration for Hawaii disabled,
+returned accel_working2 value %u is smaller than 2.
+Please install a newer kernel.\n,
+ws-accel_working2);
+return FALSE;
+}
+
if (radeon_get_drm_value(ws-fd, RADEON_INFO_SI_TILE_MODE_ARRAY, NULL,
ws-info.si_tile_mode_array)) {
ws-info.si_tile_mode_array_valid = TRUE;
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
index ea6f7f0..aebc391 100644
--- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
+++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.h
@@ -55,6 +55,7 @@ struct radeon_drm_winsys {
enum radeon_generation gen;
struct radeon_info info;
uint32_t va_start;
+uint32_t accel_working2;
struct pb_manager *kman;
struct pb_manager *cman_vram;
--
2.0.1
___
Re: [Mesa-dev] [PATCH] mesa: guard better when building with sse4.1 optimisations
On 01/08/14 17:06, Emil Velikov wrote:
When the compiler is not capable/does not accept -msse4.1 while the target
has the instruction set we'll blow up as _mesa_streaming_load_memcpy is
going to be undefined.
To make sure that never happens, wrap the runtime cpu check+caller in an
ifdef thus do not compile that hunk of the code.
Fix the android build by enabling the optimisation and adding the define
where applicable.
This patch relies on earlier ones that did not land in the 10.2 branch. As
such the patch is not suitable in it's current form :\
-Emil
Cc: Matt Turner matts...@gmail.com
Cc: Adrian Negreanu adrian.m.negre...@intel.com
Cc: 10.1 10.2 mesa-sta...@lists.freedesktop.org
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Hi Matt,
I believe this is what you had in mind with your earlier comment -
avoid calling intel_miptree_map_movntdqa, when compiler does not support
-msse4.1, otherwise we end up with garbage output and/or locked up GPU.
Andrian,
Any chance you can give this patch/the series a test ? Things seems to
build fine in here but I'm a bit short on a Intel GPU.
-Emil
configure.ac | 3 +++
src/mesa/Android.libmesa_dricore.mk | 1 +
src/mesa/drivers/dri/i965/Android.mk | 5 +
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 ++
4 files changed, 11 insertions(+)
diff --git a/configure.ac b/configure.ac
index 698cd8d..d045619 100644
--- a/configure.ac
+++ b/configure.ac
@@ -238,6 +238,9 @@ dnl
dnl Optional flags, check for compiler support
dnl
AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+if test x$SSE41_SUPPORTED = x1; then
+DEFINES=$DEFINES -DUSE_SSE41
+endif
AM_CONDITIONAL([SSE41_SUPPORTED], [test x$SSE41_SUPPORTED = x1])
dnl
diff --git a/src/mesa/Android.libmesa_dricore.mk
b/src/mesa/Android.libmesa_dricore.mk
index 217f649..28d6feb 100644
--- a/src/mesa/Android.libmesa_dricore.mk
+++ b/src/mesa/Android.libmesa_dricore.mk
@@ -50,6 +50,7 @@ endif # MESA_ENABLE_ASM
ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
LOCAL_SRC_FILES += \
$(SRCDIR)main/streaming-load-memcpy.c
+LOCAL_CFLAGS := -msse4.1
endif
LOCAL_C_INCLUDES := \
diff --git a/src/mesa/drivers/dri/i965/Android.mk
b/src/mesa/drivers/dri/i965/Android.mk
index 7e3fd65..2c6446f 100644
--- a/src/mesa/drivers/dri/i965/Android.mk
+++ b/src/mesa/drivers/dri/i965/Android.mk
@@ -35,6 +35,11 @@ include $(LOCAL_PATH)/Makefile.sources
LOCAL_CFLAGS := \
$(MESA_DRI_CFLAGS)
+ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
+LOCAL_CFLAGS += \
+ -DUSE_SSE41
+endif
+
LOCAL_C_INCLUDES := \
$(i965_INCLUDES) \
$(MESA_DRI_C_INCLUDES) \
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index b36ffc7..1691b15 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -2270,8 +2270,10 @@ intel_miptree_map(struct brw_context *brw,
mt-bo-size = brw-max_gtt_map_object_size) {
assert(can_blit_slice(mt, level, slice));
intel_miptree_map_blit(brw, mt, map, level, slice);
+#if defined(USE_SSE41)
} else if (!(mode GL_MAP_WRITE_BIT) !mt-compressed
cpu_has_sse4_1) {
intel_miptree_map_movntdqa(brw, mt, map, level, slice);
+#endif
} else {
intel_miptree_map_gtt(brw, mt, map, level, slice);
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] radeon/compute: Report a value for PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE
On 08/08/14 15:16, Tom Stellard wrote:
CC: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/r600/r600_pipe.c | 11 ++-
src/gallium/drivers/radeonsi/si_pipe.c | 7 +++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index a08e70e..7ace671 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -421,7 +421,16 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
/* XXX Isn't this equal to TEMPS? */
return 1; /* Max native address registers */
case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE:
- return R600_MAX_CONST_BUFFER_SIZE;
+ if (shader == PIPE_SHADER_COMPUTE) {
+ uint64_t max_const_buffer_size;
+ pscreen-get_compute_param(pscreen,
+ PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE,
+ max_const_buffer_size);
+ return max_const_buffer_size;
+
+ } else {
+ return R600_MAX_CONST_BUFFER_SIZE;
+ }
case PIPE_SHADER_CAP_MAX_CONST_BUFFERS:
return R600_MAX_USER_CONST_BUFFERS;
case PIPE_SHADER_CAP_MAX_PREDS:
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 635b37d..791838f 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -327,6 +327,13 @@ static int si_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, enu
case PIPE_SHADER_CAP_DOUBLES:
return 0; /* XXX: Enable doubles once the compiler can
handle them. */
+ case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE: {
+ uint64_t max_const_buffer_size;
+ pscreen-get_compute_param(pscreen,
+ PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE,
+ max_const_buffer_size);
+ return max_const_buffer_size;
+ }
default:
return 0;
}
Hello Tom,
This patch does not apply cleanly to the 10.2 branch. I have resolved the
conflicts as below. Kindly let me know if I missed anything.
-Emil
commit f40a0750a4fcd2c7f233b962a5e74166e12456ad
Author: Tom Stellard thomas.stell...@amd.com
Date: Thu Aug 7 15:31:17 2014 -0400
radeon/compute: Report a value for PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE
CC: 10.2 mesa-sta...@lists.freedesktop.org
(cherry picked from commit 72969e0efb7a5a011629c1001e81aa2329ede6b1)
Conflicts:
src/gallium/drivers/r600/r600_pipe.c
src/gallium/drivers/radeonsi/si_pipe.c
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 0668b27..6ee4484 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -416,6 +416,17 @@ static int r600_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, e
return 1; /* Max native address registers */
case PIPE_SHADER_CAP_MAX_CONSTS:
return R600_MAX_CONST_BUFFER_SIZE;
+ case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE:
+ if (shader == PIPE_SHADER_COMPUTE) {
+ uint64_t max_const_buffer_size;
+ pscreen-get_compute_param(pscreen,
+ PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE,
+ max_const_buffer_size);
+ return max_const_buffer_size;
+
+ } else {
+ return R600_MAX_CONST_BUFFER_SIZE;
+ }
case PIPE_SHADER_CAP_MAX_CONST_BUFFERS:
return R600_MAX_USER_CONST_BUFFERS;
case PIPE_SHADER_CAP_MAX_PREDS:
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index ca8cea3..afb9bcb 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -317,6 +317,13 @@ static int si_get_shader_param(struct pipe_screen*
pscreen, unsigned shader, enu
switch (param) {
case PIPE_SHADER_CAP_PREFERRED_IR:
return PIPE_SHADER_IR_LLVM;
+ case PIPE_SHADER_CAP_MAX_CONST_BUFFER_SIZE: {
+ uint64_t max_const_buffer_size;
+ pscreen-get_compute_param(pscreen,
+ PIPE_COMPUTE_CAP_MAX_MEM_ALLOC_SIZE,
+ max_const_buffer_size);
+ return max_const_buffer_size;
+ }
default:
return 0;
}
___
mesa-dev mailing list
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
While I haven't heard about those projects, there's also GlassyMesa. Greg from LunarG (CC'd) posted about this to the mailing list. [1] However it looks like the github activity has stopped, and there's no new info on the projects website since its announcement. While it's not exactly the same as we're describing here, maybe he can share some on their experiences? Status of the project? Performance numbers? Packaging issues, ABI stability, etc? FWIW, I would prefer a world without LLVM, as long as there's not a big performance per man-hour benefit compared to rolling our own solution. LLVM brings extra complexity to debugging and bisecting, and if we want help from the users to bisect bugs it should be as easy as absolutely possible. [1] http://lists.freedesktop.org/archives/mesa-dev/2014-June/060951.html 2014-08-26 19:59 GMT+02:00 Matt Turner matts...@gmail.com: On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca jfons...@vmware.com wrote: If LLVM was a useless piece of junk, we wouldn't have any trouble adding it as a dependency, as we would be the sole user. But precisely because LLVM is successful in so many use cases, hence several packages depend on it, we shouldn't depend, so we can avoid the dealing with the oh-so-hard dependency issue!? I find it ridiculous: it's precisely because LLVM is potentially that good that it makes sense for us/distros/everybody to put up with the dependencies issues it may bring, and worth considering. It sounds like there are enough people in the Mesa community that are familiar with LLVM and interested in using it in the GLSL compiler that there would be someone willing to start working on it. Hopefully that's the case. I tried going through the LLVM language frontend tutorial on LLVM.org and only had to get to chapter 4 (the first two chapters don't use LLVM) before the code didn't compile (and I couldn't figure out why) with LLVM 3.4 on my system. I found this [1] tiny example (not updated for 2 years) using the C API and thought it'd probably not work either, but was happily surprised that it compiled and worked fine. I see that the C API is used in radeonsi and gallivm in Mesa. Here's what I think would be compelling: Using the stable C API, translate from GLSL IR into LLVM IR. Call LLVM's optimizations. Give backends the option to consume LLVM IR. From here we can evaluate just how significant the improvement from LLVM's optimizer is. At least two people have written GLSL IR - LLVM translators in the past -- Luca Barbieri (what ever happened to him?!) and Vincent Lejeune (Cc'd). Their code is [2] and [3]. I think this plan would also fit nicely with existing LLVM backends, potentially avoiding a trip through TGSI. I think this is strictly superior to other ideas like throwing out the GLSL frontend and translating LLVM IR back up to the higher level GLSL IR. So, maybe some people experienced with LLVM from VMware and AMD are interested in taking the lead? [1] https://github.com/wickedchicken/llvm-c-example [2] http://cgit.freedesktop.org/~anholt/mesa/log/?h=llvm-4 (Eric's branch based on Luca's code) [3] http://cgit.freedesktop.org/~vlj/mesa/ (one of the glsl-to-llvm* branches) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 6/7] radeonsi/compute: Stop leaking the input buffer
On 08/08/14 15:16, Tom Stellard wrote:
We were leaking the input buffer used for kernel arguments and since
we were allocating it using si_upload_const_buffer() we were leaking
1 MB per kernel invocation.
CC: 10.2 mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_compute.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index dff5ddd..01aa0c6 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -48,6 +48,7 @@ struct si_pipe_compute {
struct si_pipe_shader *kernels;
unsigned num_user_sgprs;
+ struct r600_resource *input_buffer;
struct pipe_resource *global_buffers[MAX_GLOBAL_BUFFERS];
LLVMContextRef llvm_ctx;
@@ -85,6 +86,9 @@ static void *si_create_compute_state(
LLVMDisposeModule(mod);
}
+ program-input_buffer = si_resource_create_custom(sctx-b.b.screen,
+ PIPE_USAGE_IMMUTABLE, program-input_size);
+
return program;
}
@@ -167,7 +171,7 @@ static void si_launch_grid(
struct si_context *sctx = (struct si_context*)ctx;
struct si_pipe_compute *program = sctx-cs_shader_state.program;
struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
- struct r600_resource *kernel_args_buffer = NULL;
+ struct r600_resource *input_buffer = program-input_buffer;
unsigned kernel_args_size;
unsigned num_work_size_bytes = 36;
uint32_t kernel_args_offset = 0;
@@ -199,7 +203,8 @@ static void si_launch_grid(
/* The extra num_work_size_bytes are for work group / work item size
information */
kernel_args_size = program-input_size + num_work_size_bytes + 8 /* For
scratch va */;
- kernel_args = MALLOC(kernel_args_size);
+ kernel_args = sctx-b.ws-buffer_map(input_buffer-cs_buf,
+ sctx-b.rings.gfx.cs, PIPE_TRANSFER_WRITE);
for (i = 0; i 3; i++) {
kernel_args[i] = grid_layout[i];
kernel_args[i + 3] = grid_layout[i] * block_layout[i];
@@ -236,13 +241,13 @@ static void si_launch_grid(
kernel_args[i]);
}
- si_upload_const_buffer(sctx, kernel_args_buffer, (uint8_t*)kernel_args,
- kernel_args_size, kernel_args_offset);
- kernel_args_va = r600_resource_va(ctx-screen,
- (struct pipe_resource*)kernel_args_buffer);
+ sctx-b.ws-buffer_unmap(input_buffer-cs_buf);
+
+ kernel_args_va = r600_resource_va(ctx-screen, input_buffer-b.b);
kernel_args_va += kernel_args_offset;
- si_pm4_add_bo(pm4, kernel_args_buffer, RADEON_USAGE_READ,
RADEON_PRIO_SHADER_DATA);
+ si_pm4_add_bo(pm4, input_buffer, RADEON_USAGE_READ,
+ RADEON_PRIO_SHADER_DATA);
si_pm4_set_reg(pm4, R_00B900_COMPUTE_USER_DATA_0, kernel_args_va);
si_pm4_set_reg(pm4, R_00B900_COMPUTE_USER_DATA_0 + 4,
S_008F04_BASE_ADDRESS_HI (kernel_args_va 32) | S_008F04_STRIDE(0));
@@ -374,7 +379,6 @@ static void si_launch_grid(
}
#endif
- FREE(kernel_args);
si_pm4_free_state(sctx, pm4, ~0);
}
@@ -398,6 +402,8 @@ static void si_delete_compute_state(struct pipe_context
*ctx, void* state){
if (program-llvm_ctx){
LLVMContextDispose(program-llvm_ctx);
}
+ pipe_resource_reference(
+ (struct pipe_resource **)program-input_buffer, NULL);
//And then free the program itself.
FREE(program);
Hello Tom,
This patch does not apply cleanly to the 10.2 branch. I have resolved the
conflicts as below. Kindly let me know if I missed anything.
-Emil
commit 70c7ebe5fe1f0f9a49e183857bb8f9d6497ddd7e
Author: Tom Stellard thomas.stell...@amd.com
Date: Fri Aug 8 09:27:34 2014 -0400
radeonsi/compute: Stop leaking the input buffer
We were leaking the input buffer used for kernel arguments and since
we were allocating it using si_upload_const_buffer() we were leaking
1 MB per kernel invocation.
CC: 10.2 mesa-sta...@lists.freedesktop.org
(cherry picked from commit a15088338ebe544efd90bfa7934cb99521488141)
Conflicts:
src/gallium/drivers/radeonsi/si_compute.c
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index b6aa044..d99b188 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -43,6 +43,7 @@ struct si_pipe_compute {
struct si_pipe_shader *kernels;
unsigned num_user_sgprs;
+ struct r600_resource *input_buffer;
struct pipe_resource *global_buffers[MAX_GLOBAL_BUFFERS];
LLVMContextRef llvm_ctx;
@@ -80,6 +81,9 @@ static void *si_create_compute_state(
LLVMDisposeModule(mod);
}
+ program-input_buffer =
[Mesa-dev] [PATCH] Suppress any libGL:... warnings when LIBGL_DEBUG == quiet
From: Stefan Dirsch sndir...@suse.de
Let's handle LIBGL_DEBUG env. variable in Mesa in a consistent way.
Fixes: https://bugzilla.novell.com/show_bug.cgi?id=892896
---
To: mesa-dev@lists.freedesktop.org
Cc: 10.3 mesa-sta...@lists.freedesktop.org
openSUSE maintainers: Why can't you forward your applied u_* patches to upstream
to get them included in final/next release?
---
src/mesa/drivers/dri/common/xmlconfig.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
b/src/mesa/drivers/dri/common/xmlconfig.c
index ce37647..8e48522 100644
--- a/src/mesa/drivers/dri/common/xmlconfig.c
+++ b/src/mesa/drivers/dri/common/xmlconfig.c
@@ -429,8 +429,10 @@ static void
__driUtilMessage(const char *f, ...)
{
va_list args;
+const char *libgl_debug;
-if (getenv(LIBGL_DEBUG)) {
+libgl_debug=getenv(LIBGL_DEBUG);
+if (libgl_debug !strstr(libgl_debug, quiet)) {
fprintf(stderr, libGL: );
va_start(args, f);
vfprintf(stderr, f, args);
--
2.0.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] radeonsi: save scissor state and sample mask for u_blitter
On 18/08/14 22:52, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
Hi Marek,
Going through the mesa 10.2 patches queue and I cannot see this one ever
making to the list despite the Cc tag. Are you sending the patches with
--suppress-cc by any chance ?
Thanks
Emil
Cc: mesa-sta...@lists.freedesktop.org
---
src/gallium/drivers/radeonsi/si_blit.c | 7 +++
src/gallium/drivers/radeonsi/si_state.c | 16 ++--
src/gallium/drivers/radeonsi/si_state.h | 14 --
3 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_blit.c
b/src/gallium/drivers/radeonsi/si_blit.c
index bc31dfd..9a7a2fe 100644
--- a/src/gallium/drivers/radeonsi/si_blit.c
+++ b/src/gallium/drivers/radeonsi/si_blit.c
@@ -59,9 +59,16 @@ static void si_blitter_begin(struct pipe_context *ctx,
enum si_blitter_op op)
util_blitter_save_geometry_shader(sctx-blitter, sctx-gs_shader);
util_blitter_save_vertex_shader(sctx-blitter, sctx-vs_shader);
util_blitter_save_vertex_elements(sctx-blitter, sctx-vertex_elements);
+ if (sctx-queued.named.sample_mask) {
+ util_blitter_save_sample_mask(sctx-blitter,
+
sctx-queued.named.sample_mask-sample_mask);
+ }
if (sctx-queued.named.viewport) {
util_blitter_save_viewport(sctx-blitter,
sctx-queued.named.viewport-viewport);
}
+ if (sctx-queued.named.scissor) {
+ util_blitter_save_scissor(sctx-blitter,
sctx-queued.named.scissor-scissor);
+ }
util_blitter_save_vertex_buffer_slot(sctx-blitter,
sctx-vertex_buffer);
util_blitter_save_so_targets(sctx-blitter,
sctx-b.streamout.num_targets,
(struct
pipe_stream_output_target**)sctx-b.streamout.targets);
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 98c19d6..fc928f3 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -458,18 +458,20 @@ static void si_set_scissor_states(struct pipe_context
*ctx,
const struct pipe_scissor_state *state)
{
struct si_context *sctx = (struct si_context *)ctx;
- struct si_pm4_state *pm4 = si_pm4_alloc_state(sctx);
+ struct si_state_scissor *scissor = CALLOC_STRUCT(si_state_scissor);
+ struct si_pm4_state *pm4 = scissor-pm4;
- if (pm4 == NULL)
+ if (scissor == NULL)
return;
+ scissor-scissor = *state;
si_pm4_set_reg(pm4, R_028250_PA_SC_VPORT_SCISSOR_0_TL,
S_028250_TL_X(state-minx) | S_028250_TL_Y(state-miny) |
S_028250_WINDOW_OFFSET_DISABLE(1));
si_pm4_set_reg(pm4, R_028254_PA_SC_VPORT_SCISSOR_0_BR,
S_028254_BR_X(state-maxx) | S_028254_BR_Y(state-maxy));
- si_pm4_set_state(sctx, scissor, pm4);
+ si_pm4_set_state(sctx, scissor, scissor);
}
static void si_set_viewport_states(struct pipe_context *ctx,
@@ -2774,16 +2776,18 @@ static void si_bind_sampler_states(struct
pipe_context *ctx, unsigned shader,
static void si_set_sample_mask(struct pipe_context *ctx, unsigned
sample_mask)
{
struct si_context *sctx = (struct si_context *)ctx;
- struct si_pm4_state *pm4 = si_pm4_alloc_state(sctx);
+ struct si_state_sample_mask *state =
CALLOC_STRUCT(si_state_sample_mask);
+ struct si_pm4_state *pm4 = state-pm4;
uint16_t mask = sample_mask;
-if (pm4 == NULL)
+if (state == NULL)
return;
+ state-sample_mask = mask;
si_pm4_set_reg(pm4, R_028C38_PA_SC_AA_MASK_X0Y0_X1Y0, mask | (mask
16));
si_pm4_set_reg(pm4, R_028C3C_PA_SC_AA_MASK_X0Y1_X1Y1, mask | (mask
16));
- si_pm4_set_state(sctx, sample_mask, pm4);
+ si_pm4_set_state(sctx, sample_mask, state);
}
static void si_delete_sampler_state(struct pipe_context *ctx, void *state)
diff --git a/src/gallium/drivers/radeonsi/si_state.h
b/src/gallium/drivers/radeonsi/si_state.h
index 82bea79..ce18a27 100644
--- a/src/gallium/drivers/radeonsi/si_state.h
+++ b/src/gallium/drivers/radeonsi/si_state.h
@@ -38,6 +38,16 @@ struct si_state_blend {
boolalpha_to_one;
};
+struct si_state_sample_mask {
+ struct si_pm4_state pm4;
+ uint16_tsample_mask;
+};
+
+struct si_state_scissor {
+ struct si_pm4_state pm4;
+ struct pipe_scissor_state scissor;
+};
+
struct si_state_viewport {
struct si_pm4_state pm4;
struct pipe_viewport_state viewport;
@@ -82,8 +92,8 @@ union si_state {
struct si_state_blend *blend;
struct si_pm4_state *blend_color;
struct si_pm4_state *clip;
- struct si_pm4_state
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Tue, Aug 26, 2014 at 4:34 PM, Thomas Helland thomashellan...@gmail.com wrote: While I haven't heard about those projects, there's also GlassyMesa. Greg from LunarG (CC'd) posted about this to the mailing list. [1] However it looks like the github activity has stopped, and there's no new info on the projects website since its announcement. While it's not exactly the same as we're describing here, maybe he can share some on their experiences? Status of the project? Performance numbers? Packaging issues, ABI stability, etc? FWIW, I would prefer a world without LLVM, as long as there's not a big performance per man-hour benefit compared to rolling our own solution. LLVM brings extra complexity to debugging and bisecting, and if we want help from the users to bisect bugs it should be as easy as absolutely possible. Before this discussion I think Matt, Ken, and Ian (the main compiler people still at Intel) had the same view which is why I started on NIR, but we'll see if someone can make an LLVM-based prototype that can change their minds. I guess I would be convinced if someone could make a backend for TGSI or i965 fs that won't be too hard to optimize in order to not produce extra MOV's, since I still think handling IR's like those with swizzles and writemasks is going to be painful with LLVM. Personally, I think the work to get something working with LLVM won't be much more than the work needed to get NIR to do what we need, since the optimizations we do need that LLVM would provide are either straightforward or well-described by a paper that we can pretty much follow directly, but we'll see - I'm not as sure about that. [1] http://lists.freedesktop.org/archives/mesa-dev/2014-June/060951.html 2014-08-26 19:59 GMT+02:00 Matt Turner matts...@gmail.com: On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca jfons...@vmware.com wrote: If LLVM was a useless piece of junk, we wouldn't have any trouble adding it as a dependency, as we would be the sole user. But precisely because LLVM is successful in so many use cases, hence several packages depend on it, we shouldn't depend, so we can avoid the dealing with the oh-so-hard dependency issue!? I find it ridiculous: it's precisely because LLVM is potentially that good that it makes sense for us/distros/everybody to put up with the dependencies issues it may bring, and worth considering. It sounds like there are enough people in the Mesa community that are familiar with LLVM and interested in using it in the GLSL compiler that there would be someone willing to start working on it. Hopefully that's the case. I tried going through the LLVM language frontend tutorial on LLVM.org and only had to get to chapter 4 (the first two chapters don't use LLVM) before the code didn't compile (and I couldn't figure out why) with LLVM 3.4 on my system. I found this [1] tiny example (not updated for 2 years) using the C API and thought it'd probably not work either, but was happily surprised that it compiled and worked fine. I see that the C API is used in radeonsi and gallivm in Mesa. Here's what I think would be compelling: Using the stable C API, translate from GLSL IR into LLVM IR. Call LLVM's optimizations. Give backends the option to consume LLVM IR. From here we can evaluate just how significant the improvement from LLVM's optimizer is. At least two people have written GLSL IR - LLVM translators in the past -- Luca Barbieri (what ever happened to him?!) and Vincent Lejeune (Cc'd). Their code is [2] and [3]. I think this plan would also fit nicely with existing LLVM backends, potentially avoiding a trip through TGSI. I think this is strictly superior to other ideas like throwing out the GLSL frontend and translating LLVM IR back up to the higher level GLSL IR. So, maybe some people experienced with LLVM from VMware and AMD are interested in taking the lead? [1] https://github.com/wickedchicken/llvm-c-example [2] http://cgit.freedesktop.org/~anholt/mesa/log/?h=llvm-4 (Eric's branch based on Luca's code) [3] http://cgit.freedesktop.org/~vlj/mesa/ (one of the glsl-to-llvm* branches) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa: Generate pname-based errors from glGetTexLevelParameter first
On 17/06/14 14:41, Brian Paul wrote:
On 06/16/2014 07:34 PM, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Previously, calling
glGenTextures(1, t);
glBindTexture(GL_TEXTURE_2D, t);
glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, 0xDEADBEEF, value);
would not generate an error.
Hi Ian,
This patch has been nominated for stable for a couple of months but is jet to
land in master. Has it been super-seeded by another patch or is there anything
else stopping it from going forward ?
Thanks
Emil
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/texparam.c | 63
+++-
1 file changed, 52 insertions(+), 11 deletions(-)
diff --git a/src/mesa/main/texparam.c b/src/mesa/main/texparam.c
index dc17ea5..565c1d6 100644
--- a/src/mesa/main/texparam.c
+++ b/src/mesa/main/texparam.c
@@ -1053,6 +1053,58 @@ get_tex_level_parameter_image(struct gl_context *ctx,
const struct gl_texture_image *img = NULL;
mesa_format texFormat;
+ /* Generate pname errors now. OpenGL 4.0 requires special behavior if
the
+* image is undefined, but that does not supersede pname-based errors.
+*/
+ switch (pname) {
+ case GL_TEXTURE_WIDTH:
+ case GL_TEXTURE_HEIGHT:
+ case GL_TEXTURE_DEPTH:
+ case GL_TEXTURE_INTERNAL_FORMAT:
+ case GL_TEXTURE_BORDER:
+ case GL_TEXTURE_RED_SIZE:
+ case GL_TEXTURE_GREEN_SIZE:
+ case GL_TEXTURE_BLUE_SIZE:
+ case GL_TEXTURE_ALPHA_SIZE:
+ case GL_TEXTURE_INTENSITY_SIZE:
+ case GL_TEXTURE_LUMINANCE_SIZE:
+ break;
+ case GL_TEXTURE_DEPTH_SIZE_ARB:
+ if (!ctx-Extensions.ARB_depth_texture)
+ goto invalid_pname;
+ break;
+ case GL_TEXTURE_STENCIL_SIZE:
+ break;
+ case GL_TEXTURE_SHARED_SIZE:
+ if (ctx-Version 30
+ !ctx-Extensions.EXT_texture_shared_exponent)
+ goto invalid_pname;
+ break;
+ case GL_TEXTURE_COMPRESSED_IMAGE_SIZE:
+ case GL_TEXTURE_COMPRESSED:
+ break;
+ case GL_TEXTURE_RED_TYPE_ARB:
+ case GL_TEXTURE_GREEN_TYPE_ARB:
+ case GL_TEXTURE_BLUE_TYPE_ARB:
+ case GL_TEXTURE_ALPHA_TYPE_ARB:
+ case GL_TEXTURE_LUMINANCE_TYPE_ARB:
+ case GL_TEXTURE_INTENSITY_TYPE_ARB:
+ case GL_TEXTURE_DEPTH_TYPE_ARB:
+ if (!ctx-Extensions.ARB_texture_float)
+ goto invalid_pname;
+ break;
+ case GL_TEXTURE_SAMPLES:
+ if (!ctx-Extensions.ARB_texture_multisample)
+ goto invalid_pname;
+ break;
+ case GL_TEXTURE_FIXED_SAMPLE_LOCATIONS:
+ if (!ctx-Extensions.ARB_texture_multisample)
+ goto invalid_pname;
+ break;
+ default:
+ goto invalid_pname;
+ }
+
img = _mesa_select_tex_image(ctx, texObj, target, level);
if (!img || img-TexFormat == MESA_FORMAT_NONE) {
/* In case of undefined texture image return the default values.
@@ -1135,17 +1187,12 @@ get_tex_level_parameter_image(struct gl_context *ctx,
}
break;
case GL_TEXTURE_DEPTH_SIZE_ARB:
- if (!ctx-Extensions.ARB_depth_texture)
-goto invalid_pname;
*params = _mesa_get_format_bits(texFormat, pname);
break;
case GL_TEXTURE_STENCIL_SIZE:
*params = _mesa_get_format_bits(texFormat, pname);
break;
case GL_TEXTURE_SHARED_SIZE:
- if (ctx-Version 30
- !ctx-Extensions.EXT_texture_shared_exponent)
-goto invalid_pname;
*params = texFormat == MESA_FORMAT_R9G9B9E5_FLOAT ? 5 : 0;
break;
@@ -1173,8 +1220,6 @@ get_tex_level_parameter_image(struct gl_context *ctx,
case GL_TEXTURE_LUMINANCE_TYPE_ARB:
case GL_TEXTURE_INTENSITY_TYPE_ARB:
case GL_TEXTURE_DEPTH_TYPE_ARB:
- if (!ctx-Extensions.ARB_texture_float)
-goto invalid_pname;
if (_mesa_base_format_has_channel(img-_BaseFormat, pname))
*params = _mesa_get_format_datatype(texFormat);
else
@@ -1183,14 +1228,10 @@ get_tex_level_parameter_image(struct gl_context *ctx,
/* GL_ARB_texture_multisample */
case GL_TEXTURE_SAMPLES:
- if (!ctx-Extensions.ARB_texture_multisample)
-goto invalid_pname;
*params = img-NumSamples;
break;
case GL_TEXTURE_FIXED_SAMPLE_LOCATIONS:
- if (!ctx-Extensions.ARB_texture_multisample)
-goto invalid_pname;
*params = img-FixedSampleLocations;
break;
I think another way of handling this might be to define/use a dummy
gl_texture_image to use when img would have been null. The dummy
gl_texture_image would be initialized with suitable defaults for all the
query-able fields (but mostly zeros).
That would save us the extra switch and might be less work if new queries are
added in the future.
-Brian
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Tue, Aug 26, 2014 at 12:00 PM, Jose Fonseca jfons...@vmware.com wrote: On 26/08/14 10:04, Christian König wrote: Am 26.08.2014 um 03:54 schrieb Rob Clark: On Wed, Aug 20, 2014 at 2:13 PM, Kenneth Graunke kenn...@whitecape.org wrote: we've already had problems where distros refused to ship newer Mesa releases because radeon depended on a version of LLVM newer than the one they were shipping, [...] That's news to me, can you be more specific? That sounds like basically a distro issue though, since different LLVM versions can be installed in parallel (and the one used by default doesn't have to be the newest one). And it even works if another part of the same process uses a different version of LLVM. Yes, one can argue that it's a distribution issue - but it's an extremely painful problem for distributions. For example, Debian was stuck on Mesa 9.2.2 for 4 months (2013-12-08 to 2014-03-22), and I was told this was because of LLVM versioning changes in the other drivers (primarily radeon, I believe, but probably also llvmpipe). Mesa 9.2.2 hung the GPU every 5-10 minutes on Sandybridge, and we fixed that in Mesa 9.2.3. But we couldn't get people to actually ship it, and had to field tons of bug reports from upset users for several months. Gentoo has also had trouble updating for similar reasons; Matt (the Gentoo Mesa package mantainer) can probably comment more. I've also heard stories from friends of mine who use radeonsi that they couldn't get new GL features or compiler fixes unless they upgrade both Mesa /and/ LLVM, and that LLVM was usually either not released or not available in their distribution for a few months. Those are the sorts of things I'd like to avoid. The compiler is easily the most crucial part of a modern graphics stack; splitting it out into a separate repository and project seems like a nightmare for people who care about getting new drivers released and shipped in distributions in a timely fashion. Or, looking at it the other way: today, everything you need as an Intel or (AFAIK) Nouveau 3D user is nicely contained within Mesa. Our community has complete control over when we do those releases. New important bug fixes, performance improvements, or features? Ship a new Mesa, and you're done. That's a really nice feature I'd hate to lose. tbh, it sounds a lot to me like if we start using LLVM more heavily/widely in mesa we should import LLVM (or at least the parts we need) into the mesa src tree.. as it is, the logistical/distro issues of LLVM have been what has scared me off the most about using it. Yes, agree totally. But I think we would always have that problem if we want to use a compiler infrastructure outside of mesa. Not sure in what way would having LLVM in mesa's source tree be an improvement upon building and linking LLVM from an external repository. Just so we fool packagers into believing it is a single project? It's cumbersome and won't change anything. For example, Apitrace bundles several thirdparty libraries, so it statically links them into the wrappers shared objects to prevent symbol collision when tracing proprietary applications which sometimes also bundle their own dependencies. Yet I note most distros patch apitrace source tree to use the system's libraries instead of the bundled tree. I'm pretty sure they would do precisely the same with Mesa if LLVM was imported into Mesa tree. actually we already do the opposite thing in fedora.. you are right, normally distro's prefer to unbundle things.. LLVM is kinda special (which really should be a warning sign right there) BR, -R Basically I see only two options: a) We do everything inside Mesa and so also need to maintain and develop it further by ourself. b) We use a compiler infrastructure outside of Mesa with the well known problems and advantages. Also what closed source drivers usually do is pulling a certain LLVM version into their code and so build the compiler infrastructure directly into their binaries. This obviously isn't such a good idea for distributions who seems to be concerned about the size of the resulting binaries, but completely avoids the version clash. I think it is unreasonable for distros to expect to have both ways: either they package multiple versions of LLVM (or at least one suited to Mesa), or they accept upgrading LLVM whenever they upgrade Mesa. They can't expect us to not depend on LLVM just to make packaging easier... And I must say: basing the decision to use LLVM or any other compilation framework based on how easy it is to package is having priorities _completely_ backwards. If LLVM was a useless piece of junk, we wouldn't have any trouble adding it as a dependency, as we would be the sole user. But precisely because LLVM is successful in so many use cases, hence several packages depend on it, we shouldn't depend, so we can avoid the dealing with the oh-so-hard
Re: [Mesa-dev] [Mesa-stable] [PATCH] mesa: Don't use derived vertex state in api_arrayelt.c
On 04/07/14 01:57, Carl Worth wrote: Fredrik Höglund fred...@kde.org writes: Cc: 10.1 mesa-sta...@lists.freedesktop.org (And 10.2 as pushed to master) Hi Fredrik, Hi Fredrik, Can you please provide more information about the commit to justify it landing in the 10.2 stable branch ? AFAICS the original reporter states that it fixes the issue, yet my knowledge in the area is a bit lacking. Thanks Emil I helped prod you into pushing this patch to master, which brought it more directly into my view as a candidate for the 10.2 branch. Now that I'm taking a closer look at the patch, I think it's missing something in its current form to be a candidate for the stable branch. Specifically, the commit message is a single-line, (Don't use derived vertex state...), but without any explanation of what kind of bug this is fixing, what the severity might be, etc. And the patch is long enough that it's not trivial to just look at it and have some confidence that there's just the bug fix here, (whatever that bug fix might be). [The patch could be shorter without some renaming going on here.] Could you prepare another version of this patch with a bit more content in the commit message? Your email here does have some hints: It's possible that this patch fixes a segfault in FlightGear (see bug 73504), so I think it's a candidate for the 10.1 branch, but maybe not for 10.1.0. If there's a segfault-fix here, I'd like to see that described in the commit message. (Like I said, I didn't find the segault fix in my attempt to read the patch.) And if there's a fix for a bug in bugzilla, then that should be in the commit message as well. I do recognize that you qualified things with it's possible and that may be why this text was not in the commit message itself. I'd like to see a little more certainty about bug fixes before pulling them over to the stable branch. Thanks, -Carl ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
= actually we already do the opposite thing in fedora.. you are right, normally distro's prefer to unbundle things.. LLVM is kinda special (which really should be a warning sign right there) In Fedora we unbundle llvm, in RHEL we create a special package of llvm for mesa to use, but that isn't due to llvm being annoying as much as it is due to support contracts and not wanting to ship llvm/clang to customers for their use. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 16/17] i965/fs: Refactor try_emit_saturate
On Tuesday, August 19, 2014 07:37:33 PM Matt Turner wrote:
On Mon, Aug 18, 2014 at 5:17 AM, Abdiel Janulgue
abdiel.janul...@linux.intel.com wrote:
+ /* If the last instruction from our accept() generated our
+* src, just set the saturate flag instead of emmitting a separate mov.
emitting.
*/
fs_inst *modify = get_instruction_generating_reg(pre_inst, last_inst,
src);
- if (!modify || modify-regs_written != 1) {
- this-result = fs_reg(this, ir-type);
- fs_inst *inst = emit(MOV(this-result, src));
- inst-saturate = true;
- } else {
+ if (modify modify-regs_written == 1) {
modify-saturate = true;
this-result = src;
+ return true;
}
I was going to tell you that you need to call
backend_instruction::can_do_saturate() here, but ir_unop_saturate only
operates on floats, and all i965 instructions that operate on floats
can saturate.
Messages can't, IIRC. It probably is a good idea to call it anyway.
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/13] glsl_to_tgsi: Constify mesa_sysval_to_semantic
On 21/06/14 02:00, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Hello Ian,
Looking at this series and it appears that only patches 1-4 (inclusive) made
it in master. Has the rest of it been super-seeded by other patches or did it
slip through the cracks ?
Imho most (all?) of the series does not appear like it is suitable for stable.
Feel free to let me know if you feel otherwise.
-Emil
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Ilia Mirkin imir...@alum.mit.edu
Cc: Marek Olšák marek.ol...@amd.com
Cc: Roland Scheidegger srol...@vmware.com
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index cac1e0f..109291d 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4235,7 +4235,7 @@ struct st_translate {
};
/** Map Mesa's SYSTEM_VALUE_x to TGSI_SEMANTIC_x */
-static unsigned mesa_sysval_to_semantic[SYSTEM_VALUE_MAX] = {
+static const unsigned mesa_sysval_to_semantic[SYSTEM_VALUE_MAX] = {
TGSI_SEMANTIC_FACE,
TGSI_SEMANTIC_VERTEXID,
TGSI_SEMANTIC_INSTANCEID,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/13] glsl_to_tgsi: Constify mesa_sysval_to_semantic
On 08/26/2014 02:56 PM, Emil Velikov wrote:
On 21/06/14 02:00, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
Hello Ian,
Looking at this series and it appears that only patches 1-4 (inclusive) made
it in master. Has the rest of it been super-seeded by other patches or did it
slip through the cracks ?
Imho most (all?) of the series does not appear like it is suitable for stable.
Feel free to let me know if you feel otherwise.
We're working out some kinks with the final approach. Once it's ready
(hopefully this week), I'll send a pull request from a branch. Right
now gl_VertexID is quite severly broken in some cases, so it will be
very important for this to at least land in 10.3.
Too much travel (and being out sick) over the last month has
significantly delayed this. :(
-Emil
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: Ilia Mirkin imir...@alum.mit.edu
Cc: Marek Olšák marek.ol...@amd.com
Cc: Roland Scheidegger srol...@vmware.com
Cc: 10.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
index cac1e0f..109291d 100644
--- a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
+++ b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp
@@ -4235,7 +4235,7 @@ struct st_translate {
};
/** Map Mesa's SYSTEM_VALUE_x to TGSI_SEMANTIC_x */
-static unsigned mesa_sysval_to_semantic[SYSTEM_VALUE_MAX] = {
+static const unsigned mesa_sysval_to_semantic[SYSTEM_VALUE_MAX] = {
TGSI_SEMANTIC_FACE,
TGSI_SEMANTIC_VERTEXID,
TGSI_SEMANTIC_INSTANCEID,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-announce] Mesa 10.3 release candidate 1
On 25/08/14 07:51, Thierry Vignaud wrote: On 21 August 2014 17:54, Carl Worth cwo...@cworth.org wrote: I have verified building from the .tar.bz2 file by doing the following on a Debian (unstable) system: tar xjf MesaLib-10.3.0-rc1.tar.bz2 cd Mesa-10.3.0-rc1 ./configure --enable-gallium-llvm make -j6 make install Unlike previous releases, it builds smoothly with -j4 but fails with -j24: gmake[4]: Leaving directory '/home/iurt/rpmbuild/BUILD/Mesa-10.3.0-rc1/build-osmesa/src/mapi/glapi/gen' gmake[4]: Entering directory '/home/iurt/rpmbuild/BUILD/Mesa-10.3.0-rc1/build-osmesa/src/mapi/glapi/gen' GEN ../../../../src/glx/indirect_size.h gmake[4]: Leaving directory '/home/iurt/rpmbuild/BUILD/Mesa-10.3.0-rc1/build-osmesa/src/mapi/glapi/gen' gmake all-am gmake[5]: Nothing to be done for 'all-am'. Making all in . gmake[4]: Entering directory '/home/iurt/rpmbuild/BUILD/Mesa-10.3.0-rc1/build-osmesa/src/mapi' GEN .libs/install-mesa-links touch: cannot touch '.libs/install-mesa-links': No such file or directory Makefile:2109: recipe for target '.libs/install-mesa-links' failed gmake[4]: *** [.libs/install-mesa-links] Error 1 You've missing deps in make rules that show up when using quite a lot of cores Matt it seems like doing the right thing does not always pay-off :\ Can you take a look at this when you have the chance, pretty please ? -Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] SandyBridge not handling GL_TRIANGLE_STRIP_ADJACENCY with repeating vertex indices correctly
On Friday, August 22, 2014 12:59:57 PM Samuel Iglesias Gonsálvez wrote: On Thu, 2014-08-14 at 14:28 +0200, Iago Toral Quiroga wrote: [...] At this point I'd like to hear suggestions for things we could try next to confirm whether this is a hardware problem or a driver problem, or, if we agree that this is enough evidence that this must be a hardware problem, how we can limit its impact, starting, probably, by rewriting the piglit test so that we don't alter its purpose but avoid the hang on gen6. We should also discuss if there is a way to work around this problem so that at least developers running into it (as unlikely as that may be) don't hang their systems. I am going to be on holidays starting tomorrow and will have difficult and limited Internet access for the most part, but Samuel (in the CC) will be available next week to try any suggestions you may have. As Iago said, I'm available for trying any suggestions you may have. I'm wondering if you need more information about the issue or if I can run more tests in order to confirm/discard this is a HW problem and the next steps to follow. Best regards, Sam I just came across an interesting looking errata... From the Sandybridge PRM, Volume 2 Part 1, Section 5.5.1 Partial Object Removal: An object is considered ‘partial’ if the last vertex of the primitive topology is encountered (i.e., PrimEnd is set) before a complete set of vertices for that object have been received. Given that only LINESTRIP and TRISTRIP primitive types are subject to CLIP unit partial object removal, the only supported cases of partial objects are 1-vertex LINESTRIPs and 1 or 2-vertex TRISTRIPs. [errata DevSNB]: Possible hang if final output from GS kernel is 2 vertex triangle. If it is possible for the final output from GS kernel to be a 2 vertex triangle, then have the GS kernel always output an extra single vertex triangle as the final output. Do you think this could be related? It's a SNB specific hang closely tied to triangle strips, which sounds promising, but the symptoms don't sound quite right either... --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] docs: fix up status of softpipe, llvmpipe
On 26 August 2014 05:55, srol...@vmware.com wrote: From: Roland Scheidegger srol...@vmware.com The docs were never really up to date for them, missing just about everything. So mark them off as all done for GL 3.3 (though softpipe is in fact quite broken for some newer things especially wrt texturing, and both don't have compliant, real msaa support). And add the extensions missing too (no guarantee of completeness). LGTM, at some point I might try and fix softpipe a bit better, though cube mapping and derivs were never my forte. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-announce] Mesa 10.3 release candidate 1
On Tue, Aug 26, 2014 at 3:37 PM, Emil Velikov emil.l.veli...@gmail.com wrote: On 25/08/14 07:51, Thierry Vignaud wrote: On 21 August 2014 17:54, Carl Worth cwo...@cworth.org wrote: I have verified building from the .tar.bz2 file by doing the following on a Debian (unstable) system: tar xjf MesaLib-10.3.0-rc1.tar.bz2 cd Mesa-10.3.0-rc1 ./configure --enable-gallium-llvm make -j6 make install Unlike previous releases, it builds smoothly with -j4 but fails with -j24: gmake[4]: Leaving directory '/home/iurt/rpmbuild/BUILD/Mesa-10.3.0-rc1/build-osmesa/src/mapi/glapi/gen' gmake[4]: Entering directory '/home/iurt/rpmbuild/BUILD/Mesa-10.3.0-rc1/build-osmesa/src/mapi/glapi/gen' GEN ../../../../src/glx/indirect_size.h gmake[4]: Leaving directory '/home/iurt/rpmbuild/BUILD/Mesa-10.3.0-rc1/build-osmesa/src/mapi/glapi/gen' gmake all-am gmake[5]: Nothing to be done for 'all-am'. Making all in . gmake[4]: Entering directory '/home/iurt/rpmbuild/BUILD/Mesa-10.3.0-rc1/build-osmesa/src/mapi' GEN .libs/install-mesa-links touch: cannot touch '.libs/install-mesa-links': No such file or directory Makefile:2109: recipe for target '.libs/install-mesa-links' failed gmake[4]: *** [.libs/install-mesa-links] Error 1 You've missing deps in make rules that show up when using quite a lot of cores Matt it seems like doing the right thing does not always pay-off :\ Can you take a look at this when you have the chance, pretty please ? -Emil Perfect. I've needed a reason for my manager to get me a 24-core box for a while. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Disable guardband clipping in the smaller-than-viewport case.
Apparently guardband clipping doesn't work like we thought: objects
entirely outside fthe guardband are trivially rejected, regardless of
their relation to the viewport. Normally, the guardband is larger than
the viewport, so this is not a problem. However, when the viewport is
larger than the guardband, this means that we would discard primitives
which were wholly outside of the guardband, but still visible.
We always program the guardband to 8K x 8K to enforce the restriction
that the screenspace bounding box of a single triangle must be no more
than 8K x 8K. So, if the viewport is larger than that, we need to
disable guardband clipping.
Fixes ES3 conformance tests:
- framebuffer_blit_functionality_negative_height_blit
- framebuffer_blit_functionality_negative_width_blit
- framebuffer_blit_functionality_negative_dimensions_blit
- framebuffer_blit_functionality_magnifying_blit
- framebuffer_blit_functionality_multisampled_to_singlesampled_blit
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Topi Pohjolainen topi.pohjolai...@intel.com
Cc: Ian Romanick i...@freedesktop.org
---
src/mesa/drivers/dri/i965/gen6_clip_state.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen6_clip_state.c
b/src/mesa/drivers/dri/i965/gen6_clip_state.c
index e8c1b91..524219f 100644
--- a/src/mesa/drivers/dri/i965/gen6_clip_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_clip_state.c
@@ -98,6 +98,35 @@ upload_clip_state(struct brw_context *brw)
dw2 |= GEN6_CLIP_GB_TEST;
+ /* We need to disable guardband clipping if the guardband (which we always
+* program to the maximum screen-space bounding box of 8K x 8K) will be
+* smaller than the viewport.
+*
+* Closely examining the clip determination formulas in the documentation
+* reveals that objects will be discarded entirely if they're outside the
+* (small) guardband, even if they're within the (large) viewport:
+*
+* TR = TR_GB || TR_VPXY || TR_VPZ || TR_UC || TR_NEGW
+* TA = !TR TA_GB TA_VPZ TA_NEGW
+* MC = !(TA || TR)
+*
+* Disabling guardband clipping removes the TR_GB condition, which means
+* they'll be considered MC (Must Clip) unless they're rejected for
+* some other reason.
+*
+* Note that there is no TA_VPXY condition. If there were, objects entirely
+* inside a 16384x16384 viewport would be trivially accepted, breaking the
+* objects must have a screenspace bounding box not exceeding 8K in the X
+* or Y direction restriction. Instead, they're clipped.
+*/
+ for (unsigned i = 0; i ctx-Const.MaxViewports; i++) {
+ if (ctx-ViewportArray[i].Width 8192 ||
+ ctx-ViewportArray[i].Height 8192) {
+ dw2 = ~GEN6_CLIP_GB_TEST;
+ break;
+ }
+ }
+
/* If the viewport dimensions are smaller than the drawable dimensions,
* we have to disable guardband clipping prior to Gen8. We always program
* the guardband to a fixed size, which is almost always larger than the
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/gen8: Allow 16k viewport when blitting stencil
On Monday, August 25, 2014 04:38:53 PM Ian Romanick wrote: On 08/14/2014 09:09 AM, Topi Pohjolainen wrote: From: Topi Pohjolainen topi.pohjolai...@gmail.com Fixes gles3 conformance tests: framebuffer_blit_functionality_negative_height_blit framebuffer_blit_functionality_negative_width_blit framebuffer_blit_functionality_negative_dimensions_blit framebuffer_blit_functionality_magnifying_blit framebuffer_blit_functionality_multisampled_to_singlesampled_blit Signed-off-by: Topi Pohjolainen topi.pohjolai...@gmail.com --- src/mesa/drivers/dri/i965/gen8_viewport_state.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/mesa/drivers/dri/i965/gen8_viewport_state.c b/src/mesa/drivers/dri/i965/gen8_viewport_state.c index 9c89532..eda9aad 100644 --- a/src/mesa/drivers/dri/i965/gen8_viewport_state.c +++ b/src/mesa/drivers/dri/i965/gen8_viewport_state.c @@ -94,6 +94,13 @@ gen8_upload_sf_clip_viewport(struct brw_context *brw) float gbx = maximum_guardband_extent / ctx-ViewportArray[i].Width; float gby = maximum_guardband_extent / ctx-ViewportArray[i].Height; + /** + * Stencil blits require W-tiled to be treated as Y-tiled needing in + * turn width to be programmed twice the original. + */ + if (brw-meta_in_progress) + gbx *= 2; + I've had this on my various trees for almost two weeks now, and it doesn't seem to have caused any problems. I'm wondering if we want to make this check a bit more specific to the stencil blit case. Either way, I'd like to see this or something similar land soon. NAK. While it does appear to fix the problem, this seems much too broad to me - there are plenty of meta operations that don't even touch W-tiled buffers. This also expands the guardband to be 16K x 8K, which (as I understand it), would result in TA_GB for a primitive with a screenspace bounding box wider than 8K pixels. This could mean such primitives get trivially accepted, which violates the rule in the vertex X,Y quantization section that all primitives must have width/height = 8K, which explicitly states that software must guarantee that via clipping. I have an alternate patch which should fix the problem a bit differently, and likely some other issues we'll hit if/when we bump the maximum texture size to 16K: http://mid.gmane.org/1409096395-19654-1-git-send-email-kenn...@whitecape.org --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Tuesday, August 26, 2014 10:05:35 AM Ian Romanick wrote: On 08/25/2014 06:54 PM, Rob Clark wrote: tbh, it sounds a lot to me like if we start using LLVM more heavily/widely in mesa we should import LLVM (or at least the parts we need) into the mesa src tree.. as it is, the logistical/distro issues of LLVM have been what has scared me off the most about using it. While this is the development model that LLVM expects (and the only one they support)... Dear god, no! This would mean that we would have to take the responsibility for keeping our diverged copy of LLVM in sync with bug fixes, etc. from upstream. For a project the size of LLVM, I can expect that to be a significant amount of work. I agree - I'm totally against importing LLVM into the Mesa repositories. Thankfully, it does look like the C API is pretty stable, so if you're able to use that, you don't have to worry about LLVM changing as much. It looks to me like we might need to extend it somewhat - I'm not sure all the optimization passes can be activated via C, but I imagine those extensions would be very straightforward. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
The GlassyMesa effort is ongoing despite the lack of recent activity. We continue to embrace LLVM as a basis for shader compilation in Mesa and elsewhere. We agree that translating from LLVM back up to GLSL IR is problematic and that an architecture that supports LLVM backends would be desirable. The current published code is a work-in-progress. We are currently working on tuning of compilation time and code generation quality, and some of that work will likely be appearing soon. There have also been recent improvements in glslang, the parser for this stack. Packaging and ABI stability have not been an issue for us. Best regards, Greg On Tue, Aug 26, 2014 at 2:34 PM, Thomas Helland thomashellan...@gmail.com wrote: While I haven't heard about those projects, there's also GlassyMesa. Greg from LunarG (CC'd) posted about this to the mailing list. [1] However it looks like the github activity has stopped, and there's no new info on the projects website since its announcement. While it's not exactly the same as we're describing here, maybe he can share some on their experiences? Status of the project? Performance numbers? Packaging issues, ABI stability, etc? FWIW, I would prefer a world without LLVM, as long as there's not a big performance per man-hour benefit compared to rolling our own solution. LLVM brings extra complexity to debugging and bisecting, and if we want help from the users to bisect bugs it should be as easy as absolutely possible. [1] http://lists.freedesktop.org/archives/mesa-dev/2014-June/060951.html 2014-08-26 19:59 GMT+02:00 Matt Turner matts...@gmail.com: On Tue, Aug 26, 2014 at 9:00 AM, Jose Fonseca jfons...@vmware.com wrote: If LLVM was a useless piece of junk, we wouldn't have any trouble adding it as a dependency, as we would be the sole user. But precisely because LLVM is successful in so many use cases, hence several packages depend on it, we shouldn't depend, so we can avoid the dealing with the oh-so-hard dependency issue!? I find it ridiculous: it's precisely because LLVM is potentially that good that it makes sense for us/distros/everybody to put up with the dependencies issues it may bring, and worth considering. It sounds like there are enough people in the Mesa community that are familiar with LLVM and interested in using it in the GLSL compiler that there would be someone willing to start working on it. Hopefully that's the case. I tried going through the LLVM language frontend tutorial on LLVM.org and only had to get to chapter 4 (the first two chapters don't use LLVM) before the code didn't compile (and I couldn't figure out why) with LLVM 3.4 on my system. I found this [1] tiny example (not updated for 2 years) using the C API and thought it'd probably not work either, but was happily surprised that it compiled and worked fine. I see that the C API is used in radeonsi and gallivm in Mesa. Here's what I think would be compelling: Using the stable C API, translate from GLSL IR into LLVM IR. Call LLVM's optimizations. Give backends the option to consume LLVM IR. From here we can evaluate just how significant the improvement from LLVM's optimizer is. At least two people have written GLSL IR - LLVM translators in the past -- Luca Barbieri (what ever happened to him?!) and Vincent Lejeune (Cc'd). Their code is [2] and [3]. I think this plan would also fit nicely with existing LLVM backends, potentially avoiding a trip through TGSI. I think this is strictly superior to other ideas like throwing out the GLSL frontend and translating LLVM IR back up to the higher level GLSL IR. So, maybe some people experienced with LLVM from VMware and AMD are interested in taking the lead? [1] https://github.com/wickedchicken/llvm-c-example [2] http://cgit.freedesktop.org/~anholt/mesa/log/?h=llvm-4 (Eric's branch based on Luca's code) [3] http://cgit.freedesktop.org/~vlj/mesa/ (one of the glsl-to-llvm* branches) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
On Tuesday, August 26, 2014 06:45:42 PM Greg Fischer wrote: The GlassyMesa effort is ongoing despite the lack of recent activity. We continue to embrace LLVM as a basis for shader compilation in Mesa and elsewhere. We agree that translating from LLVM back up to GLSL IR is problematic and that an architecture that supports LLVM backends would be desirable. The current published code is a work-in-progress. We are currently working on tuning of compilation time and code generation quality, and some of that work will likely be appearing soon. There have also been recent improvements in glslang, the parser for this stack. Packaging and ABI stability have not been an issue for us. As far as I know, you haven't actually shipped your software in any Linux distribution yet, so a lack of packaging problems sort of goes without saying... --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/6] radeonsi: save scissor state and sample mask for u_blitter
On 27.08.2014 05:57, Emil Velikov wrote: On 18/08/14 22:52, Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com Hi Marek, Going through the mesa 10.2 patches queue and I cannot see this one ever making to the list despite the Cc tag. Are you sending the patches with --suppress-cc by any chance ? IMO it doesn't make much sense to send patches to the mesa-stable list before they hit master, which is one reason why I indeed suppress the Cc: for git send-email. There's a bin/get-pick-list.sh script, if you run that on the 10.2 branch, it includes this patch. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] radeon/uvd: remove comment about RV770
It doesn't seem to support field based decode after testing. Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- src/gallium/drivers/radeon/radeon_video.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/gallium/drivers/radeon/radeon_video.c b/src/gallium/drivers/radeon/radeon_video.c index 6dcee45..2e683c4 100644 --- a/src/gallium/drivers/radeon/radeon_video.c +++ b/src/gallium/drivers/radeon/radeon_video.c @@ -254,7 +254,6 @@ int rvid_get_video_param(struct pipe_screen *screen, /* MPEG2 only with shaders and no support for interlacing on R6xx style UVD */ return codec != PIPE_VIDEO_FORMAT_MPEG12 - /* TODO: RV770 might actually work */ rscreen-family CHIP_RV770; default: break; -- 1.8.3.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeon/uvd: fix field handling on R6XX style UVD
On Sun, Aug 24, 2014 at 8:32 AM, Christian König deathsim...@vodafone.de wrote: From: Christian König christian.koe...@amd.com The first UVD generation can only do frame based output. Signed-off-by: Christian König christian.koe...@amd.com Can someone pick this up for stable? --- src/gallium/drivers/radeon/radeon_video.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/gallium/drivers/radeon/radeon_video.c b/src/gallium/drivers/radeon/radeon_video.c index 17e9a59..6dcee45 100644 --- a/src/gallium/drivers/radeon/radeon_video.c +++ b/src/gallium/drivers/radeon/radeon_video.c @@ -251,8 +251,11 @@ int rvid_get_video_param(struct pipe_screen *screen, profile != PIPE_VIDEO_PROFILE_VC1_MAIN; case PIPE_VIDEO_CAP_PREFERS_INTERLACED: case PIPE_VIDEO_CAP_SUPPORTS_INTERLACED: - /* and MPEG2 only with shaders */ - return codec != PIPE_VIDEO_FORMAT_MPEG12; + /* MPEG2 only with shaders and no support for + interlacing on R6xx style UVD */ + return codec != PIPE_VIDEO_FORMAT_MPEG12 + /* TODO: RV770 might actually work */ + rscreen-family CHIP_RV770; default: break; } -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH libclc] Fix build against LLVM SVN = r216393
On 26.08.2014 23:57, Aaron Watry wrote: Wrong list(s)? I don't see libclc-dev on the cc list. That's because I didn't know about that list before. :) Submitted there now, thanks. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/16] A new IR for Mesa
My apologies for a too-brief response to this question. GlassyMesa links LLVM statically into Mesa. I believe that previous posters to this thread have already done a pretty good job of arguing that this is at least a workable approach. Best regards, Greg On Tue, Aug 26, 2014 at 7:14 PM, Kenneth Graunke kenn...@whitecape.org wrote: On Tuesday, August 26, 2014 06:45:42 PM Greg Fischer wrote: The GlassyMesa effort is ongoing despite the lack of recent activity. We continue to embrace LLVM as a basis for shader compilation in Mesa and elsewhere. We agree that translating from LLVM back up to GLSL IR is problematic and that an architecture that supports LLVM backends would be desirable. The current published code is a work-in-progress. We are currently working on tuning of compilation time and code generation quality, and some of that work will likely be appearing soon. There have also been recent improvements in glslang, the parser for this stack. Packaging and ABI stability have not been an issue for us. As far as I know, you haven't actually shipped your software in any Linux distribution yet, so a lack of packaging problems sort of goes without saying... --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
