On 05/25/2014 01:02 PM, Matt Turner wrote:
On Sun, May 25, 2014 at 1:08 AM, Kenneth Graunke kenn...@whitecape.org
wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c
b/src/mesa/drivers/dri/i965/brw_clip_tri.c
index fdab260..5894b80 100644
---
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #10 from Florian Link florianl...@gmail.com ---
Sorry, seems that the trace I attached did not have the right angle.
I did another trace and used the 64bit glretrace with Mesa LLVMPipe (10.2 RC2)
opengl32.dll (64Bit) copied to the
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #11 from Florian Link florianl...@gmail.com ---
Created attachment 99841
-- https://bugs.freedesktop.org/attachment.cgi?id=99841action=edit
new api trace of example
New trace with different camera angle.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #12 from Florian Link florianl...@gmail.com ---
Created attachment 99842
-- https://bugs.freedesktop.org/attachment.cgi?id=99842action=edit
Frame 8 screenshot done with glretrace
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #13 from Florian Link florianl...@gmail.com ---
Created attachment 99843
-- https://bugs.freedesktop.org/attachment.cgi?id=99843action=edit
Frame 8 with glretrace (correct mime type)
--
You are receiving this mail because:
You are
Patch adds new implementation dependent value required by the
GL_ARB_explicit_uniform_location extension. Default value for user
assignable locations is calculated as sum of MaxUniformComponents
for each stage.
v2: fix descriptor in get_hash_params.py (Petri)
v3: simpler formula for calculating
Patch refactors the existing uniform processing so explicit locations
are taken in to account during variable processing. These locations
are temporarily stored in gl_uniform_storage before actual locations
are set.
UNMAPPED_UNIFORM_LOC marks unset location so that we can use 0 as a
valid
This function calculates the number of uniform locations required
by the type in UniformRemapTable.
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/glsl/glsl_types.cpp | 26 ++
src/glsl/glsl_types.h | 6 ++
2 files changed, 32 insertions(+)
diff --git
Hi;
Here's some fixes to GL_ARB_explicit_uniform_location patches and one
additional patch (2) to help calculate location slots for glsl types
correctly (was incorrect for matrices currently).
There is still a bit discussion ongoing on one of the patches and I
left it out for now:
Support inactive uniforms that have explicit location set in
glUniform* functions.
v2: remove unnecessary extension check, use new define (Ian)
Signed-off-by: Tapani Pälli tapani.pa...@intel.com
---
src/mesa/main/uniform_query.cpp | 15 +++
1 file changed, 15 insertions(+)
diff
Patch initializes the UniformRemapTable for explicit locations. This
needs to happen before optimizations to make sure all inactive uniforms
get their explicit locations correctly.
v2: fix initialization bug, introduce define for inactive uniforms (Ian)
Signed-off-by: Tapani Pälli
https://bugs.freedesktop.org/show_bug.cgi?id=78773
--- Comment #8 from Tapani Pälli lem...@gmail.com ---
Took a bit more look. The problem is that game opens a core context but expects
to use legacy/compatibility extensions like GL_ARB_multitexture. Same happens
with GL_ARB_texture_compression
https://bugs.freedesktop.org/show_bug.cgi?id=79263
Priority: medium
Bug ID: 79263
Assignee: mesa-dev@lists.freedesktop.org
Summary: Linking error in egl_gallium.la when compiling 32 bit
on multiarch
Severity: normal
On Sun, May 25, 2014 at 11:43 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On 05/25/2014 01:02 PM, Matt Turner wrote:
On Sun, May 25, 2014 at 1:08 AM, Kenneth Graunke kenn...@whitecape.org
wrote:
diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c
Matt Turner matts...@gmail.com writes:
On Wed, May 21, 2014 at 4:08 PM, Eric Anholt e...@anholt.net wrote:
Matt Turner matts...@gmail.com writes:
Number of compacted instructions: 827404 - 833045 (0.68%)
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 20
1 file
Hi,
On Thursday, May 22, 2014 03:38:12 Jose Fonseca wrote:
In short, besides the existing gallivm_context (which is actually not per
context, but rather per module/ compilation unit) there should be a new
object, that's truly per context, that holds two things:
- LLVMContextRef
-
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #14 from Roland Scheidegger srol...@vmware.com ---
Ok I see the error now. Too bad the trace is a bit complex and trimming didn't
work unfortunately (I bet that's got something to do with the multiple contexts
and windows). I'll try
---
src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 171
1 file changed, 171 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index 6b7c30c..987b6c4 100644
---
Hi, please review the following patch!
Thanks,
Tobias Klausmann
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
https://bugs.freedesktop.org/show_bug.cgi?id=79039
Bug 79039 depends on bug 77704, which changed state.
Bug 77704 Summary: [IVB/HSW Bisected]Ogles3conform
GL3Tests_shadow_shadow_execution_frag.test fails
https://bugs.freedesktop.org/show_bug.cgi?id=77704
What|Removed
https://bugs.freedesktop.org/show_bug.cgi?id=79039
Bug 79039 depends on bug 78692, which changed state.
Bug 78692 Summary: Football Manager 2014, gameplay rendered black white
https://bugs.freedesktop.org/show_bug.cgi?id=78692
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=79039
Bug 79039 depends on bug 78648, which changed state.
Bug 78648 Summary: Texture artifacts in Kerbal Space Program
https://bugs.freedesktop.org/show_bug.cgi?id=78648
What|Removed |Added
Before you read my comments about all the potential improvements,
congratulations on your first nouveau patch :) Well done!
On Mon, May 26, 2014 at 3:53 PM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
It's common for people to throw in a Signed-off-by line, although not
strictly
v2: change patch according to Ilia Mirkins review
---
src/gallium/drivers/nouveau/nvc0/nvc0_surface.c | 151
1 file changed, 151 insertions(+)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
b/src/gallium/drivers/nouveau/nvc0/nvc0_surface.c
index
On Mon, May 26, 2014 at 7:20 PM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
v2: change patch according to Ilia Mirkins review
This doesn't really add any particularly useful information for the
commit log... 1 year from now, looking at this commit, is that really
useful
On Wed, Apr 23, 2014 at 11:19 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On 04/18/2014 11:56 AM, Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 135
+++
1 file changed, 73 insertions(+), 62 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #15 from Roland Scheidegger srol...@vmware.com ---
Ok turns out this is indeed an interpolation problem. Depth test is enabled and
it just happens that for these failing fragments probably due to interpolation
precision issues the
v2:
- change patch name to nvc0: implement clear_buffer
- rename nvc0_clear_buffer_rgb32 - nvc0_clear_buffer_cpu and make it work for
all formats
- remove superfluous fenciing in nvc0_clear_buffer_cpu
- coding style fixes
v3:
- more coding style fixes
- nvc0_clear_buffer() - don't mark
Made a few very minor changes to it and pushed out as
http://cgit.freedesktop.org/mesa/mesa/commit/?id=a26e2bc2e3578b50bd581c8f8d8e3c428c85158f
On Mon, May 26, 2014 at 8:19 PM, Tobias Klausmann
tobias.johannes.klausm...@mni.thm.de wrote:
v2:
- change patch name to nvc0: implement clear_buffer
On 05/19/2014 06:06 PM, Kai Wasserbäch wrote:
Michel Dänzer schrieb am 19.05.2014 04:12:
On 18.05.2014 18:37, Kai Wasserbäch wrote:
And instead of just not starting, my X starts crashing, whenever
libGL fails to load a (32 bit) driver.
FWIW, some potential alternatives for avoiding the X
The following 2 patches make it possible to run Mesa programs on GK20A
(Tegra K1).
GK20A is very similar to GK104, but uses a new (backward-compatible) 3D class
as well as the same ISA as GK110 (SM35). Taking these differences into account
is sufficient to successfully render simple off-screen
GK20A is mostly compatible with GK104, but uses the SM35 ISA. Use
the GK110 path when this chip is detected.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h| 1 +
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp |
GK20A is mostly compatible with GK104, but features a new 3D
class. Add it to the relevant header and use it when GK20A is
detected.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
src/gallium/drivers/nouveau/nv_object.xml.h| 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 9
On Tue, May 27, 2014 at 12:59 AM, Alexandre Courbot acour...@nvidia.com wrote:
GK20A is mostly compatible with GK104, but uses the SM35 ISA. Use
the GK110 path when this chip is detected.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
On Tue, May 27, 2014 at 12:59 AM, Alexandre Courbot acour...@nvidia.com wrote:
GK20A is mostly compatible with GK104, but features a new 3D
class. Add it to the relevant header and use it when GK20A is
detected.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
35 matches
Mail list logo
