headers
bugzilla-daemon | 1 Oct 2009 07:08

[Bug 24226] libGL tries using direct mode when it should use indirect (only tries indirect if forced)

http://bugs.freedesktop.org/show_bug.cgi?id=24226

Chia-I Wu <olvaffe <at> gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olvaffe <at> gmail.com

--- Comment #1 from Chia-I Wu <olvaffe <at> gmail.com>  2009-09-30 22:08:11 PST ---
glxinfo creates a context that allows direct rendering, and libGL is capable of
doing direct rendering (through drisw).  I think it is a reasonable behavior. 
To get indirect rendering, you can specify -i when executing glxinfo.

As for driConvertConfigs, it should not return NULL normally.  It returns NULL
when the original psc->configs and driver_configs have no config in common. 
Can you check what's in the original psc->configs?

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 1 Oct 2009 10:17

[Bug 24226] libGL tries using direct mode when it should use indirect (only tries indirect if forced)

http://bugs.freedesktop.org/show_bug.cgi?id=24226

--- Comment #2 from Jeremy Huddleston <jeremyhu <at> freedesktop.org>  2009-10-01 01:17:41 PST ---
You miss the point.  This isn't about glxinfo, this is about *ALL* glx
applications.  glxinfo is just an example.

You said, "glxinfo creates a context that allows direct rendering" ... but
direct rendering is not available because the client is remote from the server.
 In older versions of mesa (6.5 for sure, not sure through when), it would
detect when remote and use indirect.  This behavior seems to have reverted.

Now, when remote, it tries to use drisw, but it results in an empty set of
visuals and fbconfigs as described by the codepath in my initial report.

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
Permalink | Reply | 0 comments |
headers
Peter Clifton | 1 Oct 2009 11:38
Picon
Picon
Favicon
Gravatar

Re: Intel stencil clear bug with multiple contexts

On Wed, 2009-09-30 at 10:48 -0600, Brian Paul wrote:
> Peter Clifton wrote:

> Do you have time to test the attached patch (a clean-up of your patch 
> basically)?

I gave it a quick test, and whilst it cures the original rendering
artefact (which manifested as a failure to clear the main window, and
cross-hair trails everywhere), it did introduce other issues.

Now my screen fills yellow (cursor colour), as soon as I close my
secondary window. On other occasions, it seg-faults.

It has been a little while since I wrote the rendering code, so I can't
swear exactly to the steps, but basically, as the translucent PCB
primitives on a given layer (thick, rounded lines etc..) are drawn, they
mark a particular bit in the stencil buffer - such that I don't get
overlapping geometry on a given layer. (The rounded ends of the lines
overlap otherwise).

Other geometry is constructed in the stencil buffer first, then
overpainted with a solid fill - and I suspect that "might" be where the
solid background fill is coming from. Alternatively - it could be a
glClear to the wrong colour.

I also encountered this new artifact when I was writing my original
"fix". I'd experimented with which parts of the setup needed to be
executed once, and which had to be called every time the glClear was
run.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michel Dänzer | 1 Oct 2009 16:44

[PATCH 0/3] PIPE_TRANSFER_MAP_DIRECTLY

If there are no objections, I'm planning to push the following patches to the
master branch tomorrow:

[PATCH 1/3] gallium: Preparations for adding more PIPE_TRANSFER_* usage flags.

Make sure the addition of new PIPE_TRANSFER_* flags won't break existing code.

[PATCH 2/3] gallium: Add PIPE_TRANSFER_MAP_DIRECTLY usage flag.
[PATCH 3/3] st/xorg: Use PIPE_TRANSFER_MAP_DIRECTLY flag in EXA PrepareAccess hook.

Add a new flag and use it in the xorg state tracker.

--

-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Permalink | Reply | 7 comments |
headers
Michel Dänzer | 1 Oct 2009 16:44

[PATCH 3/3] st/xorg: Use PIPE_TRANSFER_MAP_DIRECTLY flag in EXA PrepareAccess hook.

