Hi Ken,
I just did a bisect looking for the failure that's causing a few
gs-related piglits to fail on nv50, and it came up with the below. Any
ideas? Here are the tests that are failing:
tests/spec/glsl-1.50/execution/geometry/clip-distance-out-values.shader_test
tests/spec/glsl-1.50/execution/g
On Fri, 18 Apr 2014 01:41:46 +0200
Benjamin Bellec wrote:
> Hi Lauri,
>
> I tested with both commit but cannot seeing something relevant, I got 60
> FPS in both case.
> I tested with the Tremulous 1.1 test case from Phoronix Test Suite 4.8.6
> (from Fedora 19 repo).
>
> The command used (for bo
On Fri, 18 Apr 2014 10:16:53 +0300
Lauri Kasanen wrote:
> On Fri, 18 Apr 2014 01:41:46 +0200
> Benjamin Bellec wrote:
>
> > Hi Lauri,
> >
> > I tested with both commit but cannot seeing something relevant, I got 60
> > FPS in both case.
> > I tested with the Tremulous 1.1 test case from Phoron
https://bugs.freedesktop.org/show_bug.cgi?id=77449
--- Comment #1 from Kertesz Laszlo ---
The worst bug i encountered is bug #77589:
[r600g] Source engine game stopped working (bisected)
Presumably all Source-based games fail to start, usually giving a black screen
and keeping a CPU @100%. If S
On Fri, Mar 28, 2014 at 5:40 AM, Ian Romanick wrote:
> From: Ian Romanick
>
> This code was broken in some odd ways before. To much state was being
> saved, it was being restored in the wrong order, and in the wrong way.
> The biggest problem was that the pipeline object was restored before
> re
Bruno Jiménez writes:
> From: Tom Stellard
>
> ---
> src/gallium/include/pipe/p_defines.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/gallium/include/pipe/p_defines.h
> index a3a1ae1..93f9642 100644
> --- a/src/gallium
https://bugs.freedesktop.org/show_bug.cgi?id=77582
--- Comment #2 from Benjamin Bellec ---
All these tests uses the core profile.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freede
On Fri, 2014-04-18 at 12:08 +0200, Francisco Jerez wrote:
> Bruno Jiménez writes:
>
> > From: Tom Stellard
> >
> > ---
> > src/gallium/include/pipe/p_defines.h | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/src/gallium/include/pipe/p_defines.h
> > b/src/galliu
https://bugs.freedesktop.org/show_bug.cgi?id=77589
--- Comment #5 from Marek Olšák ---
This should be fixed by 352e06ddea1108bad1d2c6742fe3. Can you confirm?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailin
https://bugs.freedesktop.org/show_bug.cgi?id=77589
--- Comment #6 from Benjamin Bellec ---
Yes I confirm this is now fixed.
Tested with Left 4 Dead 2 and Counter-Strike Source on Evergreen.
--
You are receiving this mail because:
You are the assignee for the bug.
___
I disabled vsync and tested with Tremulous.
I didn't see any regression on my system, I got 256-257 FPS with or
without HyperZ, with this 2 commits and also current master (git-352e06d).
So it doesn't hit Evergreen at least.
Le 18/04/2014 09:20, Lauri Kasanen a écrit :
> On Fri, 18 Apr 2014 10:16:
https://bugs.freedesktop.org/show_bug.cgi?id=77589
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=77449
Bug 77449 depends on bug 77589, which changed state.
Bug 77589 Summary: [r600g] Source engine game stopped working (bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=77589
What|Removed |Added
-
https://bugs.freedesktop.org/show_bug.cgi?id=77449
--- Comment #2 from Alex Deucher ---
(In reply to comment #1)
> The worst bug i encountered is bug #77589:
>
> [r600g] Source engine game stopped working (bisected)
>
> Presumably all Source-based games fail to start, usually giving a black
> s
AFAICS LIBDRM_LIBS has been part of libxatracker_la_LIBADD since day one.
Not entirely sure how it can be missing in your case. Whereas for which of
the my recent commits should be queued to the stable branches it can be
argued either way.
If you feel strong about a commit or two, simply email/cc t
This series is based in Tom Stellard's 'clover-clock' branch:
http://cgit.freedesktop.org/~tstellar/mesa/log/?h=clover-clock
And should fix this bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=73511
The only changes from the original branch are in patches 2 and 3.
Patch 2 has been updated
From: Tom Stellard
v2: Updated the docs
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 5c255d0..3f38b28 100
From: Tom Stellard
v2: PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY instead of
PIPE_COMPUTE_MAX_CLOCK_FREQUENCY
Signed-off-by: Igor Gnatenko
clover: Correct the returned value for max_clock_frequency
According to OpenCL 1.1 spec, the returned value must be in MHz, and we
were returning it in kHz
From: Tom Stellard
v2: in define RADEON_INFO_MAX_SCLK use 0x1a instead of 0x19 (upstream changes)
Signed-off-by: Igor Gnatenko
r600: Correct the case MAX_CLOCK_FREQUENCY in get_compute_param
v3: Convert the frequency to MHz from kHz after getting it in
'do_winsys_init'
---
src/gallium/driver
Bruno Jiménez writes:
> From: Tom Stellard
>
> v2: Updated the docs
> ---
> src/gallium/docs/source/screen.rst | 2 ++
> src/gallium/include/pipe/p_defines.h | 3 ++-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/docs/source/screen.rst
> b/src/gallium/docs/so
Bruno Jiménez writes:
> From: Tom Stellard
>
> v2: PIPE_COMPUTE_CAP_MAX_CLOCK_FREQUENCY instead of
> PIPE_COMPUTE_MAX_CLOCK_FREQUENCY
>
> Signed-off-by: Igor Gnatenko
>
> clover: Correct the returned value for max_clock_frequency
>
> According to OpenCL 1.1 spec, the returned value must be
From: Tom Stellard
v2: Updated the docs
v3: Remove trailing comma
---
src/gallium/docs/source/screen.rst | 2 ++
src/gallium/include/pipe/p_defines.h | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
On 04/18/2014 12:09 AM, Ilia Mirkin wrote:
> Hi Ken,
>
> I just did a bisect looking for the failure that's causing a few
> gs-related piglits to fail on nv50, and it came up with the below. Any
> ideas? Here are the tests that are failing:
>
> tests/spec/glsl-1.50/execution/geometry/clip-distanc
This has nothing to do with geometry shaders. AFAIK, rendering without
vertex data is allowed no matter what shaders you have. One can fetch
or generate vertex data using gl_VertexID only.
Marek
On Fri, Apr 18, 2014 at 5:46 PM, Kenneth Graunke wrote:
> On 04/18/2014 12:09 AM, Ilia Mirkin wrote:
On 04/18/2014 08:46 AM, Kenneth Graunke wrote:
> On 04/18/2014 12:09 AM, Ilia Mirkin wrote:
>> Hi Ken,
>>
>> I just did a bisect looking for the failure that's causing a few
>> gs-related piglits to fail on nv50, and it came up with the below. Any
>> ideas? Here are the tests that are failing:
>>
>
I cannot reproduce this regression. I have tested Cayman (HD 6950)
now. I got ~300 fps with both 020c43f and Mesa master using the
phoronix test suite and the resolution was 1920x1080.
Marek
On Tue, Apr 15, 2014 at 9:35 AM, Lauri Kasanen wrote:
> Hi,
>
> Tremulous and Smoking Guns regressed in M
Hi there,
Tom Stellard schrieb am 16.04.2014 17:07:
> On Wed, Apr 16, 2014 at 02:36:19PM +0200, Kai Wasserbäch wrote:
>> Michel Dänzer schrieb am 15.04.2014 09:27:
>>> On 23.03.2014 04:53, Kai Wasserbäch wrote:
Dear Mesa devs,
I'm not sure whether this is a bug in Mesa, LLVM or in eglibc.
On 2014-04-18 08:46:00, Kenneth Graunke wrote:
> On 04/18/2014 12:09 AM, Ilia Mirkin wrote:
> > Hi Ken,
> >
> > I just did a bisect looking for the failure that's causing a few
> > gs-related piglits to fail on nv50, and it came up with the below. Any
> > ideas? Here are the tests that are failing
On 04/12/2014 12:44 AM, Chris Forbes wrote:
> As of 943b2d52bf5, layout(binding) on an atomic would fail the assertion
> here.
>
> Signed-off-by: Chris Forbes
> Cc: Ian Romanick
> ---
> src/glsl/link_uniform_initializers.cpp | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff -
This must not have existed when I wrote the original code. The atomic
operation header setup code uses this.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/gen8_fs_generator.cpp
b/
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77221
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.h | 3 +++
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 30 -
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77221
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.h | 3 +++
src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp | 26 ++-
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git
Francisco made brw_mark_surface_used a freestanding function in
commit a32817f3c248125fb537c3a915566445e5600d45. We should use it.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.h| 2 --
src/mesa/drivers/dri/i965/brw_vec4.h | 2 --
src/mesa/dr
Otherwise we crash when setting up atomic buffer objects.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77221
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen8_surface_state.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/mesa/drivers/dri/i96
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77221
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.h | 4 +++
src/mesa/drivers/dri/i965/gen8_vec4_generator.cpp | 35 ++-
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git
The brw_eu_emit.c code manually forces the header present bit when
used in align1 (scalar) mode. So, this has no effect currently.
However, it is nice to have fs_inst::header_present reflect reality.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77221
Signed-off-by: Kenneth Graunke
---
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77221
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.h | 5
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 34 -
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a
This is similar to what Eric did for Gen7 a little while ago; it also
has support for untyped surface reads.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/gen8_disasm.c | 65 +
1 file changed, 65 insertions(+)
diff --git a/src/mesa/drivers/dri/i965
The '**used' pointer was pointing into the stObj->sampler_views array.
If 'free' was null, we'd realloc that array, thus making the 'used'
pointer invalid. This soon led to memory errors.
Just change the pointer to be '*used' so it points directly at the
pipe_sampler_view.
---
src/mesa/state_tra
Kenneth Graunke writes:
> Back when I originally wrote this code, force_sechalf was only used for
> Gen4 code, so I didn't bother hooking it up. However, it's used more
> generally these days. In particular, we use it for computing
> gl_SamplePosition.
>
> Fixes Piglit's spec/ARB_sample_shading
Will get more complicated when fs_reg src becomes a pointer.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 5 +
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index c550c41..b0
Caveat: I have not tested this on < Gen7 (platforms that send
from MRF). My guess is that I've broken something on those, but
that it shouldn't be a fundamental problem.
Extending this to MRF platforms seems like it'll take a little
bit of extra work, from my 2 minutes of thinking about it.
This
Clean up with with register_coalesce()/dead_code_eliminate().
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 37
src/mesa/drivers/dri/i965/brw_fs.h | 1 +
2 files changed, 38 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dr
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 13 +++--
src/mesa/drivers/dri/i965/brw_fs.h | 3 ++-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 69d1059..506c16b 100644
--- a/src/mesa/drive
Wouldn't it be nice if case labels could be non-constant expressions.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 77 +---
src/mesa/drivers/dri/i965/brw_fs.h | 10 ++---
2 files changed, 31 insertions(+), 56 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_
Also add an emit() function that calls it.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 20
src/mesa/drivers/dri/i965/brw_fs.h | 3 +++
2 files changed, 23 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 1a7fe45..
The fs_reg src array is going to turn into a pointer and we'd rather not
consider the implications of shallow copying fs_insts.
Reviewed-by: Topi Pohjolainen
---
src/mesa/drivers/dri/i965/brw_fs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mes
Potentially we'll want more than three sources for Phi nodes.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 8
src/mesa/drivers/dri/i965/brw_fs.h | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.c
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 9 +
src/mesa/drivers/dri/i965/brw_fs.h | 2 ++
2 files changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 506c16b..1a7fe45 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 24 +++---
.../drivers/dri/i965/brw_fs_copy_propagation.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 2 +-
.../dri/i965/brw_fs_dead_code_eliminate.cpp| 2 +-
src/mesa/drivers/dri/i965/brw_fs_g
But only into non-load_payload instructions. Otherwise we would prevent
register coalescing from combining identical payloads.
---
.../drivers/dri/i965/brw_fs_copy_propagation.cpp | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_pr
---
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_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 2aa3acd..91bbe0a 100644
--- a/src/mesa/drivers/dri/
Will be used to simplify the handling of large virtual GRFs in SSA form.
---
src/mesa/drivers/dri/i965/brw_defines.h| 2 ++
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 3 +++
src/mesa/drivers/dri/i965/brw_shader.cpp | 3 +++
3 files changed, 8 insertions(+)
diff --git a/src/mes
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 33
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
index e40567f..44f1fe4 100644
--- a/src/mesa/drivers/dri/i965/brw
---
.../drivers/dri/i965/brw_fs_register_coalesce.cpp | 59 ++
1 file changed, 49 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
b/src/mesa/drivers/dri/i965/brw_fs_register_coalesce.cpp
index cb4ab57..a363c4c 100644
--- a/s
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
b/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
index 94f657d..e40567f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
++
Since CSE creates instructions, if we let CSE generate things register
coalescing can't remove, bad things will happen. Only let CSE combine
non-copy load_payloads.
E.g., allow CSE to handle this
load_payload vgrf4+0, vgrf5, vgrf6
but not this
load_payload vgrf4+0, vgrf5+0, vgrf5+1
---
s
So that we don't have partial writes to a large VGRF. Will be cleaned up
by register coalescing.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri
Helps Unigine Tropics and some (old) gstreamer shaders in shader-db.
instructions in affected programs: 792 -> 744 (-6.06%)
---
src/mesa/drivers/dri/i965/brw_fs_cse.cpp | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_cse.cpp
b
instructions in affected programs: 474 -> 462 (-2.53%)
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 602fc4a..1fe84f3 100644
--- a/src/mesa/dr
https://bugs.freedesktop.org/show_bug.cgi?id=68296
--- Comment #11 from U. Artie Eoff ---
(In reply to comment #10)
> This seems to work fine for me with the latest Mesa. Feel free to reopen if
> this is still a problem for you.
I think this was originally reported based on a side-effect it had
On Fri, 18 Apr 2014 18:40:56 +0200
Marek Olšák wrote:
> I cannot reproduce this regression. I have tested Cayman (HD 6950)
> now. I got ~300 fps with both 020c43f and Mesa master using the
> phoronix test suite and the resolution was 1920x1080.
My apologies, NOTABUG. Turned out those two were 32
On 04/11/2014 04:35 PM, Eric Anholt wrote:
> Ian Romanick writes:
>
>> From: Ian Romanick
>>
>> Almost all of the time the location set by layout(location=...) is the
>> location that will be used for the variable. Vertex shader inputs and
>> fragment shader outputs, for example, are visible to
On 04/11/2014 04:29 PM, Eric Anholt wrote:
> Ian Romanick writes:
>
>> From: Ian Romanick
>>
>> Signed-off-by: Ian Romanick
>> ---
>> src/glsl/linker.cpp | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
>> index ee07e89..e0
https://bugs.freedesktop.org/show_bug.cgi?id=77502
--- Comment #1 from Emil Velikov ---
Can you use git to bisect the commit that introduced this issue? Commit
d681b22ed77274a805c6c8e81925c18eeb57a968 is the highest suspect, interestingly
the vg symbols were available last time I built the librar
On 04/02/2014 04:47 PM, Cody Northrop wrote:
> I applied a fix locally for the problem Olv pointed out and tested the
> patches.
>
> Running into a problem with the linker code when a geometry shader has
> location layout qualifiers for both inputs and outputs.
>
> It falls into the assign_varyin
On 04/03/2014 02:20 AM, Petri Latvala wrote:
> Like AMD_performance_monitor, this extension provides an interface for
> applications (and OpenGL-based tools) to access GPU performance
> counters. Since the exact performance counters available vary between
> vendors and hardware generations, the ext
I went ahead and pushed this one with 'Reviewed-by: Ian Romanick'.
On 03/17/2014 01:43 AM, Petri Latvala wrote:
> ---
> include/GL/glext.h | 82
> ++
> 1 file changed, 76 insertions(+), 6 deletions(-)
>
> diff --git a/include/GL/glext.h b/incl
This patch is
Reviewed-by: Ian Romanick
On 03/17/2014 01:43 AM, Petri Latvala wrote:
> Signed-off-by: Petri Latvala
> ---
> src/mesa/main/tests/enum_strings.cpp | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/src/mesa/main/tests/enum_strings.cpp
> b/src/mesa/main
On 03/17/2014 01:43 AM, Petri Latvala wrote:
> Using the existing driver hooks made for AMD_performance_monitor, implement
> INTEL_performance_query functions.
>
> v2: Whitespace changes.
With the formatting nits mentioned below fixed, this patch is
Reviewed-by: Ian Romanick
> Signed-off-by: P
I'm slightly leaning towards using a single flag for both extensions.
As far as I can tell, the only difference between the extensions is
device-independent API bits. If you support one, you can surely support
the other.
Ken: What's your opinion?
That would mean that this patch would be replaced
https://bugs.freedesktop.org/show_bug.cgi?id=77502
--- Comment #2 from farmboy0+freedesk...@googlemail.com ---
GCC: 4.7.3
Binutils 2.23.2
I'll do the bisect later but I think its not your mentioned commit.
I checked the latest changes to the Makefile for vgapi and reverted them and
nothing got be
On 04/03/2014 06:57 PM, Anuj Phogat wrote:
> Fixes failures in Khronos OpenGL CTS test proxy_textures_invalid_samples
>
> Cc:
> Signed-off-by: Anuj Phogat
One tiny nit below. With that fixed,
Reviewed-by: Ian Romanick
> ---
> src/mesa/main/teximage.c | 16 +---
> 1 file changed
Chromium defined a new GL extension (that isn't registered with Khronos).
We need to add an EGL extension for it, so we can migrate ChromeOS on
Intel systems to use EGL instead of GLX.
http://git.chromium.org/gitweb/?p=chromium/src/third_party/khronos.git;a=commitdiff;h=27cbfdab35c601f70aa150581ad
On 04/03/2014 04:13 PM, Anuj Phogat wrote:
> This patch changes the behavior of glGetAttribLocation(),
> glGetFragDataLocation() and glGetFragDataIndex() functions.
>
> Code changes handle the cases described in following example:
> vertex shader:
> layout(location = 1)in vec4[4] a;
> void main()
On 03/31/2014 02:00 PM, Anuj Phogat wrote:
> In OpenGL 3.1 attribute 0 becomes non-magic, just like in
> OpenGL ES 2.0. Earlier versions of OpenGL used attribute 0
> exclusively for vertex position.
>
> Fixes 4 Khronos OpenGL CTS failures:
> glGetVertexAttrib
> depth24_basic
> depth24_precision
>
On 03/24/2014 04:33 PM, Anuj Phogat wrote:
> Currently overlapping locations of input variables are not allowed for all
> the shader types in OpenGL and OpenGL ES.
>
>>From OpenGL ES 3.0 spec, page 56:
>"Binding more than one attribute name to the same location is referred
> to as aliasing
On 03/11/2014 05:33 PM, Anuj Phogat wrote:
>>From the OpenGL 4.4 spec page 275:
> "If pname is FRAMEBUFFER_ATTACHMENT_COMPONENT_TYPE, param will
>contain the format of components of the specified attachment,
>one of FLOAT, INT, UNSIGNED_INT, SIGNED_NORMALIZED, or
>UNSIGNED_NORMALIZED
On 03/12/2014 06:07 PM, Anuj Phogat wrote:
> Section 4.3.1, page 220, of OpenGL 3.3 specification explains
> the error conditions for glreadPixels():
>
>"If the format is DEPTH_STENCIL, then values are taken from
> both the depth buffer and the stencil buffer. If there is
> no depth bu
On 04/18/2014 03:37 PM, Sarah Sharp wrote:
> Chromium defined a new GL extension (that isn't registered with Khronos).
> We need to add an EGL extension for it, so we can migrate ChromeOS on
> Intel systems to use EGL instead of GLX.
>
> http://git.chromium.org/gitweb/?p=chromium/src/third_party/k
On 04/17/2014 04:34 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
Currently it's the same value.
---
src/gallium/drivers/llvmpipe/lp_setup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
b/src/gallium/drivers/llvmpipe
Looks good, but some comments below.
On 04/17/2014 04:34 PM, srol...@vmware.com wrote:
From: Roland Scheidegger
GL (3.0) allows you to clear individual color buffers in a fb. In fact
for fbs containing both int and float/normalized color buffers this is
required (because the clearing values ar
Series is
Reviewed-by: Ian Romanick
On 04/12/2014 05:37 PM, Chris Forbes wrote:
> This gives us a better bound for some hot loops in the drivers than
> MAX_COMBINED_TEXTURE_IMAGE_UNITS, which is ridiculously large on modern
> hardware, and only getting worse as more shader stages are added.
>
>
On Fri, Apr 18, 2014 at 4:49 PM, Ian Romanick wrote:
> On 04/18/2014 03:37 PM, Sarah Sharp wrote:
>> One open question:
>>
>> I've used the normal (error checked) version of xcb_dri2_get_msc. The
>> GLX implementation of glXGetSyncValuesOML uses the unchecked version,
>> but I'm not convinced it'
On 04/18/2014 05:07 PM, Jamey Sharp wrote:
> On Fri, Apr 18, 2014 at 4:49 PM, Ian Romanick wrote:
>> On 04/18/2014 03:37 PM, Sarah Sharp wrote:
>>> One open question:
>>>
>>> I've used the normal (error checked) version of xcb_dri2_get_msc. The
>>> GLX implementation of glXGetSyncValuesOML uses t
Mesa 10.1.1 has been released. Mesa 10.1.1 is a bug fix release which
fixes bugs fixed since the 10.1 release, (see below for a list of
changes).
The tag in the git repository for Mesa 10.1.1 is 'mesa-10.1.1'.
Mesa 10.1.1 is available for download at
ftp://freedesktop.org/pub/mesa/10.1.1/
md5sum
Mesa 10.0.5 has been released. Mesa 10.0.5 is a bug fix release which
fixes bugs fixed since the 10.0.4 release, (see below for a list of
changes).
NOTE: Since the 10.1.1 release is being released concurrently, it is
anticipated that 10.0.5 will be the final release in the 10.0
series. Users of 10
[I missed Chad on the original Cc somehow; hopefully he can find the
original mails.]
On Fri, Apr 18, 2014 at 04:49:43PM -0700, Ian Romanick wrote:
> On 04/18/2014 03:37 PM, Sarah Sharp wrote:
> > Chromium defined a new GL extension (that isn't registered with Khronos).
> > We need to add an EGL e
https://bugs.freedesktop.org/show_bug.cgi?id=77582
--- Comment #3 from Timothy Arceri ---
The error Mesa throws is:
Mesa: User error: GL_INVALID_ENUM in glGetString(GL_EXTENSIONS)
The test shoudn't be calling glGetString(GL_EXTENSIONS) in a core profile you
might want to report this in their b
https://bugs.freedesktop.org/show_bug.cgi?id=77582
--- Comment #4 from Timothy Arceri ---
ok I reported it here: https://github.com/g-truc/ogl-samples/issues/34
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mai
> > The only thing I can think of to try now is making sure your system is
> > actually using the version of libGL that you built and not the system
> > one using the following command.
> >
> > ldconfig -p | grep libGL.so
> >
> > The libGL that you built should be at the top of the list.
>
> I'
On Fri, Apr 18, 2014 at 06:59:37PM +0200, Kai Wasserbäch wrote:
> Hi there,
> Tom Stellard schrieb am 16.04.2014 17:07:
> > On Wed, Apr 16, 2014 at 02:36:19PM +0200, Kai Wasserbäch wrote:
> >> Michel Dänzer schrieb am 15.04.2014 09:27:
> >>> On 23.03.2014 04:53, Kai Wasserbäch wrote:
> Dear Me
92 matches
Mail list logo
