Signed-off-by: Ian Romanick
---
glx/glxdri2.c | 10 ++
hw/xfree86/dri2/dri2ext.c | 24 ++--
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index c896536..ea5b5ef 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2
If a front-buffer is requested for a window, add the fake front-buffer
to the list of requested buffers.
Signed-off-by: Ian Romanick
---
hw/xfree86/dri2/dri2.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c
Signed-off-by: Ian Romanick
---
hw/xfree86/dri2/dri2.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 351d02b..0b52a0f 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -141,6 +
All of the client-side patches from the previous patch set were reviewed by
krh and have been committed. The server-side patches have receive some
re-work, and are here for review.
The primary change are:
* The sync of the real front-buffer to the fake has been moved from the
client to the s
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Brian Paul wrote:
>> Dave Airlie wrote:
I'm looking at making the 7.5 release on Friday. The main objective of
this development release will be an initial milestone / roll-out of the
Gallium bits. Then, I'
On Thu, Apr 9, 2009 at 20:22, Zack Rusin wrote:
> On Thursday 09 April 2009 14:03:20 Ian Romanick wrote:
>> Stephane Marchesin wrote:
>> > That's my point: video codecs move too fast to be put into silicon,
>> > and require too many resources to implement. So we should use shaders
>> > and lay eve
On Thursday 09 April 2009 14:03:20 Ian Romanick wrote:
> Stephane Marchesin wrote:
> > That's my point: video codecs move too fast to be put into silicon,
> > and require too many resources to implement. So we should use shaders
> > and lay everything onto an API that takes care of the hardware
> >
On Thu, Apr 9, 2009 at 20:03, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Stephane Marchesin wrote:
>
>> That's my point: video codecs move too fast to be put into silicon,
>> and require too many resources to implement. So we should use shaders
>> and lay everything
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephane Marchesin wrote:
> That's my point: video codecs move too fast to be put into silicon,
> and require too many resources to implement. So we should use shaders
> and lay everything onto an API that takes care of the hardware
> details.
This i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
> Dave Airlie wrote:
>>> I'm looking at making the 7.5 release on Friday. The main objective of
>>> this development release will be an initial milestone / roll-out of the
>>> Gallium bits. Then, I'd like to quickly create the Mes
Signed-off-by: Ian Romanick
---
src/i830_dri.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/i830_dri.c b/src/i830_dri.c
index 6a32492..9ede0fb 100644
--- a/src/i830_dri.c
+++ b/src/i830_dri.c
@@ -1554,11 +1554,16 @@ I830DRI2CreateBuffers(DrawablePtr pDraw,
If a front-buffer is requested for a window, add the fake front-buffer
to the list of requested buffers.
Signed-off-by: Ian Romanick
---
hw/xfree86/dri2/dri2.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c
This allows the driver to mark certain buffers, such as the real
front-buffer, to not be returned to the client.
Signed-off-by: Ian Romanick
---
glx/glxdri2.c |8
hw/xfree86/dri2/dri2.h| 10 ++
hw/xfree86/dri2/dri2ext.c | 16 ++--
3 files chan
For part of the front-buffer rendering fixes the server could actually
return N+1 buffers when only N was requested.
Signed-off-by: Ian Romanick
---
src/glx/x11/dri2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/glx/x11/dri2.c b/src/glx/x11/dri2.c
index 3b48cd9.
Assume that the front-buffer exists even if the server didn't tell the
client that it exists.
Signed-off-by: Ian Romanick
---
src/glx/x11/dri2_glx.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index 3f98c08..37
Handle the loader returning a fake front-buffer. Since the driver
never specifically requests a fake front-buffer, the driver assumes
that it will never receive both a fake and a real front-buffer.
Signed-off-by: Ian Romanick
---
src/mesa/drivers/dri/intel/intel_context.c |5 +
1 files
Signed-off-by: Ian Romanick
---
src/glx/x11/dri2_glx.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index 5acb3dd..3f98c08 100644
--- a/src/glx/x11/dri2_glx.c
+++ b/src/glx/x11/dri2_glx.c
@@ -314,6 +314,14 @@ dri2G
Track two flags: whether or not front-buffer rendering is currently
enabled and whether or not front-buffer rendering has been enabled
since the last glFlush. If the second flag is set, the front-buffer
is flushed via a loader call back. If the first flag is cleared, the
second flag is cleared a
Signed-off-by: Ian Romanick
---
include/GL/internal/dri_interface.h | 15 ++-
src/glx/x11/dri2_glx.c | 10 ++
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 27cc1
This patch series has three parts. The first, and largest, part is the set
of 6 patches to Mesa. These patches are mostly similar to what I had
previously sent out. These patches were made against mesa_7_4_branch.
The second set of patches (patches 7 and 8) are to the xserver. This
implements
Stephane Marchesin wrote:
> On Thu, Apr 9, 2009 at 17:18, Alex Deucher wrote:
>> FWIW, MC is done using the 3D engine on our hardware, so MC should be
>> able to be implemented now for those that are interested. r3xx+ use
>> shaders. r1xx/r2xx have a couple special bits to flip in the 3D
>> engin
On 4/9/09, Stephane Marchesin wrote:
> On Thu, Apr 9, 2009 at 17:18, Alex Deucher wrote:
> > On 4/9/09, Stephane Marchesin wrote:
> >> On Thu, Apr 9, 2009 at 08:49, Zou, Nanhai wrote:
> >> >
> >> >
> >> > I have not been looking into gallium support yet.
> >> > Are you working on soft
On Thu, Apr 9, 2009 at 17:18, Alex Deucher wrote:
> On 4/9/09, Stephane Marchesin wrote:
>> On Thu, Apr 9, 2009 at 08:49, Zou, Nanhai wrote:
>> >
>> >
>> > I have not been looking into gallium support yet.
>> > Are you working on software fallback or on some real hardware?
>>
>>
>> We have x
On 4/9/09, Stephane Marchesin wrote:
> On Thu, Apr 9, 2009 at 08:49, Zou, Nanhai wrote:
> >
> >
> > I have not been looking into gallium support yet.
> > Are you working on software fallback or on some real hardware?
>
>
> We have xvmc on top of g3dvl working on nv40-class hardware (and more
2009/4/9 Zou, Nanhai :
>>-Original Message-
>>From: stephane.marche...@gmail.com [mailto:stephane.marche...@gmail.com] On
>>Behalf Of Stephane Marchesin
>>Sent: 2009年4月9日 15:20
>>To: Zou, Nanhai
>>Cc: Corbin Simpson; Denis Martinez; mesa3d-dev@lists.sourceforge.net
>>Subject: Re: [Mesa3d-de
Zou, Nanhai wrote:
>> -Original Message-
>> From: stephane.marche...@gmail.com [mailto:stephane.marche...@gmail.com] On
>> Behalf Of Stephane Marchesin
>> Sent: 2009年4月9日 15:20
>> To: Zou, Nanhai
>> Cc: Corbin Simpson; Denis Martinez; mesa3d-dev@lists.sourceforge.net
>> Subject: Re: [Mesa3d
2009/4/9 Zou, Nanhai :
>
> You can choose to implement 1 single entry point e.g. VLD.
> What I think VAAPI is missing is post processing,However I can talk to
> VAAPI people to improve the API, anyway VAAPI is only at version 0.30.
>
>>
>>> I think merge the VAAPI support into mesa might be a g
>-Original Message-
>From: stephane.marche...@gmail.com [mailto:stephane.marche...@gmail.com] On
>Behalf Of Stephane Marchesin
>Sent: 2009年4月9日 15:20
>To: Zou, Nanhai
>Cc: Corbin Simpson; Denis Martinez; mesa3d-dev@lists.sourceforge.net
>Subject: Re: [Mesa3d-dev] Google Summer of Code
>
>On
On Thu, Apr 9, 2009 at 08:49, Zou, Nanhai wrote:
>
>
> I have not been looking into gallium support yet.
> Are you working on software fallback or on some real hardware?
We have xvmc on top of g3dvl working on nv40-class hardware (and more
generically, it should work any card which has a gallium
29 matches
Mail list logo
