When copy_array_to_vbo_array encountered an array with src_stride == 0
and dst_stride != 0, we would replicate out the single element to the
whole size (max - min + 1). This is unnecessary: we can simply upload
one copy and set the buffer's stride to 0.
Decreases vertex upload overhead in an upco
This essentially reverts the following:
commit c625aa19cb53ed27f91bfd16fea6ea727e9a5bbd
Author: Chris Wilson
Date: Fri Feb 18 10:37:43 2011 +
intel: extend current vertex buffers
While working on optimizing an upcoming Steam title, I broke this code.
Eric expressed his doubts
On Fri, Oct 26, 2012 at 10:26 PM, Tzvetan Mikov wrote:
>> -Original Message-
>> From: Jerome Glisse
>
>> > Can anyone shed some light on this? Is this by design - e.g. is
>> > this a case of "we know that tiling is currently slower than linear
>> > but the huge payoff is scheduled to arriv
> -Original Message-
> From: Jerome Glisse
> > Can anyone shed some light on this? Is this by design - e.g. is
> > this a case of "we know that tiling is currently slower than linear
> > but the huge payoff is scheduled to arrive in a future revision"?
> >
> > Thanks!
> > Tzvetan
>
> No,
On Fri, Oct 26, 2012 at 10:01 PM, wrote:
> From: Jerome Glisse
>
> On r6xx/r7xx shader resource management need to make sure that the
> shader does not goes over the gpr register limit. Each specific
> asic has a maxmimum register that can be split btw shader stage.
> For each stage the shader m
From: Jerome Glisse
On r6xx/r7xx shader resource management need to make sure that the
shader does not goes over the gpr register limit. Each specific
asic has a maxmimum register that can be split btw shader stage.
For each stage the shader must not use more register than the
limit programmed.
On Fri, Oct 26, 2012 at 8:07 PM, Tzvetan Mikov wrote:
> Hi,
> I have been running tests with Mesa 9.0 and Rdeon R600 (Radeon HD 6460) and I
> accidentally noticed that a small hack I did to disable texture tiling,
> actually *doubles* the frame rate. With different chips (e.g. 6750) the
> diffe
Hi,
I have been running tests with Mesa 9.0 and Rdeon R600 (Radeon HD 6460) and I
accidentally noticed that a small hack I did to disable texture tiling,
actually *doubles* the frame rate. With different chips (e.g. 6750) the
difference is less pronounced, but in all cases texture tiling decreas
https://bugs.freedesktop.org/show_bug.cgi?id=56410
Matt Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=40611
Matt Turner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Kenneth Graunke writes:
> This patch series replaces the old brw_vs_emit.c backend with a (much
> smaller) translator from Mesa IR -> brw_vec4 IR, similar to what Eric
> recently did on the FS side.
>
> You can obtain this from the 'vpclean' branch of ~kwg/mesa.
>
> Here's the diffstat:
> src/me
Kenneth Graunke writes:
> Rather than having two separate backends, just create a small layer that
> translates the subset of Mesa IR used for ARB_vertex_program and fixed
> function programs to the Vec4 IR. This allows us to use the same
> optimization passes, code generator, register allocator
Kenneth Graunke writes:
> void
> +vec4_visitor::emit_minmax(uint32_t conditionalmod, dst_reg dst,
> + src_reg src0, src_reg src1)
> +{
> + vec4_instruction *inst;
> +
> + if (intel->gen >= 6) {
> + inst = emit(BRW_OPCODE_SEL, dst, src0, src1);
> + inst->cond
On Thu, Oct 25, 2012 at 3:17 PM, Brian Paul wrote:
> On 10/24/2012 02:22 PM, Anuj Phogat wrote:
>>
>>
>> Signed-off-by: Anuj Phogat
>> ---
>> src/mesa/main/format_unpack.c |9 +
>> src/mesa/main/formats.c | 13 +
>> src/mesa/main/formats.h |1 +
>> sr
Variable indexing of non-uniform arrays only exists in GLSL. Likewise,
OPCODE_CAL/OPCODE_RET only existed to try and support GLSL's function
calls. We don't use Mesa IR for GLSL, and these features are explicitly
disallowed by ARB_vertex_program/ARB_fragment_program and never
generated by ffverte
brw_vec4_emit.cpp implements this directly; only the old backend used
the brw_eu_emit.c code.
---
src/mesa/drivers/dri/i965/brw_eu.h | 11
src/mesa/drivers/dri/i965/brw_eu_emit.c | 110
2 files changed, 121 deletions(-)
diff --git a/src/mesa/drivers/dri
The old VS backend doesn't exist, but I believe these still need to be
delivered to the clipper thread.
---
src/mesa/drivers/dri/i965/brw_curbe.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c
b/src/mesa/drivers/dri/i965/brw_cur
It was only used for the old backend.
---
src/mesa/drivers/dri/i965/brw_vs.c | 18 +-
src/mesa/drivers/dri/i965/brw_vs.h | 1 -
2 files changed, 1 insertion(+), 18 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c
b/src/mesa/drivers/dri/i965/brw_vs.c
index 551f977..a8
Only the old backend used it.
---
src/mesa/drivers/dri/i965/brw_context.h | 1 -
src/mesa/drivers/dri/i965/brw_curbe.c | 21 ++-
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 1 -
src/mesa/drivers/dri/i965/brw_vs_state.c| 12 +
src/mesa/drivers/dri/i965/gen6_vs_
It's no longer used for anything.
---
src/mesa/drivers/dri/i965/Makefile.sources |1 -
src/mesa/drivers/dri/i965/brw_context.h|1 -
src/mesa/drivers/dri/i965/brw_vs.h | 24 -
src/mesa/drivers/dri/i965/brw_vs_emit.c| 1810
4 files changed, 1836
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.h | 2 ++
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 37 +-
2 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/drivers/dri/
Rather than having two separate backends, just create a small layer that
translates the subset of Mesa IR used for ARB_vertex_program and fixed
function programs to the Vec4 IR. This allows us to use the same
optimization passes, code generator, register allocator as for GLSL.
Signed-off-by: Kenn
This patch series replaces the old brw_vs_emit.c backend with a (much
smaller) translator from Mesa IR -> brw_vec4 IR, similar to what Eric
recently did on the FS side.
You can obtain this from the 'vpclean' branch of ~kwg/mesa.
Here's the diffstat:
src/mesa/drivers/dri/i965/brw_vs_emit.c
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4.h | 1 +
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp| 4
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 1 +
3 files changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.h
b/src/mesa/d
This will become necessary once we start supporting ARB programs and
fixed function in this backend.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_vec4_emit.cpp | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Similar to commit 41954107c00d68.
diff --git a/src/mesa
On Thu, Oct 25, 2012 at 11:17:59PM +0200, Vincent Lejeune wrote:
> ---
> lib/Target/AMDGPU/R600Instructions.td | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
I've pushed both these patches.
Thanks!
-Tom
> diff --git a/lib/Target/AMDGPU/R600Instructions.td
> b/lib/Target/AMDGPU
On 10/24/2012 10:08 AM, Ian Romanick wrote:
This series contains a bunch of Mesa and GLX fixes releated to sRGB
drawables. It should contain all of the work necessary to allow drivers to
advertise sRGB fbconfigs.
What is missing is a 9th patch to actually add some sRGB fbconfigs to the
Intel dr
Kenneth Graunke writes:
> I like this!
Hmm. Now I'm wondering if this is the right thing. The spec isn't very
clear, but here's a sample:
(5) Should the extension measure total time elapsed between the full
completion of the BeginQuery and EndQuery commands, or just time
s
How well would llvm-pipe run on the"Paralella" chip?
See this kickstarter project below. Looks like it might actually get funded.
http://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-everyone/
Ignoring for a moment there is no LLVM backend for this CPU yet, how well does
This is great. I wanted to do this when I last touched
intel_screen_make_dri_configs but was unable to find the motivation.
I have one suggestion below, but that nit doesn't block the patch.
Reviewed-by: Chad Versace
> + switch (format) {
> + case MESA_FORMAT_RGB565:
> + masks = masks_
Looks good to me. There's a test for gen >= 6, and you've tested it there.
Reviewed-by: Chad Versace
On 10/26/2012 12:39 AM, Tapani Pälli wrote:
> Patch adds additional singlesample config with 565 color buffer,
> 24 bit depth and 8 bit stencil buffer. This makes Quadrant benchmark
> work on And
On 10/26/2012 11:32 AM, Kenneth Graunke wrote:
On 10/26/2012 09:58 AM, Marek Olšák wrote:
We're starting to get apps utilizing more than 16 varyings and
most current hardware supports 32 anyway.
Tested with r600g.
swrast, softpipe and llvmpipe still advertise 16 varyings.
This fixes a WebGL cr
On 10/26/2012 09:58 AM, Marek Olšák wrote:
We're starting to get apps utilizing more than 16 varyings and
most current hardware supports 32 anyway.
Tested with r600g.
swrast, softpipe and llvmpipe still advertise 16 varyings.
This fixes a WebGL crash after launching this demo:
https://developer
We're starting to get apps utilizing more than 16 varyings and
most current hardware supports 32 anyway.
Tested with r600g.
swrast, softpipe and llvmpipe still advertise 16 varyings.
This fixes a WebGL crash after launching this demo:
https://developer.mozilla.org/en-US/demos/detail/falling-cubes
Hi Dave,
On Thu, Oct 25, 2012 at 11:22 PM, Dave Airlie wrote:
> On Thu, Oct 25, 2012 at 11:12 PM, Jose Fonseca wrote:
>> Gallium interface seems a good place to cleanly separate state tracking from
>> rendering. Everything is already done for you -- you just need to insert RPC
>> between Mesa
Patch adds additional singlesample config with 565 color buffer,
24 bit depth and 8 bit stencil buffer. This makes Quadrant benchmark
work on Android. Tested with Sandybridge and Ivybridge machines.
Signed-off-by: Tapani Pälli
---
src/mesa/drivers/dri/intel/intel_screen.c | 9 +++--
1 file c
36 matches
Mail list logo
