On 04/07/2014 06:24 AM, Ian Romanick wrote:
On 04/06/2014 11:49 PM, Kenneth Graunke wrote:
The i965 MUL instruction doesn't natively support 32-bit by 32-bit
integer multiplication; additional instructions (MACH/MOV) are required.
However, we can avoid those if we know one of the operands can
On 04/07/2014 05:41 AM, Ilia Mirkin wrote:
On Mon, Apr 7, 2014 at 2:49 AM, Kenneth Graunke kenn...@whitecape.org wrote:
The i965 MUL instruction doesn't natively support 32-bit by 32-bit
integer multiplication; additional instructions (MACH/MOV) are required.
However, we can avoid those if we
This extension is a huge grab-bag of stuff that's in DX11. Break it
apart to make it clear what still needs to be done.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
docs/GL3.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index
Notice our multiple values for M_PI_2, which rounded ...32 up to
...4 and ...5.
---
src/glsl/builtin_functions.cpp | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp b/src/glsl/builtin_functions.cpp
index 26ea923..3991f9d
On 04/07/2014 11:00 AM, Matt Turner wrote:
On Sun, Apr 6, 2014 at 11:49 PM, Kenneth Graunke kenn...@whitecape.org
wrote:
Integer shifts are basically always well supported and efficient; that
isn't always true of integer division, and sometimes even integer
multiplication isn't without
is_power_of_two() is now provided by mesa so its definition must be removed
from the i915 driver code.
---
src/mesa/drivers/dri/i915/intel_context.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/intel_context.h
b/src/mesa/drivers/dri/i915/intel_context.h
On 04/07/2014 09:20 PM, Courtney Goeltzenleuchter wrote:
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's
On 04/08/2014 12:27 AM, Iago Toral Quiroga wrote:
is_power_of_two() is now provided by mesa so its definition must be removed
from the i915 driver code.
---
src/mesa/drivers/dri/i915/intel_context.h | 6 --
1 file changed, 6 deletions(-)
diff --git
Thanks for the review Eric.
I am attaching reverts for two commits:
intel: Fix initial MakeCurrent for single-buffer drawables
11baad35088dfd4bdabc1710df650dbfb413e7a3
i965: Only update renderbuffers on initial intelMakeCurrent
05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39
The first commit is the
This reverts commit 05da4a7a5e7d5bd988cb31f94ed8e1f053d9ee39.
We should always call intel_prepare_render in MakeCurrent.
---
src/mesa/drivers/dri/i965/brw_context.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
This reverts commit 11baad35088dfd4bdabc1710df650dbfb413e7a3.
This was producing regressions, at least:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74005
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77083
---
src/mesa/drivers/dri/i965/brw_context.c | 10 ++
1 file
On 04/02/2014 01:05 AM, Chris Forbes wrote:
Signed-off-by: Chris Forbes chr...@ijw.co.nz
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git
On 04/02/2014 01:05 AM, Chris Forbes wrote:
The sampler can handle R8G8B8X8 (and substitute 1.0 for the fourth
component) but we can't use it as a render target.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
src/mesa/drivers/dri/i965/brw_surface_formats.c | 3 +++
1 file changed, 3
Building fails in i830_state.c
Broken version: 73f80c20f68cd30421c13da29d7d7801ed096101
Last known good version: 4ccff1499c956b51f18710c7308cbce883f64cd9
In file included from intel_batchbuffer.h:6:0,
from i830_state.c:40:
intel_context.h:508:1: error: redefinition of
On 04/02/2014 01:04 AM, Chris Forbes wrote:
This series adds ARB_texture_view support for i965 Gen7/7.5.
Significant changes from V2:
- All the assorted post-V2 format fixups are moved to the start of the series.
This gives us consistent memory layout for all the formats between which we
Hi Knut,
this should be now fixed in master by commit
dff3439fef8690192bcc40108729da711fcf706b.
Thanks,
Iago
On Tue, 2014-04-08 at 10:49 +0200, Knut Petersen wrote:
Building fails in i830_state.c
Broken version: 73f80c20f68cd30421c13da29d7d7801ed096101
Last known good version:
On 04/08/2014 01:49 AM, Knut Petersen wrote:
Building fails in i830_state.c
Broken version: 73f80c20f68cd30421c13da29d7d7801ed096101
Last known good version: 4ccff1499c956b51f18710c7308cbce883f64cd9
In file included from intel_batchbuffer.h:6:0,
from i830_state.c:40:
On 08.04.2014 11:27, Kenneth Graunke wrote:
On 04/08/2014 01:49 AM, Knut Petersen wrote:
Building fails in i830_state.c
Broken version: 73f80c20f68cd30421c13da29d7d7801ed096101
Last known good version: 4ccff1499c956b51f18710c7308cbce883f64cd9
In file included from intel_batchbuffer.h:6:0,
On 01/21/2014 03:35 PM, Fredrik Höglund wrote:
So here is my take on GL_ARB_multi_bind.
I tried to come up with names for the new hash table functions that
don't suggest that they should be used to do unlocked insertions/lookups.
I'm not entirely happy with the ones I came up with though, so
This should help prevent situations where we render without proper index
bounds. For example: https://bugs.freedesktop.org/show_bug.cgi?id=59455
---
src/mesa/drivers/dri/i965/brw_draw.c | 24 ++--
src/mesa/drivers/dri/nouveau/nouveau_vbo_t.c | 6 ++---
btw, I think I've tracked down at least one of the rendercheck issues
I was having. Which seems to be a pre-existing condition. The
problem is a composite operation with xrgb src and a8 dst. Ends up
generating a shader along the lines of:
0: TEX TEMP[0], IN[0], SAMP[0], 2D
1: MOV
On Tue, Apr 8, 2014 at 2:52 AM, Eric Anholt e...@anholt.net wrote:
Chia-I Wu olva...@gmail.com writes:
From: Chia-I Wu o...@lunarg.com
Given
mov vgrf7, vgrf9.xyxz
add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw
add vgrf10.x, vgrf6.xyzw, vgrf7.
the last instruction would be wrongly
It looks like i965 was the only thing directly calling _tnl_draw_prims
without going through _tnl_vbo_draw_prims. That was a good suggestion,
Eric.
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
On 04/08/2014 04:01 AM, Iago Toral Quiroga wrote:
This should help prevent situations where we
On Mon, Apr 7, 2014 at 11:57 PM, Chris Forbes chr...@ijw.co.nz wrote:
This extension is a huge grab-bag of stuff that's in DX11. Break it
apart to make it clear what still needs to be done.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
docs/GL3.txt | 11 +++
1 file changed, 11
Apologies folks, I had made those changes and somehow grabbed the wrong
patch when I went to add the bug reference. Ugh.
This time for sure! I'll follow this with the -- real -- patch.
Courtney
On Tue, Apr 8, 2014 at 1:28 AM, Kenneth Graunke kenn...@whitecape.orgwrote:
On 04/07/2014 09:20
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's Manhattan test.
v2: add more detail comment. Compute limit outside
From: Christian König christian.koe...@amd.com
v2: move allocation to a function as first step
to clean vid_enc_EncodeFrame
Signed-off-by: Christian König christian.koe...@amd.com
Signed-off-by: Leo Liu leo@amd.com
---
src/gallium/state_trackers/omx/vid_enc.c | 124
From: Leo Liu leo@amd.com
cleanup by moving each step into a separate function
Signed-off-by: Leo Liu leo@amd.com
---
src/gallium/state_trackers/omx/vid_enc.c | 220 +--
1 file changed, 118 insertions(+), 102 deletions(-)
diff --git
Am 08.04.2014 16:57, schrieb Leo Liu:
From: Christian König christian.koe...@amd.com
v2: move allocation to a function as first step
to clean vid_enc_EncodeFrame
Signed-off-by: Christian König christian.koe...@amd.com
Signed-off-by: Leo Liu leo@amd.com
Reviewed and pushed both
On Mon, Apr 7, 2014 at 9:24 AM, Eric Anholt e...@anholt.net wrote:
Iago Toral Quiroga ito...@igalia.com writes:
Commit 11baad35088dfd4bdabc1710df650dbfb413e7a3 produces a regression when
switching a single context between multiple drawables.
The problem is that we check whether we have a
On 04/07/2014 11:57 PM, Chris Forbes wrote:
This extension is a huge grab-bag of stuff that's in DX11. Break it
apart to make it clear what still needs to be done.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
---
docs/GL3.txt | 11 +++
1 file changed, 11 insertions(+)
diff
Kenneth Graunke kenn...@whitecape.org writes:
On 04/02/2014 01:04 AM, Chris Forbes wrote:
This series adds ARB_texture_view support for i965 Gen7/7.5.
Significant changes from V2:
- All the assorted post-V2 format fixups are moved to the start of the
series.
This gives us consistent
On 04/08/2014 02:13 AM, Kenneth Graunke wrote:
On 04/02/2014 01:04 AM, Chris Forbes wrote:
This series adds ARB_texture_view support for i965 Gen7/7.5.
Significant changes from V2:
- All the assorted post-V2 format fixups are moved to the start of the
series.
This gives us consistent
On 04/08/2014 08:10 AM, Courtney Goeltzenleuchter wrote:
Decompressing ETC2 textures was causing intermitent segfault
by copying resulting 4x4 texel block to the destination texture
regardless of the size of the destination texture. Issue found
via application crash in GLBenchmark 3.0's
On 04/04/2014 01:20 PM, Thomas Hellstrom wrote:
NAK!
No generic mmap() APIs of GBM bos, please.
The reason is that this impossible to implement in an efficient way on
non-coherent architectures, and once the interface is there, people will
start using it and ignore the non-coherent
On 04/04/2014 01:37 PM, Emil Velikov wrote:
On 04/04/14 09:36, Ander Conselvan de Oliveira wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
This should give the caller some information of what called the error.
For the gbm_bo_import() case, for instance, it is
On 04/04/2014 02:06 PM, Emil Velikov wrote:
On 04/04/14 09:36, Ander Conselvan de Oliveira wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
A few minor nits inline.
---
src/gbm/Makefile.am| 14 +-
src/gbm/backends/intel/gbm_intel.c | 258
Ian,
Would we put that format in a view class by itself?
-- Chris
On Wed, Apr 9, 2014 at 7:49 AM, Ian Romanick i...@freedesktop.org wrote:
On 04/08/2014 02:13 AM, Kenneth Graunke wrote:
On 04/02/2014 01:04 AM, Chris Forbes wrote:
This series adds ARB_texture_view support for i965 Gen7/7.5.
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Changes from previous version:
- make it clearer that the interface is optional;
- fix other issues raised on the last review round.
Thanks,
Ander
Ander Conselvan de Oliveira (10):
gbm/dri: Fix out-of-memory error
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
This allows the pointer stored in dri2_surf in the EGL platform to be
changed to a generic gbm_surface pointer.
---
src/egl/drivers/dri2/egl_dri2.h | 2 +-
src/egl/drivers/dri2/platform_drm.c | 37
From: Neil Roberts n...@linux.intel.com
It looks like this bit of code is trying to disable the prime capability if
the driver doesn't support createImageFromFds. However the logic looks a bit
broken and what it would actually do is disable all other capabilities apart
from prime. This patch
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Otherwise it fails to compile if the drm egl platform is disabled.
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
Reviewed-by: Emil Velikov emil.l.veli...@gmail.com
---
src/egl/drivers/dri2/egl_dri2.c | 2 ++
1 file
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Add gbm_bo_map() and gbm_bo_unmap(). This lets a user access the
contents of a bo using the CPU.
v2:
- improve documentation to clarify this is an optional interface;
- make gbm_bo_create() fail with ENOSYS if the
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
---
src/egl/drivers/dri2/egl_dri2.c | 9 +-
src/egl/drivers/dri2/egl_dri2.h | 3 +-
src/egl/drivers/dri2/platform_drm.c | 217 ++--
src/gbm/main/common_drm.h | 6 +
4
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
v2:
- restore src/gbm/Makefile.am include that was deleted by mistake;
- fix error path of gbm_intel_device_create();
- remove unused function align().
---
src/gbm/Makefile.am| 12 ++
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Add bo and bufmgr fields to gbm_drm_bo and gbm_drm_device respectively.
---
src/gbm/backends/intel/gbm_intel.c | 4
src/gbm/main/common_drm.h | 6 ++
2 files changed, 10 insertions(+)
diff --git
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
If the fd used by the DRI driver is going to be shared with something
else, like gbm, this lets the loader pass the bufmgr struct so it is
shared too.
---
include/GL/internal/dri_interface.h | 11 +++
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
The native handle is a pointer to drm_intel_bo for the i965 driver.
---
include/GL/internal/dri_interface.h | 13 +++-
src/mesa/drivers/dri/i965/intel_regions.c | 50 ++-
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Cc: 10.0 10.1 mesa-sta...@lists.freedesktop.org
---
src/gbm/backends/dri/gbm_dri.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 50fa588..f681836
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
This should give the caller some information of what called the error.
For the gbm_bo_import() case, for instance, it is possible to know if
the import is not supported or the error was caused by an invalid
parameter.
---
From: Rob Clark robcl...@freedesktop.org
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
src/gallium/state_trackers/xa/xa_composite.c | 3 +--
src/gallium/state_trackers/xa/xa_context.c | 5 +
src/gallium/state_trackers/xa/xa_priv.h | 3 +--
From: Rob Clark robcl...@freedesktop.org
While still more of a stop-gap solution (until glamor) for freedreno,
with these few relatively simple changes I get a pretty big performance
boost (~40%) for xf86-video-freedreno.
Since the first iteration of these patches, I have:
* re-worked the
From: Rob Clark robcl...@freedesktop.org
Keep track of the maximal bounds of all the operations and set scissor
accordingly. For tiling GPU's this can be a big win by reducing the
memory bandwidth spent moving pixels from system memory to tile buffer
and back.
You could imagine being more
On 04/08/2014 10:28 PM, Ander Conselvan de Oliveira wrote:
From: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
Changes from previous version:
- make it clearer that the interface is optional;
No! this is still a NAK!
The reason is, just like the last time, that as soon
From: Rob Clark robcl...@freedesktop.org
Add support to property handle solid-fill src and/or mask. Without this
we fallback to sw a lot for common things like text rendering.
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
src/gallium/state_trackers/xa/xa_composite.c | 115 +--
From: Thomas Hellstrom thellst...@vmware.com
Otherwise it will trick the gallium driver into thinking that the render
target has actually changed (due to different pipe_surface pointing to
same underlying pipe_resource). This is really badness for tiling GPUs
like adreno.
Signed-off-by: Thomas
From: Rob Clark robcl...@freedesktop.org
Detect the edge cases where texture fetch is unneeded (due to alpha
channel being wired to 1.0 and non-alpha components thrown out).
Signed-off-by: Rob Clark robcl...@freedesktop.org
---
src/gallium/state_trackers/xa/xa_composite.c | 13 +++--
The new fragment shader backend has never supported the necessary
color conversion code for this to work. We began using the new backend
in Mesa 7.10 for GLSL (commit a81d423d93f22a948f3aa4bf73, October 2010),
and for ARB_fragment_program in Mesa 9.1 (commit 97615b2d8c7c3cea6fd3a4,
August 2012).
Here's a rework of the series for meta CopyTexSubImage (required for
i965's gen8 support, since we're probably going to avoid doing blorp at
all for it). Ken had almost-reviewed a previous version of the patch, but
I went back and did some refactors before it that bring this feature
improvement
---
src/mesa/drivers/common/meta.c | 10 --
src/mesa/drivers/common/meta.h | 3 +--
src/mesa/drivers/common/meta_generate_mipmap.c | 6 --
3 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c
This avoids a ReadPixels() if there's accelerated CopyTexImage present.
It now requires GLSL as opposed to just fragment programs, but we don't
have any drivers that do ARB_fp but not GLSL.
---
src/mesa/drivers/common/meta.h | 1 -
src/mesa/drivers/common/meta_blit.c | 139
There's already code for them due to the GenerateMipmap path, so we just
need to make sure we've got our coordinates present.
v2: Apply De Morgan's law (review by Ken)
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/common/meta_blit.c | 17 +++--
1 file
I added support to bind_fbo_image in the process of building meta
CopyTexSubImage, and found that it broke generatemipmap because previously
we would just throw a GL error there and then end up with an incomplete
FBO and fallback.
---
src/mesa/drivers/common/meta.c | 4
You'll note from the previous commits that there's something of a loop
here: You call CTSI, which calls BlitFB, then if things go wrong that
falls back to CTSI. As a result, meta CTSI reaches over into blitfb to
tell it no, don't try that fallback.
v2: Drop the _mesa_update_state(), which was
There shouldn't be anything special about copying out a subset of the src
rb to a temp before texturing from it, so just do it when we're figuring
out our src texture binding.
This drops Anuj's change to copy an extra border of 1 pixel around the src
area. I can't see how that change could be
I need to do the same code again for CopyTexSubImage().
---
src/mesa/drivers/common/meta.c | 33 +++
src/mesa/drivers/common/meta.h | 4 +++
src/mesa/drivers/common/meta_generate_mipmap.c | 36 ++
3 files changed, 39
I think we can assert that renderbuffer size is = maximum 2D texture
size. Our source coordinates should have already been clipped to the src
renderbuffer size, but haven't actually (so we could potentially have
trouble if there's scaling, and we're in the CopyTexImage path that tries
to use src
We don't have any piglit tests for this currently.
v2: Use vec3s for the texcoords so it has some hope of working.
---
src/mesa/drivers/common/meta.h | 8 ++
src/mesa/drivers/common/meta_blit.c | 56 ++---
2 files changed, 48 insertions(+), 16
Chris Forbes chr...@ijw.co.nz writes:
Ian,
Would we put that format in a view class by itself?
For glamor, I would really want it to be the same view class as, say,
RGBA2101010.
pgp1gXkqy5PTm.pgp
Description: PGP signature
___
mesa-dev mailing
The topic of improving application load time by running the GLSL
compiler in a separate thread for each call to glCompileShader (or
glLinkProgram). Eric had done some experiments with this before (is
there a branch somewhere?), and he found that it wasn't a win because
programs regularly do
On 04/08/2014 04:01 AM, Iago Toral Quiroga wrote:
This should help prevent situations where we render without proper index
bounds. For example: https://bugs.freedesktop.org/show_bug.cgi?id=59455
---
src/mesa/drivers/dri/i965/brw_draw.c | 24 ++--
On 04/08/2014 01:25 PM, Chris Forbes wrote:
Ian,
Would we put that format in a view class by itself?
I think the BGRA8 could go in VIEW_CLASS_32_BITS. If you create an
RGBA8 view of a BGRA8 texture you'll get swizzled reads. Given that you
can create a RGB9_E5 view of a RGB10_A2UI texture,
Improves cairo performance on glamor by 2.87752% +/- 0.966977 (n=57).
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 1 +
src/mesa/drivers/dri/i965/brw_context.h | 3 +++
src/mesa/drivers/dri/i965/gen7_misc_state.c | 8
src/mesa/drivers/dri/i965/gen8_depth_state.c | 8
It's just the array index, so we can just go look at the array and see
which element we are.
No significant performance difference (n=140)
---
src/mesa/drivers/dri/i965/brw_context.h | 2 --
src/mesa/drivers/dri/i965/brw_draw.c | 1 -
src/mesa/drivers/dri/i965/brw_draw_upload.c | 2
Improves cairo performance on glamor by 1.64828% +/- 1.04742% (n=65).
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
On 04/08/2014 02:03 PM, Eric Anholt wrote:
There shouldn't be anything special about copying out a subset of the src
rb to a temp before texturing from it, so just do it when we're figuring
out our src texture binding.
This drops Anuj's change to copy an extra border of 1 pixel around the
Kenneth Graunke kenn...@whitecape.org writes:
The new fragment shader backend has never supported the necessary
color conversion code for this to work. We began using the new backend
in Mesa 7.10 for GLSL (commit a81d423d93f22a948f3aa4bf73, October 2010),
and for ARB_fragment_program in Mesa
Am 08.04.2014 13:49, schrieb Rob Clark:
btw, I think I've tracked down at least one of the rendercheck issues
I was having. Which seems to be a pre-existing condition. The
problem is a composite operation with xrgb src and a8 dst. Ends up
generating a shader along the lines of:
0: TEX
On 04/08/2014 02:03 PM, Eric Anholt wrote:
Here's a rework of the series for meta CopyTexSubImage (required for
i965's gen8 support, since we're probably going to avoid doing blorp at
all for it). Ken had almost-reviewed a previous version of the patch, but
I went back and did some refactors
Even though patch 3 doesn't help performance, I think it makes the code
better. Series is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
One question below...
On 04/08/2014 02:31 PM, Eric Anholt wrote:
Improves cairo performance on glamor by 2.87752% +/- 0.966977 (n=57).
---
Ian Romanick i...@freedesktop.org writes:
The topic of improving application load time by running the GLSL
compiler in a separate thread for each call to glCompileShader (or
glLinkProgram). Eric had done some experiments with this before (is
there a branch somewhere?), and he found that it
On Tue, Apr 8, 2014 at 5:41 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 08.04.2014 13:49, schrieb Rob Clark:
btw, I think I've tracked down at least one of the rendercheck issues
I was having. Which seems to be a pre-existing condition. The
problem is a composite operation with xrgb
v2: Fix fragment program fragment.color output, fix smaller-than-vec4 dual
src output codegen, use offset() a bit more.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs.h | 5 +--
src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 18
On 04/08/2014 02:57 PM, Ian Romanick wrote:
Even though patch 3 doesn't help performance, I think it makes the code
better. Series is
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
One question below...
On 04/08/2014 02:31 PM, Eric Anholt wrote:
Improves cairo performance on
https://bugs.freedesktop.org/show_bug.cgi?id=77208
Priority: medium
Bug ID: 77208
Assignee: mesa-dev@lists.freedesktop.org
Summary: VdpPresentationQueueGetTime does not return a
monotonic time
Severity: normal
On 04/08/2014 01:56 PM, Kenneth Graunke wrote:
The new fragment shader backend has never supported the necessary
color conversion code for this to work. We began using the new backend
in Mesa 7.10 for GLSL (commit a81d423d93f22a948f3aa4bf73, October 2010),
and for ARB_fragment_program in Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=77208
nfx...@gmail.com changed:
What|Removed |Added
CC||nfx...@gmail.com
--- Comment #1 from
Reviewed-by: Brian Paul bri...@vmware.com
On Mon, Apr 7, 2014 at 1:08 PM, Anuj Phogat anuj.pho...@gmail.com wrote:
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
src/mesa/swrast/s_blit.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/mesa/swrast/s_blit.c
From: Marek Olšák marek.ol...@amd.com
This fixes random crashes of: piglit/glx-multithread-shader-compile.
---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 75 ++-
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 35 ---
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 70 -
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 2 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 6 --
src/gallium/winsys/radeon/drm/radeon_drm_winsys.h | 1 +
src/gallium/winsys/radeon/drm/radeon_winsys.h | 7 +++
4 files
From: Marek Olšák marek.ol...@amd.com
Both contained the GEM flink name.
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 19 +--
src/gallium/winsys/radeon/drm/radeon_drm_bo.h | 5 +
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git
From: Marek Olšák marek.ol...@amd.com
This also hides the reference count from drivers.
---
src/gallium/drivers/r300/r300_screen.c| 2 +-
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c| 2 +-
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index 3dfa525..95c2053 100644
---
From: Marek Olšák marek.ol...@amd.com
Create the screen in the winsys while the mutex is locked.
This also results in a nice code cleanup!
---
src/gallium/targets/egl-static/egl_pipe.c | 42 ---
src/gallium/targets/pipe-loader/pipe_r300.c | 14 ++--
From: Marek Olšák marek.ol...@amd.com
This also hides the reference count from drivers.
v2: update the reference count while the mutex is locked in winsys_create
---
src/gallium/drivers/r300/r300_screen.c| 2 +-
src/gallium/drivers/r600/r600_pipe.c | 2 +-
When considering assignment expressions like:
v.x += u.x;
v.x += u.x;
the vectorizer would incorrectly keep going, attempting to find more
instructions to vectorize. It would overwrite the saved assignment
to point at the second one, and increment channels a second time,
resulting in
On Tue, Apr 8, 2014 at 5:40 PM, Kenneth Graunke kenn...@whitecape.org wrote:
When considering assignment expressions like:
v.x += u.x;
v.x += u.x;
the vectorizer would incorrectly keep going, attempting to find more
instructions to vectorize. It would overwrite the saved assignment
On Mit, 2014-04-09 at 02:15 +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
Create the screen in the winsys while the mutex is locked.
This also results in a nice code cleanup!
[...]
diff --git a/src/gallium/targets/egl-static/egl_pipe.c
Loop unrolling will need to know a few more options in the future.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/glsl_parser_extras.cpp | 2 +-
src/glsl/loop_analysis.h| 3 ++-
src/glsl/loop_unroll.cpp| 20 +---
3 files changed, 16
1 - 100 of 107 matches
Mail list logo