From: Michel Dänzer <daenzer <at> vmware.com>

Propagate NULL return value.

This also allows removing the DRM_MODE_FEATURE_DIRTYFB specific pixmap
management hacks.
---
 src/gallium/state_trackers/xorg/xorg_exa.c |   93 ++++++++++------------------
 1 files changed, 34 insertions(+), 59 deletions(-)

diff --git a/src/gallium/state_trackers/xorg/xorg_exa.c b/src/gallium/state_trackers/xorg/xorg_exa.c
index b54e31a..f7949ba 100644
--- a/src/gallium/state_trackers/xorg/xorg_exa.c
+++ b/src/gallium/state_trackers/xorg/xorg_exa.c
 <at>  <at>  -202,7 +202,7  <at>  <at>  ExaPrepareAccess(PixmapPtr pPix, int index)
     if (!priv->tex)
 	return FALSE;

-    if (priv->map_count++ == 0)
+    if (priv->map_count == 0)
     {
 	if (exa->pipe->is_texture_referenced(exa->pipe, priv->tex, 0, 0) &
 	    PIPE_REFERENCED_FOR_WRITE)
 <at>  <at>  -210,14 +210,21  <at>  <at>  ExaPrepareAccess(PixmapPtr pPix, int index)

 	priv->map_transfer =
 	    exa->scrn->get_tex_transfer(exa->scrn, priv->tex, 0, 0, 0,
+#ifdef EXA_MIXED_PIXMAPS
+					PIPE_TRANSFER_MAP_DIRECTLY |
+#endif
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michel Dänzer | 1 Oct 2009 16:44

[PATCH 2/3] gallium: Add PIPE_TRANSFER_MAP_DIRECTLY usage flag.

From: Michel Dänzer <daenzer <at> vmware.com>

Asks the driver to map the texture storage directly or return NULL if that's
not possible.
---
 src/gallium/include/pipe/p_defines.h |   13 ++++++++++++-
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/src/gallium/include/pipe/p_defines.h b/src/gallium/include/pipe/p_defines.h
index ad42bef..f8fa1e3 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
 <at>  <at>  -193,7 +193,18  <at>  <at>  enum pipe_texture_target {
 enum pipe_transfer_usage {
    PIPE_TRANSFER_READ = (1 << 0),
    PIPE_TRANSFER_WRITE = (1 << 1),
-   PIPE_TRANSFER_READ_WRITE = PIPE_TRANSFER_READ | PIPE_TRANSFER_WRITE /**≤ Read/modify/write */
+   /** Read/modify/write */
+   PIPE_TRANSFER_READ_WRITE = PIPE_TRANSFER_READ | PIPE_TRANSFER_WRITE,
+   /** 
+    * The transfer should map the texture storage directly. The driver may
+    * return NULL if that isn't possible, and the state tracker needs to cope
+    * with that and use an alternative path without this flag.
+    *
+    * E.g. the state tracker could have a simpler path which maps textures and
+    * does read/modify/write cycles on them directly, and a more complicated
+    * path which uses minimal read and write transfers.
+    */
+   PIPE_TRANSFER_MAP_DIRECTLY = (1 << 2)
 };
(Continue reading)

Permalink | Reply | 4 comments |
headers
bugzilla-daemon | 1 Oct 2009 16:51

[Bug 22157] Build fixes for cygwin

http://bugs.freedesktop.org/show_bug.cgi?id=22157

Jon TURNEY <jon.turney <at> dronecode.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Jon TURNEY <jon.turney <at> dronecode.org.uk>  2009-10-01 07:51:01 PST ---
This seems to have been commited as commit
7eed6ab5b525b75f690d05042c90d05827253114, closing.

--

-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
Permalink | Reply | 0 comments |
headers
Brian Paul | 1 Oct 2009 16:43
Favicon

Re: [PATCH] util: Enable sockets on BSD

Robert Noland wrote:
> I think this should be safe for all of the BSDs.
> 
> Signed-off-by: Robert Noland <rnoland <at> 2hip.net>

Committed. Thanks.

-Brian

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
Permalink | Reply | 0 comments |
headers
Michel Dänzer | 1 Oct 2009 16:44

[PATCH 1/3] gallium: Preparations for adding more PIPE_TRANSFER_* usage flags.

From: Michel Dänzer <daenzer <at> vmware.com>

Always test for PIPE_TRANSFER_READ/WRITE using the bit-wise and operator, and
add a pipe_transfer_buffer_flags() helper for getting the buffer usage flags
corresponding to them.
---
 src/gallium/auxiliary/util/u_tile.c                |    4 +-
 src/gallium/drivers/cell/ppu/cell_texture.c        |   18 +++----------
 src/gallium/drivers/i915simple/i915_texture.c      |    2 +-
 src/gallium/drivers/llvmpipe/lp_texture.c          |   14 ++--------
 src/gallium/drivers/nv04/nv04_transfer.c           |   26 ++++----------------
 src/gallium/drivers/nv10/nv10_transfer.c           |   26 ++++----------------
 src/gallium/drivers/nv20/nv20_transfer.c           |   26 ++++----------------
 src/gallium/drivers/nv30/nv30_transfer.c           |   26 ++++----------------
 src/gallium/drivers/nv40/nv40_transfer.c           |   26 ++++----------------
 src/gallium/drivers/nv50/nv50_transfer.c           |    4 +-
 src/gallium/drivers/r300/r300_screen.c             |   11 +-------
 src/gallium/drivers/softpipe/sp_texture.c          |   15 ++---------
 src/gallium/drivers/trace/tr_screen.c              |    2 +-
 src/gallium/include/pipe/p_inlines.h               |   16 ++++++++++++
 .../state_trackers/python/retrace/interpreter.py   |    2 +-
 src/gallium/state_trackers/vega/st_inlines.h       |    3 +-
 src/mesa/state_tracker/st_cb_accum.c               |    2 +-
 src/mesa/state_tracker/st_texture.c                |    3 +-
 18 files changed, 63 insertions(+), 163 deletions(-)

diff --git a/src/gallium/auxiliary/util/u_tile.c b/src/gallium/auxiliary/util/u_tile.c
index 0d6489c..8a22f58 100644
--- a/src/gallium/auxiliary/util/u_tile.c
+++ b/src/gallium/auxiliary/util/u_tile.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Paul | 1 Oct 2009 16:41
Favicon

Re: [PATCH] util: define PIPE_OS_FREEBSD to correct u_cpu_detect on FreeBSD.

Robert Noland wrote:
> Since the various BSDs use some different features here,
> define PIPE_OS_OPENBSD and PIPE_OS_NETBSD as well
> 
> Signed-off-by: Robert Noland <rnoland <at> 2hip.net>
> ---
>  src/gallium/include/pipe/p_config.h |   13 +++++++++++++
>  1 files changed, 13 insertions(+), 0 deletions(-)
> 
> diff --git a/src/gallium/include/pipe/p_config.h b/src/gallium/include/pipe/p_config.h
> index 78fe1f4..f6feea5 100644
> --- a/src/gallium/include/pipe/p_config.h
> +++ b/src/gallium/include/pipe/p_config.h
>  <at>  <at>  -126,6 +126,19  <at>  <at> 
>  #endif
>  
>  #if defined(__FreeBSD__)
> +#define PIPE_OS_FREEBSD
> +#define PIPE_OS_BSD
> +#define PIPE_OS_UNIX
> +#endif
> +
> +#if defined(__OpenBSD__)
> +#define PIPE_OS_OPENBSD
> +#define PIPE_OS_BSD
> +#define PIPE_OS_UNIX
> +#endif
> +
> +#if defined(__NetBSD__)
> +#define PIPE_OS_NETBSD
(Continue reading)

Permalink | Reply | 0 comments |

Gmane