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 PRO
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
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|normal |critical
Priority|medium
http://bugs.freedesktop.org/show_bug.cgi?id=12194
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Comment
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: requir
-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 i
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
palett
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 s
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
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 behavio
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 trac
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
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 a
>
> 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 000
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 non-cache
15 matches
Mail list logo
