On 01/20/2012 04:12 AM, Christoph Bumiller wrote:
On 20.01.2012 12:45, Henri Verbeet wrote:
On 20 January 2012 03:24, Eric Anholt wrote:
So is it also allowed to blit from S8Z24 to Z24S8 ? Could we also allow
to blit from RGBA8 to BGRA8 then, please ?
That's already allowed.
Yeah, but not f
From: Ian Romanick
When ARB VAOs are used, glPopClientAttrib does not resurrect a deleted
VAO or VBO. This difference between the two spec is, unfortunately,
not very well spelled out in the specs.
Fixes oglc vao(advanced.pushPop.deleteVAO) and
vao(advanced.pushPop.deleteVBO) tests.
NOTE: This
From: Ian Romanick
There are more differences between Apple and ARB than just the Gen
requirement.
NOTE: This is a candidate for release branches.
Signed-off-by: Ian Romanick
---
src/mesa/main/arrayobj.c |1 +
src/mesa/main/mtypes.h |5 +
2 files changed, 6 insertions(+), 0 dele
On Fri, Jan 20, 2012 at 8:40 PM, Matt Turner wrote:
> Yep, this is broken by adefee50, but it's not immediately clear how.
Whoops, sorry. I take that back. I wasn't building with
--enable-shared-glapi on the earlier commits.
When building with --enable-xlib-glx --enable-shared-glapi we have the
On Fri, Jan 20, 2012 at 7:58 PM, Matt Turner wrote:
> On Fri, Jan 20, 2012 at 6:12 PM, Brian Paul wrote:
>> Hi Matt,
>>
>> I'm not sure if your recent changes are responsible for this. I did
>> "./configure --enable-xlib-glx ; make"
>>
>> The build appears to complete cleanly but I can't run any
On Fri, Jan 20, 2012 at 6:12 PM, Brian Paul wrote:
> Hi Matt,
>
> I'm not sure if your recent changes are responsible for this. I did
> "./configure --enable-xlib-glx ; make"
>
> The build appears to complete cleanly but I can't run anything:
>
> $ glxinfo
> name of display: :0.0
> glxinfo: symbo
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/r600_asm.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index b8d43c0..107c864 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src
On Fri, 20 Jan 2012 16:09:51 -0800, "Ian Romanick" wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44818
Sensible workaround for now.
Reviewed-by: Eric Anholt
pgpVubsVauqEh.pgp
Description: PGP signature
_
On Sat, Jan 21, 2012 at 1:30 AM, Alexander von Gluck
wrote:
> Quick question, I noticed that Mesa and gallium both implement rtasm...
>
> src/gallium/auxiliary/rtasm/rtasm_x86sse.c: p->need_emms = 1;
> src/gallium/auxiliary/rtasm/rtasm_x86sse.c: assert(p->need_emms);
> src/gallium/auxiliary/rt
Quick question, I noticed that Mesa and gallium both implement rtasm...
src/gallium/auxiliary/rtasm/rtasm_x86sse.c: p->need_emms = 1;
src/gallium/auxiliary/rtasm/rtasm_x86sse.c: assert(p->need_emms);
src/gallium/auxiliary/rtasm/rtasm_x86sse.c: p->need_emms = 0;
src/gallium/auxiliary/rtasm/r
On 01/20/2012 04:39 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.
How about having uint, ushort, ubyte functions and
On 01/20/2012 04:39 PM, Eric Anholt wrote:
This is a step toward fixing Intel oglconform's
int-textures advanced.fbo.rtt.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/texgetimage.c | 118 +--
1 files changed, 80 insertions(+), 38 del
On 01/20/2012 04:39 PM, Eric Anholt wrote:
Similarly to how we handle this in texstore, we have to remap height
to depth so that we MapTextureImage each image layer individually.
Fixes Intel oglconform's int-textures advanced.fbo.rtt
NOTE: This is a candidate for the 8.0 branch.
Reviewed-by:
On 01/20/2012 04:39 PM, Eric Anholt wrote:
This fixes intel oglconform's int-textures basic.getteximage and
basic.clamping.uint, and improves many aborts due to memory corruption
into being just rendering failures. No piglit tests for it currently.
NOTE: This is a candidate for the 8.0 branch.
On 01/20/2012 04:39 PM, Eric Anholt wrote:
This code is unprepared for handling integer (particularly, the
baseFormat of the TexFormat comes out as GL_RGBA, not GL_RGBA_INTEGER,
so the direct call of Driver.ReadPixels crashes due to the int vs
non-int error checking not having happened). I'm fra
On 01/20/2012 04:39 PM, Eric Anholt wrote:
This is part of fixing Intel oglconform
negative.typeFormatMismatch.copyteximage.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/image.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
Reviewed-by: Brian Pau
On 01/20/2012 04:39 PM, Eric Anholt wrote:
Fixes Intel oglconform negative.typeFormatMismatch.copyteximage.
NOTE: This is a candidate for the 8.0 branch.
---
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://l
On 20 January 2012 16:12, Kenneth Graunke wrote:
> On 01/19/2012 06:28 PM, Paul Berry wrote:
>
>> i965 processes assignments of whole structures using
>> vec4_visitor::emit_block_move, a recursive function which visits each
>> element of a structure or array (to arbitrary nesting depth) and
>> co
On 01/19/2012 06:28 PM, Paul Berry wrote:
i965 processes assignments of whole structures using
vec4_visitor::emit_block_move, a recursive function which visits each
element of a structure or array (to arbitrary nesting depth) and
copies it from the source to the destination. Then it increments t
From: Ian Romanick
Signed-off-by: Ian Romanick
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44818
---
src/mesa/drivers/common/meta.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index dca
Similarly to how we handle this in texstore, we have to remap height
to depth so that we MapTextureImage each image layer individually.
Fixes Intel oglconform's int-textures advanced.fbo.rtt
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/texgetimage.c |9 +++--
1 files c
This code is unprepared for handling integer (particularly, the
baseFormat of the TexFormat comes out as GL_RGBA, not GL_RGBA_INTEGER,
so the direct call of Driver.ReadPixels crashes due to the int vs
non-int error checking not having happened). I'm frankly tempted to
convert this code to MapRende
We can't really do this because we don't have support for forcing the
alpha to 1 when it gets used for other purposes (readpixels,
texturing).
Fixes the last failure in EXT_texture_integer/fbo-blending
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/i965/brw_wm_surface_sta
This is part of fixing Intel oglconform
negative.typeFormatMismatch.copyteximage.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/image.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/image.c b/src/mesa/main/image.c
index b37cd7
Fixes Intel oglconform negative.typeFormatMismatch.copyteximage.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/teximage.c | 39 +++
1 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/texi
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
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 932405e..b3c631f 100
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|
Before, we were mapping them to RGBA integer textures using
ChooseTexFormat, but core Mesa doesn't handle enforcing texture
swizzling to get the right channels out, and core Mesa doesn't remap
channels on the way out of ReadPixels -- it just does format_unpack to
RGBA and then packs RGBA to the use
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(+
This doesn't result in correct rendering -- GL requires that logic ops
work, while the hardwaer specs say it doesn't do them. I'm not sure
how we would want to handle this.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/i965/gen6_cc.c |9 +++--
1 files changed, 7
Right now we claim to not support these MESA_FORMATs, so the texture
gets promoted to RGBA integer. This almost works, except that there's
nothing in Mesa to make sure that the channels get replaced with
appropriate values when read by ReadPixels or texturing. So, the
driver really needs to provi
Fixes GPU hangs and some rendering failures in piglit
EXT_texture_integer/fbo-blending
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/i965/gen6_cc.c | 29 +++--
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i
Once these are mapped to R/RG, they would show up as renderable thanks
to the default logic above, even though we don't have fragment shader
output swizzling for them.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 32 ++
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 4 Intel oglconform int-textures cases.
NOTE: This is a candidate for the 8.0 branch.
---
This is a step toward fixing Intel oglconform's
int-textures advanced.fbo.rtt.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/texgetimage.c | 118 +--
1 files changed, 80 insertions(+), 38 deletions(-)
diff --git a/src/mesa/main/texgetima
This fixes intel oglconform's int-textures basic.getteximage and
basic.clamping.uint, and improves many aborts due to memory corruption
into being just rendering failures. No piglit tests for it currently.
NOTE: This is a candidate for the 8.0 branch.
---
src/mesa/main/pack.c | 119
The pixel pack stuff is a bit of a WIP. I think it could probably be
reused for the float pixel pack, with just a bit more massaging.
Remaining known problems with GL_EXT_texture_integer:
- meta copytexsubimage on integer fails.
- mipmap gen fails
- possible filtering occuring on i965 when it sho
Hi Matt,
I'm not sure if your recent changes are responsible for this. I did
"./configure --enable-xlib-glx ; make"
The build appears to complete cleanly but I can't run anything:
$ glxinfo
name of display: :0.0
glxinfo: symbol lookup error: /home/brian/mesa/lib/libGL.so.1:
undefined symbol
---
tests/all.tests |6 +
tests/spec/ext_texture_integer/CMakeLists.gl.txt |1 +
tests/spec/ext_texture_integer/fbo-blending.c| 329 ++
3 files changed, 336 insertions(+), 0 deletions(-)
create mode 100644 tests/spec/ext_texture_in
---
.../fbo-integer-precision-clear.c | 17 -
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/tests/spec/ext_texture_integer/fbo-integer-precision-clear.c
b/tests/spec/ext_texture_integer/fbo-integer-precision-clear.c
index ad6d8f7..5a7ba9d 10064
---
tests/util/piglit-util.c | 25 +
tests/util/piglit-util.h |1 +
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/tests/util/piglit-util.c b/tests/util/piglit-util.c
index 9c4f0a5..d834487 100644
--- a/tests/util/piglit-util.c
+++ b/tests/util/piglit
Clip planes are uploaded as a constant buffer and used by the vertex
shader to produce corresponding clip distances for hw clipping.
Signed-off-by: Vadim Girlin
---
v2: don't duplicate as PARAM the clipdist outputs that were generated
for clipvertex, they could break spi setup on r6xx/r7xx
src
It didn't actually do anything except modify the GL_RENDERER string.
---
configs/linux-dri-ppc |3 -
configure.ac |5 --
src/mesa/SConscript|8 ---
src/mesa/main/cpuinfo.c| 18 ---
src/mesa/main/cpuinfo.h|
On Sat, Jan 14, 2012 at 11:16 AM, Matt Turner wrote:
> now that libtool provides them.
>
> Signed-off-by: Matt Turner
> ---
Ping. This is sensible, right?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/lis
On Fri, 20 Jan 2012 04:16:00 -0800, Kenneth Graunke
wrote:
> While reading through the simulator, I found some interesting code that
> looks like it checks the sampler default color pointer against the bound
> set in STATE_BASE_ADDRESS. On failure, it appears to program it to a
> bogus but in-bo
On Fri, 20 Jan 2012 11:06:56 +, Dave Airlie wrote:
> On Wed, Jan 11, 2012 at 5:40 PM, Paul Berry wrote:
> > On 10 January 2012 13:38, Christoph Bumiller
> > wrote:
> >>
> >> On 01/10/2012 10:09 PM, Dave Airlie wrote:
> >> > On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt wrote:
> >> >> On Tue,
On Fri, 20 Jan 2012 10:56:09 -0800, Ian Romanick wrote:
> On 01/17/2012 02:58 PM, Brian Paul wrote:
> > On 01/16/2012 08:30 PM, Brian Paul wrote:
> >> On Mon, Jan 16, 2012 at 4:31 PM, Ian Romanick wrote:
> >>> On 01/16/2012 01:30 PM, Brian Paul wrote:
>
>
> The renderbuffer-cleanups
On 01/20/2012 11:56 AM, Ian Romanick wrote:
On 01/17/2012 02:58 PM, Brian Paul wrote:
On 01/16/2012 08:30 PM, Brian Paul wrote:
On Mon, Jan 16, 2012 at 4:31 PM, Ian Romanick
wrote:
On 01/16/2012 01:30 PM, Brian Paul wrote:
The renderbuffer-cleanups-v2 branch removes all the old swrast
GetRo
On Fri, 20 Jan 2012 13:00:10 +, Jonathan Coome
wrote:
> On 19/01/2012 23:48, Yuanhan Liu wrote:
> Is there any need for GEN6_SF_POINT_SPRITE_UPPERLEFT? It's basically 0,
> so the | operation with dw1 won't have any effect, and you could remove
> the else clauses. And if you wanted to clear th
On Thu, 19 Jan 2012 18:28:50 -0800, Paul Berry wrote:
> i965 processes assignments of whole structures using
> vec4_visitor::emit_block_move, a recursive function which visits each
> element of a structure or array (to arbitrary nesting depth) and
> copies it from the source to the destination. T
On Tue, 17 Jan 2012 15:15:21 -0500, Matt Turner wrote:
> On Sat, Jan 14, 2012 at 11:15 AM, Matt Turner wrote:
> > There don't seem to be any reasons to prefer unshared-dricore,
> > and clang and icc both support rpath.
> >
> > Signed-off-by: Matt Turner
>
> Okay to commit? Anyone tested it?
Te
Add support for multiple kcache banks (constant buffers).
Lock the required lines only.
Allow up to 4 kcache line sets in the alu clause by using ALU_EXTENDED on eg+.
Signed-off-by: Vadim Girlin
---
v2: fix a bug in the r600_bytecode_assign_kcache_banks
src/gallium/drivers/r600/eg_asm.c |
On 01/17/2012 02:58 PM, Brian Paul wrote:
On 01/16/2012 08:30 PM, Brian Paul wrote:
On Mon, Jan 16, 2012 at 4:31 PM, Ian Romanick wrote:
On 01/16/2012 01:30 PM, Brian Paul wrote:
The renderbuffer-cleanups-v2 branch removes all the old swrast
GetRow/PutRow stuff. All swrast rendering is now d
Clip planes are uploaded as a constant buffer and used by the vertex
shader to produce corresponding clip distances for hw clipping.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/evergreen_hw_context.c |8 +
src/gallium/drivers/r600/evergreen_state.c |8 +
src/gallium/dri
Add support for multiple kcache banks (constant buffers).
Lock the required lines only.
Allow up to 4 kcache line sets in the alu clause by using ALU_EXTENDED on eg+.
Signed-off-by: Vadim Girlin
---
src/gallium/drivers/r600/eg_asm.c | 17 +++
src/gallium/drivers/r600/eg_sq.h| 49 ++
On Jan 20, 2012 9:07 PM, "Jonathan Coome" wrote:
>
> On 19/01/2012 23:48, Yuanhan Liu wrote:
> > When rendering to FBO, rendering is inverted. At the same time, we would
> > also make sure the point sprite origin is inverted. Or, we will get an
> > inverted result correspoinding to rendering to th
Thanks for the patch.
Reviewed-by: Yuanhan Liu
On Jan 20, 2012 9:40 PM, "Kenneth Graunke" wrote:
> While reading through the simulator, I found some interesting code that
> looks like it checks the sampler default color pointer against the bound
> set in STATE_BASE_ADDRESS. On failure, it appe
On 01/20/2012 05:12 AM, Christoph Bumiller wrote:
On 20.01.2012 12:45, Henri Verbeet wrote:
On 20 January 2012 03:24, Eric Anholt wrote:
So is it also allowed to blit from S8Z24 to Z24S8 ? Could we also allow
to blit from RGBA8 to BGRA8 then, please ?
That's already allowed.
Yeah, but not f
https://bugs.freedesktop.org/show_bug.cgi?id=40920
José Fonseca changed:
What|Removed |Added
CC||z...@kde.org
--
Configure bugmail: https
https://bugs.freedesktop.org/show_bug.cgi?id=40920
José Fonseca changed:
What|Removed |Added
Attachment #51473|0 |1
is obsolete|
On 01/20/2012 03:06 AM, Dave Airlie wrote:
On Wed, Jan 11, 2012 at 5:40 PM, Paul Berry wrote:
On 10 January 2012 13:38, Christoph Bumiller
wrote:
On 01/10/2012 10:09 PM, Dave Airlie wrote:
On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt wrote:
On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie
w
https://bugs.freedesktop.org/show_bug.cgi?id=40920
José Fonseca changed:
What|Removed |Added
CC||bri...@vmware.com,
|
While reading through the simulator, I found some interesting code that
looks like it checks the sampler default color pointer against the bound
set in STATE_BASE_ADDRESS. On failure, it appears to program it to the
base address itself.
So I decided to try programming a legitimate bound, and lo a
On 19/01/2012 23:48, Yuanhan Liu wrote:
> When rendering to FBO, rendering is inverted. At the same time, we would
> also make sure the point sprite origin is inverted. Or, we will get an
> inverted result correspoinding to rendering to the default winsys FBO.
>
> Bugzilla: https://bugs.freedeskto
While reading through the simulator, I found some interesting code that
looks like it checks the sampler default color pointer against the bound
set in STATE_BASE_ADDRESS. On failure, it appears to program it to a
bogus but in-bound value.
So I decided to try programming a legitimate bound, and l
On 20.01.2012 12:45, Henri Verbeet wrote:
> On 20 January 2012 03:24, Eric Anholt wrote:
>>> So is it also allowed to blit from S8Z24 to Z24S8 ? Could we also allow
>>> to blit from RGBA8 to BGRA8 then, please ?
>> That's already allowed.
>>
> Yeah, but not for multisampled framebuffers, unless RG
On 20 January 2012 03:24, Eric Anholt wrote:
>> So is it also allowed to blit from S8Z24 to Z24S8 ? Could we also allow
>> to blit from RGBA8 to BGRA8 then, please ?
>
> That's already allowed.
>
Yeah, but not for multisampled framebuffers, unless RGBA8 and BGRA8
are considered identical (ARB_fbo)
https://bugs.freedesktop.org/show_bug.cgi?id=40920
--- Comment #6 from Andreas Betz 2012-01-20
03:10:02 PST ---
Hello,
i just checked it again with MESA trunk and still see those defects.
My setup is:
MESA src from trunk
LLVM 2.9
and i build it for Windows using scons with the following param
On Wed, Jan 11, 2012 at 5:40 PM, Paul Berry wrote:
> On 10 January 2012 13:38, Christoph Bumiller
> wrote:
>>
>> On 01/10/2012 10:09 PM, Dave Airlie wrote:
>> > On Tue, Jan 10, 2012 at 7:28 PM, Eric Anholt wrote:
>> >> On Tue, 10 Jan 2012 11:52:57 +, Dave Airlie
>> >> wrote:
>> >>> From: Da
70 matches
Mail list logo
