Hi Brian,
On 3/19/13, Brian Paul bri...@vmware.com wrote:
It is fair to say, if running llvm driver in my local machine (a
32-bit CentOS 6.2 without VNC connection), it was indeed faster than
the xlib driver.
Seems to me that the llvm driver broken the xlib VNC connection which
could be
From: Michel Dänzer michel.daen...@amd.com
Fixes random failures with piglit glsl-max-varyings.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/si_state_draw.c | 5 +
1 file changed, 5 insertions(+)
diff
Am 20.03.2013 11:43, schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
Fixes random failures with piglit glsl-max-varyings.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
Reviewed-by: Christian König christian.koe...@amd.com
On 03/20/2013 04:07 AM, jupiter wrote:
Hi Brian,
On 3/19/13, Brian Paulbri...@vmware.com wrote:
It is fair to say, if running llvm driver in my local machine (a
32-bit CentOS 6.2 without VNC connection), it was indeed faster than
the xlib driver.
Seems to me that the llvm driver broken the
You're building with scons right?
Jose
- Original Message -
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
Sorry, this has become longer than I anticipated ...
I've been toying with adding support for TGSI_FILE_INPUT/OUTPUT arrays
because, since I cannot allocate varyings in the same order that the
register index specifies, I need it:
===
EXAMPLE:
OUT[0], CLIPDIST[1], must be allocated at address
https://bugs.freedesktop.org/show_bug.cgi?id=61364
--- Comment #6 from Jerome Glisse gli...@freedesktop.org ---
Yeah i saw same issue on radeon
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
I am using Visual Studio. I found that all these missing constants like
MAPI_TABLE_NUM_STATIC are getting there values in mapi_abi.py. Since I am
building it in UEFI I am making [.inf] files and using them to generate the
makefilesand not the makefiles given in the mesa kit. Could this be a
I pushed a different fix for this. The gallium egl code doesn't have
support for buffer sharing via fd passing so we can't just ask the
protocol code to advertise that, even if the kernel has the
DRM_CAP_PRIME features. Instead we just pass 0 for the flags
argument.
thanks,
Kristian
On Tue,
On 19 March 2013 17:10, Eric Anholt e...@anholt.net wrote:
Paul Berry stereotype...@gmail.com 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
The arithmetic to convert a 3D texture slice to an R coordinate was
incorrect. Found when MSVC warned of a divide by zero.
Note that we don't actually ever hit this path. We don't decompress
slices of 3D textures and we don't support 3D mipmap generation yet.
---
src/mesa/drivers/common/meta.c
Am 20.03.2013 15:41, schrieb Christoph Bumiller:
Sorry, this has become longer than I anticipated ...
I've been toying with adding support for TGSI_FILE_INPUT/OUTPUT arrays
because, since I cannot allocate varyings in the same order that the
register index specifies, I need it:
===
On 20.03.2013 17:05, Roland Scheidegger wrote:
Am 20.03.2013 15:41, schrieb Christoph Bumiller:
Sorry, this has become longer than I anticipated ...
I've been toying with adding support for TGSI_FILE_INPUT/OUTPUT arrays
because, since I cannot allocate varyings in the same order that the
Am 20.03.2013 17:46, schrieb Christoph Bumiller:
On 20.03.2013 17:05, Roland Scheidegger wrote:
Am 20.03.2013 15:41, schrieb Christoph Bumiller:
Sorry, this has become longer than I anticipated ...
I've been toying with adding support for TGSI_FILE_INPUT/OUTPUT arrays
because, since I cannot
On 20.03.2013 18:30, Roland Scheidegger wrote:
Am 20.03.2013 17:46, schrieb Christoph Bumiller:
On 20.03.2013 17:05, Roland Scheidegger wrote:
Not sure I fully understand this, but I'm thinking whenever in doubt,
use something close to what dx10 does since that's likely going to work
SCons builds via Visual Studio compilers. So I assume by I am using Visual
Studio you mean, no, I'm not using SCons...
I'd strongly recommend using scons instead of replicating Mesa build with MSVC
project, as Mesa build is extremely complex (a lot of code generation).
If you are determined
https://bugs.freedesktop.org/show_bug.cgi?id=62571
Jesus Cortez jesus.corte...@gmail.com changed:
What|Removed |Added
Assignee|nouveau@lists.freedesktop.o
Am 20.03.2013 19:09, schrieb Christoph Bumiller:
On 20.03.2013 18:30, Roland Scheidegger wrote:
Am 20.03.2013 17:46, schrieb Christoph Bumiller:
On 20.03.2013 17:05, Roland Scheidegger wrote:
Not sure I fully understand this, but I'm thinking whenever in doubt,
use something close to what
https://bugs.freedesktop.org/show_bug.cgi?id=62571
Maarten Lankhorst m.b.lankho...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=62571
--- Comment #3 from Jesus Cortez jesus.corte...@gmail.com ---
(In reply to comment #2)
First of all, this is a bug with scientific linux' packaging probably.
Second, are you sure that it doesn't exist?
ldd /usr/lib/dri/nouveau_dri.so
Yes,
Future patches will allow for there to be separate VUE maps when both
a geometry shader and a vertex shader are in use. When this happens,
we will want to have correspondingly separate outputs_written
bitfields. Moving outputs_written into the VUE map will make this
easy.
For consistency with
Currently, the GPU pipeline has one active VUE map in effect at any
given time--the one representing the layout of vertex data coming from
the vertex shader. However, when geometry shaders are added, they
will have their own independent VUE map. Later pipeline stages (clip,
sf, fs) will need to
This patch modifies post-GS pipeline stages (transform feedback, clip,
sf, fs) to refer to the VUE map through brw-vue_map_geom_out rather
than brw-vs.prog_data-vue_map. This ensures that when geometry
shader support is added, these pipeline stages will consult the
geometry shader output VUE map
With the introduction of geometry shaders, fragment inputs will no
longer come exclusively from the vertex shader; sometimes they come
from the geometry shader. So the name vp_outputs_written will
become a misnomer. This patch renames vp_outputs_written to
input_slots_valid, to reflect the true
On Tuesday 12 March 2013 09:25:07 Ian Romanick wrote:
On 03/10/2013 11:24 AM, Stefan Brüns wrote:
Hi everyone,
I have run into a problem leading to a crashing X server for a bunch of
indirect GLX calls.
This problem affects any OpenGL clients using indirect rendering and
calling
Am Dienstag, 19. März 2013, 21:36:47 schrieb Andreas Boll:
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
On 03/20/2013 02:43 PM, Stefan Brüns wrote:
On Tuesday 12 March 2013 09:25:07 Ian Romanick wrote:
On 03/10/2013 11:24 AM, Stefan Brüns wrote:
Hi everyone,
I have run into a problem leading to a crashing X server for a bunch of
indirect GLX calls.
This problem affects any OpenGL clients using
On Wednesday 20 March 2013 15:47:24 you wrote:
On 03/20/2013 02:43 PM, Stefan Brüns wrote:
On Tuesday 12 March 2013 09:25:07 Ian Romanick wrote:
On 03/10/2013 11:24 AM, Stefan Brüns wrote:
Hi everyone,
I have run into a problem leading to a crashing X server for a bunch of
indirect
On Wednesday 20 March 2013 15:47:24 you wrote:
On 03/20/2013 02:43 PM, Stefan Brüns wrote:
On Tuesday 12 March 2013 09:25:07 Ian Romanick wrote:
On 03/10/2013 11:24 AM, Stefan Brüns wrote:
Hi everyone,
I have run into a problem leading to a crashing X server for a bunch of
indirect
Jordan Justen jordan.l.jus...@intel.com writes:
Previously only 'uniform' was allowed for uniform blocks.
Now, in/out can be parsed, but it will only be allowed for
GLSL = 150.
basic_interface_block:
- UNIFORM NEW_IDENTIFIER '{' member_list '}' instance_name_opt ';'
+
Jordan Justen jordan.l.jus...@intel.com writes:
Interface blocks in GLSL 150 allow an instance name to be used.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/glsl/glsl_parser.yy | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git
Jordan Justen jordan.l.jus...@intel.com writes:
Previously uniform blocks allowed for the 'uniform' keyword
to be used with members of a uniform blocks. With interface
blocks 'in' can be used on 'in' interface block members and
'out' can be used on 'out' interface block members.
The
https://bugs.freedesktop.org/show_bug.cgi?id=61554
It's had more me toos than I would have expected, so I've marked all but
2 incidental patches as a candidate for 9.1. It's also fairly invasive,
so I'm quite uncomfortable doing so. I've tested on gm45, snb, and ivb so
far, and it seems to be
This happens quite a bit with varying-index uniform loads. We could also
do better by avoiding the MACH entirely, but there's no reason not to at
least take this step.
---
src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
We weren't inserting it into the list, so it did nothing. This line was
replaced by the MOV/MUL block above.
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
I'm going to want to change the math for gen7 using sampler LD
instructions in a way that gets CSE to occur like we'd hope.
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 16 +---
src/mesa/drivers/dri/i965/brw_fs.h |3
Right now we don't have anything with regs_written() 1 and !inst-mlen,
but that's about to change.
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/drivers/dri/i965/brw_fs.cpp |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
We want to load vec4s, since loading a vec4 instead of a dword is
basically no increased latency. But for variable indexed access, the
previous requirement of aligned vec4s for a sampler LD was hard to
implement.
Note that this change only affects those messages that use the surface
format, like
I think this makes it much more obvious what's going on here.
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
This is our first CSE on a regs_written() 1 instruction, so it takes a
bit of extra fixup. Reduces the number of loads on kwin's Lanczos shader
from 12 to 2.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61554
NOTE: This is a candidate for the 9.1 branch.
---
We weren't setting needs_dep[i] in the loops, so we'd continue on to
potentially add the same workaround MOVs to the later basic block
boundaries, too. We can either set needs_dep[i] to exit through the
normal path, or we can just return since we know we're done.
---
Like we have done for the VS and for constant-index uniform loads, we use
the sampler engine to get caching in front of the L3 to avoid tickling the
IVB L3 bug. This is also a bit of a functional change, as we're now
loading a vec4 instead of a single dword, though we're not taking
advantage of
For sampler messages, it depends on the target gen, and on gen4
SIMD16-sampler-on-SIMD8-execution we were returning 4 instead of 8 like we
should.
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 29 +++-
This comes at a minor performance cost at the moment (-3.2% +/- 0.2%, n=14 on
my GM45 forced to load all uniforms through the varying-index path), but we
get a whole vec4 at a time to reuse in the next commit.
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/drivers/dri/i965/brw_fs.cpp
All the other expression types allowed here have inst-mlen == 0, and this
one has implied MRF writes for all of its payload, so nothing else in the
implementation should need to change.
Reduces SEND messages for loading from pull constants in kwin's Lanczos
shader from 16 to 6. (Due to a
45 matches
Mail list logo
