On 05/16/2011 09:15 PM, Eric Anholt wrote:
On Mon, 16 May 2011 15:09:43 -0700, Kenneth Graunke
wrote:
On Sandybridge, we don't need to break down primitives. There's no need
to bother setting up brw_compile and such if it's not going to be used;
bail as early as possible.
This series looks
On Mon, 16 May 2011 15:09:43 -0700, Kenneth Graunke
wrote:
> On Sandybridge, we don't need to break down primitives. There's no need
> to bother setting up brw_compile and such if it's not going to be used;
> bail as early as possible.
This series looks very nice. You've tested it on a pre-gen
On Mon, 16 May 2011 15:36:14 -0700, Kenneth Graunke
wrote:
> This will make it much easier to add new dirty bits.
Reviewed-by: Eric Anholt
pgpvU3CQsxQZo.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://l
This will make it much easier to add new dirty bits.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 66 +--
1 files changed, 45 insertions(+), 21 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri
Bail out early in probe, so other driver can take control of the card.
Doing it in screen_create would be too late.
---
src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 44 ++-
1 files changed, 35 insertions(+), 9 deletions(-)
diff --git a/src/gallium/targets/xorg-nouveau/n
On Mon, May 16, 2011 at 10:51:58PM +0200, Roland Scheidegger wrote:
> Hmm not sure about the 8-bit case. Is that really mono and ok if we use
> red channel? And I guess it doesn't make a difference if you'd use 1.0
> as color[3] instead of 0 (just seems that would be more correct)?
Something is de
The primary motivation for this is to better support Ivybridge control
flow. Ivybridge IF instructions need to point to the first instruction
of the ELSE block -and- the ENDIF instruction; the existing code only
supported back-patching one instruction ago.
A second goal is to simplify and central
This hides the IF stack and back-patching of IF/ELSE instructions from
each of the code generators, greatly simplifying the interface.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_clip_line.c | 26 --
src/mesa/drivers/dri/i965/brw_clip_tri.c | 66
This would be so much easier if we were using C++; we could simply use
constructors and destructors. Instead, we have to update all the
callers.
While we're at it, ralloc various brw_wm_compile fields rather than
explicitly calloc/free'ing them.
Signed-off-by: Kenneth Graunke
---
src/mesa/driv
On Sandybridge, we don't need to break down primitives. There's no need
to bother setting up brw_compile and such if it's not going to be used;
bail as early as possible.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_gs.c | 12 ++--
1 files changed, 6 insertions(+),
Hmm not sure about the 8-bit case. Is that really mono and ok if we use
red channel? And I guess it doesn't make a difference if you'd use 1.0
as color[3] instead of 0 (just seems that would be more correct)?
Also, you're passing in bpp to xorg_pixel_to_float4 but don't actually
use it.
Otherwise,
---
src/gallium/targets/xorg-nouveau/Makefile |2 +-
src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/gallium/targets/xorg-nouveau/Makefile
b/src/gallium/targets/xorg-nouveau/Makefile
index 5a2cdb1
---
src/gallium/auxiliary/util/u_debug.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_debug.h
b/src/gallium/auxiliary/util/u_debug.h
index c47c13c..b5ea405 100644
--- a/src/gallium/auxiliary/util/u_debug.h
+++ b/src/gallium/auxiliary/util
samplers[0] may remain uninititialized if src picture/pixmap is null
---
src/gallium/state_trackers/xorg/xorg_composite.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_composite.c
b/src/gallium/state_trackers/xorg/xorg_composite.c
i
---
src/gallium/state_trackers/xorg/xorg_composite.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/xorg/xorg_composite.c
b/src/gallium/state_trackers/xorg/xorg_composite.c
index cadec59..9fdbc90 100644
--- a/src/gallium/state_trackers/xorg
It's a hack, but it allows rendercheck to pass all fill and most blend tests.
(without it all blend tests failed)
---
src/gallium/state_trackers/xorg/xorg_composite.c | 70 +++---
src/gallium/state_trackers/xorg/xorg_composite.h |6 +-
src/gallium/state_trackers/xorg/xorg_exa
Bail out early in probe, so other driver can take control of the card.
Doing it in screen_create would be too late.
PCIID list taken from xf86-video-nv, so it's probably complete.
---
src/gallium/targets/xorg-nouveau/nouveau_xorg.c | 100 +--
1 files changed, 93 insertions(+)
Christian König wrote:
My rv670 is still suffering quite different problems both xvmc and vdpau -
http://www.andyqos.ukfsn.org/pend-rv670-vdpau.png
http://www.andyqos.ukfsn.org/mobcal-rv670-vdpau.png
It's on my todo list, but I don't have any idea what's causing this,
probably more a bug inside
https://bugs.freedesktop.org/show_bug.cgi?id=37236
--- Comment #3 from Tobias Jakobi 2011-05-16 08:40:34 PDT
---
I would vote at least for a big warning when enabling i965g in configure.
Removing the complete driver probably isn't a good idea. IIRC the i915 gallium
driver was also unmaintained
https://bugs.freedesktop.org/show_bug.cgi?id=37236
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On 05/16/2011 03:52 PM, Benoit Jacob wrote:
>> I don't see a bug filed related to dri2FlushFrontBuffer() but I see
>> one for dri2InvalidateBuffers(). Don't know if they're related. You
>> should file a bug for the issue you're having in dri2 with details on
>> how to reproduce it.
>
> I just fi
Sorry, having some troubles with git send-email so sending the patch like
this now.
// Tapani
From 71e687839b41e11a392de58bba3b31bc472bbe2a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tapani=20P=C3=A4lli?=
Date: Mon, 16 May 2011 16:56:43 +0300
Subject: [PATCH] add $SELINUX_LIBS to EGL and OpenVG lib
https://bugs.freedesktop.org/show_bug.cgi?id=36333
--- Comment #1 from Tapani Pälli 2011-05-16 07:33:05 PDT ---
Created an attachment (id=46767)
View: https://bugs.freedesktop.org/attachment.cgi?id=46767
Review: https://bugs.freedesktop.org/review?bug=36333&attachment=46767
link to selinux cor
- Original Message -
> So how does one go about testing WebGL in Firefox these days? The
> environment variable to override the blacklist doesn't seem to be in
> use
> any longer?
https://wiki.mozilla.org/index.php?title=Blocklisting/Blocked_Graphics_Drivers#On_X11
In Nightly (to become F
> I don't see a bug filed related to dri2FlushFrontBuffer() but I see
> one for dri2InvalidateBuffers(). Don't know if they're related. You
> should file a bug for the issue you're having in dri2 with details on
> how to reproduce it.
I just filed https://bugs.freedesktop.org/show_bug.cgi?id=37253
https://bugs.freedesktop.org/show_bug.cgi?id=37236
--- Comment #1 from Tobias Jakobi 2011-05-16 05:56:03 PDT
---
AFAIK the i965 gallium driver is completly unsupported.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: -
https://bugs.freedesktop.org/show_bug.cgi?id=37234
--- Comment #3 from almos 2011-05-16 02:51:51 PDT ---
(In reply to comment #2)
> almos, either your libGL or the drivers were messed up during compilation or
> you have non-matching versions thereof (like an old libGL and a new driver).
> Delete
Hi Jakob,
Thank you very much for your reply!
I have tried your method and other method from VMware community
http://communities.vmware.com/message/1544516 to build vmwgfx in Ununtu
11.04. I have found that:
I could build vmwgfx and glxinfo shows "Gallium 0.4 on SVGA3D; build:
RELEASE" on Window
28 matches
Mail list logo
