https://bugs.freedesktop.org/show_bug.cgi?id=90264
Diego Viola changed:
What|Removed |Added
CC|
Thanks for testing :)
On Monday, July 25, 2016, Andy Furniss wrote:
> Nayan Deshmukh wrote:
>
>> Hi Christian,
>>
>> I have sent the new patches, they should fix all the artifacts. :)
>>
>
> I have briefly tried these over time and v3 1/2 + v2 2/2 still show
> artifacts for
On 23.07.2016 22:04, Nicolai Hähnle wrote:
> On 22.07.2016 17:09, Emil Velikov wrote:
>> On 18 July 2016 at 00:46, Eric Engestrom wrote:
>>>
>>> --- /dev/null
>>> +++ b/src/mesa/drivers/dri/radeon/.editorconfig
>>> @@ -0,0 +1,3 @@
>>> +# Coin toss? Leaving this one empty (ie.
https://bugs.freedesktop.org/show_bug.cgi?id=97019
--- Comment #7 from Dieter Nützel ---
Created attachment 125305
--> https://bugs.freedesktop.org/attachment.cgi?id=125305=edit
clover-llvm-codegen-native.cpp.patch
--
You are receiving this mail because:
You are the QA
https://bugs.freedesktop.org/show_bug.cgi?id=97019
--- Comment #6 from Dieter Nützel ---
(In reply to Francisco Jerez from comment #5)
> Seems like a GCC bug... You may be able to work around the issue by using
> the old-fashioned constructor call syntax with parentheses
https://bugs.freedesktop.org/show_bug.cgi?id=97067
--- Comment #2 from Luke ---
Yes, I'm seeing these errors even with llvmpipe (LIBGL_ALWAYS_SOFTWARE=1
./firefox).
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the
Hello,
after fixing problem with mako version mesa from git still fails to
compile. Now problematic part is clover state tracker. Error message is:
libtool: compile: g++-4.8 -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TARNAME=\"mesa\" -
DPACKAGE_VERSION=\"12.1.0-devel\" "-DPACKAGE_STRING=\"Mesa
On Tuesday 19 July 2016 05:11:56 Kenneth Graunke wrote:
> On Monday, July 18, 2016 10:58:25 PM PDT Pali Rohár wrote:
> > Any conclusion or fix for this issue?
>
> Dylan suggested you use pip --user to install a newer version of
> Mako. Is that a workable solution to your problem?
Now I was able
Your proposition seems reasonable, but it's sad that drivers have to
deal with this.
Marek
On Mon, Jul 25, 2016 at 12:32 AM, Ilia Mirkin wrote:
> I was working on the component layouts stuff required for
> ARB_enhanced_layouts, and ran into an issue with representing this
On Sun, Jul 24, 2016 at 7:36 PM, Timothy Arceri
wrote:
> This makes link_assign_uniform_locations().
I think you accidentally the whole sentence.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Builtins already have locations assigned so this shouldn't
changing anything. We want to call it earlier so we can tranform
GLSL IR to NIR earlier.
---
src/compiler/glsl/linker.cpp | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/src/compiler/glsl/linker.cpp
This makes link_assign_uniform_locations() easier to follow.
---
src/compiler/glsl/link_uniforms.cpp | 330 +++-
src/compiler/glsl/linker.cpp| 4 +-
src/compiler/glsl/linker.h | 5 +-
3 files changed, 177 insertions(+), 162 deletions(-)
diff
There is no need to be looping over all the uniforms.
---
src/compiler/glsl/link_uniform_initializers.cpp | 29 ++---
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/src/compiler/glsl/link_uniform_initializers.cpp
---
src/compiler/glsl/link_uniform_initializers.cpp | 78 -
1 file changed, 39 insertions(+), 39 deletions(-)
diff --git a/src/compiler/glsl/link_uniform_initializers.cpp
b/src/compiler/glsl/link_uniform_initializers.cpp
index 1d7c207..db5e899 100644
---
This makes link_assign_uniform_locations().
---
src/compiler/glsl/link_uniforms.cpp | 132 +++-
1 file changed, 69 insertions(+), 63 deletions(-)
diff --git a/src/compiler/glsl/link_uniforms.cpp
b/src/compiler/glsl/link_uniforms.cpp
index 89196e6..793f12c 100644
Here a new function link_varyings_and_uniforms() is created this
should help make it easier to follow the code in link_shader()
which was getting very large.
Note the end of the new function contains a for loop with some
lowering calls that currently don't seem related to varyings or
uniforms but
https://bugs.freedesktop.org/show_bug.cgi?id=97019
--- Comment #5 from Francisco Jerez ---
Seems like a GCC bug... You may be able to work around the issue by using the
old-fashioned constructor call syntax with parentheses instead of braces to
initialize the "fos"
Nayan Deshmukh wrote:
Hi Christian,
I have sent the new patches, they should fix all the artifacts. :)
I have briefly tried these over time and v3 1/2 + v2 2/2 still show
artifacts for me.
All versions have issues with 8/9, and I agree with the view that
you shouldn't really use up all the
I was working on the component layouts stuff required for
ARB_enhanced_layouts, and ran into an issue with representing this in
TGSI.
Right now when we indirectly index into arrays, we include an ArrayID
to indicate which array it is we're indexing into.
However with component layouts, we might
https://bugs.freedesktop.org/show_bug.cgi?id=93551
Thomas J. Moore changed:
What|Removed |Added
CC||dark...@gmail.com
https://bugs.freedesktop.org/show_bug.cgi?id=97019
--- Comment #4 from Jan Vesely ---
(In reply to Dieter Nützel from comment #3)
> c++ (SUSE Linux) 4.8.3
>
> openSUSE 13.2 system version (worked for ages)
>
> Iaroslav is on openSUSE Leap 42.1+ (4.8.5) or updated to
https://bugs.freedesktop.org/show_bug.cgi?id=97019
--- Comment #3 from Dieter Nützel ---
c++ (SUSE Linux) 4.8.3
openSUSE 13.2 system version (worked for ages)
Iaroslav is on openSUSE Leap 42.1+ (4.8.5) or updated to 5.x, I think.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=97067
Ilia Mirkin changed:
What|Removed |Added
QA Contact|nouveau@lists.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=97019
--- Comment #2 from Jan Vesely ---
This looks like an old compiler (not fully c++11 capable). what version are you
using?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee
Hi Christian,
I have sent the new patches, they should fix all the artifacts. :)
Regards,
Nayan.
On Sat, Jul 23, 2016 at 3:30 PM, Nayan Deshmukh
wrote:
> Hi Christian,
>
> I tried using the approach, the artifacts are gone. But for some videos
> the output quality
HIGH_QUALITY_SCALING_L2 to HIGH_QUALTIY_SCALING_L9
uses lanczos filter with number representing the size
of the sinc window.
Signed-off-by: Nayan Deshmukh
---
src/gallium/state_trackers/vdpau/mixer.c | 116 ---
v2: avoiding dividing by zero when calculating lanczos
v3: make range of vtex 0..width instead of 0..1 (Christian)
Signed-off-by: Nayan Deshmukh
---
src/gallium/auxiliary/Makefile.sources | 2 +
src/gallium/auxiliary/vl/vl_lanczos_filter.c | 445
https://bugs.freedesktop.org/show_bug.cgi?id=97019
--- Comment #1 from Dieter Nützel ---
I'm back from vacation and can second this with
LLVM 3.9.0svn and current (today)
LLVM 4.0.0svn
my post was titled:
clover: compilation error with former LLVM 3.9.0svn and current
/opt/opencl-example> llc --version
LLVM (http://llvm.org/):
LLVM version 4.0.0svn
Optimized build.
Default target: x86_64-unknown-linux-gnu
Host CPU: nehalem
Registered Targets:
amdgcn - AMD GCN GPUs
r600 - AMD GPUs HD2XXX-HD6XXX
x86- 32-bit X86: Pentium-Pro and above
29 matches
Mail list logo