On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote:
If you're not sure how the actual video card works,
http://www.x.org/wiki/Development/Documentation/HowVideoCardsWork is a
great starting point. Of particular interest is the 3D engine; r300g
only talks to the 3D part of the
Hi,
the last days I was testing Alex Deucher's power-management-2 patches
for radeon OSS driver.
While testing I saw that especially r300g dri/statetracker with
OpenArena have problems with mesa 7.8/master GIT branch.
Mesa r300 classic (KMS/DRI2) is working fine here on RV515.
7.8 GIT:
Scenes
Please apply this patch.
Otherwise st:es has a compile error in st_es2.c!
Thanks.
Johannes
Ping
If you do not believe try compiling it on a fresh machine like OBS.
Include flow:
src/gallium/state_trackers/es/st_es2.c - src/mesa/state_tracker/st_manager.h
- src/mesa/state_tracker/st_context.h
On Fri, Mar 19, 2010 at 11:36 AM, Sedat Dilek sedat.di...@googlemail.comwrote:
Hi,
the last days I was testing Alex Deucher's power-management-2 patches
for radeon OSS driver.
While testing I saw that especially r300g dri/statetracker with
OpenArena have problems with mesa 7.8/master GIT
Johannes Obermayr wrote:
Please apply this patch.
Otherwise st:es has a compile error in st_es2.c!
Thanks.
Johannes
Ping
If you do not believe try compiling it on a fresh machine like OBS.
Include flow:
src/gallium/state_trackers/es/st_es2.c - src/mesa/state_tracker/st_manager.h
-
http://bugs.freedesktop.org/show_bug.cgi?id=27189
Jakob Bornecrantz wallbra...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
tom fogal wrote:
They seem to have become hidden with the visibility changes, at least
--with-driver=xlib.
Your patch doesn't apply cleanly for me but I'll do it by hand.
It looks like there's some other functions also lacking PUBLIC.
I'll fix those too.
-Brian
On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen l...@skynet.be wrote:
So, identify the volatile interfaces, and the more stable interfaces,
and then isolate the volatile ones, and then you come to only one
conclusion.
Except that the Mesa core - classic driver interface also wants to
change
Hi Marek,
indeed the patch you recommended is fixing the red-ish effect with
mesa 7.8 GIT branch!
r300g: remove hacks from translate_vertex_data_swizzle
commit 821c830f11fc1c3529a186ace1d1ba3ddeab4957
Feel free to apply to 7.8 GIT.
IIRC with Dave's screen/winsys rework I had no problems, but
Pulling drm back out of the kernel tree seems like a hard sell, but the
ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for
grouping.
I guess the core question is whether we expect the X-to-ddx and
mesa-to-hw-driver interfaces to be more or less volatile than the
Hi Marek - you are nominated for the next DRIgeller (Uri Geller) :-)
concerning my problems r300g dri/st with mesa master GIT:
THE BAD:
commit 68e58a96e80865878e6881dc4d34fcc3ec24eb19
Author: Dave Airlie airl...@redhat.com
r300g: rebuild screen/winsys interface
THE GOOD:
commit
It may seem e.g. like the DRM interface is the worst because of rather large
threads caused by certain kernel developer's problems, but that doesn't mean
problems wouldn't be created by splitting other areas.
This would probably be best solved by merging libdrm into the Linux kernel tree.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicolai Haehnle wrote:
On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen l...@skynet.be wrote:
So, identify the volatile interfaces, and the more stable interfaces,
and then isolate the volatile ones, and then you come to only one
conclusion.
On Thu, Feb 25, 2010 at 9:41 PM, Dan Nicholson dbn.li...@gmail.com wrote:
diff --git a/configure.ac b/configure.ac
index 485836a..a582337 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,8 +28,11 @@ AC_PROG_CPP
AC_PROG_CC
AC_PROG_CXX
AC_CHECK_PROGS([MAKE], [gmake make])
How about applying this?
It should prevent introducing regressions similar to ones that
happened in the past, with very little downside.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for
On Sun, Mar 14, 2010 at 12:25 PM, George Sapountzis
gsapount...@gmail.com wrote:
Hi,
I put some patches at
http://cgit.freedesktop.org/~gsap7/mesa/log/?h=gallium-drisw that do
the plumbing in order to build the swrast_dri wrapper around gallium
instead of classic mesa. For reference,
On Fri, Mar 19, 2010 at 12:23 PM, Xavier Chantry
chantry.xav...@gmail.com wrote:
On Thu, Feb 25, 2010 at 9:41 PM, Dan Nicholson dbn.li...@gmail.com wrote:
diff --git a/configure.ac b/configure.ac
index 485836a..a582337 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,8 +28,11 @@
Can we just put this program in the demos? Or at least just make it a
separate target (make test-link)? It seems excessive to make this part
of the default build path.
The whole purpose is to run this as part of the standard build, so
that the build fails if any driver is unloadable, (i.e. a
On Fri, Mar 19, 2010 at 2:19 PM, Luca Barbieri l...@luca-barbieri.com wrote:
Can we just put this program in the demos? Or at least just make it a
separate target (make test-link)? It seems excessive to make this part
of the default build path.
The whole purpose is to run this as part of the
For developers that makes a lot of sense, but I've never seen any
other projects impose this type of thing on regular users.
Why do you see it as an onerous imposition?
It just tries to compile a program linked with a couple of libraries
(the DRI driver, plus libGL) and makes the build fail if
On Fri, Mar 19, 2010 at 10:39 PM, Dan Nicholson dbn.li...@gmail.com wrote:
On Fri, Mar 19, 2010 at 2:19 PM, Luca Barbieri l...@luca-barbieri.com wrote:
Can we just put this program in the demos? Or at least just make it a
separate target (make test-link)? It seems excessive to make this part
To quote Dan Nicholson :
In fact, when I wrote configure.ac originally, I wanted it to be a hard
requirement and assumed that AC_PATH_PROG would error by default if it
didn't find the program.
I have been updating and building mesa a few times per week. More often than
not, this just resulted in
This just changes the error message printed with LIBGL_DEBUG when loading
dri2 driver fails. It makes it more informative, more consistent with second
fallback swrast-indirect , and possibly more consistent with old dri1
behavior.
OLD:
libGL error: dlopen foo/nouveau_dri.so failed
http://bugs.freedesktop.org/show_bug.cgi?id=24942
Corbin Simpson mostawesomed...@gmail.com changed:
What|Removed |Added
CC|
On Fri, Mar 19, 2010 at 4:17 PM, Xavier Chantry
chantry.xav...@gmail.com wrote:
On Fri, Mar 19, 2010 at 10:39 PM, Dan Nicholson dbn.li...@gmail.com wrote:
On Fri, Mar 19, 2010 at 2:19 PM, Luca Barbieri l...@luca-barbieri.com
wrote:
Can we just put this program in the demos? Or at least just
Hi,
The documentation on mesa3d.org doesn't seem to be up to date; at least
shading.html does not mention the MESA_GLSL env variable.
--
Cheers,
Sven Arvidsson
http://www.whiz.se
PGP Key ID 760BDD22
signature.asc
Description: This is a digitally signed message part
http://bugs.freedesktop.org/show_bug.cgi?id=27150
Chia-I Wu olva...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
27 matches
Mail list logo
