From: Michel Dänzer
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74868
Cc: mesa-sta...@lists.freedesktop.org
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/r600/r600_shader.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/src/gallium/dri
Hi,
On Thursday, March 27, 2014 19:39:39 Mathias Fröhlich wrote:
> attached a change to llvmpipe fixing a long standing problem with
> multithreaded OpenGL applications.
>
> Please review!
> thanks!
Ping?
Mathias
___
mesa-dev mailing list
mesa-dev@lis
Many shaders use a pattern such as:
for (int i = 0; i < NUM_LIGHTS; i++) {
...access a uniform array, or shader input/output array...
}
where NUM_LIGHTS is a small constant (such as 2, 4, or 8).
The expectation is that the compiler will unroll those loops, turning
the array access into consta
Many shaders use a pattern such as:
for (int i = 0; i < NUM_LIGHTS; i++) {
...access a uniform array, or shader input/output array...
}
where NUM_LIGHTS is a small constant (such as 2, 4, or 8).
The expectation is that the compiler will unroll those loops, turning
the array access into consta
These were out of sync with the flags used to control
lower_variable_index_to_cond_assign in brw_shader.cpp.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
This series is also available as 'loop-vi-v4' of ~kw
This will prevent the two from getting out of sync again.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_shader.cpp | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shad
Now that we pass in gl_shader_compiler_options, it makes sense to just
use options->MaxUnrollIterations, rather than passing a separate
parameter.
Half of the invocations already passed options->MaxUnrollIterations,
while the other half passed in a hardcoded value of 32.
Signed-off-by: Kenneth Gr
The "fail" flag is set if loop_unroll_count encounters a nested loop;
calling the flag "nested_loop" is a bit clearer.
The original reasoning was that count is inaccurate (too small) if there
are nested loops, as we don't do any sort of analysis on the inner loop.
Signed-off-by: Kenneth Graunke
Loop unrolling will need to know a few more options in the future.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser_extras.cpp | 2 +-
src/glsl/loop_analysis.h| 3 ++-
src/glsl/loop_unroll.cpp| 20 +---
3 files changed, 16 insertions(+), 9 deletions(-)
d
On Mit, 2014-04-09 at 02:15 +0200, Marek Olšák wrote:
> From: Marek Olšák
>
> 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
> b/src/gallium/targets/egl-static/egl_pipe.c
> inde
On Tue, Apr 8, 2014 at 5:40 PM, Kenneth Graunke 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
> to point at
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 try
From: Marek Olšák
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 +-
src/gallium/drivers/radeonsi/si
From: Marek Olšák
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 ++--
src/gallium/targets/pipe-loa
From: Marek Olšák
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 +-
src/gallium/winsys/radeon/drm/radeon_drm_winsys
From: Marek Olšák
---
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
--- a/src/gallium/winsys/radeon/drm/radeon_drm_bo
From: Marek Olšák
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 a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c
b/src/gallium/
From: Marek Olšák
---
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 -
src/gallium/winsys/radeon/tools/radeon_ctx.h
From: Marek Olšák
---
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 changed, 9 insertions(+),
From: Marek Olšák
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 a/src/gallium/winsys/radeon/drm/radeon_drm_bo.
Reviewed-by: Brian Paul
On Mon, Apr 7, 2014 at 1:08 PM, Anuj Phogat wrote:
> Signed-off-by: Anuj Phogat
> ---
> src/mesa/swrast/s_blit.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/mesa/swrast/s_blit.c b/src/mesa/swrast/s_blit.c
> index 1ba188c..e3b45f1 100644
> ---
https://bugs.freedesktop.org/show_bug.cgi?id=77208
nfx...@gmail.com changed:
What|Removed |Added
CC||nfx...@gmail.com
--- Comment #1 from n
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
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
Classificat
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
>
> One question below...
>
> On 04/08/2014 02:31 PM, Eric Anholt wrote:
>> Improves cairo performance on glamor by 2.87752% +
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
s
Ian Romanick 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 wasn't a win becau
On Tue, Apr 8, 2014 at 5:41 PM, Roland Scheidegger 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 src and a8 d
Even though patch 3 doesn't help performance, I think it makes the code
better. Series is
Reviewed-by: Ian Romanick
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).
> ---
> src/mesa/drivers/dri/i965/brw_bl
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 refacto
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:
Kenneth Graunke 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 9.1 (commit 976
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 th
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
b/src/mesa/drivers/dri/i965/brw_draw_u
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 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
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
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 ++--
> src/mesa/drivers/
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
Chris Forbes 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 list
mesa-dev@lis
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 o
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 val
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 deletions(-
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
src/me
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 inse
---
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 b/src/mesa/drivers
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
---
src/mesa/drivers/common/meta_blit.c | 17 +++--
1 file changed, 3 insertions(+), 1
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 to
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).
From: Thomas Hellstrom
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 Hellstrom
---
src/ga
From: Rob Clark
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
---
src/gallium/state_trackers/xa/xa_composite.c | 13 +++--
src/gallium/state_trackers/xa/xa_priv.h | 10 +
On 04/08/2014 10:28 PM, Ander Conselvan de Oliveira wrote:
> From: Ander Conselvan de Oliveira
>
> 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 as the major
drivers implement t
From: Rob Clark
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
---
src/gallium/state_trackers/xa/xa_composite.c | 115 +--
src/gallium/state_trackers/xa/xa_priv.h | 1
From: Rob Clark
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 'solid-fill src/mask' patch to
From: Rob Clark
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 sophisticated and splitting up
From: Rob Clark
Signed-off-by: Rob Clark
---
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 +--
src/gallium/state_trackers/xa/xa_renderer.c | 7 ---
src/gallium/state_trackers/x
From: Ander Conselvan de Oliveira
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.
---
src/gbm/backends/dri/gbm_dri.c | 36
From: Ander Conselvan de Oliveira
Cc: "10.0" "10.1"
---
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 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/
From: Ander Conselvan de Oliveira
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 +++
src/egl/drivers/dri2/egl_dri2.h | 3 ++
From: Ander Conselvan de Oliveira
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 ++-
src/mesa/drivers/dri/i965/intel_regions.h | 6
From: Ander Conselvan de Oliveira
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 a/src/gbm/backends/intel/gbm_intel.c
b/src/gbm/
From: Ander Conselvan de Oliveira
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 GBM_BO_USE_MAP flag
was supplied and gbm
From: Ander Conselvan de Oliveira
---
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 files changed, 200 insertions(+), 35 de
From: Ander Conselvan de Oliveira
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 ++
src/gbm/backends/intel/gbm_intel.c | 254 ++
From: Neil Roberts
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 fixes it to actually disa
From: Ander Conselvan de Oliveira
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 -
src/gbm/backends/dri/
From: Ander Conselvan de Oliveira
Otherwise it fails to compile if the drm egl platform is disabled.
Cc: "10.0" "10.1"
Reviewed-by: Emil Velikov
---
src/egl/drivers/dri2/egl_dri2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl
From: Ander Conselvan de Oliveira
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 path in dri_device_create()
gbm: Set
Ian,
Would we put that format in a view class by itself?
-- Chris
On Wed, Apr 9, 2014 at 7:49 AM, Ian Romanick 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.
>>>
>>> Signific
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
A few minor nits inline.
---
src/gbm/Makefile.am| 14 +-
src/gbm/backends/intel/gbm_intel.c | 258 +
s
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
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 sup
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 architecture
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 Man
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
Kenneth Graunke 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 memory
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
> ---
> docs/GL3.txt | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/do
On Mon, Apr 7, 2014 at 9:24 AM, Eric Anholt wrote:
> Iago Toral Quiroga writes:
>
>> Commit 11baad35088dfd4bdabc1710df650dbfb413e7a3 produces a regression when
>> switching a single context between multiple drawables.
>>
>> The problem is that we check whether we have a viewport set to decide if
Am 08.04.2014 16:57, schrieb Leo Liu:
From: Christian König
v2: move allocation to a function as first step
to clean vid_enc_EncodeFrame
Signed-off-by: Christian König
Signed-off-by: Leo Liu
Reviewed and pushed both patches.
Thanks,
Christian.
---
src/gallium/state_trackers/omx/v
From: Leo Liu
cleanup by moving each step into a separate function
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/vid_enc.c | 220 +--
1 file changed, 118 insertions(+), 102 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_enc.c
b/src/galliu
From: Christian König
v2: move allocation to a function as first step
to clean vid_enc_EncodeFrame
Signed-off-by: Christian König
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/omx/vid_enc.c | 124 +++
1 file changed, 42 insertions(+), 82 deletions(-)
d
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
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 wrote:
> On 04/07/2014 09:20 PM, Courtney Goeltzenle
On Mon, Apr 7, 2014 at 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
> ---
> docs/GL3.txt | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --
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
On 04/08/2014 04:01 AM, Iago Toral Quiroga wrote:
> This should help prevent situations where we render without proper in
On Tue, Apr 8, 2014 at 2:52 AM, Eric Anholt wrote:
> Chia-I Wu writes:
>
>> From: Chia-I Wu
>>
>> Given
>>
>> mov vgrf7, vgrf9.xyxz
>> add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw
>> add vgrf10.x, vgrf6.xyzw, vgrf7.
>>
>> the last instruction would be wrongly changed to
>>
>> add vgrf10.x,
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 TEMP[0].w,
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 ++---
src/mesa/tnl/t_conte
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
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 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
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: 4ccff1499
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 whi
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 'is_power_
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
> ---
> src/mesa/drivers/dri/i965/brw_surface_formats.c | 3 +++
> 1 file changed, 3 insertions(+)
On 04/02/2014 01:05 AM, Chris Forbes wrote:
> Signed-off-by: Chris Forbes
> Reviewed-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_
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 cha
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
b/src/mesa/drive
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 on
1 - 100 of 105 matches
Mail list logo
