[Mesa-dev] [Bug 73096] New: Query GL_RGBA_SIGNED_COMPONENTS_EXT missing
https://bugs.freedesktop.org/show_bug.cgi?id=73096 Priority: medium Bug ID: 73096 Assignee: mesa-dev@lists.freedesktop.org Summary: Query GL_RGBA_SIGNED_COMPONENTS_EXT missing Severity: normal Classification: Unclassified OS: All Reporter: bme...@gmail.com Hardware: All Status: NEW Version: unspecified Component: Mesa core Product: Mesa Created attachment 91251 --> https://bugs.freedesktop.org/attachment.cgi?id=91251&action=edit Patch to add a regression test to piglit The EXT_packed_float extension defines a glGet* query GL_RGBA_SIGNED_COMPONENTS_EXT. However, querying it in Mesa generates GL_INVALID_ENUM, and a search of the codebase seems to indicate that it is not implemented. I'm using Mesa 10.0.1, which is not yet a valid Version in the bug-tracker. I'll attach a patch to piglit to add a test for this. Let me know if you'd like me to do anything about getting it pushed into the piglit code base. -- 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] i965: slow glTexSubImage2D because of Y tiling
Ok, thanks for the answers, I'll wait for release 10.1 on Fedora then. -- Tomash Brechko ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 73100] New: Please use AC_PATH_TOOL instead of AC_PATH_PROG for llvm-config
https://bugs.freedesktop.org/show_bug.cgi?id=73100 Priority: medium Bug ID: 73100 Assignee: mesa-dev@lists.freedesktop.org Summary: Please use AC_PATH_TOOL instead of AC_PATH_PROG for llvm-config Severity: normal Classification: Unclassified OS: All Reporter: mgo...@gentoo.org Hardware: Other Status: NEW Version: git Component: Other Product: Mesa Created attachment 91255 --> https://bugs.freedesktop.org/attachment.cgi?id=91255&action=edit Patch replacing the check with AC_PATH_TOOL Since llvm-config is a tool used to obtain build host paths, the check should use AC_PATH_TOOL instead of AC_PATH_PROG. This helps with cross-compiling and multilib, e.g. finding i686-pc-linux-gnu-llvm-config as necessary. -- 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 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate
https://bugs.freedesktop.org/show_bug.cgi?id=45466 Michał Górny changed: What|Removed |Added CC||mgo...@gentoo.org See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=73100 --- Comment #4 from Michał Górny --- Every distribution uses its own hacks to do multilib, and I don't think anything related to this really belongs in mesa. Even if you can find a sane defaults that don't result in really bad results in some distros, you are putting amd64-specific magic in package that supposedly can be used on any arch. For a cleaner solution, take a look at bug #73100. It uses well-established practice and works for multilib, assuming you pass proper --host to configure and split llvm-config accordingly. -- 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 73100] Please use AC_PATH_TOOL instead of AC_PATH_PROG for llvm-config
https://bugs.freedesktop.org/show_bug.cgi?id=73100 Michał Górny changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=45466 -- 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] [PATCH] Use AC_PATH_TOOL instead of AC_PATH_PROG for llvm-config.
This should help with cross-compiling and multilib when $CHOST-specific llvm-config is expected rather than build host default one. It will help us a bit in Gentoo where we've started using i686-pc-linux-gnu-llvm-config for 32-bit multilib LLVM. Signed-off-by: Michał Górny Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73100 --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index f75325d..1d68547 100644 --- a/configure.ac +++ b/configure.ac @@ -1567,9 +1567,9 @@ if test "x$enable_gallium_llvm" = xauto; then fi if test "x$enable_gallium_llvm" = xyes; then if test "x$llvm_prefix" != x; then -AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no], ["$llvm_prefix/bin"]) +AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no], ["$llvm_prefix/bin"]) else -AC_PATH_PROG([LLVM_CONFIG], [llvm-config], [no]) +AC_PATH_TOOL([LLVM_CONFIG], [llvm-config], [no]) fi if test "x$LLVM_CONFIG" != xno; then -- 1.8.5.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 72926] Memory corruption (crash) in draw/draw_pt_fetch_shade_pipeline_llvm.c:435
https://bugs.freedesktop.org/show_bug.cgi?id=72926 --- Comment #3 from Alexander Monakov --- I don't have llvmpipe installed so I can't investigate further. Have you tried running glretrace under valgrind before/after the offending commit? -- 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 72926] Memory corruption (crash) in draw/draw_pt_fetch_shade_pipeline_llvm.c:435
https://bugs.freedesktop.org/show_bug.cgi?id=72926 --- Comment #4 from Peter Wu --- Created attachment 91257 --> https://bugs.freedesktop.org/attachment.cgi?id=91257&action=edit valgrind apitrace mesa-a3ae5dc7dd5c2f8893f86a920247e690e550ebd4 Steps to reproduce: # good commit: 98d2498404ba69a3efc1c765b1a1885d151181ed # bad commit: git checkout a3ae5dc7dd5c2f8893f86a920247e690e550ebd4 NOCONFIGURE=1 ./autogen.sh ./configure --prefix=/tmp/mesa-root --with-gallium-drivers=swrast --with-dri-drivers=i965 --with-llvm-shared-libs --enable-gallium-llvm --enable-shared-glapi --enable-dri --enable-glx --enable-texture-float make install Run with: LIBGL_DEBUG=verbose \ LD_LIBRARY_PATH=/tmp/mesa-root/lib \ LIBGL_DRIVERS_PATH=/tmp/mesa-root/lib/dri \ LIBGL_ALWAYS_SOFTWARE=1 \ valgrind glretrace /tmp/java.trace This is tested with LLVM 3.3. The two conditional jump warnings are also present in the "good" commit, everything thereafter is new (starting from "Invalid write"). -- 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 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate
https://bugs.freedesktop.org/show_bug.cgi?id=45466 --- Comment #5 from Alexandre Demers --- (In reply to comment #4) > Every distribution uses its own hacks to do multilib, and I don't think > anything related to this really belongs in mesa. Even if you can find a sane > defaults that don't result in really bad results in some distros, you are > putting amd64-specific magic in package that supposedly can be used on any > arch. > > For a cleaner solution, take a look at bug #73100. It uses well-established > practice and works for multilib, assuming you pass proper --host to > configure and split llvm-config accordingly. Then everything that has to do with cross-compiling should be stripped off mesa. I'm pointing the infamous "--enable-XXbit" flags here. I've been using --host for a long time to circumvent limitations/problems encountered with the --enable-XXbit flags (but you have to set some other variables to have a proper build). We should seriously consider taking a decision about cleaning the --enable-XXbit flags off. Either we fix it properly (which doesn't seem to be happening even with the many patches laying around) or we strip it completely and we let the builder set the proper environment variables to do the job. -- 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 73096] Query GL_RGBA_SIGNED_COMPONENTS_EXT missing
https://bugs.freedesktop.org/show_bug.cgi?id=73096 Alan Coopersmith changed: What|Removed |Added Version|unspecified |10.0 -- 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 09/16] i965/fs: Calculate interference better in register_coalesce.
I'm sorry, the text I was thinking of was on page 20 of the Iterated
Register Coalescing paper (
http://www.cs.cmu.edu/afs/cs/academic/class/15745-s07/www/papers/george.pdf),
"Move instructions are given special consideration...", but it's still the
same idea.
On Fri, Dec 27, 2013 at 7:38 PM, Connor Abbott wrote:
> I'm not sure if this is relevant to the i965 fs backend in particular, but
> Briggs in his thesis [1] recommended simply ignoring the liveness of any
> register read by a copy instruction immediately after said instruction when
> computing the interference graph in order to solve this exact problem (see
> section 2.2.2).
>
> [1] http://www.cs.utexas.edu/~mckinley/380C/lecs/briggs-thesis-1992.pdf
> On Dec 19, 2013 4:40 PM, "Matt Turner" wrote:
>
>> Previously we simply considered two registers whose live ranges
>> overlapped to interfere. Cases such as
>>
>>set A --
>>... |
>>mov B, A --|
>>... | B | A
>>use B --|
>>... |
>>use A --
>>
>> would be considered to interfere, even though B is an unmodified copy of
>> A whose live range fit wholly inside that of A.
>>
>> If no writes to A or B occur between the mov B, A and the use of B then
>> we can safely coalesce them.
>>
>> Instead of removing MOV instructions, we make them NOPs and remove them
>> at once after the main pass is finished in order to avoid recomputing
>> live intervals (which are needed to perform the previous step).
>>
>> total instructions in shared programs: 1543768 -> 1513077 (-1.99%)
>> instructions in affected programs: 951563 -> 920872 (-3.23%)
>> GAINED:46
>> LOST: 22
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.cpp | 69
>>
>> 1 file changed, 62 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> index e4ac0a5..ad56b87 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> @@ -2273,7 +2273,7 @@ fs_visitor::register_coalesce()
>> int last_use[MAX_SAMPLER_MESSAGE_SIZE];
>> int next_ip = 0;
>>
>> - foreach_list_safe(node, &this->instructions) {
>> + foreach_list(node, &this->instructions) {
>>fs_inst *inst = (fs_inst *)node;
>>
>>int ip = next_ip;
>> @@ -2299,8 +2299,39 @@ fs_visitor::register_coalesce()
>>int var_to = live_intervals->var_from_reg(&inst->dst);
>>
>>if (live_intervals->vars_interfere(var_from, var_to) &&
>> - !inst->dst.equals(inst->src[0]))
>> - continue;
>> + !inst->dst.equals(inst->src[0])) {
>> +
>> + if (live_intervals->end[var_to] > live_intervals->end[var_from])
>> +continue;
>> +
>> + bool overwritten = false;
>> + int scan_ip = -1;
>> +
>> + foreach_list(n, &this->instructions) {
>> + fs_inst *scan_inst = (fs_inst *)n;
>> +scan_ip++;
>> +
>> +if (scan_inst->is_control_flow()) {
>> + overwritten = true;
>> + break;
>> +}
>> +
>> +if (scan_ip <= live_intervals->start[var_to])
>> + continue;
>> +
>> +if (scan_ip > live_intervals->end[var_to])
>> + break;
>> +
>> +if (scan_inst->dst.equals(inst->dst) ||
>> +scan_inst->dst.equals(inst->src[0])) {
>> + overwritten = true;
>> + break;
>> +}
>> + }
>> +
>> + if (overwritten)
>> +continue;
>> + }
>>
>>if (reg_from != inst->src[0].reg) {
>> reg_from = inst->src[0].reg;
>> @@ -2342,9 +2373,18 @@ fs_visitor::register_coalesce()
>>if (live_channels_remaining)
>> continue;
>>
>> + bool removed = false;
>>for (int i = 0; i < src_size; i++) {
>> - if (mov[i])
>> -mov[i]->remove();
>> + if (mov[i]) {
>> +removed = true;
>> +
>> +mov[i]->opcode = BRW_OPCODE_NOP;
>> +mov[i]->conditional_mod = BRW_CONDITIONAL_NONE;
>> +mov[i]->dst = reg_undef;
>> +mov[i]->src[0] = reg_undef;
>> +mov[i]->src[1] = reg_undef;
>> +mov[i]->src[2] = reg_undef;
>> + }
>>}
>>
>>foreach_list(node, &this->instructions) {
>> @@ -2366,11 +2406,26 @@ fs_visitor::register_coalesce()
>> scan_inst->src[j].reg_offset = reg_to_offset[i];
>>}
>> }
>> -
>> - progress = true;
>> }
>> }
>>}
>> +
>> + if (removed) {
>> + live_intervals->start[var_to] =
>> MIN2(live_intervals->start[var_to],
>> +
>> live_intervals->start[var_from]);
>> + live_intervals->end[var_to] = MAX2(live_intervals->end[var_to],
>> +
>> live_intervals->end[var_from]);
>> +
[Mesa-dev] [Bug 73100] Please use AC_PATH_TOOL instead of AC_PATH_PROG for llvm-config
https://bugs.freedesktop.org/show_bug.cgi?id=73100 Alexandre Demers changed: What|Removed |Added CC||alexandre.f.dem...@gmail.co ||m -- 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 73106] New: gtest-port.h:499:13: fatal error: 'tr1/tuple' file not found
https://bugs.freedesktop.org/show_bug.cgi?id=73106 Priority: medium Bug ID: 73106 Assignee: mesa-dev@lists.freedesktop.org Summary: gtest-port.h:499:13: fatal error: 'tr1/tuple' file not found Severity: normal Classification: Unclassified OS: Mac OS X (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: e2d53fac1c5b18f5c9e95d39d4e2be4703b0b363 (master) gtest-1.6.0 build fails on Mac OS X 10.9 Mavericks. $ make check [...] CXX src/gtest-all.lo In file included from src/gtest-all.cc:39: In file included from ../../src/gtest/include/gtest/gtest.h:57: In file included from ../../src/gtest/include/gtest/internal/gtest-internal.h:40: ../../src/gtest/include/gtest/internal/gtest-port.h:499:13: fatal error: 'tr1/tuple' file not found # include // NOLINT ^ $ g++ --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix $ sw_vers ProductName:Mac OS X ProductVersion:10.9.1 BuildVersion:13B42 -- 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
