https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #10 from Florian Link ---
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 apitrace-msvc\x64\bin. I
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #11 from Florian Link ---
Created attachment 99841
--> https://bugs.freedesktop.org/attachment.cgi?id=99841&action=edit
new api trace of example
New trace with different camera angle.
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #12 from Florian Link ---
Created attachment 99842
--> https://bugs.freedesktop.org/attachment.cgi?id=99842&action=edit
Frame 8 screenshot done with glretrace
--
You are receiving this mail because:
You are the assignee for the bu
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #13 from Florian Link ---
Created attachment 99843
--> https://bugs.freedesktop.org/attachment.cgi?id=99843&action=edit
Frame 8 with glretrace (correct mime type)
--
You are receiving this mail because:
You are the assignee for th
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 in
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 explicit
This function calculates the number of uniform locations required
by the type in UniformRemapTable.
Signed-off-by: Tapani Pälli
---
src/glsl/glsl_types.cpp | 26 ++
src/glsl/glsl_types.h | 6 ++
2 files changed, 32 insertions(+)
diff --git a/src/glsl/glsl_types.cp
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:
http://list
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
---
src/mesa/main/uniform_query.cpp | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/mesa/main/unif
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
---
src/glsl/
https://bugs.freedesktop.org/show_bug.cgi?id=78773
--- Comment #8 from Tapani Pälli ---
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 and GL_ARB_vertex_b
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
Class
On Sun, May 25, 2014 at 11:43 PM, Kenneth Graunke wrote:
> On 05/25/2014 01:02 PM, Matt Turner wrote:
>> On Sun, May 25, 2014 at 1:08 AM, Kenneth Graunke
>> 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
Matt Turner writes:
> On Wed, May 21, 2014 at 4:08 PM, Eric Anholt wrote:
>> Matt Turner writes:
>>
>>> Number of compacted instructions: 827404 -> 833045 (0.68%)
>>> ---
>>> src/mesa/drivers/dri/i965/brw_eu_emit.c | 20
>>> 1 file changed, 20 insertions(+)
>>>
>>> diff --
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 ---
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 to extract the neces
---
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
--- a/src/gallium/drivers/nouveau/nvc
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
wrote:
It's common for people to throw in a Signed-off-by line, although not
strictly required (like it is in the kernel)
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 6b7c30c..24
On Mon, May 26, 2014 at 7:20 PM, Tobias Klausmann
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 information to see? I tend to put that sort
On Wed, Apr 23, 2014 at 11:19 PM, Kenneth Graunke 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 a/src/mesa/drivers/dri/i965/brw
https://bugs.freedesktop.org/show_bug.cgi?id=78914
--- Comment #15 from Roland Scheidegger ---
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 depth test fails. At l
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
wrote:
> v2:
> - change patch name to "nvc0: implement clear_buffer"
> - rename nvc0_clear_buffer_rgb
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 av
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 buf
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
---
src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h| 1 +
src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 2 +-
src/gallium/d
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
---
src/gallium/drivers/nouveau/nv_object.xml.h| 1 +
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c | 9 -
2 files ch
On Tue, May 27, 2014 at 12:59 AM, Alexandre Courbot 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
> ---
> src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h| 1 +
> src/galli
On Tue, May 27, 2014 at 12:59 AM, Alexandre Courbot 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
> ---
> src/gallium/drivers/nouveau/nv_object.xml.h| 1 +
On 05/27/2014 02:29 PM, Ilia Mirkin wrote:
On Tue, May 27, 2014 at 12:59 AM, Alexandre Courbot 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
---
src/gallium/drivers
On 05/27/2014 02:26 PM, Ilia Mirkin wrote:
On Tue, May 27, 2014 at 12:59 AM, Alexandre Courbot 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
---
src/gallium/drivers/nouveau/codegen/nv50_ir
36 matches
Mail list logo
