On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote:
Nifty. Well, there's a few places to look for information.
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
http://bugs.freedesktop.org/show_bug.cgi?id=27254
--- Comment #3 from Ian Romanick i...@freedesktop.org 2010-03-23 00:09:37
PST ---
(In reply to comment #2)
I guess I am just curious why this one is left out as all the other GL calls
we
use in our software are included in Mesa's libGL,
On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard tstel...@gmail.com wrote:
On Thu, Mar 18, 2010 at 03:25:04PM -0700, Corbin Simpson wrote:
Nifty. Well, there's a few places to look for information.
If you're not sure how the actual video card works,
On Tue, Mar 23, 2010 at 12:13 AM, Corbin Simpson
mostawesomed...@gmail.com wrote:
Good question. There's a handful of things. Passing piglit might be a
good goal. Bumping the GL version further up, or solidifying the GLSL
support, might be good too.
Oh, and how could I forget this? We have a
http://bugs.freedesktop.org/show_bug.cgi?id=27254
--- Comment #4 from Chia-I Wu olva...@gmail.com 2010-03-23 00:38:57 PST ---
I think I should brought this up since 7.8 is about to be released. In
gl_API.xml, we have
function name=HistogramEXT alias=Histogram static_dispatch=false
C and
On Mon, Mar 8, 2010 at 5:51 PM, Jose Fonseca jfons...@vmware.com wrote:
Dave,
I don't oppose this new method -- it shouldn't be necessary to add fencing
just to use pb_cache --, but this method adds a new way of doing the same
thing.
Does the underlying buffer support
Hi,
I was trying to compile latest mesa master GIT:
commit 2a3accb
r300g: fix glean occlusion query test
Unfortunately, the build breaks (see below investigations).
I suspect the cause is I have here Debian's libdrm-2.4.18 installed.
radeon: add square-tiling flag in [1] was post-2.4.18.
So
Fixes here latest issues with mesa master GIT [1].
--
Sedat
[1] http://marc.info/?l=mesa3d-devm=126934502904478w=2
From abfee27605a026769152f067fa572eacea150dc2 Mon Sep 17 00:00:00 2001
From: Sedat Dilek sedat.di...@gmail.com
Date: Tue, 23 Mar 2010 12:53:34 +0100
Subject: [PATCH] configure.ac:
http://bugs.freedesktop.org/show_bug.cgi?id=27261
Summary: GLSL Compiler fails on the following vertex shader
Product: Mesa
Version: 7.5
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: major
http://bugs.freedesktop.org/show_bug.cgi?id=27261
--- Comment #1 from Karthik Hariharakrishnan karha...@arm.com 2010-03-23
05:14:07 PST ---
Created an attachment (id=34360)
-- (http://bugs.freedesktop.org/attachment.cgi?id=34360)
Failing Vertex Shader
Attaching one more vertex shader that
http://bugs.freedesktop.org/show_bug.cgi?id=27261
--- Comment #2 from Karthik Hariharakrishnan karha...@arm.com 2010-03-23
05:17:17 PST ---
Created an attachment (id=34361)
-- (http://bugs.freedesktop.org/attachment.cgi?id=34361)
Fragment shader with a lot of preprocessing fails
--
Fixed in master without requiring new libdrm.
-Marek
On Tue, Mar 23, 2010 at 1:01 PM, Sedat Dilek sedat.di...@googlemail.comwrote:
Fixes here latest issues with mesa master GIT [1].
--
Sedat
[1] http://marc.info/?l=mesa3d-devm=126934502904478w=2
Thanks for the turbo fix, but you workarounded the real bug.
With my patch I get here in build.log:
...
checking for LIBDRM... yes
...
checking for LIBDRM_RADEON... no
...
With setting LIBDRM_RADEON_REQUIRED=2.4.19 I expected that the build
should immediately stop while libdrm package here has
Hi,
what do you think about this proposal?
--
Sedat
From dafb5cf87fa3cc0d8dee0ad4d8dbb9e7a9ab4078 Mon Sep 17 00:00:00 2001
From: Sedat Dilek sedat.di...@gmail.com
Date: Tue, 23 Mar 2010 14:09:23 +0100
Subject: [PATCH 1/2] configure.ac: Simplify check for LIBDRM_RADEON_REQUIRED
---
configure.ac
I've updated the TODO list with the stuff from my private one, in case you
guys think there are too few things to do. ;)
http://dri.freedesktop.org/wiki/R300ToDo?action=diff
-Marek
On Tue, Mar 23, 2010 at 8:16 AM, Corbin Simpson
mostawesomed...@gmail.comwrote:
On Tue, Mar 23, 2010 at 12:13
On Tue, Mar 23, 2010 at 02:16:03PM +0100, Sedat Dilek wrote:
Hi,
what do you think about this proposal?
--
Sedat
Makes _a_ _lot_ of sense.
Luc Verhaegen.
--
Download Intel#174; Parallel Studio Eval
Try the new
Unfortunately, this means to get rid of
$RADEON_CFLAGS
$RADEON_LDFLAGS
in other source files.
As I said I am no autotools expert, but if libdrm_intel does not need
any furher CFLAGS/LDFLAGS, why libdrm_radeon is different?
The benefit of simplifying would mean to have libdrm_{intel,radeon}
http://bugs.freedesktop.org/show_bug.cgi?id=27265
Summary: GLSL Compiler doesnt link the attached vertex shader
Product: Mesa
Version: 7.5
Platform: Other
OS/Version: All
Status: NEW
Severity: major
Priority:
http://bugs.freedesktop.org/show_bug.cgi?id=27265
--- Comment #1 from Karthik Hariharakrishnan karha...@arm.com 2010-03-23
07:33:37 PST ---
Created an attachment (id=34366)
-- (http://bugs.freedesktop.org/attachment.cgi?id=34366)
source code - sample GLES app
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=27265
--- Comment #2 from Karthik Hariharakrishnan karha...@arm.com 2010-03-23
07:34:03 PST ---
Created an attachment (id=34367)
-- (http://bugs.freedesktop.org/attachment.cgi?id=34367)
fragment shader used in main.c
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=27261
--- Comment #4 from Karthik Hariharakrishnan karha...@arm.com 2010-03-23
07:38:08 PST ---
(In reply to comment #3)
The fragment shader / preprocessor bug has been fixed for Mesa 7.8.
I probably won't get around to the other bugs for a
http://bugs.freedesktop.org/show_bug.cgi?id=27261
--- Comment #5 from Brian Paul brian.e.p...@gmail.com 2010-03-23 07:46:01
PST ---
(In reply to comment #4)
I will try the latest release candidate and see if the problem has been fixed.
I have also been observing random failures in the
http://bugs.freedesktop.org/show_bug.cgi?id=27261
--- Comment #6 from Karthik Hariharakrishnan karha...@arm.com 2010-03-23
08:04:53 PST ---
(In reply to comment #5)
(In reply to comment #4)
I will try the latest release candidate and see if the problem has been
fixed.
I have also
On Tue, Mar 23, 2010 at 7:04 AM, Sedat Dilek sedat.di...@googlemail.com wrote:
V2 of my proposal.
0001: Reviewed-by: Dan Nicholson dbn.li...@gmail.com
0002: Having a hard requirement on libdrm_radeon needs to be passed by
the radeon developers. If it is deemed OK, then just drop the 3rd and
4th
http://bugs.freedesktop.org/show_bug.cgi?id=22536
Yu Dai yu@intel.com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=22536
Yu Dai yu@intel.com changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
Configure
http://bugs.freedesktop.org/show_bug.cgi?id=27265
Kristof Ralovich kristof.ralov...@gmail.com changed:
What|Removed |Added
Attachment #34365|application/octet-stream|text/x-csrc
http://bugs.freedesktop.org/show_bug.cgi?id=27265
Kristof Ralovich kristof.ralov...@gmail.com changed:
What|Removed |Added
Attachment #34367|application/octet-stream|text/x-csrc
http://bugs.freedesktop.org/show_bug.cgi?id=27265
--- Comment #3 from Brian Paul brian.e.p...@gmail.com 2010-03-23 09:19:23
PST ---
Created an attachment (id=34368)
-- (http://bugs.freedesktop.org/attachment.cgi?id=34368)
do varying var allocation upon usage to use fewer regs
The fragment
http://bugs.freedesktop.org/show_bug.cgi?id=27261
--- Comment #7 from Brian Paul brian.e.p...@gmail.com 2010-03-23 09:21:42
PST ---
(In reply to comment #6)
It looks like 7.8rc2 fixes the issue but fails a whole lot of other shaders.
More specifically lots of tests fail in the GL/build
Luca Barbieri wrote:
Apparently _mesa_Clear should not set BUFFER_BIT_STENCIL if the visual
lacks a stencil buffer.
So it seems the visual is somehow incorrect, or a visual with a
stencil buffer is being selected but the stencil renderbuffer is not
actually set.
At line 167 of
We have a visual haveStencilBuffer == 1 but stencilBits == 0 (and no
stencil renderbuffer), which I suppose shouldn't be happening.
visualid and fbconfigid are also 0.
Here is the full structure:
$1 = {next = 0x0, rgbMode = 1 '\001', floatMode = 0 '\000',
colorIndexMode = 0 '\000',
The problem seems to be in st_manager.c:
if (visual-depth_stencil_format != PIPE_FORMAT_NONE) {
mode-haveDepthBuffer = GL_TRUE;
mode-haveStencilBuffer = GL_TRUE;
mode-depthBits =
util_format_get_component_bits(visual-depth_stencil_format,
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,
Luca Barbieri wrote:
Fixes a segfault when clearing a non-existent stencil buffer.
---
src/mesa/state_tracker/st_manager.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/state_tracker/st_manager.c
b/src/mesa/state_tracker/st_manager.c
index
http://bugs.freedesktop.org/show_bug.cgi?id=27261
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
Attachment #34360|application/octet-stream|text/plain
Hi,
http://tinderbox.x.org/builds/2010-03-23-0024/logs/libGL/#build
mklib: Making Linux shared library: mach64_dri.so.tmp
gcc -o mach64_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o
mach64_dri.so.tmp -L../../../../../lib -lGL
/usr/bin/ld: cannot find -lGL
collect2: ld
http://bugs.freedesktop.org/show_bug.cgi?id=27268
--- Comment #1 from Karthik Hariharakrishnan karha...@arm.com 2010-03-23
11:41:38 PST ---
Created an attachment (id=34372)
-- (http://bugs.freedesktop.org/attachment.cgi?id=34372)
Output image with step function in vec4 constructor
--
On Tue, Mar 23, 2010 at 11:09 AM, Chris Ball c...@laptop.org wrote:
Hi,
http://tinderbox.x.org/builds/2010-03-23-0024/logs/libGL/#build
mklib: Making Linux shared library: mach64_dri.so.tmp
gcc -o mach64_dri.so.test
../../../../../src/mesa/drivers/dri/common/dri_test.o mach64_dri.so.tmp
On Tue, Mar 23, 2010 at 6:37 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Mar 23, 2010 at 1:57 PM, Sedat Dilek sedat.di...@googlemail.com
wrote:
Thanks for the turbo fix, but you workarounded the real bug.
Frankly, the Mesa build system isn't my area and I don't want to have
anything to
On Fri, 19 Mar 2010 23:05:27 +0100
Luca Barbieri l...@luca-barbieri.com wrote:
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
Hi,
http://tinderbox.x.org/builds/2010-03-23-0034/logs/libGL/#build
/usr/bin/ld: xeglthreads.o: undefined reference to symbol
'pthread_join@@GLIBC_2.0'
/usr/bin/ld: note: 'pthread_join@@GLIBC_2.0' is defined in DSO
/lib/libpthread.so.0 so try adding it to the linker command line
On Tue, Mar 23, 2010 at 12:13:25AM -0700, Corbin Simpson wrote:
On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard tstel...@gmail.com wrote:
Thanks for the information.
After spending some time learning about the Gallium driver architecture, I
think it might be better to set a goal to
On Thu, 4 Mar 2010 15:20:46 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 05 Mar 2010 00:16:45 +0100
Michel Dänzer mic...@daenzer.net wrote:
On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote:
Jesse Barnes wrote:
Would anyone have objections if these lists moved to
On Tue, Mar 23, 2010 at 11:41 PM, Luca Barbieri luca.barbi...@gmail.com wrote:
Do Radeons have a CP command to write an arbitrary value to some place
in memory?
If so, you may want to use that to implement userspace-accessible
fencing in the obvious way and then use the fenced bufmgr, which
On Tue, Mar 23, 2010 at 12:27 PM, Chris Ball c...@laptop.org wrote:
Hi,
http://tinderbox.x.org/builds/2010-03-23-0034/logs/libGL/#build
/usr/bin/ld: xeglthreads.o: undefined reference to symbol
'pthread_join@@GLIBC_2.0'
/usr/bin/ld: note: 'pthread_join@@GLIBC_2.0' is defined in DSO
The issue should be hopefully completely fixed by
7e246e6aa63979d53731a591f4caee3651c1d96b.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and
We have a hack in the xdemos directory to link the programs with
-lpthread for the same reason (I think). Probably need to carry that
hack to the progs/egl directory for xeglthreads, too.
Reasons for the hack in xdemos was linking with binutils-gold.
See explanations in [1] concerning X11.
--
On Tue, Mar 23, 2010 at 2:04 PM, Sedat Dilek sedat.di...@googlemail.com wrote:
We have a hack in the xdemos directory to link the programs with
-lpthread for the same reason (I think). Probably need to carry that
hack to the progs/egl directory for xeglthreads, too.
Reasons for the hack in
The issue should be hopefully completely fixed by
7e246e6aa63979d53731a591f4caee3651c1d96b.
Unfortunately, build breaks here.
Not sure which of the last changes really breaks it.
[build.log]
...
/bin/bash ../../../../../bin/mklib -o r300_dri.so.tmp -noprefix
-linker 'ccache gcc' -ldflags '' \
On Tue, Mar 23, 2010 at 10:14 PM, Dan Nicholson dbn.li...@gmail.com wrote:
On Tue, Mar 23, 2010 at 2:04 PM, Sedat Dilek sedat.di...@googlemail.com
wrote:
We have a hack in the xdemos directory to link the programs with
-lpthread for the same reason (I think). Probably need to carry that
hack to
On Tue, Mar 23, 2010 at 10:45 PM, Sedat Dilek
sedat.di...@googlemail.com wrote:
The issue should be hopefully completely fixed by
7e246e6aa63979d53731a591f4caee3651c1d96b.
Unfortunately, build breaks here.
Not sure which of the last changes really breaks it.
Hopefully fixed that too now.
http://bugs.freedesktop.org/show_bug.cgi?id=27266
--- Comment #1 from Brian Paul brian.e.p...@gmail.com 2010-03-23 15:15:23
PST ---
The problem is this line:
vec4 base = texture2D(base, uv);
base was previously declared as sampler2D. We're getting the scoping wrong
with the
Hi,
dri: fix dri_test.c for non-TLS build
_glapi_Context and _glapi_Dispatch have different constness
between TLS and non-TLS builds.
Breaks the build here, on Fedora 11/ppc64:
http://tinderbox.x.org/builds/2010-03-23-0038/logs/libGL/#build
http://bugs.freedesktop.org/show_bug.cgi?id=27273
Summary: Lightsmark2008 robot model is drawn flat
Product: Mesa
Version: 7.6
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
http://bugs.freedesktop.org/show_bug.cgi?id=27273
--- Comment #1 from Ruslan b7.10110...@gmail.com 2010-03-23 15:37:47 PST ---
Maybe this matters, i tested windows version of it, using WINE. Anyway, it does
work correctly on nVidia proprietary driver, so i guess it's Mesa bug.
--
According to the logs, that build was not based on that commit, which
instead actually fixes that issue.
http://tinderbox.x.org/builds/2010-03-23-0040/ was actually the first
tinderbox build using that, and it went past that issue to fail on
xeglthreads problem, which is unrelated.
Thanks anyway
Hi Sedat,
While striving the log of libGL [1], I noticed that
configure-option --enable-radeon-experimental-api is set, this is
obsolete and build by default, now. Please change.
Thanks, I've removed it now.
- Chris.
--
Chris Ball c...@laptop.org
One Laptop Per Child
Hi Luca,
According to the logs, that build was not based on that commit,
which instead actually fixes that issue.
http://tinderbox.x.org/builds/2010-03-23-0040/ was actually the
first tinderbox build using that, and it went past that issue to
fail on xeglthreads problem,
On Wed, Mar 24, 2010 at 12:56 AM, Brian Paul bri...@vmware.com wrote:
The problem seems to be in st_manager.c:
if (visual-depth_stencil_format != PIPE_FORMAT_NONE) {
mode-haveDepthBuffer = GL_TRUE;
mode-haveStencilBuffer = GL_TRUE;
mode-depthBits =
Hi,
I've made xeglthreads link against -lpthread. Hope it fixes the
issue in next build round.
Looks like it did, thanks very much. All of the tinderbox machines
are passing the mesa build successfully now.
- Chris.
--
Chris Ball c...@laptop.org
One Laptop Per Child
61 matches
Mail list logo
