https://bugs.freedesktop.org/show_bug.cgi?id=61821
Vinson Lee changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
On 03/12/2013 10:39 PM, Paul Berry wrote:
On 12 March 2013 22:23, Kenneth Graunke mailto:kenn...@whitecape.org>> wrote:
On 03/11/2013 03:51 PM, Paul Berry wrote:
This patch updates the bitfields brw_context::wm.input_size___masks,
tracker::size_masks, and brw_wm_prog_key::pr
I'm pretty sure this commit broke 'make check'.
On 03/12/2013 03:07 PM, Jose Fonseca wrote:
Module: Mesa
Branch: master
Commit: 70fe7c6d3e1c7534f6598c4616bebf672f42668b
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=70fe7c6d3e1c7534f6598c4616bebf672f42668b
Author: José Fonseca
Date:
On 03/11/2013 03:51 PM, Paul Berry wrote:
This patch series combines the enums gl_vert_result, gl_geom_attrib,
gl_geom_result, and gl_frag_attrib into a single enum.
These four enums serve very similar purposes: they all identify data
that flows through the pipeline from vertex shader to fragmen
On 12 March 2013 22:23, Kenneth Graunke wrote:
> On 03/11/2013 03:51 PM, Paul Berry wrote:
>
>> This patch updates the bitfields brw_context::wm.input_size_**masks,
>> tracker::size_masks, and brw_wm_prog_key::proj_attrib_**mask, all of
>> which are indexed by gl_frag_attrib, from 32-bit to 64-bi
On 03/11/2013 03:51 PM, Paul Berry wrote:
This patch updates the bitfields brw_context::wm.input_size_masks,
tracker::size_masks, and brw_wm_prog_key::proj_attrib_mask, all of
which are indexed by gl_frag_attrib, from 32-bit to 64-bit.
This paves the way for supporting geometry shaders, and for
This was only produced by the brw_wm_input_dimensions atom, which was
removed in the previous commit. So there's no need for the dirty bit.
Cc: Eric Anholt
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 2 --
src/mesa/drivers/dri/i965/brw_state_upload.c | 1 -
The previous commit removed the last user of this field, so there's no
longer any point in setting it. Removing this should eliminate
state-dependent recompiles, and make the precompile more reliable.
Cc: Eric Anholt
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 6
This was only used to compute proj_attrib_mask, which was removed by the
previous commit. That makes this dead code.
Cc: Eric Anholt
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/Makefile.sources | 1 -
src/mesa/drivers/dri/i965/brw_context.h | 5 -
src/mesa/drivers/d
This optimization attempts to avoid extra attribute interpolation
instructions for texture coordinates where the W-component is 1.0.
Unfortunately, it requires a lot of complexity: the brw_wm_input_sizes
state atom (all the brw_vs_constval.c code) needs to run on each draw.
It computes the input_s
On Mar 12, 2013, at 6:10 PM, Jose Fonseca wrote:
> This patch has some #if near the end. It's not clear if it should be
> removed or completed.
Yeah, I'll remove that before committing. I haven't needed it in testing so far.
> Otherwise the series looks good AFAICT.
Thanks.
-Brian
On Tue, Mar 12, 2013 at 8:38 PM, Zack Rusin wrote:
>> hmm, well, I think my fix is not incorrect.. we can tell from dri2
>> proto version that the xserver does not support ScheduleSwap. Maybe
>> there should be other conditions where we also don't advertise this
>> extension, but this patch still
> hmm, well, I think my fix is not incorrect.. we can tell from dri2
> proto version that the xserver does not support ScheduleSwap. Maybe
> there should be other conditions where we also don't advertise this
> extension, but this patch still improves things. If we absolutely
> know from the dri2
On Mon, Mar 11, 2013 at 10:12 AM, Eric Anholt wrote:
> Matt Turner writes:
>
>> A step toward working make dist/distcheck.
>> ---
>> configure.ac | 37 -
>> src/Makefile.am | 30 +++---
>> src/mapi/Makefile.am | 42 ++
On Tue, Mar 12, 2013 at 8:09 PM, Zack Rusin wrote:
> > well, from what I can tell, if you advertise this extension
>> applications will expect a swap event. Which will never come if
>> dri/glx on client side remaps scheduleswap to copyregion.
>>
>> So maybe there are other conditions where we sh
This patch has some #if near the end. It's not clear if it should be
removed or completed.
Otherwise the series looks good AFAICT.
Jose
- Original Message -
> ---
> src/gallium/state_trackers/osmesa/osmesa.c | 828
>
> 1 files changed, 828 insertions
> well, from what I can tell, if you advertise this extension
> applications will expect a swap event. Which will never come if
> dri/glx on client side remaps scheduleswap to copyregion.
>
> So maybe there are other conditions where we should not advertise this
> extension. But if we know we w
On Tue, Mar 12, 2013 at 7:53 PM, Zack Rusin wrote:
>> If ddx does not support swap, don't advertise it. We might also be
>> able to get rid of the vmwgfx check (I'm not quite sure the purpose of
>> that check vs. just checking dri2Minor.
>
>
> No, not really. GLX_INTEL_swap_event doesn't have any
> If ddx does not support swap, don't advertise it. We might also be
> able to get rid of the vmwgfx check (I'm not quite sure the purpose of
> that check vs. just checking dri2Minor.
No, not really. GLX_INTEL_swap_event doesn't have any hooks. You're checking
for presence of generic swap exten
If ddx does not support swap, don't advertise it. We might also be
able to get rid of the vmwgfx check (I'm not quite sure the purpose of
that check vs. just checking dri2Minor.
Signed-off-by: Rob Clark
---
src/glx/dri2_glx.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
d
On 03/11/2013 04:51 PM, Paul Berry wrote:
This patch series combines the enums gl_vert_result, gl_geom_attrib,
gl_geom_result, and gl_frag_attrib into a single enum.
These four enums serve very similar purposes: they all identify data
that flows through the pipeline from vertex shader to fragmen
Paul Berry writes:
> Since apps typically begin rendering with a call to glClear(), it is
> likely that when brw_workaround_depthstencil_alignment() moves a
> miplevel to a temporary buffer, it can avoid doing a blit, since the
> contents of the miplevel are about to be erased.
>
> This patch add
On 03/12/2013 04:12 PM, Jordan Justen wrote:
On Tue, Mar 12, 2013 at 2:12 PM, Brian Paul wrote:
On 03/12/2013 02:52 PM, Jordan Justen wrote:
On Mon, Mar 11, 2013 at 5:28 PM, Brian Paul wrote:
On Sat, Mar 2, 2013 at 7:29 AM, Brian Paul wrote:
I've respun my remove-mfeatures branch as r
On Tue, Mar 12, 2013 at 3:39 PM, wrote:
> From: José Fonseca
>
> We were in four already...
> ---
> include/c99_compat.h | 105
> +
> src/egl/main/eglcompiler.h| 44 ++
> src/gallium/include/pipe/p_compiler.h | 74 ++-
On Tue, Mar 12, 2013 at 2:12 PM, Brian Paul wrote:
> On 03/12/2013 02:52 PM, Jordan Justen wrote:
>>
>> On Mon, Mar 11, 2013 at 5:28 PM, Brian Paul wrote:
>>>
>>> On Sat, Mar 2, 2013 at 7:29 AM, Brian Paul wrote:
I've respun my remove-mfeatures branch as remove-mfeatures-2. It's in
>>
Looks good to me.
Jose
- Original Message -
> If geometry shader is present its stream output info should
> be used instead of the vs and we shouldn't use the pre-clipped
> corrdinates.
>
> Signed-off-by: Zack Rusin
> ---
> .../draw/draw_pt_fetch_shade_pipeline_llvm.c |2 +-
>
On Tue, Mar 12, 2013 at 4:23 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> v2:
> - Only dump shaders when env variable is set.
A couple of comments below, other than that, looks good.
Reviewed-by: Alex Deucher
> ---
> src/gallium/drivers/radeon/radeon_llvm_util.c |2 +-
> src/gall
If geometry shader is present its stream output info should
be used instead of the vs and we shouldn't use the pre-clipped
corrdinates.
Signed-off-by: Zack Rusin
---
.../draw/draw_pt_fetch_shade_pipeline_llvm.c |2 +-
src/gallium/auxiliary/draw/draw_pt_so_emit.c | 37 ++
- Original Message -
> On Tue, Mar 12, 2013 at 10:31 AM, Christian König
> wrote:
> > Am 12.03.2013 02:48, schrieb Marek Olšák:
> >
> >> On Mon, Mar 11, 2013 at 1:44 PM, Christian König
> >> wrote:
> >>>
> >>> Hi everybody,
> >>>
> >>> this problem has been open for quite some time now,
On Tue, Mar 12, 2013 at 10:31 AM, Christian König
wrote:
> Am 12.03.2013 02:48, schrieb Marek Olšák:
>
>> On Mon, Mar 11, 2013 at 1:44 PM, Christian König
>> wrote:
>>>
>>> Hi everybody,
>>>
>>> this problem has been open for quite some time now, with a bunch of
>>> different
>>> opinions and som
On 03/12/2013 02:52 PM, Jordan Justen wrote:
On Mon, Mar 11, 2013 at 5:28 PM, Brian Paul wrote:
On Sat, Mar 2, 2013 at 7:29 AM, Brian Paul wrote:
I've respun my remove-mfeatures branch as remove-mfeatures-2. It's in my
repo on freedesktop.org
This removes the mfeatures.h file and the last o
- Original Message -
> On 03/12/2013 02:49 PM, Brian Paul wrote:
> > On 03/12/2013 02:39 PM, jfons...@vmware.com wrote:
> >> From: José Fonseca
> >>
> >> ---
> >> common.py | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/common.py b/common.py
> >> index 6ff9
On 03/12/2013 02:49 PM, Brian Paul wrote:
On 03/12/2013 02:39 PM, jfons...@vmware.com wrote:
From: José Fonseca
---
common.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 6ff9608..1d618e6 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @
https://bugs.freedesktop.org/show_bug.cgi?id=47607
Alexander Monakov changed:
What|Removed |Added
CC||amona...@gmail.com
--- Comment #6 fr
On Mon, Mar 11, 2013 at 5:28 PM, Brian Paul wrote:
> On Sat, Mar 2, 2013 at 7:29 AM, Brian Paul wrote:
>> I've respun my remove-mfeatures branch as remove-mfeatures-2. It's in my
>> repo on freedesktop.org
>>
>> This removes the mfeatures.h file and the last of the #ifdef FEATURE_x
>> code
>> fr
On 03/12/2013 02:39 PM, jfons...@vmware.com wrote:
From: José Fonseca
---
common.py |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 6ff9608..1d618e6 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opts):
opts
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #14 from José Fonseca ---
(In reply to comment #13)
> VS 2012 refuses to compile Mesa due to macro definition of "inline".
>
> I've tried downloading 9.0.3 and 9.1, no change. I had expected to see
> inline/INLINE changes in the sou
From: José Fonseca
---
include/c99_compat.h | 42 ++
1 file changed, 42 insertions(+)
diff --git a/include/c99_compat.h b/include/c99_compat.h
index 39f958f..3a9f502 100644
--- a/include/c99_compat.h
+++ b/include/c99_compat.h
@@ -30,6 +30,37 @@
/*
From: José Fonseca
We were in four already...
---
include/c99_compat.h | 105 +
src/egl/main/eglcompiler.h| 44 ++
src/gallium/include/pipe/p_compiler.h | 74 ++-
src/mapi/mapi/u_compiler.h
From: José Fonseca
---
common.py |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common.py b/common.py
index 6ff9608..1d618e6 100644
--- a/common.py
+++ b/common.py
@@ -100,4 +100,4 @@ def AddOptions(opts):
opts.Add(BoolOption('quiet', 'DEPRECATED: profile build',
Signed-off-by: Jordan Justen
---
src/glsl/link_varyings.cpp | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link_varyings.cpp
index 616933d..6c5ec6f 100644
--- a/src/glsl/link_varyings.cpp
+++ b/src/gls
Convert interface blocks with instance names into flat
interface blocks without an instance name.
Signed-off-by: Jordan Justen
---
src/glsl/Makefile.sources |1 +
src/glsl/ir_optimization.h|1 +
src/glsl/linker.cpp |6 +
src/glsl/
Signed-off-by: Jordan Justen
---
src/glsl/linker.cpp | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 57e7a9a..b33df37 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -478,6 +478,7 @@ cross_validate_globals(struct g
Signed-off-by: Jordan Justen
---
src/glsl/ir.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/glsl/ir.h b/src/glsl/ir.h
index 393b486..c6bfb11 100644
--- a/src/glsl/ir.h
+++ b/src/glsl/ir.h
@@ -120,6 +120,7 @@ public:
virtual class ir_dereference * as_dereference()
Interface blocks in GLSL 150 allow an instance name to be used.
Signed-off-by: Jordan Justen
---
src/glsl/glsl_parser.yy | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 8e6b04d..1fd8cc2 100644
--- a/sr
An interface block member may specify the type:
in {
in vec4 in_var_with_qualifier;
};
In this case it must match the interface block type.
It can also omit the qualifier:
uniform {
vec4 uniform_var_without_qualifier;
};
In this case, it should use the same type as the interface block.
Signed-off-by: Jordan Justen
---
src/glsl/ast_to_hir.cpp | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 40f3188..ee54c70 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -4293,6
Previously uniform blocks allowed for the 'uniform' keyword
to be used with members of a uniform blocks. With interface
blocks 'in' can be used on 'in' interface block members and
'out' can be used on 'out' interface block members.
The basic_interface_block rule will verify that the same
qualifier
Signed-off-by: Jordan Justen
---
src/glsl/glsl_parser.yy | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 7adc06d..8e6b04d 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -1935,6 +1935,20 @@ basic_i
Signed-off-by: Jordan Justen
---
src/glsl/ast.h |4 ++--
src/glsl/ast_to_hir.cpp |6 +++---
src/glsl/glsl_parser.yy | 14 +++---
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index fcc6b45..49c3939 100644
--- a/src/glsl
Previously only 'uniform' was allowed for uniform blocks.
Now, in/out can be parsed, but it will only be allowed for
GLSL >= 150.
Signed-off-by: Jordan Justen
---
src/glsl/glsl_parser.yy | 60 ++-
1 file changed, 49 insertions(+), 11 deletions(-)
d
Signed-off-by: Jordan Justen
---
src/glsl/glsl_parser.yy | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index cd33078..33b74ea 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@
git://people.freedesktop.org/~jljusten/mesa interface-blocks-v1
v1:
* Initial support for GLSL 1.50 interface block support
* Known issue: interface block arrays are not working
* Known issue: rejection of unmatched interface blocks
is not working
* Piglit tests for known issue
From: Tom Stellard
v2:
- Only dump shaders when env variable is set.
---
src/gallium/drivers/radeon/radeon_llvm_util.c |2 +-
src/gallium/drivers/radeon/radeon_llvm_util.h |2 +
src/gallium/drivers/radeonsi/Makefile.sources |1 +
src/gallium/drivers/radeonsi/radeonsi_compute.
From: Tom Stellard
This target string now contains four values instead of three. The old
processor field (which was really being interpreted as arch) has been split
into two fields: processor and arch. This allows drivers to pass a
more a more detailed description of the hardware to compiler fr
From: Tom Stellard
---
configure.py | 119 -
1 files changed, 75 insertions(+), 44 deletions(-)
diff --git a/configure.py b/configure.py
index d861c24..dfd9a8f 100755
--- a/configure.py
+++ b/configure.py
@@ -68,6 +68,15 @@ llvm_clang = o
Checks that no functions are exported that are not part of the ABI.
Note that currently we are exporting functions that are aliased to
functions that are part of the ABI. They shouldn't be exported, but the
XML descriptions don't adequately describe this case.
---
src/mapi/es2api/ABI-check | 2
Checks that no functions are exported that are not part of the ABI.
Note that currently we are exporting functions that are aliased to
functions that are part of the ABI. They shouldn't be exported, but the
XML descriptions don't adequately describe this case.
---
src/mapi/es1api/ABI-check | 2
On 12 March 2013 12:28, Eric Anholt wrote:
> Paul Berry writes:
>
> > Fast depth clears have the same depth/stencil alignment requirements
> > as other drawing operations. Therefore, we need to call
> > brw_workaround_depthstencil_alignment() from both the clear and
> > drawing paths.
> >
> > W
Paul Berry writes:
> Fast depth clears have the same depth/stencil alignment requirements
> as other drawing operations. Therefore, we need to call
> brw_workaround_depthstencil_alignment() from both the clear and
> drawing paths.
>
> Without this fix, we get image corruption if the following co
I'd previously added the minimum names to understand my dumps, but this
makes dumps in general much easier to read.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 20 +-
src/mesa/drivers/dri/i965/brw_shader.cpp | 110 ++
src/mesa/drivers/dri/i965/brw_shader.h |
This is now done in the VS backend before instruction emit.
---
src/mesa/drivers/dri/i965/Makefile.sources |1 -
src/mesa/drivers/dri/i965/brw_eu.h |5 --
src/mesa/drivers/dri/i965/brw_optimize.c | 114
3 files changed, 120 deletions(-)
delete mode
This is a more aggressive version of the old brw_optimize() path.
Reduces cycles spent in the vertex shader on minecraft by 18.6% +/- 10.0%
(n=15).
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 109 +++
src/mesa/drivers/dri/i965/brw_vec4.h|2 +
src/mesa/dri
On 03/12/2013 12:15 PM, Matt Turner wrote:
Fixes piglit's texture-immutable-levels test.
Reported-by: Marek Olšák
---
src/mesa/main/mtypes.h |1 +
src/mesa/main/texparam.c | 12
src/mesa/main/texstorage.c |1 +
3 files changed, 14 insertions(+), 0 deletions(-)
d
On 03/11/2013 11:29 AM, Paul Berry wrote:
Fast depth clears have the same depth/stencil alignment requirements
as other drawing operations. Therefore, we need to call
brw_workaround_depthstencil_alignment() from both the clear and
drawing paths.
Without this fix, we get image corruption if the
Fixes piglit's texture-immutable-levels test.
Reported-by: Marek Olšák
---
src/mesa/main/mtypes.h |1 +
src/mesa/main/texparam.c | 12
src/mesa/main/texstorage.c |1 +
3 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/ma
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #13 from Keith Kriewall ---
VS 2012 refuses to compile Mesa due to macro definition of "inline".
F:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\INCLUDE\xkeycheck.h(199): warning C4005: 'inline' : macro redefinition
On 03/11/2013 06:23 PM, Marek Olšák wrote:
On Mon, Mar 11, 2013 at 6:49 PM, Ian Romanick wrote:
Once upon a time Matt Turner was talking about using pixman to accelerate
operations like this in Mesa. It has a lot of highly optimized paths for
just this sort of thing. Since it's used by other
On 03/05/2013 06:58 AM, Henri Verbeet wrote:
On 2 March 2013 00:14, Ian Romanick wrote:
I added some comments, but I think the extension is pretty much fine
for at least Wine's purposes.
GLX_ARB_create_context and GLX_ARB_create_context_profile are required.
It's probably not a big d
Am 12.03.2013 02:23, schrieb Marek Olšák:
> On Mon, Mar 11, 2013 at 6:49 PM, Ian Romanick wrote:
>> Once upon a time Matt Turner was talking about using pixman to accelerate
>> operations like this in Mesa. It has a lot of highly optimized paths for
>> just this sort of thing. Since it's used by
On 03/10/2013 11:24 AM, Stefan Brüns wrote:
Hi everyone,
I have run into a problem leading to a crashing X server for a bunch of
indirect GLX calls.
This problem affects any OpenGL clients using indirect rendering and calling
functions which are outside the ABI. Problems range from malfunctioni
On 03/12/2013 07:13 AM, Bartosz Zawistowski wrote:
This fix splits several entries in dispatch table mechanism as in
es2 compatibility mode EXT calls should be different than ARB ones.
EXT equivalents wraps non-EXT calls so that DRI drivers are not affected
by changes in frontend.
This will com
https://bugs.freedesktop.org/show_bug.cgi?id=62236
Priority: medium
Bug ID: 62236
Assignee: mesa-dev@lists.freedesktop.org
Summary: the issue of not correct display from MALI Integer
Logic sample
Severity: major
Classific
On 03/11/2013 10:02 PM, Jordan Justen wrote:
On Mon, Mar 11, 2013 at 5:28 PM, Brian Paul wrote:
On Sat, Mar 2, 2013 at 7:29 AM, Brian Paul wrote:
I've respun my remove-mfeatures branch as remove-mfeatures-2. It's in my
repo on freedesktop.org
This removes the mfeatures.h file and the last o
On 12.03.2013 12:10, Christoph Bumiller wrote:
> On 12.03.2013 10:31, Christian König wrote:
>> Am 12.03.2013 02:48, schrieb Marek Olšák:
>>> On Mon, Mar 11, 2013 at 1:44 PM, Christian König
>>> wrote:
Hi everybody,
this problem has been open for quite some time now, with a bunch of
Well, the Xlib/swrast driver does everything in software, unlike a DRI
driver which does most things with the GPU. Xlib will always be slower.
The gallium llvmpipe driver should be quite a bit faster.
Just install LLVM first, then reconfigure/rebuild Mesa, set your
LD_LIBRARY_PATH to the lib/
Hi Brian,
You are right, setting MESA_GLX_DEPTH_BITS to 24 bit does not change
anything. So why Xlib has such poor performance to run following
application?
http://www.cgl.ucsf.edu/chimera/download.html
Are there any other things I can try to make Xlib driver performance
equals to DRI?
Thank yo
On 12/03/2013 03:12, Stéphane Marchesin wrote:
> It looks like this commit (and the other ones in the series) aren't
> present in the mesa git tree. It also looks like the last commit was
> pushed twice, and is present with the hash from the second time.
Last week, I pushed a bunch of wrong commit
On Tue, Mar 12, 2013 at 7:57 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> In cases where the vertex element size is smaller than the vertex buffer
> stride, the previous calculation could end up 1 too low. This would result
> in the GPU using index 0 instead of the maximum index for those e
From: Michel Dänzer
In cases where the vertex element size is smaller than the vertex buffer
stride, the previous calculation could end up 1 too low. This would result
in the GPU using index 0 instead of the maximum index for those elements,
which would be visible as intermittent distorted triang
On 12.03.2013 10:31, Christian König wrote:
> Am 12.03.2013 02:48, schrieb Marek Olšák:
>> On Mon, Mar 11, 2013 at 1:44 PM, Christian König
>> wrote:
>>> Hi everybody,
>>>
>>> this problem has been open for quite some time now, with a bunch of
>>> different
>>> opinions and sometimes even patches
Am 11.03.2013 22:03, schrieb Jose Fonseca:
- Original Message -
Am 11.03.2013 15:52, schrieb Jose Fonseca:
Christian,
I didn't comment on the previous threads, but the approach mentioned in
http://lists.freedesktop.org/archives/mesa-dev/2012-November/030476.html
seems sensible to me.
Am 12.03.2013 02:48, schrieb Marek Olšák:
On Mon, Mar 11, 2013 at 1:44 PM, Christian König
wrote:
Hi everybody,
this problem has been open for quite some time now, with a bunch of different
opinions and sometimes even patches floating on the list.
The solutions proposed or implemented so far
https://bugs.freedesktop.org/show_bug.cgi?id=62042
Michel Dänzer changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |xorg-t...@lists.x.org
https://bugs.freedesktop.org/show_bug.cgi?id=62202
meng changed:
What|Removed |Added
CC||mengmeng.m...@intel.com
--
You are receiving thi
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #12 from José Fonseca ---
It looks like Visual Studio 2012 (must be the final version, and not the
earlier preview) compiles the fd58718.zip test case correctly. I don't know if
it fully fixes all bit field usage in Mesa, or just thi
https://bugs.freedesktop.org/show_bug.cgi?id=62202
kobeqin changed:
What|Removed |Added
CC||gordon@intel.com,
|
https://bugs.freedesktop.org/show_bug.cgi?id=62202
kobeqin changed:
What|Removed |Added
CC||kobe@intel.com
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=62202
Priority: medium
Bug ID: 62202
Assignee: mesa-dev@lists.freedesktop.org
Summary: Mesa demo dest window of wincopy flickers while toggle
f/b buffer on software render
Severity
89 matches
Mail list logo
