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
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
Both patches look good.
Jose
- Original Message -
From: Brian Paul bri...@vmware.com
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
https://bugs.freedesktop.org/show_bug.cgi?id=41677
José Fonseca jfons...@vmware.com changed:
What|Removed |Added
CC||jfons...@vmware.com
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.
But don't hook it up just yet until we figure out a good way to do that.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
.../state_trackers/dri/common/dri_drawable.c | 126 +++-
.../state_trackers/dri/common/dri_drawable.h | 12 ++-
2 files changed, 136
Needed for throttling.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
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
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
On Tue, Oct 11, 2011 at 3:33 PM, Jose Fonseca jfons...@vmware.com 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
- Original Message -
On Tue, Oct 11, 2011 at 3:33 PM, Jose Fonseca jfons...@vmware.com
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.
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 the
https://bugs.freedesktop.org/show_bug.cgi?id=41677
Vinson Lee v...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, 10 Oct 2011 11:23:29 -0700, Ian Romanick i...@freedesktop.org wrote:
On 10/10/2011 11:06 AM, Eric Anholt wrote:
On Thu, 06 Oct 2011 14:40:28 -0700, Ian Romanicki...@freedesktop.org
wrote:
On 10/06/2011 09:36 AM, Eric Anholt wrote:
These will be used by the FF VS/FS to represent
On Mon, 10 Oct 2011 13:22:46 -0700, Chad Versace c...@chad-versace.us 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
On Mon, 10 Oct 2011 21:05:32 -0600, Brian Paul brian.e.p...@gmail.com wrote:
From: Brian Paul bri...@vmware.com
---
src/mesa/main/framebuffer.c | 117 +++---
1 files changed, 31 insertions(+), 86 deletions(-)
diff --git a/src/mesa/main/framebuffer.c
On Mon, 10 Oct 2011 21:05:31 -0600, Brian Paul brian.e.p...@gmail.com wrote:
From: Brian Paul bri...@vmware.com
These functions were only called in framebuffer.c where they were defined.
Remove the unneeded attIndex parameter too.
Reviewed-by: Eric Anholt e...@anholt.net
pgpefD1sxeN6k.pgp
On 10/11/2011 12:55 PM, Eric Anholt wrote:
On Mon, 10 Oct 2011 21:05:32 -0600, Brian Paulbrian.e.p...@gmail.com wrote:
From: Brian Paulbri...@vmware.com
---
src/mesa/main/framebuffer.c | 117 +++---
1 files changed, 31 insertions(+), 86 deletions(-)
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
Ian Romanick i...@freedesktop.org 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
On 10/11/2011 01:21 PM, tom fogal wrote:
Ian Romanick i...@freedesktop.org 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
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
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:
From: Brian Paul bri...@vmware.com
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
On Mon, 10 Oct 2011 16:31:51 -0700, Kenneth Graunke kenn...@whitecape.org
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
On Mon, 10 Oct 2011 18:10:59 -0700, Chad Versace c...@chad-versace.us 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
On Mon, 10 Oct 2011 16:31:50 -0700, Kenneth Graunke kenn...@whitecape.org
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:
On Mon, 10 Oct 2011 16:31:48 -0700, Kenneth Graunke kenn...@whitecape.org
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
27 matches
Mail list logo
