http://people.freedesktop.org/~airlied/intel_batchbuffer_test_code.patch
is a patch to blit the contents of the batchbuffer to another memory
space, and compare them before submitting the batchbuffer for the hardware
to consume..
so on my 965, starting X using a batchbuffer allocated
is a patch to blit the contents of the batchbuffer to another memory
space, and compare them before submitting the batchbuffer for the hardware
to consume..
so on my 965, starting X using a batchbuffer allocated non-cached in TT
space, I get to see this:
index: 0 : src
http://bugs.freedesktop.org/show_bug.cgi?id=8357
--- Comment #12 from [EMAIL PROTECTED] 2007-10-23 03:12 PST ---
I will gladly do any testing needed.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You
http://bugs.freedesktop.org/show_bug.cgi?id=12194
--- Comment #1 from [EMAIL PROTECTED] 2007-10-23 07:09 PST ---
The combination of
xorg-libs,xorg-server,xorg-drivers,drm, drm kernel modules, Mesa, pixman (all
from git 2007-10-23) , linux kernel 2.6.22.9
and
intel 965GM
now works
On Mon, 2007-10-22 at 16:00 -0700, Jesse Barnes wrote:
On Friday, September 28, 2007 1:06 pm Jesse Barnes wrote:
On Friday, September 28, 2007 12:51 pm Ian Romanick wrote:
No, in that case the MSC will change and possibly decrease. But
drivers can handle that case by tracking which
On Tuesday, October 23, 2007 7:32 am Michel Dänzer wrote:
Thinking about this more, I think we can make the counter not
decrease, but I don't think we can avoid bad behavior.
Why not, with something like the scheme Ian outlined above?
You snipped out the reasons: we'll get bad behavior of
On Tuesday, October 23, 2007 10:03 am Jesse Barnes wrote:
On Tuesday, October 23, 2007 7:32 am Michel Dänzer wrote:
Thinking about this more, I think we can make the counter not
decrease, but I don't think we can avoid bad behavior.
Why not, with something like the scheme Ian outlined
Some time ago Vector Quantisation (VQ) texture compression was
implemented in some chips like the PowerVR series or the ATI MAch64 and
R128.
Is this still supported by today's hardware?
Is there an OpenGL extension for it (I looked briefly through those
texture compression extensions that contain
Philipp Klaus Krause wrote:
Some time ago Vector Quantisation (VQ) texture compression was
implemented in some chips like the PowerVR series or the ATI MAch64 and
R128.
Is this still supported by today's hardware?
I think the VQ schemes were basically implemented like an extension of
paletted
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp Klaus Krause wrote:
Some time ago Vector Quantisation (VQ) texture compression was
implemented in some chips like the PowerVR series or the ATI MAch64 and
R128.
Is this still supported by today's hardware?
As far as I know, only DXTC is
On Tuesday, October 23, 2007 12:54 am Dave Airlie wrote:
shared-core/i915_dma.c |3 +++
1 file changed, 3 insertions(+)
New commits:
commit a294aa724a1e932fb6017383e08532bfcc914df0
Author: Dave Airlie [EMAIL PROTECTED]
Date: Tue Oct 23 17:54:07 2007 +1000
i915: require mfence
http://bugs.freedesktop.org/show_bug.cgi?id=12194
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment
http://bugs.freedesktop.org/show_bug.cgi?id=12855
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|normal |critical
Priority|medium
http://bugs.freedesktop.org/show_bug.cgi?id=12855
--- Comment #4 from [EMAIL PROTECTED] 2007-10-23 22:19 PST ---
I have tried bisect this, but failed
but according to our testing result history. this issue happened around
10-14-2007
for 10-13-2007, this issue didn't happen, we have:
http://bugs.freedesktop.org/show_bug.cgi?id=12855
--- Comment #5 from [EMAIL PROTECTED] 2007-10-23 22:37 PST ---
It seems the following dri2 merge brings in this issue:
commit f9c6dfc4d12451c21f39f38b048758cbee5723cf
Merge: bf805d3... a249446...
Author: Kristian Høgsberg [EMAIL
15 matches
Mail list logo