On Mon, Mar 18, 2013 at 01:45:26PM -0700, Ian Romanick wrote:
On 03/13/2013 10:11 AM, Tom Stellard wrote:
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
Kenneth Graunke kenn...@whitecape.org writes:
On 03/18/2013 03:56 PM, Eric Anholt wrote:
On an INTEL_DEBUG=perf piglit run on IVB, reduces the instances of HW
workaround: blit (the printouts from the misaligned-depth workaround
blits) from 725 to 684
It doesn't totally eliminate the
So we have this virtual GPU with nothing approaching a 3D engine,
so we are currently running llvmpipe with drisw on it. However
this incurs some overheads that now that we have a kernel driver,
I believe we can remove.
The main overheads are putimage for all rendering from
a 3D compositor and
From: Dave Airlie airl...@redhat.com
We have cases on virtual GPU hw that renders using a wrapped llvmpipe,
that we can't produce the normal DRI2 semantics having the kernel/hw
enforce synchronisation semantics. It is also suboptimal to flush
all surfaces on the server side in the block handler.
From: Dave Airlie airl...@redhat.com
This is for a specific use-case for the QXL driver (which wraps
llvmpipe/softpipe). Texture it get via TFP are inverted, so
we need to use a negative stride to sample from them. So
this converts a bunch of cases where we use unsigned stride
to a signed value.
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
On Mon, Mar 18, 2013 at 6:57 PM, Kenneth Graunke kenn...@whitecape.org wrote:
This series improves our basic GLSL 1.50 support. First, it makes 1.50
shaders using built-in functions work. Secondly, it adds the new types
and built-ins from
On Tue, Mar 19, 2013 at 5:40 AM, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
We have cases on virtual GPU hw that renders using a wrapped llvmpipe,
that we can't produce the normal DRI2 semantics having the kernel/hw
enforce synchronisation semantics. It is also
For the series: Reviewed-by: Chris Forbes chr...@ijw.co.nz
On Tue, Mar 19, 2013 at 2:57 PM, Kenneth Graunke kenn...@whitecape.org wrote:
This series improves our basic GLSL 1.50 support. First, it makes 1.50
shaders using built-in functions work. Secondly, it adds the new types
and built-ins
Op 18-03-13 16:28, Andreas Boll schreef:
2013/3/18 Maarten Lankhorst maarten.lankho...@canonical.com:
This is one of the 2 patches used in ubuntu for decreasing size of mesa
build.
The other one is more hacky, and links libmesagallium into libgallium,
and then links libgallium against
Errr, what about using flush_frontbuffer, it seems todo
the exact same thing.
Hmm I wonder if I could overload it actually I hadn't considered that,
its not exactly the same thing,
but its pretty close to what I'd want to do alright.
diff --git a/src/gallium/drivers/softpipe/sp_texture.h
On Tue, Mar 19, 2013 at 8:29 AM, Dave Airlie airl...@gmail.com wrote:
Errr, what about using flush_frontbuffer, it seems todo
the exact same thing.
Hmm I wonder if I could overload it actually I hadn't considered that,
its not exactly the same thing,
but its pretty close to what I'd want to
From: Michel Dänzer michel.daen...@amd.com
Not sure it actually works though, some buffer callbacks seem to have rotted
before.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/state_trackers/egl/drm/native_drm.c | 8 +++-
On Die, 2013-03-19 at 11:07 +0100, Michel Dänzer wrote:
From: Michel Dänzer michel.daen...@amd.com
Not sure it actually works though, some buffer callbacks seem to have rotted
before.
Also, more than 20 piglit tests are now failing with radeonsi (via
egl_dri2) with:
libEGL fatal: DRI2: did
Hi Brian,
On 3/19/13, Brian Paul bri...@vmware.com wrote:
I'm not familiar with glxspheres. But the xlib/swrast driver was
optimized for simple things like glxgears. llvm might be slower on
that kind of thing, but it should be much, much faster with modern
apps that uses shaders and
I think this is fine in principle, but I believe it's better to be exhaustive
now than to waste time debugging unsigned/signed stride mismatches later.
Especially all src/gallium/auxiliary/util modules should be updated:
- src/gallium/auxiliary/util/u_format_*
-
Ported from downstream:
http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/119-libllvmradeon-link.patch;h=ee47f8a07dbf33c32f8b57faed923680ed6648fb;hb=refs/heads/ubuntu%2B1
Fixes a regression introduced with
f70c3853513637fa6ed38e75f73d472a9fa61213
NOTE: This is a
On Mon, Mar 18, 2013 at 04:35:10PM -0700, Jordan Justen wrote:
With this change we now support interface block arrays.
For example, cases like this:
out block_name {
float f;
} block_instance[2];
This allows Mesa to pass the piglit glsl-1.50 test:
*
https://bugs.freedesktop.org/show_bug.cgi?id=62425
--- Comment #2 from Matthieu Baerts matt...@gmail.com ---
Hello Brian,
Thank you for this quick answer!
(In reply to comment #1)
This sounds the same as fedora bug 918661:
http://bugzilla.redhat.com/show_bug.cgi?id=918661
Can you see if
- Original Message -
On Tue, Mar 19, 2013 at 8:29 AM, Dave Airlie airl...@gmail.com wrote:
Errr, what about using flush_frontbuffer, it seems todo
the exact same thing.
Hmm I wonder if I could overload it actually I hadn't considered that,
its not exactly the same thing,
but its
Hey,
Op 19-03-13 11:55, Andreas Boll schreef:
Ported from downstream:
http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=blob;f=debian/patches/119-libllvmradeon-link.patch;h=ee47f8a07dbf33c32f8b57faed923680ed6648fb;hb=refs/heads/ubuntu%2B1
Fixes a regression introduced with
- Original Message -
So we have this virtual GPU with nothing approaching a 3D engine,
so we are currently running llvmpipe with drisw on it. However
this incurs some overheads that now that we have a kernel driver,
I believe we can remove.
The main overheads are putimage for all
I have no particular objection with the above in principle, as this seems a
perfectly valid use of llvmpipe.
I just have some remarks on implementation details done separately.
For my curiosity sake, how much these changes matter in practice? (For
example, what is the % effect of gloss
On Tue, Mar 19, 2013 at 8:54 PM, Jose Fonseca jfons...@vmware.com wrote:
I think this is fine in principle, but I believe it's better to be exhaustive
now than to waste time debugging unsigned/signed stride mismatches later.
Especially all src/gallium/auxiliary/util modules should be updated:
2013/3/19 Maarten Lankhorst maarten.lankho...@canonical.com:
Op 18-03-13 16:28, Andreas Boll schreef:
2013/3/18 Maarten Lankhorst maarten.lankho...@canonical.com:
This is one of the 2 patches used in ubuntu for decreasing size of mesa
build.
The other one is more hacky, and links
On 03/18/2013 10:40 PM, Dave Airlie wrote:
From: Dave Airlieairl...@redhat.com
We have cases on virtual GPU hw that renders using a wrapped llvmpipe,
that we can't produce the normal DRI2 semantics having the kernel/hw
enforce synchronisation semantics. It is also suboptimal to flush
all
https://bugs.freedesktop.org/show_bug.cgi?id=62425
Brian Paul bri...@vmware.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Op 19-03-13 12:37, Andreas Boll schreef:
2013/3/19 Maarten Lankhorst maarten.lankho...@canonical.com:
Op 18-03-13 16:28, Andreas Boll schreef:
2013/3/18 Maarten Lankhorst maarten.lankho...@canonical.com:
This is one of the 2 patches used in ubuntu for decreasing size of mesa
build.
The
Use vmw_printf() just for extra debugging info (off by default).
Use vmw_error() for real errors/failures/etc that we definitely
want to report.
---
src/gallium/winsys/svga/drm/vmw_context.h | 10 +++
src/gallium/winsys/svga/drm/vmw_screen_dri.c | 34
On 15.03.2013 22:16, Christoph Bumiller wrote:
This makes it possible to identify gl_TexCoord and gl_PointCoord
for drivers where sprite coordinate replacement is restricted.
The new PIPE_CAP_TGSI_TEXCOORD decides whether these varyings
should be hidden behind the GENERIC semantic or not.
Hi,
I used the latest mesa and I am still receiving the same errors. It works
perfectly fine in Ubuntu though.
Can somebody please tell in the file mapi_tmp.h how does the following constant
included?
#include MAPI_ABI_HEADER
Thanks,
Ritvik
-Original Message-
From: Jose Fonseca
---
src/gallium/drivers/r600/eg_asm.c | 38 +++
src/gallium/drivers/r600/eg_sq.h | 59
src/gallium/drivers/r600/r600_asm.c| 119 +
src/gallium/drivers/r600/r600_asm.h| 8 ++-
src/gallium/drivers/r600/r600_shader.c |
On Tue, Mar 19, 2013 at 9:14 AM, ritvik_sha...@dell.com wrote:
Hi,
I used the latest mesa and I am still receiving the same errors. It works
perfectly fine in Ubuntu though.
Can somebody please tell in the file mapi_tmp.h how does the following
constant included?
Look at how Makefile.am
We check the extension version manually instead and verify that we have
the createImageFromFds function before enabling prime fd passing.
---
src/egl/drivers/dri2/egl_dri2.c | 6 --
src/egl/drivers/dri2/platform_wayland.c | 9 +
2 files changed, 13 insertions(+), 2
From: Dave Airlie airl...@gmail.com
v2 [mattst88]:
- Rebase.
- #define GL_ARB_texture_query_lod to 1.
- Remove comma after ir_lod in ir.h for MSVC.
- Handled ir_lod in ir_hv_accept.cpp, ir_rvalue_visitor.cpp,
opt_tree_grafting.cpp.
- Rename textureQueryLOD to textureQueryLod,
---
src/mesa/drivers/dri/i965/brw_defines.h|2 ++
src/mesa/drivers/dri/i965/brw_fs.cpp |4 +++-
src/mesa/drivers/dri/i965/brw_fs_emit.cpp |6 ++
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |9 +
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp |
---
docs/GL3.txt |2 +-
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index de51693..212e590 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -87,7 +87,7 @@
On Tue, Mar 19, 2013 at 3:57 AM, Pohjolainen, Topi
topi.pohjolai...@intel.com wrote:
On Mon, Mar 18, 2013 at 04:35:10PM -0700, Jordan Justen wrote:
With this change we now support interface block arrays.
For example, cases like this:
out block_name {
float f;
} block_instance[2];
This
Am Montag, 18. März 2013, 15:38:31 schrieb Maarten Lankhorst:
This is one of the 2 patches used in ubuntu for decreasing size of mesa build.
The other one is more hacky, and links libmesagallium into libgallium,
and then links libgallium against libdricore too for minimal duplication.
I am
Fixes a few regressions since the TGSI array changes.
---
src/gallium/auxiliary/tgsi/tgsi_build.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_build.c
b/src/gallium/auxiliary/tgsi/tgsi_build.c
index 435d94a..509bc5c 100644
LGTM.
Jose
- Original Message -
Use vmw_printf() just for extra debugging info (off by default).
Use vmw_error() for real errors/failures/etc that we definitely
want to report.
---
src/gallium/winsys/svga/drm/vmw_context.h | 10 +++
- Original Message -
Fixes a few regressions since the TGSI array changes.
---
src/gallium/auxiliary/tgsi/tgsi_build.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_build.c
2013/3/19 Johannes Obermayr johannesoberm...@gmx.de:
Am Montag, 18. März 2013, 15:38:31 schrieb Maarten Lankhorst:
This is one of the 2 patches used in ubuntu for decreasing size of mesa
build.
The other one is more hacky, and links libmesagallium into libgallium,
and then links libgallium
https://bugs.freedesktop.org/show_bug.cgi?id=59187
--- Comment #12 from aa pets1...@gmail.com ---
Is anybody working on this?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=59187
Chris Forbes chr...@ijw.co.nz changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |chr...@ijw.co.nz
Normally when submitting the first batch buffer after a flush, we
check whether the GPU has completed processing of the first batch
buffer of the previous frame. If it hasn't, we wait for it to finish
before submitting any more batches. This prevents GPU-heavy and
CPU-light applications from
Previously, if you just wrote a constant color to the render target, no
time got noted at all. This is convenient for doing single-instruction
timings, but not so much for actual program analysis.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |3 ---
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 49 +---
src/mesa/drivers/dri/i965/brw_vec4.h |1 +
2 files changed, 39 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index
This incidentally also teaches it a bit about gen6 math -- we now allow
unswizzled, unmodified GRF temps as the sources for math.
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 12
src/mesa/drivers/dri/i965/brw_vec4.h |6 ++
This much more accurately reflects the cost of the vertex shader, since
the payload setup is often a significant fraction of the instructions in
the VS.
---
src/mesa/drivers/dri/i965/brw_vec4.cpp |3 ---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 12 +++-
2 files
This will let us emit it later, after we're setting up MRFs for the
URB write.
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 24
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp |3 +--
2 files changed, 13 insertions(+), 14 deletions(-)
diff --git
This will let us do much better printouts for non-GLSL programs.
---
src/mesa/drivers/dri/i965/brw_context.h |7 +-
src/mesa/drivers/dri/i965/brw_fs.cpp| 14 ++--
src/mesa/drivers/dri/i965/brw_fs.h |2 +-
src/mesa/drivers/dri/i965/brw_program.c | 38
I've been experimenting with the simd16 replicated data message
(non-gen7-specific fast clears), and was bothered that shader_time wasn't
noting any time spent in our clear FS currently, so I wasn't totally sure
which apps I should be looking at.
Many apps won't spend any time in the clear FS
Ken asked me the other day what -1 vs 0 vs 3 vs other meant in our shader
names, and I realized that it was really unclear. I'd like to do even
better, like noting which one is the clear shader, but that would require
exposing the metaops struct to the driver.
---
This avoids conflicts between shader_time and FB writes, so we can include
more of the program under our profiling. This does mean hiding more of
the message setup from the optimizer, which doesn't have a way to handle
multi-reg sends from GRFs.
---
src/mesa/drivers/dri/i965/brw_eu.h |
Mesa 9.1.1 has been released. Mesa 9.1.1 is a bug fix release which
fixes bugs found since the 9.1 release.
The tag in the GIT repository for Mesa 9.1.1 is 'mesa-9.1.1'.
Mesa 9.1.1 is available for download at
ftp://freedesktop.org/pub/mesa/9.1.1/
md5sums:
6508d9882d8dce7106717f365632700c
On Sat, Mar 16, 2013 at 05:45:31PM +0100, Vincent Lejeune wrote:
It allows the backend to generate reads to constant cache which
are faster that VTX_READ.
Hi Vincent,
Is there a corresponding Mesa change that goes with this patch?
-Tom
---
lib/Target/R600/R600ISelLowering.cpp | 2 +-
1
On Mon, Mar 18, 2013 at 03:07:06PM -0700, Jordan Justen wrote:
On Wed, Mar 13, 2013 at 10:11 AM, Tom Stellard t...@stellard.net wrote:
- A brief description of the project
- A difficulty rating (e.g. easy, medium, hard)
- The skills / programming languages required
GL/GLSL tests for GL
On Tue, Mar 19, 2013 at 9:21 PM, Dave Airlie airl...@gmail.com wrote:
I have no particular objection with the above in principle, as this seems a
perfectly valid use of llvmpipe.
I just have some remarks on implementation details done separately.
For my curiosity sake, how much these
58 matches
Mail list logo
