On Dec 4, 2016 11:18 PM, "Pohjolainen, Topi"
wrote:
On Sun, Dec 04, 2016 at 08:36:03PM -0800, Jason Ekstrand wrote:
>On Sun, Dec 4, 2016 at 2:08 PM, Topi Pohjolainen
><[1]topi.pohjolai...@gmail.com> wrote:
>
> Otherwise subsequent render cycles keep on using compression
> and/or
On Sun, Dec 04, 2016 at 08:36:03PM -0800, Jason Ekstrand wrote:
>On Sun, Dec 4, 2016 at 2:08 PM, Topi Pohjolainen
><[1]topi.pohjolai...@gmail.com> wrote:
>
> Otherwise subsequent render cycles keep on using compression
> and/or fast clear.
>
>I believe that's because most th
Signed-off-by: Nayan Deshmukh
---
src/gallium/state_trackers/vdpau/mixer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/vdpau/mixer.c
b/src/gallium/state_trackers/vdpau/mixer.c
index c205427..aca43c1 100644
--- a/src/gallium/state_trackers/vdpau/
Yes, you are right, sorry for the noise.
Regards,
Nayan.
On Mon, Dec 5, 2016 at 10:14 AM, Jason Ekstrand wrote:
> Calling exit() is going to cause the program to terminate and all of its
> resources will get cleaned up by the OS. There's no real reason why we need
> to free anything first.
>
>
Calling exit() is going to cause the program to terminate and all of its
resources will get cleaned up by the OS. There's no real reason why we
need to free anything first.
On Sun, Dec 4, 2016 at 9:47 AM, Nayan Deshmukh
wrote:
> CovID: 1373563
>
> Signed-off-by: Nayan Deshmukh
> ---
> src/int
On Sun, Dec 4, 2016 at 2:08 PM, Topi Pohjolainen wrote:
> Otherwise subsequent render cycles keep on using compression
> and/or fast clear.
>
I believe that's because most things look at mt->mcs_buf rather than
no_ccs. Given that we're allocating the CCS up-front, is no_ccs really
doing anythin
https://bugs.freedesktop.org/show_bug.cgi?id=90264
Michel Dänzer changed:
What|Removed |Added
CC||ch...@chris-wilson.co.uk
--- Comment #70
On 4 December 2016 at 08:04, Bas Nieuwenhuizen wrote:
> On Mon, Nov 28, 2016 at 5:19 AM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This isn't fully what we want yet, but is a good step on the way.
>>
>> This allows the compiler to create the information structures
>> for the state setting si
https://bugs.freedesktop.org/show_bug.cgi?id=90264
--- Comment #69 from Vedran Miletić ---
(In reply to Furkan from comment #68)
> For what it's worth, I installed AMDGPU-PRO today, and the problem went away.
That's a completely different OpenGL driver.
--
You are receiving this mail because:
On Monday, December 5, 2016 12:08:13 AM PST Topi Pohjolainen wrote:
> Otherwise subsequent render cycles keep on using compression
> and/or fast clear.
>
> Signed-off-by: Topi Pohjolainen
> CC: Kalyan Kondapally
> CC: Kenneth Graunke
> ---
> src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 ++
Otherwise subsequent render cycles keep on using compression
and/or fast clear.
Signed-off-by: Topi Pohjolainen
CC: Kalyan Kondapally
CC: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/intel_mip
On Sat, 2016-12-03 at 14:33 -0800, Vinson Lee wrote:
> Hi, Tobias.
>
> /bin/llvm-config --includedir returns /include. I am
> not setting the "--with-llvm-prefix" configure option.
Have you completed mesa build with only the configure.ac fix?
I'm not sure if using llvm without make install is sup
https://bugs.freedesktop.org/show_bug.cgi?id=98974
--- Comment #5 from lukas.fuernkranz+bugzil...@gmail.com ---
Unfortunately I doesn't seem to fix the problem for me, Dylan.
--
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=98974
--- Comment #4 from Dylan Baker ---
Mesa 13.0.2 and 13.0.1 demonstrate the problem, and I'm using stellaris 1.3.2
(2620). I saw the bug that idr opened, and I have a work around, setting the
launch options in steam to "MESA_GL_VERSION_OVERRIDE=31
CovID: 1373563
Signed-off-by: Nayan Deshmukh
---
src/intel/tools/aubinator.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/intel/tools/aubinator.c b/src/intel/tools/aubinator.c
index 5e3a684..f64a843 100644
--- a/src/intel/tools/aubinator.c
+++ b/src/intel/tool
CovID: 1396387
Signed-off-by: Nayan Deshmukh
---
src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_cs.c
index b8558fa..08abb9d 100644
--- a/src/amd/vulkan/win
https://bugs.freedesktop.org/show_bug.cgi?id=98842
--- Comment #5 from yjd...@gmail.com ---
no , have another libdrm package.
dpkg -l | grep "libdrm"
ri libdrm-dev:amd64
2.4.58-2 amd64Userspace interface to
kernel DRM services -- development files
ri libdrm-
Hello,
Sampling the stencil value in Mesa seems to work only with NEAREST filter
type. This seems to be consistent with the following excerpt from the GL
spec:
"In order to access the stencil index texture component the
DEPTH_STENCIL_TEXTURE_MODE texture parameter should be set to STENCIL_INDEX
.
They are picked automatically by the provided llvm-config flags, but are
not needed.
Fixes loading radv through a vulkan loader.
Cc: 13.0
---
It's work-around for:
https://lists.freedesktop.org/archives/mesa-dev/2016-October/130765.html
Since there are other people than me dealing with this is
https://bugs.freedesktop.org/show_bug.cgi?id=98974
Pierre Moreau changed:
What|Removed |Added
CC||pierre.mor...@free.fr
--- Comment #3 fro
https://bugs.freedesktop.org/show_bug.cgi?id=98974
--- Comment #2 from Pierre Moreau ---
(In reply to Dylan Baker from comment #1)
> I can verify this bug on Archlinux using the i965 driver on both HSW and
> SKL, thus moving to mesa core.
>
> On i965 I'm using low settings but see no borders for
21 matches
Mail list logo