Okay I've pushed another iteration of the gallium + mesa + softpipe +
r600g changes for accelerated stencil rendering to
http://cgit.freedesktop.org/~airlied/mesa/log/?h=gallium-stencil-export
Quick patch summary by area: I've marked two mesa ones as needing some
competent review.
Gallium:
add T
https://bugs.freedesktop.org/show_bug.cgi?id=30481
--- Comment #10 from David Gorst 2010-10-06 23:12:34 PDT ---
Also I should add that it's still failing to create a context :
libEGL debug: the value (0x0) of attribute 0x3025 did not meet the criteria
(0x1)
libEGL debug: the value (0x0) of attri
https://bugs.freedesktop.org/show_bug.cgi?id=30481
--- Comment #9 from David Gorst 2010-10-06 22:35:04 PDT ---
Apologies - I've just re-checked out the source and done a clean/rebuild and
the issue with OpenGL is gone. However I still have this issue running lion_x11
:
couldn't open libtxc_dxtn
https://bugs.freedesktop.org/show_bug.cgi?id=30481
--- Comment #8 from Chia-I Wu 2010-10-06 21:58:35 PDT ---
(In reply to comment #7)
> The last time I used :
>
> /configure --prefix=/home/dgorst/mesa-git --enable-gles-overlay --enable-debug
> --with-state-trackers=egl,vega --enable-gallium-swra
https://bugs.freedesktop.org/show_bug.cgi?id=30633
--- Comment #2 from Chia-I Wu 2010-10-06 21:36:48 PDT ---
openvg/trivial/eglcommon.h also seems to be missing. I've added it in a
following commit.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=30481
--- Comment #7 from David Gorst 2010-10-06 21:32:44 PDT ---
The last time I used :
/configure --prefix=/home/dgorst/mesa-git --enable-gles-overlay --enable-debug
--with-state-trackers=egl,vega --enable-gallium-swrast
(In reply to comment #6)
>
https://bugs.freedesktop.org/show_bug.cgi?id=30481
--- Comment #6 from Chia-I Wu 2010-10-06 21:24:01 PDT ---
(In reply to comment #4)
> Rebuilt again from the latest Git source and the OpenGL demos are running, but
> not OpenVG or OpenGLES. This is the debug output from lion_x11. Attribute
> 0x30
https://bugs.freedesktop.org/show_bug.cgi?id=30481
--- Comment #5 from Chia-I Wu 2010-10-06 21:21:15 PDT ---
(In reply to comment #1)
> even if i forcibly link those programs with libdrm, they fail with:
> EGLUT: failed to create context
>
> even though eglinfo says:
> EGL client APIs: OpenGL Op
https://bugs.freedesktop.org/show_bug.cgi?id=30481
--- Comment #4 from David Gorst 2010-10-06 19:07:36 PDT ---
Rebuilt again from the latest Git source and the OpenGL demos are running, but
not OpenVG or OpenGLES. This is the debug output from lion_x11. Attribute
0x3040 is EGL_RENDERABLE_TYPE and
https://bugs.freedesktop.org/show_bug.cgi?id=30481
--- Comment #3 from David Gorst 2010-10-06 16:48:42 PDT ---
Just checked - the same issue is present in the OpenGL demos, and binding the
API as OpenGL in my code is giving the same results as binding to OpenVG.
--
Configure bugmail: https://bu
The shaders only depend on the shader itself, the vertex_elements state and
flatshade and we don't need to emit the registers again if these are not
changed. Tracking is also faster
than the memcmp in r600_shader_update, so in some cases that expensive check
doesn't have to be performed. I also
https://bugs.freedesktop.org/show_bug.cgi?id=30629
--- Comment #5 from lsalz...@gmail.com 2010-10-06 12:08:58 PDT ---
(In reply to comment #4)
> I checked all client *_ARRAY states via glIsEnabled() at the point he alleges
> this error occurred, and on my end, they are always disabled. (Using NV
>
The shaders only depend on the shader itself, the vertex_elements state and
flatshade and we don't need to emit the registers again if these are not
changed. Tracking is also faster
than the memcmp in r600_shader_update, so in some cases that expensive check
doesn't have to be performed. I also
https://bugs.freedesktop.org/show_bug.cgi?id=30629
--- Comment #4 from lsalz...@gmail.com 2010-10-06 11:47:07 PDT ---
I checked all client *_ARRAY states via glIsEnabled() at the point he alleges
this error occurred, and on my end, they are always disabled. (Using NV
proprietary drivers)
The text
On Wed, Oct 6, 2010 at 12:22 PM, Bas Nieuwenhuizen
wrote:
> The shaders only depend on the shader itself and the vertex_elements state
> and we don't need to emit the registers again if these are not changed.
> Tracking is also faster than the
> memcmp in r600_shader_update, so in some cases tha
On Wed, Oct 6, 2010 at 6:22 PM, Bas Nieuwenhuizen
wrote:
> The shaders only depend on the shader itself and the vertex_elements state
> and we don't need to emit the registers again if these are not changed.
> Tracking is also faster than the
> memcmp in r600_shader_update, so in some cases that
The shaders only depend on the shader itself and the vertex_elements state and
we don't need to emit the registers again if these are not changed. Tracking is
also faster than the
memcmp in r600_shader_update, so in some cases that expensive check doesn't
have to be performed. I also optimized t
On Wed, Sep 29, 2010 at 7:55 PM, Alexandre Demers wrote:
> Hi,
> I've been following the development of mesa and gallium for some time now.
> Each time a developer talks about the gallium i915/945 driver, it's always
> in an "almost done" state... However, even now, it doesn't support
> everythin
https://bugs.freedesktop.org/show_bug.cgi?id=30633
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=30629
--- Comment #3 from Fabio Pedretti 2010-10-06 08:10:27
PDT ---
Created an attachment (id=39234)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39234)
output of call _mesa_print_arrays(ctx)
--
Configure bugmail: https://bugs.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=30629
--- Comment #2 from Brian Paul 2010-10-06 08:00:42 PDT ---
This error is reported when one of the indexes/elements specified by the
glDraw[Range]Elements call points to a vertex attribute that's outside the
bounds of the containing VBO. If nothi
Fix typo in copyright notice.
Signed-off-by: Nicolas Kaiser
---
src/gallium/drivers/nv50/nv50_program.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/gallium/drivers/nv50/nv50_program.c
b/src/gallium/drivers/nv50/nv50_program.c
index db68176..9f5e58e 100644
--- a
On Wed, Oct 6, 2010 at 5:19 AM, Keith Whitwell wrote:
> Yes, I belive so (at work now, so can't double-check). I started with
> the top of tree last night, which is well past this commit.
>
> Keith
Strange i am using rv710 without issue, however my rs780 seems to have
similar issue as one you de
https://bugs.freedesktop.org/show_bug.cgi?id=30629
--- Comment #1 from Fabio Pedretti 2010-10-06 04:58:19
PDT ---
Created an attachment (id=39221)
--> (https://bugs.freedesktop.org/attachment.cgi?id=39221)
backtrace
Backtrace with mesa and sauerbraten debug symbols is attached.
--
Configure
Yes, I belive so (at work now, so can't double-check). I started with
the top of tree last night, which is well past this commit.
Keith
On Wed, 2010-10-06 at 02:12 -0700, Dave Airlie wrote:
> On Wed, Oct 6, 2010 at 6:29 PM, Keith Whitwell
> wrote:
> > Hmm, same results on the machine's built-i
On Wed, Oct 6, 2010 at 6:29 PM, Keith Whitwell wrote:
> Hmm, same results on the machine's built-in rs880 (whatever that is...)
>
You have tested with a commit after this?
http://cgit.freedesktop.org/mesa/mesa/commit/?id=585e4098aa0cb68a2cfce55ced5c585bd20aba24
Dave.
> Keith
>
> On Wed, Oct 6,
Hmm, same results on the machine's built-in rs880 (whatever that is...)
Keith
On Wed, Oct 6, 2010 at 9:08 AM, Keith Whitwell wrote:
> (using the correct mesa3d-dev address)
>
>
> -- Forwarded message --
> From: Keith Whitwell
> Date: Wed, Oct 6, 2010 at 9:07 AM
> Subject: Re: Me
(using the correct mesa3d-dev address)
-- Forwarded message --
From: Keith Whitwell
Date: Wed, Oct 6, 2010 at 9:07 AM
Subject: Re: Mesa (master): r600g: use constant buffer instead of
register for constant
To: mesa-dev@lists.freedesktop.org
Cc: mesa3d-dev
Hi Jerome,
I was pla
Hi Jerome,
I was playing with this driver on my new machine (rv710) & was
impressed with how well it worked. Unfortunately the next update
everything went black...
I traced it down to this commit - it basically seems like all the
vertex-buffer constants (at least) are ending up as zero, so most
29 matches
Mail list logo
