http://bugs.freedesktop.org/show_bug.cgi?id=20291
--- Comment #32 from zhao jian 2009-07-02 01:27:56 PST
---
Yes. I tried with the newest code on G45, it works well.
Libdrm: (master)de1ed01214874dcdd6116ff2587c8710d6ed4d2d
Mesa: (master)5e6b593d35156a0068dc0eb3e55dec086f1
On Wed, 2009-07-01 at 23:47 -0700, Corbin Simpson wrote:
> So, a couple months ago I opined about the inability of Gallium to
> guarantee non-overlapping blits. I need to revisit the subject.
>
> I can't detect when blits will overlap, every time, without massive hax,
> and I'm not terribly certai
This patch plugs a leak triggerable by display lists. I am not
familiar with this part of mesa, maybe there are better ways to do
this, in that case regard the patch as a pointer to the problem.
Tested and works with sauerbraten and gears.
Please review!
Thanks,
Kristof
>From 5567e4ea594d95bd76
Hi,
I try to use the function glXSwapBuffers, but with this function, the demo
doesn't run correctly, I have no vertical sync. So i try to follow the
differents function called to see where is my problem.
The function glXSwapBuffers (file : glxcmds.c) calls the function glFlush (file
: ???) an
On Wed, 2009-07-01 at 10:35 -0700, Jesse Barnes wrote:
> On Wed, 01 Jul 2009 11:53:14 -0400
> Owen Taylor wrote:
>
> > There's a more subtle reason why you want to actually glFinish()
> > rather than glFlush() - if your rendering takes long enough so that
> > you can't keep up with the refresh ra
On Tue, 2009-06-30 at 09:41 -0700, Eric Anholt wrote:
> On Tue, 2009-06-30 at 16:59 +0200, Michel Dänzer wrote:
> > On Mon, 2009-06-29 at 10:57 -0700, Eric Anholt wrote:
> > >
> > > This code was originally introduced with the i915tex code dump, so it's
> > > not
> > > clear what it was there for
The trace driver is a debugging tool, so I don't mind it getting tainted
with api specific code as long as it is useful to somebody.
But since we are it, it would be nice to start discussing what should be
the way to address the problem for all drivers.
So the problem is that although we've cam
The trace driver integration should be done in state tracker, so that it
automatically works for all existing and future pipe drivers, and not
for individual winsyses...
Jose
On Thu, 2009-07-02 at 06:08 -0700, Jakob Bornecrantz wrote:
> Module: Mesa
> Branch: master
> Commit: d1c8a0a30860ab6cd4a5
On 2 jul 2009, at 16.25, José Fonseca wrote:
> The trace driver integration should be done in state tracker, so
> that it
> automatically works for all existing and future pipe drivers, and not
> for individual winsyses...
That is a valid point.
There is the counter argument that since its the
On Thu, 2009-07-02 at 08:29 -0700, Jakob Bornecrantz wrote:
> On 2 jul 2009, at 16.25, José Fonseca wrote:
> > The trace driver integration should be done in state tracker, so
> > that it
> > automatically works for all existing and future pipe drivers, and not
> > for individual winsyses...
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Whitwell wrote:
> Module: Mesa
> Branch: mesa_7_5_branch
> Commit: 47173cf67f0ed55012b0820397f6d620d8ad4473
> URL:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=47173cf67f0ed55012b0820397f6d620d8ad4473
>
> Author: Keith Whitwell
> Date
On Thu, 02 Jul 2009 12:07:20 +0200
Michel Dänzer wrote:
> On Wed, 2009-07-01 at 10:35 -0700, Jesse Barnes wrote:
> > On Wed, 01 Jul 2009 11:53:14 -0400
> > Owen Taylor wrote:
> >
> > > There's a more subtle reason why you want to actually glFinish()
> > > rather than glFlush() - if your renderi
On Thu, 2009-07-02 at 09:20 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Keith Whitwell wrote:
> > Module: Mesa
> > Branch: mesa_7_5_branch
> > Commit: 47173cf67f0ed55012b0820397f6d620d8ad4473
> > URL:
> > http://cgit.freedesktop.org/mesa/mesa/commit/?id=471
On Thu, Jul 02, 2009 at 06:03:01PM +0100, Keith Whitwell wrote:
> On Thu, 2009-07-02 at 09:20 -0700, Ian Romanick wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Keith Whitwell wrote:
> > > Module: Mesa
> > > Branch: mesa_7_5_branch
> > > Commit: 47173cf67f0ed55012b0820397f6d6
On Thu, 2009-07-02 at 11:01 -0700, Ian Romanick wrote:
> On Thu, Jul 02, 2009 at 06:03:01PM +0100, Keith Whitwell wrote:
> > On Thu, 2009-07-02 at 09:20 -0700, Ian Romanick wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > Keith Whitwell wrote:
> > > > Module: Mesa
> > >
http://bugs.freedesktop.org/show_bug.cgi?id=22604
Summary: glxgears prints incorrect "The framerate should be
approximately 1/21955 the monitor refresh rate" messages
Product: Mesa
Version: CVS
Platform: x86-64 (AMD64)
OS/Versi
I believe there's a bug in the piglit vbo-map-remap.c test. The test fails for
me with a GL_INVALID_ENUM error that comes from glEnable(GL_VERTEX_ARRAY).
GL_VERTEX_ARRAY is a client-side capability so the error seems valid.
tests/general/vbo-map-remap.c
42 static void
43 init()
44
On Wed, 2009-07-01 at 23:47 -0700, Corbin Simpson wrote:
> So, a couple months ago I opined about the inability of Gallium to
> guarantee non-overlapping blits. I need to revisit the subject.
>
> I can't detect when blits will overlap, every time, without massive hax,
> and I'm not terribly certai
18 matches
Mail list logo
