On Wed, Jan 25, 2012 at 1:53 AM, Ian Romanick wrote:
> On 01/24/2012 04:39 PM, Marek Olšák wrote:
>>
>> It always had the same value as ctx->Extensions.EXT_framebuffer_sRGB.
>
>
> I'd be curious why Dave added this flag in the first place. It's... odd.
> In any case,
So would I, but I think I w
Color clamping should be enabled in glGetTexImage if texture dataType is
GL_UNSIGNED_NORMALIZED and format is GL_LUMINANCE or GL_LUMINANCE_ALPHA
Fixes 2 Intel oglconform test cases: pxconv-gettex and pxtrans-gettex
https://bugs.freedesktop.org/show_bug.cgi?id=40864
NOTE: This is a candidate for t
On Tue, Jan 24, 2012 at 1:09 PM, Eric Anholt wrote:
> You don't want to continue on when you've used something that is
> probably a typo of a real symbol, or maybe just using the wrong
> signature.
> ---
-Werror=implicit would help cover this from the caller side of things, too.
> configure.ac
On Tue, Jan 24, 2012 at 6:59 PM, Eric Anholt wrote:
> A pure swrast-allocated buffer gets an irb of NULL, so we segfaulted
> in the clear-accum test. Just look at the swrast renderbuffer pointer
> for handling swrast rbs.
> ---
> src/mesa/drivers/dri/intel/intel_fbo.c | 12 +++-
> 1 fi
On Thu, Jan 19, 2012 at 1:46 PM, Eric Anholt wrote:
> On Mon, 16 Jan 2012 18:50:44 -0500, nobled wrote:
>> Noticed this was missing when writing the "glapi: sort ARB extensions
>> by number" commit, which at least shows it was effective.
>> ---
>> .../glapi/gen/ARB_texture_compression_rgtc.xml
On Tue, Jan 17, 2012 at 6:10 PM, Brian Paul wrote:
> On 01/16/2012 04:45 PM, nobled wrote:
>>
>> glGetTexImage, for example, has no width/height/depth parameters.
>>
>> Also, copy some missing parameter info from the original versions
>> of certain functions over to their ARB_robustness counterpar
Please ignore that, I forgot to replace it. That said the rest has
been updated :)
Stéphane
2012/1/24 Stéphane Marchesin :
> I picked those draw changes from Jakob's branch. I discarded the first two
> commits (regresses glest) and the last one (i915g specific, works around a bug
> that was alre
From: Jakob Bornecrantz
In bad applications like ipers which does a lot of draw calls with
no state changes this helps to greatly reduce time spent in prepare.
In ipers around 7% of CPU was spent in various prepare functions,
after this commit no prepare function show on the profile.
This commit
From: Jakob Bornecrantz
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_pipe.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe.c
b/src/gallium/auxiliary/draw/draw_pipe.c
index f1b
From: Jakob Bornecrantz
Conflicts:
src/gallium/auxiliary/draw/draw_context.c
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_context.c |4
src/gallium/auxiliary/draw/draw_private.h |2 --
src/gallium/auxiliary/draw/draw_p
I picked those draw changes from Jakob's branch. I discarded the first two
commits (regresses glest) and the last one (i915g specific, works around a bug
that was already fixed properly in git). Gives me a ~10% perf improvement in
state-intensive apps like ipers on i915g.
Checked that the series d
On Tue, Jan 24, 2012 at 9:03 AM, Benjamin Franzke
wrote:
> A current incomplete framebuffer was incorrectly used as a
> st_framebuffer. When accessing st_framebuffer childs bad things happen:
> e.g. st_framebuffer::iface was used to check whether its an incomplete
> fb, instead we need to compare
On Tue, Jan 24, 2012 at 8:34 PM, Eric Anholt wrote:
> In the core, we always treat spans of int/uint data as uint, so this
> extract function was truncating storage of integer pixel data to a n
> int texture to (0, max_int) instead of (min_int, max_int). There is
> probably missing code for handl
On Tue, Jan 24, 2012 at 8:34 PM, Eric Anholt wrote:
> This cut and paste is pretty awful. I'm tempted to do a lot of this
> using preprocessor tricks for customizing the parameter type from a
> template function, but that's just a different sort of hideous.
>
> Fixes 8 Intel oglconform int-textur
On Tue, Jan 24, 2012 at 8:34 PM, Eric Anholt wrote:
> This was losing bits of precision. Fixes (with the previous commits):
> piglit EXT_texture_integer/getteximage-clamping
> piglit EXT_texture_integer/getteximage-clamping GL_ARB_texture_rg
> oglc advanced.mipmap.upload
>
> Regresses oglc negati
On Tue, Jan 24, 2012 at 9:09 PM, Marek Olšák wrote:
> The check for ctx->API was unnecessary, because OES extensions are not exposed
> in desktop GL.
>
> Also require renderbuffer support for ARB_texture_rgb10_a2ui,
> as per the spec.
>
> Tested by comparing old and new glxinfo with softpipe and r
On Tue, Jan 24, 2012 at 6:42 PM, Eric Anholt wrote:
> Noticed when handling a similar problem in EXT_framebuffer_multisample.
>
> From the EXT_framebuffer_object spec:
>
> Added to section 5.4, as part of the discussion of which commands
> are not compiled into display lists:
>
> "Certain
The check for ctx->API was unnecessary, because OES extensions are not exposed
in desktop GL.
Also require renderbuffer support for ARB_texture_rgb10_a2ui,
as per the spec.
Tested by comparing old and new glxinfo with softpipe and r600g.
v2: fix bugs
---
src/mesa/state_tracker/st_extensions.c |
On 01/24/2012 03:59 PM, Eric Anholt wrote:
A pure swrast-allocated buffer gets an irb of NULL, so we segfaulted
in the clear-accum test. Just look at the swrast renderbuffer pointer
for handling swrast rbs.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 12 +++-
1 files changed, 7 ins
On 01/24/2012 04:39 PM, Marek Olšák wrote:
It always had the same value as ctx->Extensions.EXT_framebuffer_sRGB.
I'd be curious why Dave added this flag in the first place. It's...
odd. In any case,
Reviewed-by: Ian Romanick
---
src/mesa/drivers/dri/intel/intel_context.c |1 -
sr
Please disregard this patch. I'll send a version 2.
Marek
On Wed, Jan 25, 2012 at 1:39 AM, Marek Olšák wrote:
> The check for ctx->API was unnecessary, because OES extensions are not exposed
> in desktop GL.
>
> Also require renderbuffer support for ARB_texture_rgb10_a2ui,
> as per the spec.
> -
In the core, we always treat spans of int/uint data as uint, so this
extract function was truncating storage of integer pixel data to a n
int texture to (0, max_int) instead of (min_int, max_int). There is
probably missing code for handling truncation on conversion between
pixel formats, still, bu
This cut and paste is pretty awful. I'm tempted to do a lot of this
using preprocessor tricks for customizing the parameter type from a
template function, but that's just a different sort of hideous.
Fixes 8 Intel oglconform int-textures cases.
NOTE: This is a candidate for the 8.0 branch.
v2: A
Mostly fixes piglit EXT_texture_integer/getteximage-clamping. The
remaining failure involves precision loss on storing of int32 texture
data (something I knew was an issue, but wasn't trying to test).
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/pack.c |8
1 files
This was losing bits of precision. Fixes (with the previous commits):
piglit EXT_texture_integer/getteximage-clamping
piglit EXT_texture_integer/getteximage-clamping GL_ARB_texture_rg
oglc advanced.mipmap.upload
Regresses oglc negative.typeFormatMismatch.teximage from fail to
abort, because it's
Fixes piglit EXT_texture_integer/fbo-blending.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index ed8cc01
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 29 +
1 files changed, 9 insertions(+), 20 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index 8e6eb91..6622131 100
Otherwise, when you asked for the _BaseFormat of an rb wrapping a
GL_RGB texture, you got GL_RGBA because that's what we were storing
the texture data as.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/intel/intel_fbo.c |2 +-
1 files changed, 1 insertions(+), 1 deleti
I'm going to want to go looking at it for an integer texture fix.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/i915/i830_vtbl.c |5 -
src/mesa/drivers/dri/i915/i915_vtbl.c |5 -
src/mesa/drivers/dri/i965/brw_wm.h|
With this, I'm a lot more convinced that EXT_texture_integer would
work for users. The clamping to 0 of negative integers on texstore
was particularly nasty. (note that clamping of big integers to small
integer formats in texstore is still broken).
___
Most of this function was just calling
intel_renderbuffer_update_wrapper(), which was called immediately
afterwards in the only caller.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 56 ++--
1 files changed, 3 insertions(+
The check for ctx->API was unnecessary, because OES extensions are not exposed
in desktop GL.
Also require renderbuffer support for ARB_texture_rgb10_a2ui,
as per the spec.
---
src/mesa/state_tracker/st_extensions.c | 355 +---
1 files changed, 148 insertions(+), 207
It always had the same value as ctx->Extensions.EXT_framebuffer_sRGB.
---
src/mesa/drivers/dri/intel/intel_context.c |1 -
src/mesa/main/fbobject.c |2 +-
src/mesa/main/framebuffer.c|2 +-
src/mesa/main/mtypes.h |3 ---
src/mesa
This change is not exactly equivalent (sometimes we checked for non-zero,
sometimes if >0 or >1), but the behavior shouldn't change, because all drivers
report 0 for unsupported CAPs.
Exposing CAP_STREAM_OUTPUT_PAUSE_RESUME without CAP_MAX_STREAM_OUTPUT_BUFFERS
is a driver bug and st/mesa does no
---
src/gallium/docs/source/screen.rst |3 ++
src/gallium/drivers/softpipe/sp_screen.c |2 +
src/gallium/include/pipe/p_defines.h |3 +-
src/mesa/state_tracker/st_extensions.c | 49 +-
4 files changed, 35 insertions(+), 22 deletions(-)
diff --
The glsl_{lexer.lpp,parser.ypp} symlinks allow automake to figure out
dependency information, since .ll generates a .cc file, and .lpp
generates a .cpp. They were originally named .lpp/.ypp, but were changed
to work around scons.
---
Future TODO: use src/glsl/Makefile.sources. It'll have to be refa
Needed for automake. Using AC_PROG_PATH(bison/flex) causes automake to
fail to build .y and .l files.
It is up to the builder to use bison/flex instead of yacc/lex.
---
configs/autoconf.in |4 ++--
configure.ac| 13 -
2 files changed, 10 insertions(+), 7 deletions(-)
di
now that libtool provides them.
---
configure.ac | 32 +---
1 files changed, 1 insertions(+), 31 deletions(-)
diff --git a/configure.ac b/configure.ac
index 18a40fc..71933e4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -273,39 +273,9 @@ if test "x$enable_64bit" =
A pure swrast-allocated buffer gets an irb of NULL, so we segfaulted
in the clear-accum test. Just look at the swrast renderbuffer pointer
for handling swrast rbs.
---
src/mesa/drivers/dri/intel/intel_fbo.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/me
Noticed when handling a similar problem in EXT_framebuffer_multisample.
>From the EXT_framebuffer_object spec:
Added to section 5.4, as part of the discussion of which commands
are not compiled into display lists:
"Certain commands, when called while compiling a display list, are
>From the extension spec:
Added to section 5.4, as part of the discussion of which commands
are not compiled into display lists:
"Certain commands, when called while compiling a display list, are
not compiled into the display list but are executed immediately.
These are: ...,
Hello,
I'm working on a server-based VTK application that renders snapshots of
3D (STL meshes). We're working on 64-bit Fedora 15 but I can try out
another platform if necessary. The application works fine with an X11
DISPLAY using hardware GL but crashes when we try to use Mesa only. I
decid
https://bugs.freedesktop.org/show_bug.cgi?id=44757
--- Comment #3 from almos 2012-01-24 15:10:12 PST ---
I tried this with fglrx on my barts pro, and the balls are rendered correctly.
On a geforce 8600m gs (nv86) with mesa 7.11 there is the one bright triangle.
--
Configure bugmail: https://bug
On 01/24/2012 08:10 AM, Matt Turner wrote:
On Tue, Jan 24, 2012 at 10:12 AM, Brian Paul wrote:
On Mon, Jan 23, 2012 at 12:48 PM, Matt Turner wrote:
On Mon, Jan 23, 2012 at 9:28 AM, Jakob Bornecrantz wrote:
- Original Message -
If you're building mesa, you know what drivers you want
On 01/24/2012 12:35 PM, Paul Berry wrote:
Previously, max_vs_entries was set to 128 for GT1, and 256 for GT2,
based on the PRM (see Vol2, part1, p28). However, Bspec section 1.6.5
indicates that the maximum number of VS entries is 256 for GT1.
No piglit regressions on GT1.
---
src/mesa/driver
On Tue, Jan 24, 2012 at 2:57 PM, Andy Furniss wrote:
> make[5]: Entering directory
> `/home/andy/Src/Mesa-git/mesa/src/mesa/drivers/dri/swrast'
> make[5]: *** No rule to make target `swrast_span.c', needed by
> `swrast_span.lo'. Stop.
> ___
> mesa-dev m
https://bugs.freedesktop.org/show_bug.cgi?id=44928
--- Comment #10 from Matt Turner 2012-01-24 14:01:46 UTC
---
Created attachment 56112
--> https://bugs.freedesktop.org/attachment.cgi?id=56112
patch2
maybe a better fix... if it works.
--
Configure bugmail: https://bugs.freedesktop.org/user
make[5]: Entering directory
`/home/andy/Src/Mesa-git/mesa/src/mesa/drivers/dri/swrast'
make[5]: *** No rule to make target `swrast_span.c', needed by
`swrast_span.lo'. Stop.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedes
Linker generates location_tree * instead of single ints to store
varying locations, this patch makes i965 VS and FS code generator
able to produce output register access accordingly.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 +++-
src/mesa/drivers/dri/i965/brw_vec4.h |
This commit adds a basic packing function for varyings.
It merges vec3 with float and vec2 with vec2 when possible, but does
neither try to merge vec2 with floats nor floats with floats.
By default the packing does not occur as this function is used mostly
for debug purpose only.
---
src/glsl/link
This patch modify the assign_varying_locations function so that it
populates ir_variable::complete_location instead of
ir_variable::location. The final layout remains unchanged though.
Tfb_declaration is also updated to handles the use of the new
field.
---
src/glsl/builtin_variables.cpp |
This patch adds a location_tree * field to ir_variable class.
Such field is aimed at replacing the location field in 2 cases :
- If the variable is a varying,
- If the variable is stored in an UBO.
In the later case, the UBO spec has precise requirements on the storage
layout of every UBO variabl
Ir_variable::location field is currently represented by a single int.
Datas of composite type (arrays, records) is assumed to be stored in a
linear fashion from this base location. In some situation this assumption
is not optimal : struct fields cannot be stored in a custom order and a
single loca
On 01/24/2012 08:10 AM, Matt Turner wrote:
On Tue, Jan 24, 2012 at 10:12 AM, Brian Paul wrote:
On Mon, Jan 23, 2012 at 12:48 PM, Matt Turner wrote:
On Mon, Jan 23, 2012 at 9:28 AM, Jakob Bornecrantz wrote:
- Original Message -
If you're building mesa, you know what drivers you want
https://bugs.freedesktop.org/show_bug.cgi?id=44928
--- Comment #9 from Matt Turner 2012-01-24 12:48:04 PST ---
Created attachment 56111
--> https://bugs.freedesktop.org/attachment.cgi?id=56111
patch
The attached patch fixes the problem (I've gotten confirmation from 2 people)
but I didn't real
Previously, max_vs_entries was set to 128 for GT1, and 256 for GT2,
based on the PRM (see Vol2, part1, p28). However, Bspec section 1.6.5
indicates that the maximum number of VS entries is 256 for GT1.
No piglit regressions on GT1.
---
src/mesa/drivers/dri/i965/brw_context.c |2 +-
1 files c
On Tue, Jan 24, 2012 at 12:40 PM, Kenneth Graunke wrote:
> On 01/24/2012 10:08 AM, Brian Paul wrote:
>>
>> I've been seeing this error from linker.cpp for a few days now:
>>
>> linker.cpp: In function ‘gl_shader* link_intrastage_shaders(void*,
>> gl_context*, gl_shader_program*, gl_shader**, unsig
On 01/24/2012 10:08 AM, Brian Paul wrote:
I've been seeing this error from linker.cpp for a few days now:
linker.cpp: In function ‘gl_shader* link_intrastage_shaders(void*,
gl_context*, gl_shader_program*, gl_shader**, unsigned int)’:
linker.cpp:1008: warning: ‘link_intrastage_shaders(void*, gl_
Even though it should be safe to use them for one frame, better be sure.
Suggested by Michael Dänzer.
NOTE: This is a candidate for the 8.0 stable branch.
Signed-off-by: Lauri Kasanen
---
src/gallium/auxiliary/postprocess/pp_run.c | 10 ++
1 files changed, 10 insertions(+), 0 deletion
This prevents a possible lapse of the depth buffer - the situation where
the app and pp have different depth buffers.
NOTE: This is a candidate for the 8.0 stable branch.
Signed-off-by: Lauri Kasanen
---
src/gallium/auxiliary/postprocess/postprocess.h|3 +--
src/gallium/auxiliary/postpr
On 01/24/2012 10:08 AM, Brian Paul wrote:
I've been seeing this error from linker.cpp for a few days now:
linker.cpp: In function ‘gl_shader* link_intrastage_shaders(void*,
gl_context*, gl_shader_program*, gl_shader**, unsigned int)’:
linker.cpp:1008: warning: ‘link_intrastage_shaders(void*, gl_
Hi all
The first patch fixes a bug where the depth filters may have used an old depth
buffer.
The second adds safeguards suggested by Michael Dänzer.
Could they both be applied to the stable 8.0 tree too?
--
- Lauri
___
mesa-dev mailing list
mesa-dev
Signed-off-by: Vadim Girlin
---
Tested on evergreen, fixes interpolation tests
Two tesselation tests turned to "WARN" - "tessellation polygon flat_first" and
"tessellation quads flat_first", I think this patch uncovered some other
problem.
src/gallium/drivers/r600/evergreen_state.c | 17 +
This mostly existed to cause a build error when you typoed a function
name, didn't see the warning in the Mesa build spew, then some time
later tried to use your driver and it failed in a strange way. Now
that we enable errors on missing prototypes, the problem that this was
fixing should be gone.
On 01/24/2012 10:09 AM, Eric Anholt wrote:
You don't want to continue on when you've used something that is
probably a typo of a real symbol, or maybe just using the wrong
signature.
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/confi
On Mon, 23 Jan 2012 16:25:23 -0800, Paul Berry wrote:
> When storing data in a buffer of type DYNAMIC_DRAW, we don't create a
> drm_intel_bo for it; instead we store the data in system memory and
> defer allocation of the GPU buffer until it is needed. Therefore, in
> brw_update_sol_surface(), we
You don't want to continue on when you've used something that is
probably a typo of a real symbol, or maybe just using the wrong
signature.
---
configure.ac |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 18a40fc..74e5fe4 100644
--- a/con
I've been seeing this error from linker.cpp for a few days now:
linker.cpp: In function ‘gl_shader* link_intrastage_shaders(void*,
gl_context*, gl_shader_program*, gl_shader**, unsigned int)’:
linker.cpp:1008: warning: ‘link_intrastage_shaders(void*, gl_context*,
gl_shader_program*, gl_shader**, u
On Tue, Jan 24, 2012 at 10:42 AM, Matt Turner wrote:
> In the meantime, I think we should just revert adefee50 since
> shared-glapi causes a lot of problems with --enable-xlib-glx. I don't
> want to hold up your renderbuffer-cleanups-v2 branch any more.
Reverted. If/when I get the kinks worked ou
Conflicts:
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 14 +++-
src/mesa/drivers/dri/i965/brw_vec4.h |3 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 106 +--
3 files changed, 111 insertions
---
src/glsl/linker.cpp | 133 +++
1 files changed, 133 insertions(+), 0 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 9c65f92..9c2fad5 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1839,6 +1839,139 @@ d
---
src/glsl/builtin_variables.cpp |2 +
src/glsl/ir_set_program_inouts.cpp | 13 -
src/glsl/linker.cpp| 115 +++-
3 files changed, 112 insertions(+), 18 deletions(-)
diff --git a/src/glsl/builtin_variables.cpp b/src/glsl/builtin_vari
---
src/glsl/ir.cpp |2 ++
src/glsl/ir.h | 12 +++-
src/glsl/ir_clone.cpp |4
3 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/src/glsl/ir.cpp b/src/glsl/ir.cpp
index a5eca5a..ce89b1b 100644
--- a/src/glsl/ir.cpp
+++ b/src/glsl/ir.cpp
@@ -26,6 +2
GL_ARB_uniform_buffer_object spec defines standard layout rules to define how
data
are packed in a uniform buffer object, using offset and stride. A single
ir_variable::location is not enough to hold every possible case and thus we
defined a
new type whose structure mirror the one of associated g
On Tue, Jan 24, 2012 at 10:12 AM, Brian Paul wrote:
> On Mon, Jan 23, 2012 at 12:48 PM, Matt Turner wrote:
>> On Mon, Jan 23, 2012 at 9:28 AM, Jakob Bornecrantz wrote:
>>> - Original Message -
If you're building mesa, you know what drivers you want.
>>>
>>> NACK, the default should
On Tue, Jan 24, 2012 at 10:33 AM, Matt Turner wrote:
> On Mon, Jan 23, 2012 at 8:59 PM, Brian Paul wrote:
>> On Mon, Jan 23, 2012 at 6:41 PM, Brian Paul wrote:
>>> On Mon, Jan 23, 2012 at 12:48 PM, Matt Turner wrote:
-fvisibility=hidden was preventing them from being exported, which
c
On Mon, Jan 23, 2012 at 8:59 PM, Brian Paul wrote:
> On Mon, Jan 23, 2012 at 6:41 PM, Brian Paul wrote:
>> On Mon, Jan 23, 2012 at 12:48 PM, Matt Turner wrote:
>>> -fvisibility=hidden was preventing them from being exported, which
>>> combined with shared-glapi was causing undefined symbol error
-fvisibility=hidden was preventing them from being exported, which
combined with shared-glapi was causing undefined symbol errors at
runtime.
We don't want to make these functions part of the ABI, and given
how simple they are, we simply inline them.
---
src/mapi/mapi/sources.mak |3 +-
src/m
On Mon, Jan 23, 2012 at 12:48 PM, Matt Turner wrote:
> On Mon, Jan 23, 2012 at 9:28 AM, Jakob Bornecrantz wrote:
>> - Original Message -
>>> If you're building mesa, you know what drivers you want.
>>
>> NACK, the default should be build as much as possible.
>
> We don't build OpenVG, OSM
On Mon, Jan 23, 2012 at 6:19 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> This is a hack to work around drivers such as i965 that:
>
> - Set _MaintainTexEnvProgram to generate GLSL IR for
> fixed-function fragment processing.
> - Don't call _mesa_ir_link_shader to generate Mesa IR
On Mon, Jan 23, 2012 at 6:23 PM, Ian Romanick wrote:
> From: Ian Romanick
>
> There are more differences between Apple and ARB than just requiring
> that all arrays be stored in VBOs. Additional uses will be added in
> following commits.
>
> Also, set the flag at Bind time instead of Gen time.
On Tue, Jan 24, 2012 at 8:33 AM, STEVEN WARD wrote:
> Hi to all,
> I used to compile the nvfx driver for my NV40,but I don't that
> Graphics Card anymore.
>
> Anyway, I'm using a NV28 Quatro with 128Mb of memory and I compile
> the nouveau_vieux_dri.so driver for that card instead.
>
On Die, 2012-01-24 at 13:07 +0100, Christian König wrote:
> On 24.01.2012 11:39, Michel Dänzer wrote:
> > On Mon, 2012-01-23 at 18:06 +0100, Fabio Pedretti wrote:
> >>> Fabio Pedretti (23/01/2012):
> >>>
> --- mesa-debian-originale/debian//control2012-01-23
> 13:39:09.471085849
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_asm.c |6 +++---
src/gallium/drivers/r600/r600_opcodes.h | 10 +-
src/gallium/drivers/r600/r600_shader.c |6 +++---
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_a
A current incomplete framebuffer was incorrectly used as a
st_framebuffer. When accessing st_framebuffer childs bad things happen:
e.g. st_framebuffer::iface was used to check whether its an incomplete
fb, instead we need to compare st_framebuffer::Base against
mesa_get_incomplete_framebuffer.
Bug
Hi to all, I used to compile the nvfx driver for my NV40,but I
don't that Graphics Card anymore.
Anyway, I'm using a NV28 Quatro with 128Mb of memory and I compile the
nouveau_vieux_dri.so driver for that card instead.
I use the DRM,Mesa,and the nouveau driver code all compiled from
IIUC, patch 3-6 should be squashed, otherwise regressions will happen when
checking out the tree at commits of patch 3, 4 or 5.
The comments of these patches (e.g., why it's necessary a full flush when prim
changes, future improvements, etc) should be next to the code itself for future
referenc
Looking at the source code, DRAW_FLUSH_* flags were clearly intended as a
bitmask. Maybe flags combinations are never used, but for future proof sake,
bitwise arithmetic should be used for draw flush flags, instead of == or !=, in
this and other patches of this series.
Jose
- Original Mes
Fixing a circular build dependency.
NOTE: This is a candidate for the 8.0 branch.
Signed-off-by: Christian König
---
configure.ac |2 +-
src/gallium/state_trackers/xorg/xvmc/subpicture.c |3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff
Andy Furniss ukfsn.org> writes:
>
> Brian Paul wrote:
> > On Thu, Mar 3, 2011 at 3:44 AM, Andy Furniss ukfsn.org> wrote:
> >> Andy Furniss wrote:
> >>>
> >>> I am getting a build fail today -
> >>>
> >>> mklib: Making Linux stati
Hi Brain Paul,
I am trying to learn how OPENGL works...
Ca
On 24.01.2012 11:39, Michel Dänzer wrote:
On Mon, 2012-01-23 at 18:06 +0100, Fabio Pedretti wrote:
Fabio Pedretti (23/01/2012):
--- mesa-debian-originale/debian//control 2012-01-23 13:39:09.471085849
+0100
+++ mesa-debian-test/debian//control2012-01-21 20:29:38.350117156 +0100
@@
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_asm.c | 92 ++-
1 files changed, 80 insertions(+), 12 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index a888704..8fce5a1 100644
--- a/src/gall
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_opcodes.h | 90 +--
1 files changed, 85 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_opcodes.h
b/src/gallium/drivers/r600/r600_opcodes.h
index a64df59..e8582cc 100644
--- a/sr
On Mon, 2012-01-23 at 18:06 +0100, Fabio Pedretti wrote:
> >Fabio Pedretti (23/01/2012):
> >
> >> --- mesa-debian-originale/debian//control 2012-01-23 13:39:09.471085849
> +0100
> >> +++ mesa-debian-test/debian//control 2012-01-21 20:29:38.350117156
> >> +0100
> >> @@ -32,6 +32,9 @@ Buil
- Original Message -
> On Tue, Jan 24, 2012 at 2:41 AM, Brian Paul
> wrote:
> > On Mon, Jan 23, 2012 at 12:48 PM, Matt Turner
> > wrote:
> >> -fvisibility=hidden was preventing them from being exported, which
> >> combined with shared-glapi was causing undefined symbol errors at
> >> ru
From: Jakob Bornecrantz
In certain conditions when going from different primitive requires
us to flush and validate the different stages. Like smoth lines being
active but first drawing with triangles and then drawing lines.
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
sr
From: Jakob Bornecrantz
We could improve this by only flushing the frontend and the fetch part
of the middle. This would avoid recalculating the emit keys.
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_context.c |3 +++
1 files changed,
From: Jakob Bornecrantz
This could be improved so only the frontend is flushed since it
convertes all indecies to ushots and the fetch part of the middle
always perpares both linear and indexed.
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_
From: Jakob Bornecrantz
In bad applications like ipers which does a lot of draw calls with
no state changes this helps to greatly reduce time spent in prepare.
In ipers around 7% of CPU was spent in various prepare functions
after this commit no prepare function show on the profile.
This commit
From: Jakob Bornecrantz
Reviewed-by: Stéphane Marchesin
Tested-by: Stéphane Marchesin
---
src/gallium/auxiliary/draw/draw_pipe.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_pipe.c
b/src/gallium/auxiliary/draw/draw_pipe.c
index f1b
1 - 100 of 102 matches
Mail list logo
