https://bugs.freedesktop.org/show_bug.cgi?id=41571
Alexandre Demers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
From: Brian Paul
Again, there was already a call to _mesa_source_buffer_exists() earlier in
the function.
---
src/mesa/main/teximage.c | 17 -
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 28c9705..84ee
From: Brian Paul
---
src/mesa/main/teximage.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 84eed23..2d06f84 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -1893,7 +1893,7 @@ co
From: Brian Paul
There was already a call to _mesa_source_buffer_exists() earlier in
the function.
---
src/mesa/main/teximage.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index 8efe715..28c9705 1006
From: Brian Paul
Instead of the renderbuffer pointer. In the future, attaching a texture
may not mean the renderbuffer pointer gets set too.
Plus, remove some commented-out assertions.
---
src/mesa/main/framebuffer.c | 14 --
1 files changed, 4 insertions(+), 10 deletions(-)
diff
From: Brian Paul
---
src/mesa/main/framebuffer.c | 117 +++---
1 files changed, 31 insertions(+), 86 deletions(-)
diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c
index 8beda31..90ac2ef 100644
--- a/src/mesa/main/framebuffer.c
+++ b/src
From: Brian Paul
These functions were only called in framebuffer.c where they were defined.
Remove the unneeded attIndex parameter too.
---
src/mesa/main/framebuffer.c | 34 ++
src/mesa/main/framebuffer.h |8
2 files changed, 10 insertions(+), 32 de
On Mon, Oct 10, 2011 at 7:11 PM, Chad Versace wrote:
> Fix is in {read,draw}_depth_stencil_pixels(). If depthRb == stencilRb,
> then it is redundant to check depthRb->x *and* stencilRb->x.
>
> Signed-off-by: Chad Versace
> ---
> src/mesa/swrast/s_drawpix.c | 1 -
> src/mesa/swrast/s_readpix.
On Mon, Oct 10, 2011 at 7:10 PM, Chad Versace wrote:
> For glReadPixels, the user supplied pixels have format
> GL_UNSIGNED_INT_24_8. But, when the depthstencil buffer's format was
> MESA_FORMAT_S8_Z24, the fastpath read from the buffer without reordering
> the depth and stencil bits. To fix this
From: Brian Paul
In the past, swrast_texture_image::Data has been overloaded. It could
either point to malloc'd memory storing texture data, or it could point
to a current mapping of GPU memory.
Now, Buffer always points to malloc'd memory (if we're not using GPU
memory) and Data always points
From: Brian Paul
Core Mesa no longer does any texture memory allocation.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |4 +-
src/mesa/drivers/dri/intel/intel_tex.c |2 +-
src/mesa/drivers/dri/intel/intel_tex_image.c |1 +
src/mesa/drivers/dri/radeon/radeon_mipma
From: Brian Paul
Only swrast and the drivers that fall back to swrast need these fields now.
This removes the last of the fields related to software rendering from
gl_texture_image.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 10 +-
src/mesa/drivers/dri/intel/intel_tex.c |
For glReadPixels, the user supplied pixels have format
GL_UNSIGNED_INT_24_8. But, when the depthstencil buffer's format was
MESA_FORMAT_S8_Z24, the fastpath read from the buffer without reordering
the depth and stencil bits. To fix this, this patch just skips the
fastpath when the format is not ME
Fix is in {read,draw}_depth_stencil_pixels(). If depthRb == stencilRb,
then it is redundant to check depthRb->x *and* stencilRb->x.
Signed-off-by: Chad Versace
---
src/mesa/swrast/s_drawpix.c |1 -
src/mesa/swrast/s_readpix.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff
From: Brian Paul
Previously it was getting set in draw_set_mapped_constant_buffer() but
if there were no shader constants, that function wasn't called. So the
pt.user.planes field was null and we died when we tried to access the
clip planes in the LLVM-generated code.
Fixes https://bugs.freedes
From: Brian Paul
Instead of 12 use DRAW_TOTAL_CLIP_PLANES. The max number of user-defined
clip planes was increased to 8 so the total number of planes is 14.
This doesn't fix any specific bug, but clearly the old code was wrong.
---
src/gallium/auxiliary/draw/draw_context.c |2 +-
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_disasm.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
b/src/mesa/drivers/dri/i965/brw_disasm.c
index 1dd6b4b..7f20d19 100644
--- a/src/mesa/drivers/dri/i96
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_structs.h | 118 +--
1 files changed, 79 insertions(+), 39 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_structs.h
b/src/mesa/drivers/dri/i965/brw_structs.h
index af83511..85f8318 100644
---
Finding this bit in the documentation proved challenging. It wasn't in
the SEND instruction's message descriptor section, nor the data port
message descriptor section. It turns out to be part of the Render
Target Write message's control bits, and in the documentation is named
"Last Render Target
After printing the details of a specific message, we always print out
the message length and response length with nice "mlen" and "rlen"
labels.
For Gen5+ URB writes, we were dumping mlen and rlen a second time:
urb 0 urb_write interleave used complete mlen 5, rlen 0 mlen 5 rlen 0
Also, for Gen6
Every brw_set_???_message function had duplicated code, per-generation,
to set the Message Descriptor and Extended Message Descriptor bits
(SFID, message length, response length, header present, end of thread).
However, these fields are actually specified as part of the SEND
instruction itself; in
The existing code asserted that eot == 0, as it doesn't make sense for
a thread to sample a texture as the last thing it does.
It doesn't make much sense to pass around a dead parameter either.
Especially for a function which already has a long parameter list.
So, remove the parameter and just se
I can see no reason why we'd use the sampler cache; these reads are
either scratch data (spilling or variably-indexed arrays) or pull
constants. We write through the render cache, so being symmetric is
probably a good thing.
>From a code archaeology perspective, our use of the sampler cache likel
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_structs.h | 29 +++--
1 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_structs.h
b/src/mesa/drivers/dri/i965/brw_structs.h
index e1947d5..b47be69 100644
--- a/s
When reading the data port code, it was not clear to me what these
values meant, nor where I could find them in the documentation.
Especially since the latest BSpec and older PRMs document them in
radically different places...neither of which are near the descriptions
of individual messages.
Cite
Using the constant cache for reads isn't going to work for scratch
reads (variably-indexed arrays or register spills), as these aren't
constant at all.
Also, in the new VS backend, use the proper message number for OWord
Dual Block Write messages. It's now 10, instead of 9. Prior to this,
we wer
Patch 1 fixes the variable indexing Piglit tests on Ivybridge. I was
hoping it would also fix bug 41318 (rendering issues in GLBenchmark/PRO)
as well, but alas. Still, seems worthwhile; the old code was clearly wrong.
Patch 2 may be somewhat controversial, and implements a change in behavior
on
One of our programs which relies on shaders heavily is having issues,
and I have tracked it down to unexpected values in gl_NormalMatrix
within the fragment shader.
Using the attached program (patch against mesademos repo) I did
printf-esque debugging to get the values of gl_NormalMatrix. Search
In commit 018ea68d8780ab5baeef0b8122b8410e5e55ae6d, when I
de-compacted clip planes on Gen6+, I updated both the old and new VS
back-ends to reflect the change in how clip planes are stored, but I
failed to change the code in gen6_vs_state.c that uploads clip plane
constants when using the old VS b
On Thu, 6 Oct 2011 13:24:20 +0200 (CEST), Fabio wrote:
> >Da: kei...@vmware.com
> >Data: 05/10/2011 11.39
> >A: "Christopher James Halse Rogers"
> >Cc: "Joakim Sindholt", org>, "Fabio"
> >Ogg: Re: [Mesa-dev] libgallium.so and miscelaneous buildsystem patches
> >
> >On Wed, 2011-10-05 at 20:14 +11
What I would prefer to assert is that, for each region that is currently
mapped, no batch is emitted that uses that region's bo. However, it's much
easier to implement this big hammer.
Observe that this requires that the batch flush in intel_region_map() be
moved to within the map_refcount guard.
This is required for d3d1x's CheckFormatSupport query.
It also seems generally useful for state trackers, which could
choose alternative rendering paths or formats if blending would
come at a significant performance loss.
---
src/gallium/docs/source/screen.rst |3 +++
src/gallium/include/pi
- Original Message -
> On 10/08/2011 05:55 AM, Jose Fonseca wrote:
> > Just noticed that the latest glext.h doesn't define
> > DEPTH_BUFFER/STENCIL_BUFFER anymore. This is what enum.spec says:
> >
> > # Due to a syncing problem between the ARB_framebuffer_object
> > extension
> > # specif
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/10/2011 10:53 AM, Eric Anholt wrote:
> On Fri, 7 Oct 2011 10:16:47 -0700, Chad Versace wrote:
>> The "slight optimization to avoid the GS program" in brw_set_prim() is not
>> used by Gen 6, since Gen 6 doesn't use a GS program. Also, Gen 6 does
On Mon, Oct 10, 2011 at 12:34 PM, Ian Romanick wrote:
> On 10/08/2011 05:55 AM, Jose Fonseca wrote:
>>
>> Just noticed that the latest glext.h doesn't define
>> DEPTH_BUFFER/STENCIL_BUFFER anymore. This is what enum.spec says:
>>
>> # Due to a syncing problem between the ARB_framebuffer_object ext
On 10/08/2011 05:55 AM, Jose Fonseca wrote:
Just noticed that the latest glext.h doesn't define DEPTH_BUFFER/STENCIL_BUFFER
anymore. This is what enum.spec says:
# Due to a syncing problem between the ARB_framebuffer_object extension
# specification and the core API specification during develop
On 10/06/2011 11:46 AM, Romain Failliot wrote:
2011/10/6 Ian Romanick:
You will have to *completely* uninstall the NVIDIA closed-source driver in
order to use the Mesa driver. NVIDIA installs their own kernel module and
their own libGL, so it is impossible for both to live on the same system.
On 10/10/2011 11:17 AM, Eric Anholt wrote:
On Thu, 6 Oct 2011 14:18:35 -0700, Chad Versace wrote:
What I would prefer to assert is that, for each region that is currently
mapped, no batch is emitted that uses that region's bo. However, it's much
easier to implement this big hammer.
diff --g
On 10/10/2011 11:06 AM, Eric Anholt wrote:
On Thu, 06 Oct 2011 14:40:28 -0700, Ian Romanick wrote:
On 10/06/2011 09:36 AM, Eric Anholt wrote:
These will be used by the FF VS/FS to represent the current attributes
when they don't have an active vertex array.
I just want to make sure I grok th
On Thu, 6 Oct 2011 14:18:35 -0700, Chad Versace wrote:
> What I would prefer to assert is that, for each region that is currently
> mapped, no batch is emitted that uses that region's bo. However, it's much
> easier to implement this big hammer.
> diff --git a/src/mesa/drivers/dri/intel/intel_re
On Thu, 06 Oct 2011 14:40:28 -0700, Ian Romanick wrote:
> On 10/06/2011 09:36 AM, Eric Anholt wrote:
> > These will be used by the FF VS/FS to represent the current attributes
> > when they don't have an active vertex array.
>
> I just want to make sure I grok this completely. These are arrays o
On 10/07/2011 08:28 PM, Kenneth Graunke wrote:
brw_set_compression_control took a GLboolean as an argument, then
promptly used a switch statement to compare it with various enumeration
values. Clearly it's not actually a boolean.
Introduce a new enumeration type, enum brw_compression, and use t
On Thu, 06 Oct 2011 14:41:35 -0700, Ian Romanick wrote:
> On 10/06/2011 02:11 PM, Marek Olšák wrote:
> > If I get this right... Why not use a vertex array with stride == 0 instead?
>
> In the GL API, stride == 0 is a magic value that tells the GL
> implementation to figure out what the stride sh
On Sun, Oct 09, 2011 at 04:36:19PM +0200, Marcin Slusarz wrote:
> On Thu, Oct 06, 2011 at 06:54:38PM -0700, Stéphane Marchesin wrote:
> > Hi Ian,
> >
> > This regresses Chrome GPU acceleration for all GPUs (I tested i915g,
> > llvmpipe, i965).
> >
>
> FYI, I bisected black screen in OilRush (glr
On Mon, Oct 10, 2011 at 10:18:26AM -0700, Ian Romanick wrote:
> On 10/09/2011 07:41 AM, Marcin Slusarz wrote:
> > On Tue, Oct 04, 2011 at 01:44:03PM -0700, Ian Romanick wrote:
> >> This is the next in my series of internal shader API cleaning. The
> >> primary purpose of this series is to remove t
On Fri, 7 Oct 2011 10:16:48 -0700, Chad Versace wrote:
> For example, GL_TRIANLGES is converted to _3DPRIM_TRILIST.
>
> The conversion is necessary because HiZ and MSAA resolve operations emit
> a 3DPRIM_RECTLIST, which cannot be conveyed by GLenum.
>
> As a consequence, brw_gs_prog_key.primiti
On Fri, 7 Oct 2011 10:16:47 -0700, Chad Versace wrote:
> The "slight optimization to avoid the GS program" in brw_set_prim() is not
> used by Gen 6, since Gen 6 doesn't use a GS program. Also, Gen 6 doesn't use
> reduced primitives.
>
> Also, document that intel_context.reduced_primitive is only
On Fri, 7 Oct 2011 12:25:55 -0700, Paul Berry wrote:
> When updating a register reference to reflect the fact that we were
> taking its absolute value, the fragment shader back-end failed to
> clear the negate flag, resulting in abs(-x) getting computed as
> -abs(x).
>
> I also found (and fixed)
From: Tom Fogal
In addition to setting up the flags correctly, this renames the
generated libraries to ensure they get 'Mangled' in the name.
This is very useful for distros and the like, where mangled Mesa
and non-mangled GL libraries typically need to be installed
side-by-side.
---
configs/aut
On Fri, 7 Oct 2011 20:28:35 -0700, Kenneth Graunke
wrote:
> brw_set_compression_control took a GLboolean as an argument, then
> promptly used a switch statement to compare it with various enumeration
> values. Clearly it's not actually a boolean.
>
> Introduce a new enumeration type, enum brw_
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/07/2011 08:28 PM, Kenneth Graunke wrote:
> brw_set_compression_control took a GLboolean as an argument, then
> promptly used a switch statement to compare it with various enumeration
> values. Clearly it's not actually a boolean.
>
> Introduce
On 10/09/2011 07:41 AM, Marcin Slusarz wrote:
On Tue, Oct 04, 2011 at 01:44:03PM -0700, Ian Romanick wrote:
This is the next in my series of internal shader API cleaning. The
primary purpose of this series is to remove the extra tracking of Mesa
IR shaders. The gl_shader_program has a referenc
I tested with a shader that generates an ARL instruction and found
inst->dst is:
{file = PROGRAM_ADDRESS, index = 0, writemask = 1, cond_mask = 8, type
= 2, reladdr = 0x0}
in the code in question. I don't think there's any way that the dest
register's writemask could be set to zero.
Oth
The X server has limited throttle support on the server side,
but doing this in the client has some benefits:
1) X server throttling is per client. Client side throttling can be done
per drawable.
2) It's easier to control the throttling based on what client is run,
for example using "driconf".
On 10/09/2011 09:36 AM, Dave Airlie wrote:
Module: Mesa
Branch: master
Commit: dd20256a1c1566f11e1fa970028f3bb4f05445b7
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=dd20256a1c1566f11e1fa970028f3bb4f05445b7
Author: Dave Airlie
Date: Sun Oct 9 16:35:28 2011 +0100
u_blitter: don't
https://bugs.freedesktop.org/show_bug.cgi?id=41630
Andy Furniss changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
56 matches
Mail list logo
