On Tue, Mar 19, 2013 at 9:21 PM, Dave Airlie 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 changes m
On Mon, Mar 18, 2013 at 03:07:06PM -0700, Jordan Justen wrote:
> On Wed, Mar 13, 2013 at 10:11 AM, Tom Stellard 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 3.2, 3.3 i
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 +-
>
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 Me
Paul Berry writes:
> 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
> C
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 |
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.
---
src/mesa/drivers/dri/i965/brw_pr
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 sinc
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 +++
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 a/src/mesa/drivers/
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 change
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 ++
.../drivers/dri/i965/b
---
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 3e628c8..36b5
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_fs_visito
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 raci
https://bugs.freedesktop.org/show_bug.cgi?id=59187
Chris Forbes changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |chr...@ijw.co.nz
|org
https://bugs.freedesktop.org/show_bug.cgi?id=59187
--- Comment #12 from aa ---
Is anybody working on this?
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.
2013/3/19 Johannes Obermayr :
> 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 libdr
- 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
> b/src/gallium/auxiliary/tgsi/
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 +++
> src/gallium/winsys/svga/drm/vmw_
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
-
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.
>
On Tue, Mar 19, 2013 at 3:57 AM, Pohjolainen, Topi
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 allows Me
---
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 @@ GL_A
---
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 |
From: Dave Airlie
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, see
https://w
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 deletions(-)
On Tue, Mar 19, 2013 at 9:14 AM, 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 defines MAPI_A
---
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 | 3
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 [ma
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.
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
src/ga
Op 19-03-13 12:37, Andreas Boll schreef:
> 2013/3/19 Maarten Lankhorst :
>> Op 18-03-13 16:28, Andreas Boll schreef:
>>> 2013/3/18 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 libmesaga
https://bugs.freedesktop.org/show_bug.cgi?id=62425
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 03/18/2013 10:40 PM, Dave Airlie wrote:
From: Dave Airlie
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 si
2013/3/19 Maarten Lankhorst :
> Op 18-03-13 16:28, Andreas Boll schreef:
>> 2013/3/18 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 libgall
On Tue, Mar 19, 2013 at 8:54 PM, Jose Fonseca 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:
>
> - src/galli
> 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
- 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 a
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
> f70c
- Original Message -
> On Tue, Mar 19, 2013 at 8:29 AM, Dave Airlie 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 pret
https://bugs.freedesktop.org/show_bug.cgi?id=62425
--- Comment #2 from Matthieu Baerts ---
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 the patch from
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:
> * execution/interface-block
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 ca
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_*
- src/gallium/auxiliary/util/u_surf
Hi Brian,
On 3/19/13, Brian Paul 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 texturing.
>
>
>> It
On Die, 2013-03-19 at 11:07 +0100, Michel Dänzer wrote:
> From: Michel Dänzer
>
> 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 not find extension
From: Michel Dänzer
Not sure it actually works though, some buffer callbacks seem to have rotted
before.
Signed-off-by: Michel Dänzer
---
src/gallium/state_trackers/egl/drm/native_drm.c | 8 +++-
src/gallium/state_trackers/egl/wayland/native_drm.c | 8 +++-
src/gallium/state_trac
On Tue, Mar 19, 2013 at 8:29 AM, Dave Airlie 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 do alright
> 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
Op 18-03-13 16:28, Andreas Boll schreef:
> 2013/3/18 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
For the series: Reviewed-by: Chris Forbes
On Tue, Mar 19, 2013 at 2:57 PM, Kenneth Graunke 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 the ARB_texture_multisample e
On Tue, Mar 19, 2013 at 5:40 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> 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 surfa
53 matches
Mail list logo
