On 10.10.2014 18:43, Marek Olšák wrote:
I wonder if it wouldn't be nicer if the cache manager understood that
there are buffers with different flags, so that we don't have to have
so many of them.
Maybe, though it might increase CPU overhead in the cache manager?
Thanks for the review.
--
E
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #19 from Iago Toral ---
Jason, for conversions where we cannot use a fast path in the master converter
(that is, where we need to unpack the src to rgba and then pack from rgba to
dst) you differentiate between 3 paths: uint (integer)
With so many cache managers, memory usage might be a bigger problem.
Usually when a cache manager fails to allocate a new buffer, it clears
the cache and tries again. This is not so useful when there are a lot
of them, because the other managers aren't cleared.
A cache manager also has a limit on
Hi;
Here's a v2 of 'runtime sampler validation' patch. This patch does not
fix existing failure with a Piglit test
'arb_separate_shader_object-active-sampler-conflict' because I consider
that a separate issue. I took a look and that test fails because
_mesa_validate_program_pipeline throws GL_INV
Patch fixes 'glsl-2types-of-textures-on-same-unit' in WebGL conformance
test suite. No Piglit regressions, fixes gl-2.0-active-sampler-conflict.
To avoid adding potentially heavy check during draw (valid_to_render),
check is done during uniform updates by inspecting TexturesUsed mask.
A new boole
Caveat: Shaders using UBO/sampler indexing will
not be optimized by SB, due to SB not currently
supporting the necessary CF_INDEX_[01] index
registers.
Signed-off-by: Glenn Kennard
---
docs/GL3.txt | 4 +--
src/gallium/drivers/r600/eg_asm.c | 52 ++
Requires evergreen/cayman
Signed-off-by: Glenn Kennard
---
docs/GL3.txt | 2 +-
src/gallium/drivers/r600/r600_shader.c | 237 ++-
src/gallium/drivers/r600/r600_state_common.c | 3 +
3 files changed, 238 insertions(+), 4 deletions(
https://bugs.freedesktop.org/show_bug.cgi?id=84570
Kai changed:
What|Removed |Added
Attachment #107574|0 |1
is obsolete||
https://bugs.freedesktop.org/show_bug.cgi?id=84570
--- Comment #19 from Andreas Hartmetz ---
I've noticed that disabling CPU frequency scaling makes a big difference in the
severity of micro-hangs (3.17, dynamic lights off). My explanation is that,
when threads are waiting for each other, the sch
https://bugs.freedesktop.org/show_bug.cgi?id=84570
--- Comment #20 from Ian C. Bullard ---
(In reply to Kai from comment #18)
> That's quite possible, though I can see drops (as shown in the attached
> screenshot), when I do nothing particularily intersting besides moving
> around in an area whic
https://bugs.freedesktop.org/show_bug.cgi?id=84570
--- Comment #21 from Kai ---
(In reply to Andreas Hartmetz from comment #19)
> I've noticed that disabling CPU frequency scaling makes a big difference in
> the severity of micro-hangs (3.17, dynamic lights off). My explanation is
> that, when th
https://bugs.freedesktop.org/show_bug.cgi?id=84570
--- Comment #22 from Ian C. Bullard ---
(In reply to Kai from comment #21)
> From my POV that sounds
> like "supporting" Radeons with the FLOSS driver should be ok or at least not
> worse than nVidia cards. Especially when combined with Andreas'
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #20 from Jason Ekstrand ---
(In reply to Iago Toral from comment #18)
> (In reply to Jason Ekstrand from comment #17)
> > (In reply to Iago Toral from comment #16)
> > > We also need new mesa_format enums and pack/unpack functions for
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #21 from Jason Ekstrand ---
(In reply to Iago Toral from comment #19)
> Jason, for conversions where we cannot use a fast path in the master
> converter (that is, where we need to unpack the src to rgba and then pack
> from rgba to ds
On Tue, Oct 14, 2014 at 4:42 PM, Kenneth Graunke
wrote:
> According to INTEL_DEBUG=perf, "Borderlands: The Pre-Sequel" was
> stalling on nearly every glBufferSubData call, with very slightly
> overlapping busy ranges.
>
> It turns out the draw upload code was accidentally including an extra
> str
On Wednesday, October 15, 2014 09:50:42 AM Jason Ekstrand wrote:
> On Tue, Oct 14, 2014 at 4:42 PM, Kenneth Graunke
> wrote:
>
> > According to INTEL_DEBUG=perf, "Borderlands: The Pre-Sequel" was
> > stalling on nearly every glBufferSubData call, with very slightly
> > overlapping busy ranges.
>
diff --git a/src/gallium/targets/pipe-loader/pipe_i965.c
b/src/gallium/targets/pipe-loader/pipe_i965.c
index f4d447c..810dffc 100644
--- a/src/gallium/targets/pipe-loader/pipe_i965.c
+++ b/src/gallium/targets/pipe-loader/pipe_i965.c
@@ -21,6 +21,27 @@ create_screen(int fd)
return screen;
}
Whoops, forgot to add the description. This is another trivial patch for
ilo, all the frameworks were already implemented. In hindsight, I should
have included this with my previous patch.
On Wed, Oct 15, 2014 at 4:08 PM, Nick Sarnie
wrote:
> diff --git a/src/gallium/targets/pipe-loader/pipe_i96
NewBufferObject took a "target" parameter, which it blindly passed to
_mesa_initialize_buffer_object(), which ignored it.
Not much point in passing it around.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i915/intel_buffer_objects.c| 4 ++--
src/mesa/drivers/dri/i965/intel_buffer
On 10/15/2014 03:06 PM, Kenneth Graunke wrote:
NewBufferObject took a "target" parameter, which it blindly passed to
_mesa_initialize_buffer_object(), which ignored it.
Not much point in passing it around.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i915/intel_buffer_objects.c
Tested-by: David Heidelberger
---
src/gallium/targets/vdpau/Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/targets/vdpau/Makefile.am
b/src/gallium/targets/vdpau/Makefile.am
index 2d6e2e7..c137d04 100644
--- a/src/gallium/targets/vdpau/Makefile.am
+++ b/src/gallium/
Consider GLSL code such as:
const ivec2 offsets[] =
ivec2[](ivec2(-1, -1), ivec2(-1, 0), ivec2(-1, 1),
ivec2(0, -1), ivec2(0, 0), ivec2(0, 1),
ivec2(1, -1), ivec2(1, 0), ivec2(1, 1));
ivec2 offset = offsets[];
Both i965 and nv50 currently handle this v
I like the idea (when you suggested it in April), but I think this
implementation has some issues. I believe making the constant array
into a uniform will cause it to be shown by the GL API (e.g., returned
by glGetActiveUniform) and counted against uniform limits. Since I
doubt we have any piglit
On 10/15/2014 01:15 PM, Brian Paul wrote:
> On 10/15/2014 03:06 PM, Kenneth Graunke wrote:
>> NewBufferObject took a "target" parameter, which it blindly passed to
>> _mesa_initialize_buffer_object(), which ignored it.
>>
>> Not much point in passing it around.
>>
>> Signed-off-by: Kenneth Graunke
On 10/15/2014 10:04 AM, Kenneth Graunke wrote:
> On Wednesday, October 15, 2014 09:50:42 AM Jason Ekstrand wrote:
>> On Tue, Oct 14, 2014 at 4:42 PM, Kenneth Graunke
>> wrote:
>>
>>> According to INTEL_DEBUG=perf, "Borderlands: The Pre-Sequel" was
>>> stalling on nearly every glBufferSubData call,
Nothing uses the vector_elements temporary variable.
Setting this->result.file is dead because we overwrite this->result a
few lines later.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 8
1 file changed, 8 deletions(-)
diff --git a/src/mesa/drive
Previously, we generated an extra CMP instruction:
cmp.ge.f0(8) g4<1>D g2<0,1,0>F 0F
cmp.nz.f0(8) nullg4<8,8,1>D 0D
(+f0) sel(8) g120<1>Fg2.4<0,1,0>Fg3<0,1,0>F
The first operand is always a boolean, and we want to predicate the SEL
on that
Previously, we generated an extra CMP instruction:
cmp.ge.f0(8)g6<1>D g1<0,4,1>F 0F
cmp.nz.f0(8)nullg6<4,4,1>D 0D
(+f0) sel(8)g5<1>F g1.4<0,4,1>Fg2<0,4,1>F
The first operand is always a boolean, and we want to predicate the SEL
on t
Using dst_reg(this, ir->type) automatically sets the writemask to the
proper size for the type; src_reg(dst_reg) preserves that. This should
be equivalent, but less code.
Note that src_reg(dst_reg) either uses SWIZZLE_ or SWIZZLE_XYZW, so
the old code did need the manual writemask adjustment,
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #22 from Iago Toral ---
(In reply to Jason Ekstrand from comment #20)
> (In reply to Iago Toral from comment #18)
> > (In reply to Jason Ekstrand from comment #17)
> > > (In reply to Iago Toral from comment #16)
> > > > We also need n
From: Michel Dänzer
The trick is to generate a unique buffer usage value for each possible
combination of domains and flags, with only one bit set each for the
domains and flags. This ensures pb_check_usage() only returns TRUE when
the domains and flags the cached buffer was created for exactly m
31 matches
Mail list logo
