On Mon, 10 Oct 2011 16:31:48 -0700, Kenneth Graunke
wrote:
> 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 a
On Mon, 10 Oct 2011 16:31:44 -0700, Kenneth Graunke
wrote:
> 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
On Mon, 10 Oct 2011 16:31:50 -0700, Kenneth Graunke
wrote:
> 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_wri
On Mon, 10 Oct 2011 16:31:46 -0700, Kenneth Graunke
wrote:
> 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...neit
On Mon, 10 Oct 2011 18:10:59 -0700, 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 t
On Mon, 10 Oct 2011 16:31:51 -0700, Kenneth Graunke
wrote:
> 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
From: Brian Paul
v2: add a 'reading' parameter to distinguish between reading and writing
to the renderbuffer (we don't want to check if _ColorReadBuffer is null
when we're about to draw). Eric found this mistake.
---
src/mesa/main/framebuffer.c | 130 ++
https://bugs.freedesktop.org/show_bug.cgi?id=41700
Summary: Gallium won't build with --enable-32-bit on a 64-bit
system
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: norm
On 10/10/2011 01:22 PM, 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.
Observe that this requires that the batch flush in intel_region_map
On 10/11/2011 01:21 PM, tom fogal wrote:
> Ian Romanick writes:
>> Yikes! A *lot* has changed in the fragment shader back-end for i965
>> since 7.10.2. Have you at least tried 7.10.3? 7.11?
>
> I have not. To be honest, I am pretty daunted by trying a new X
> driver. I don't quite understand
Ian Romanick writes:
> On 10/10/2011 03:30 PM, tom fogal wrote:
> > 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 mesadem
On 10/10/2011 03:30 PM, tom fogal wrote:
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
On 10/11/2011 12:55 PM, Eric Anholt wrote:
On Mon, 10 Oct 2011 21:05:32 -0600, Brian Paul wrote:
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
On Mon, 10 Oct 2011 21:05:31 -0600, Brian Paul wrote:
> From: Brian Paul
>
> These functions were only called in framebuffer.c where they were defined.
> Remove the unneeded attIndex parameter too.
Reviewed-by: Eric Anholt
pgpefD1sxeN6k.pgp
Description: PGP signature
On Mon, 10 Oct 2011 21:05:32 -0600, Brian Paul wrote:
> 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
> in
On Mon, 10 Oct 2011 13:22:46 -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.
>
> Observe that this requires that the batch flus
On Mon, 10 Oct 2011 11:23:29 -0700, Ian Romanick wrote:
> 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
> >>>
https://bugs.freedesktop.org/show_bug.cgi?id=41677
Vinson Lee changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Die, 2011-10-11 at 15:44 +0200, Thomas Hellstrom wrote:
> 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
- Original Message -
> On Tue, Oct 11, 2011 at 3:33 PM, Jose Fonseca
> wrote:
> > Makes sense and looks good.
> >
> > Did you use a sed/vim script for this, and could you post it? That
> > would save me some time replicating this change in some internal
> > repos we have.
> >
>
> I'd lo
On Tue, Oct 11, 2011 at 3:33 PM, Jose Fonseca wrote:
> Makes sense and looks good.
>
> Did you use a sed/vim script for this, and could you post it? That would save
> me some time replicating this change in some internal repos we have.
>
I'd love to say I did, but I can't remember how I did the
On 10/09/2011 12:50 PM, Bryan Cain wrote:
I don't think there's any reason we can't eliminate a dead instruction
when the writemask is zero. I do wonder, though, why this patch
actually makes a difference. There's an "if (!inst->dead_mask ||
!inst->dst.writemask)" three lines before the code vi
Needed for throttling.
Signed-off-by: Thomas Hellstrom
---
src/gallium/winsys/svga/drm/vmw_context.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_context.c
b/src/gallium/winsys/svga/drm/vmw_context.c
index 666e198..b5ca841 100644
---
But don't hook it up just yet until we figure out a good way to do that.
Signed-off-by: Thomas Hellstrom
---
.../state_trackers/dri/common/dri_drawable.c | 126 +++-
.../state_trackers/dri/common/dri_drawable.h | 12 ++-
2 files changed, 136 insertions(+), 2 deleti
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".
https://bugs.freedesktop.org/show_bug.cgi?id=41677
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
--- Comment #1 from J
Both patches look good.
Jose
- Original Message -
> 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 acce
Hi!
If we want to add optional driver stuff, like throttling, to a state
tracker, what's the best way to do that?
I was thinking of either adding a new throttling member to the drm
driver_descriptor?
Any suggestions?
/Thomas
___
mesa-dev mailing
https://bugs.freedesktop.org/show_bug.cgi?id=41677
Summary: Potential deallocation at null pointer while getting
of extra extensions info
Product: Mesa
Version: 7.11
Platform: All
OS/Version: All
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=36792
--- Comment #5 from Fabio Pedretti 2011-10-11 02:14:34
PDT ---
(In reply to comment #3)
> So with this patch we'll try to link with a file name libLLVM-x.y.so? I only
> have static LLVM libs here and there's no libLLVM-2.9.so file. I get this
30 matches
Mail list logo
