- Original Message -
Adds a possibility for the state tracker manager to query the
target for a specific configuration.
All these patches looks good. There is one thing I'm wondering, is there
really a driconf option exposed for this? The commit kind of makes it
sound like there is. It
- Original Message -
- Original Message -
Adds a possibility for the state tracker manager to query the
target for a specific configuration.
All these patches looks good. There is one thing I'm wondering, is
there really a driconf option exposed for this? The commit kind
- Original Message -
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
On 10/13/2011 02:04 PM, Jakob Bornecrantz wrote:
- Original Message -
Adds a possibility for the state tracker manager to query the
target for a specific configuration.
All these patches looks good. There is one thing I'm wondering, is there
really a driconf option exposed
- Original Message -
On 10/13/2011 02:04 PM, Jakob Bornecrantz wrote:
- Original Message -
Adds a possibility for the state tracker manager to query the
target for a specific configuration.
All these patches looks good. There is one thing I'm wondering, is
On 10/12/2011 06:21 PM, Eric Anholt wrote:
On Wed, 12 Oct 2011 11:44:10 -0600, Brian Paulbri...@vmware.com wrote:
On 10/12/2011 10:57 AM, Eric Anholt wrote:
On Mon, 10 Oct 2011 20:27:44 -0600, Brian Paulbrian.e.p...@gmail.com wrote:
From: Brian Paulbri...@vmware.com
Only swrast and the
Hi,
We have experienced a problem with the win32 wgl pbuffer implementation using
gallium together with threading.
This attached change releases the stw_framebuffer::mutex past creation of
the pbuffer stw_framebuffer. Without this change the pbuffers
lock is never released. Since on win32
Hi,
The attached change just makes the bitfield macro match the register number it
is used for. Both actually expand into the same values.
Please apply
Thanks!
Mathias
From eaf61856ba5e40700a4b562fc38750f66cf7cba1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mathias=20Fr=C3=B6hlich?=
On Don, 2011-10-13 at 10:03 -0700, Marcin XXlusarz wrote:
Module: Mesa
Branch: master
Commit: 349e4db99e938f8ee8826b0d27e490c66a1e8356
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=349e4db99e938f8ee8826b0d27e490c66a1e8356
Author: Marcin Slusarz marcin.slus...@gmail.com
Date:
Hi,
This patch restores the previous memory characteristic of the recently removed
r600g winsys. Static and immutable buffers were placed in any case in vram.
This really improoves rendering performance for some OpenSceneGraph based
applications I often use for testing here.
Please review and
- Original Message -
Hi,
We have experienced a problem with the win32 wgl pbuffer
implementation using
gallium together with threading.
This attached change releases the stw_framebuffer::mutex past
creation of
the pbuffer stw_framebuffer. Without this change the pbuffers
lock
Hi Jose,
On Thursday, October 13, 2011 20:18:25 Jose Fonseca wrote:
We should also acquire/release the mutex on every entry point on that file
for consistency, but it would make no difference, given that pbuffers
can't be resized like normal windows are.
Do you have commit access or should
For my problem with the nouveau driver burning up my card, I'll take
the simplest solution: get an ATI card (nVidia should have opened up
their specs!).
2011/9/27 Eric Anholt e...@anholt.net:
I'd definitely recommend working on a texturing format extension for
your hardware as a great way to
2011/10/13 Mathias Fröhlich mathias.froehl...@gmx.net:
Hi Jose,
On Thursday, October 13, 2011 20:18:25 Jose Fonseca wrote:
We should also acquire/release the mutex on every entry point on that file
for consistency, but it would make no difference, given that pbuffers
can't be resized like
On Thu, Oct 13, 2011 at 07:54:32PM +0200, Michel Dänzer wrote:
On Don, 2011-10-13 at 10:03 -0700, Marcin XXlusarz wrote:
Module: Mesa
Branch: master
Commit: 349e4db99e938f8ee8826b0d27e490c66a1e8356
URL:
Well, trivial answer is that Win32 uses some C/C++ runtime provided by
Microsoft, usually something like MSVCR90.DLL (v9.0) etc. Solaris uses
libC.so, for example. As far as I know, only systems where the GNU C/C++
compiler is main system compiler (and generally therefore the GNU C++
runtime) uses
On Thursday 13 October 2011 08:44:27 Michel Dänzer wrote:
On Mit, 2011-10-12 at 22:54 +0200, Martin Stolpe wrote:
I'm using the Gallium R300 driver with the Xorg state tracker on my
system. Everything is running very smoothly when I'm using OpenGL ES
2.0 composited mode of kwin. Running for
We discussed this on IRC and there was no concensus as to what's best
for every app. While one app can benefit from this, some other app may
suffer. I am OK with comitting the patch though. CC'ing Vadim as he
had a similar patch too.
Marek
2011/10/13 Mathias Fröhlich mathias.froehl...@gmx.net:
https://bugs.freedesktop.org/show_bug.cgi?id=41768
Summary: Logic error in mesa/drivers/common/meta.c
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=41768
Brian Paul bri...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
From: Ian Romanick ian.d.roman...@intel.com
This is supported by the pseudo-code on pages 27 and 28 (pages 41 and
42 of the PDF) of the OpenGL 2.1 spec. The last part of the
implementation of ArrayElement is:
if (generic attribute array 0 enabled) {
if (generic vertex attribute 0
On Thu, 2011-10-13 at 23:41 +0200, Marek Olšák wrote:
We discussed this on IRC and there was no concensus as to what's best
for every app. While one app can benefit from this, some other app may
suffer. I am OK with comitting the patch though. CC'ing Vadim as he
had a similar patch too.
I
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/pbo.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/pbo.c b/src/mesa/main/pbo.c
index 4e7e6f9..4611c5d 100644
--- a/src/mesa/main/pbo.c
+++ b/src/mesa/main/pbo.c
@@ -82,6 +82,11
On 10/13/2011 06:46 PM, Yuanhan Liu wrote:
Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com
---
src/mesa/main/pbo.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/pbo.c b/src/mesa/main/pbo.c
index 4e7e6f9..4611c5d 100644
---
On Thu, Oct 13, 2011 at 08:01:32PM -0700, Ian Romanick wrote:
On 10/13/2011 06:46 PM, Yuanhan Liu wrote:
Signed-off-by: Yuanhan Liuyuanhan@linux.intel.com
---
src/mesa/main/pbo.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/pbo.c
v2: quote the spec; explicitly exclude the GL_BITMAP case to make code
more readable. (comments from Ian)
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
src/mesa/main/pbo.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/mesa/main/pbo.c
On 10/12/2011 08:34 PM, Yuanhan Liu wrote:
The patch(based on the reading of the emulator) came from while I was
trying to fix the oglc pbo texImage.1PBODefaults fail. This case
generates a texture with the width and height equal to window's width
and height respectively, then try to texture it
On Thu, Oct 13, 2011 at 09:12:09PM -0700, Ian Romanick wrote:
On 10/12/2011 08:34 PM, Yuanhan Liu wrote:
The patch(based on the reading of the emulator) came from while I was
trying to fix the oglc pbo texImage.1PBODefaults fail. This case
generates a texture with the width and height equal to
The patch(based on the reading of the emulator) came from while I was
trying to fix the oglc pbo texImage.1PBODefaults fail. This case
generates a texture with the width and height equal to window's width
and height respectively, then try to texture it on the whole window.
So, it's exactly one
29 matches
Mail list logo
