https://bugs.freedesktop.org/show_bug.cgi?id=61821
Vinson Lee v...@freedesktop.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
On Die, 2013-03-12 at 17:42 -0400, Alex Deucher wrote:
On Tue, Mar 12, 2013 at 4:23 PM, Tom Stellard t...@stellard.net wrote:
From: Tom Stellard thomas.stell...@amd.com
v2:
- Only dump shaders when env variable is set.
A couple of comments below, other than that, looks good.
https://bugs.freedesktop.org/show_bug.cgi?id=61821
--- Comment #6 from Marc marvi...@gmx.de ---
works fine here.
git clean -f -d -x -e b.sh
./autogen.sh\
--prefix=/usr \
--libdir=/usr/lib64 \
--disable-debug \
My tests of nightly VTK built against nightly OSMesa failed last
night.
The onscreen builds are fine.
The OSMesa build tests now fail with all black output but I
haven't found any error message to inform me of what's going on.
I know osmesa just switched to Gallium: that is reflected in
VTK's
Hi Brian,
Sorry for not being clear, let me clarify it.
On 3/13/13, Brian Paul bri...@vmware.com wrote:
Well, the Xlib/swrast driver does everything in software, unlike a DRI
driver which does most things with the GPU. Xlib will always be slower.
My local test machine graphic card does not
On 12 March 2013 17:46, Ian Romanick i...@freedesktop.org wrote:
Right... the extension also adds an attribute that can only be used with
glXCreateContextAttribsARB.
Yeah, all I was saying is that it probably wouldn't be too hard to
word things along the lines of If glXCreateContextAttribsARB()
On 12 March 2013 12:53, Paul Berry stereotype...@gmail.com wrote:
On 12 March 2013 12:28, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
Fast depth clears have the same depth/stencil alignment requirements
as other drawing operations. Therefore, we need to
Hi,
I have tested your changes but it looks like they fail to compile on Android.
==
Tested the patch(es) on top of the following commits:
f7ef83c scons: Define PACKAGE_xxx
6f86b93 docs: rewrite the OSMesa info / instructions
79eac7d configure:
(switching over mesa-dev.. sent to the wrong list initially)
On Wed, Mar 13, 2013 at 8:25 AM, Paul Menzel
paulepan...@users.sourceforge.net wrote:
Dear Rob,
Am Dienstag, den 12.03.2013, 19:44 -0400 schrieb Rob Clark:
»it« sounds strange in commit summary.
If ddx does not support swap,
On 03/13/2013 04:11 AM, jupiter wrote:
Hi Brian,
Sorry for not being clear, let me clarify it.
On 3/13/13, Brian Paulbri...@vmware.com wrote:
Well, the Xlib/swrast driver does everything in software, unlike a DRI
driver which does most things with the GPU. Xlib will always be slower.
My
On 03/13/2013 04:04 AM, Kevin H. Hobbs wrote:
My tests of nightly VTK built against nightly OSMesa failed last
night.
The onscreen builds are fine.
The OSMesa build tests now fail with all black output but I
haven't found any error message to inform me of what's going on.
I know osmesa just
https://bugs.freedesktop.org/show_bug.cgi?id=58718
--- Comment #15 from José Fonseca jfons...@vmware.com ---
(In reply to comment #14)
I posted a series of patches to mesa3d-dev which seems to fix the inline
issue.
I pushed these now, the most important being
commit
I think Vinson fixed that issue. Let me know if there are still build issues.
Jose
- Original Message -
Sorry. I'll look into it. I did try running make locally, but it was not
representative because it didn't have everything enabled.
BTW, scons is also busted with the recent
Paul Berry stereotype...@gmail.com writes:
Now that there is no difference between the enums that represent
vertex outputs and fragment inputs, there's no need for a conversion
function. But we still need to be able to detect when a given vertex
output has no corresponding fragment input.
well, I'm more familiar w/ EGL where we don't have the xserver
advertising anything, and it is all on the client side.. but when it
is an inexpensive check, it seems reasonable to want mesa to do the
right thing where possible.
It's simply silly. In the same sense that adding yet another if
Paul Berry stereotype...@gmail.com writes:
On 12 March 2013 12:53, Paul Berry stereotype...@gmail.com wrote:
On 12 March 2013 12:28, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
Fast depth clears have the same depth/stencil alignment requirements
as
On Wed, Mar 13, 2013 at 11:19 AM, Zack Rusin za...@vmware.com wrote:
well, I'm more familiar w/ EGL where we don't have the xserver
advertising anything, and it is all on the client side.. but when it
is an inexpensive check, it seems reasonable to want mesa to do the
right thing where
If ddx does not support swap, don't advertise it. This is a hack to
work around current xservers which advertise this extension even when it
is clearly not supported. When:
http://lists.x.org/archives/xorg-devel/2013-February/035449.html
is merged in upstream xserver and makes it's way into
Kenneth Graunke kenn...@whitecape.org writes:
This optimization attempts to avoid extra attribute interpolation
instructions for texture coordinates where the W-component is 1.0.
Unfortunately, it requires a lot of complexity: the brw_wm_input_sizes
state atom (all the brw_vs_constval.c
On 02/27/2013 08:36 AM, Jon TURNEY wrote:
It looks like this has been broken since commit
1a1db1746db82efc7f0643508886dfc78a15eb71 Standardize names of OpenGL
functions.
As far as I can tell, I run this test with every build, and I've never
seen it fail. The ARB names are part of the Linux
On 03/13/2013 06:07 AM, Adrian M Negreanu wrote:
Hi,
I have tested your changes but it looks like they fail to compile on Android.
==
Tested the patch(es) on top of the following commits:
f7ef83c scons: Define PACKAGE_xxx
6f86b93 docs: rewrite
On 03/13/2013 01:14 AM, Jose Fonseca wrote:
Sorry. I'll look into it. I did try running make locally, but it was not
representative because it didn't have everything enabled.
BTW, scons is also busted with the recent autotools changes.
Blarg. Of course it did. :( Has the break been
- Original Message -
On 03/13/2013 01:14 AM, Jose Fonseca wrote:
Sorry. I'll look into it. I did try running make locally, but it was not
representative because it didn't have everything enabled.
BTW, scons is also busted with the recent autotools changes.
Blarg. Of course it
Please don't reply off list. Subscribe to the list and participate. We
can't make decisions that affect everyone behind closed doors.
On 03/13/2013 02:32 AM, Zawistowski, Bartosz L wrote:
Hi Ian,
Thank you for quick feedback. This fix is aimed at separating EXT and
ARB framebuffer_object
Hi,
It's time again for Google Summer of Code, so we need to start updating
the X.Org ideas page (http://www.x.org/wiki/SummerOfCodeIdeas) with new
ideas. Since there have been a few issues with the wikis lately, if you
have any ideas please respond to this thread, and I will make sure they
get
This avoids some snooping overhead between EUs processing separate shaders
(so VS versus FS).
Improves performance of a minecraft trace with shader_time by 28.9% +/-
18.3% (n=7), and performance of my old GLSL demo by 93.7% +/- 0.8% (n=4).
v2: Add a define for the stride with a comment
On Mar 13, 2013 9:25 AM, Kenneth Graunke kenn...@whitecape.org wrote:
On 03/13/2013 06:07 AM, Adrian M Negreanu wrote:
Hi,
I have tested your changes but it looks like they fail to compile on
Android.
==
Tested the patch(es) on top of the
On 03/13/2013 10:40 AM, Brian Paul wrote:
Can you tell me what the parameters are for your OSMesaCreateContext()
and OSMesaMakeCurrent() calls (in particular the image format/type)?
I do not know. I'll do some digging into the VTK source and ask on the
VTK list.
You could also try
From: Tom Stellard thomas.stell...@amd.com
This target string now contains four values instead of three. The old
processor field (which was really being interpreted as arch) has been split
into two fields: processor and arch. This allows drivers to pass a
more a more detailed description of the
From: Tom Stellard thomas.stell...@amd.com
This function is a holdover from r600g and is identical to
si_pm4_inval_texture_cache(), so it is not needed.
---
src/gallium/drivers/radeonsi/radeonsi_pm4.c |6 --
src/gallium/drivers/radeonsi/radeonsi_pm4.h |1 -
From: Tom Stellard thomas.stell...@amd.com
---
src/gallium/drivers/radeonsi/radeonsi_pm4.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/radeonsi_pm4.c
b/src/gallium/drivers/radeonsi/radeonsi_pm4.c
index 9a884f7..4ea30f6 100644
---
From: Tom Stellard thomas.stell...@amd.com
v2:
- Only dump shaders when env variable is set.
v3:
- Don't emit VGT registers
---
src/gallium/drivers/radeon/radeon_llvm_util.c |2 +-
src/gallium/drivers/radeon/radeon_llvm_util.h |2 +
src/gallium/drivers/radeonsi/Makefile.sources
On Wed, Mar 13, 2013 at 2:11 PM, Tom Stellard t...@stellard.net wrote:
From: Tom Stellard thomas.stell...@amd.com
This target string now contains four values instead of three. The old
processor field (which was really being interpreted as arch) has been split
into two fields: processor and
On 12 March 2013 16:33, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
void
-brw_workaround_depthstencil_alignment(struct brw_context *brw)
+brw_workaround_depthstencil_alignment(struct brw_context *brw,
+ GLbitfield
https://bugs.freedesktop.org/show_bug.cgi?id=61416
--- Comment #5 from Mike Lothian m...@fireburn.co.uk ---
Created attachment 76494
-- https://bugs.freedesktop.org/attachment.cgi?id=76494action=edit
Xorg log old
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=61416
Mike Lothian m...@fireburn.co.uk changed:
What|Removed |Added
Attachment #75466|0 |1
is obsolete|
Second attempt, 2 years ago no one replied or cared ...
We really need to know about these on nvc0 because there are only 8
fixed hardware locations that can be overwritten by sprite coordinates,
and one location that represents gl_PointCoord and unconditionally
returns sprite coordinates.
So
https://bugs.freedesktop.org/show_bug.cgi?id=61416
--- Comment #7 from Mike Lothian m...@fireburn.co.uk ---
Created attachment 76498
-- https://bugs.freedesktop.org/attachment.cgi?id=76498action=edit
Glibc error
This shows the glibc lined lists issue
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=61416
Mike Lothian m...@fireburn.co.uk changed:
What|Removed |Added
Summary|Clover doesn't work on a|Clover doesn't
On 12 March 2013 19:29, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com writes:
Now that there is no difference between the enums that represent
vertex outputs and fragment inputs, there's no need for a conversion
function. But we still need to be able to detect
---
lib/Target/R600/AMDILISelDAGToDAG.cpp| 34 ++
lib/Target/R600/R600InstrInfo.cpp| 54 ++
lib/Target/R600/R600InstrInfo.h | 3 ++
lib/Target/R600/R600MachineScheduler.cpp | 77
- Original Message -
Second attempt, 2 years ago no one replied or cared ...
We really need to know about these on nvc0 because there are only 8
fixed hardware locations that can be overwritten by sprite coordinates,
and one location that represents gl_PointCoord and unconditionally
On Wed, Mar 13, 2013 at 09:12:41PM +0100, Vincent Lejeune wrote:
---
lib/Target/R600/AMDILISelDAGToDAG.cpp| 34 ++
lib/Target/R600/R600InstrInfo.cpp| 54 ++
lib/Target/R600/R600InstrInfo.h | 3 ++
lib/Target/R600/R600MachineScheduler.cpp
From: Roland Scheidegger srol...@vmware.com
We can't handle them yet, however we can safely just warn (we will
just render to first layer, which is fine since we can't handle
rendertarget system value neither).
Also make behavior more predictable with buffer surfaces
(it would sometimes hit bogus
From: Roland Scheidegger srol...@vmware.com
instead just warn when creating the surface, rendering will simply happen
to first layer.
---
src/gallium/drivers/llvmpipe/lp_scene.c |2 --
src/gallium/drivers/llvmpipe/lp_texture.c |3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
From: Roland Scheidegger srol...@vmware.com
Those cases were apparently forgotten.
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 30 +++---
1 file changed, 11 insertions(+), 19 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c
The only format returned by _mesa_get_format_base_format() that
satisfies _mesa_is_depthstencil_format() is GL_DEPTH_STENCIL, so we
can simplify the check.
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
---
lib/Target/R600/R600ISelLowering.cpp | 23 +++
test/CodeGen/R600/clamp-constants.ll | 20
2 files changed, 43 insertions(+)
create mode 100644 test/CodeGen/R600/clamp-constants.ll
diff --git a/lib/Target/R600/R600ISelLowering.cpp
On Wed, Mar 13, 2013 at 10:26:38PM +0100, Vincent Lejeune wrote:
---
lib/Target/R600/R600ISelLowering.cpp | 23 +++
test/CodeGen/R600/clamp-constants.ll | 20
2 files changed, 43 insertions(+)
create mode 100644 test/CodeGen/R600/clamp-constants.ll
I fixed the coding style issue.
The iostream include was a debug leftover line, it shouldn't be there.
- Mail original -
De : Tom Stellard t...@stellard.net
À : Vincent Lejeune v...@ovi.com
Cc : llvm-comm...@cs.uiuc.edu; mesa-dev@lists.freedesktop.org
Envoyé le : Mercredi 13 mars
On Wed, Mar 13, 2013 at 3:51 PM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
Second attempt, 2 years ago no one replied or cared ...
We really need to know about these on nvc0 because there are only 8
fixed hardware locations that can be overwritten by sprite coordinates,
and one
On 03/13/2013 12:08 PM, Kevin H. Hobbs wrote:
On 03/13/2013 10:40 AM, Brian Paul wrote:
Can you tell me what the parameters are for your OSMesaCreateContext()
and OSMesaMakeCurrent() calls (in particular the image format/type)?
I do not know. I'll do some digging into the VTK source and ask
Sure:
http://crab-lab.zool.ohiou.edu/kevin/vtkRenderingOpenGLCxxTests
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
The python changes in this file look good to me. I haven't done a
line-by-line review of the SI changes.
I tested this patch and v2 of the related mesa series on r600g (radeon
6850) with a recent LLVM and fresh mesa master as of this evening. No real
change in the piglit CL test success/failure
On 03/13/2013 10:45 AM, Eric Anholt wrote:
This avoids some snooping overhead between EUs processing separate shaders
(so VS versus FS).
Plausible!
Improves performance of a minecraft trace with shader_time by 28.9% +/-
18.3% (n=7), and performance of my old GLSL demo by 93.7% +/- 0.8%
https://bugs.freedesktop.org/show_bug.cgi?id=62319
Priority: medium
Bug ID: 62319
Assignee: mesa-dev@lists.freedesktop.org
Summary: libtxc: missing m4 folder preventing build
Severity: blocker
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=62319
--- Comment #1 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Also, I think there should be no m4 in the .gitignore file (I'm supposing
this from mesa's .gitignore file)
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=62319
Alexandre Demers alexandre.f.dem...@gmail.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
58 matches
Mail list logo
