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 deficie
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
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 +++-
src/mesa/drivers/dri
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 th
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.
---
src/mesa/drivers/dri/i965/brw
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.
---
src/mesa/drivers/dri/i965
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
b/src/mesa/dri
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
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
b/src/mes
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 +
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
b/src/me
This puts the rounding-up logic into the function itself instead of all
the callers having to manage it. Also drop an "unused" comment in gen4,
as the stride *is* used for texbos (and will be for uniforms soon).
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/drivers/dri/i965/brw_vs_s
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 --
https://bugs.freedesktop.org/show_bug.cgi?id=61554
It's had more "me too"s 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
Jordan Justen 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 basic_interface_block rule
Jordan Justen writes:
> Interface blocks in GLSL 150 allow an instance name to be used.
>
> Signed-off-by: Jordan Justen
> ---
> src/glsl/glsl_parser.yy | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
Jordan Justen 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 ';'
> + interface_qualifier NEW_IDEN
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 bunc
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 bunc
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
Am Dienstag, 19. März 2013, 21:36:47 schrieb Andreas Boll:
> 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 lib
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
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
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 ma
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 c
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 th
https://bugs.freedesktop.org/show_bug.cgi?id=62571
--- Comment #3 from Jesus Cortez ---
(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, the nouveau_dri.so
https://bugs.freedesktop.org/show_bug.cgi?id=62571
Maarten Lankhorst changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 somethin
https://bugs.freedesktop.org/show_bug.cgi?id=62571
--- Comment #1 from Armin K ---
nouveau_dri.so exists on my system in the very same directory. It's Gallium
driver. Add "nouveau" to the --with-gallium-drivers list at build time.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=62571
Jesus Cortez changed:
What|Removed |Added
Assignee|nouveau@lists.freedesktop.o |mesa-dev@lists.freedesktop.
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 determine
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
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,
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
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:
>
> ===
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
On 19 March 2013 17:10, Eric Anholt wrote:
> 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 submi
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, Mar
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 rea
https://bugs.freedesktop.org/show_bug.cgi?id=61364
--- Comment #6 from Jerome Glisse ---
Yeah i saw same issue on radeon
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
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 0x2c
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 M
On 03/20/2013 04:07 AM, jupiter wrote:
Hi Brian,
On 3/19/13, Brian Paul 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
Am 20.03.2013 11:43, schrieb Michel Dänzer:
From: Michel Dänzer
Fixes random failures with piglit glsl-max-varyings.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer
Reviewed-by: Christian König
---
src/gallium/drivers/radeonsi/si_state_draw.c | 5 +
1 f
From: Michel Dänzer
Fixes random failures with piglit glsl-max-varyings.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeonsi/si_state_draw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state_d
Hi Brian,
On 3/19/13, Brian Paul 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 caused by
47 matches
Mail list logo
