Also, as suggested by Ian Romanick, make it so we don't need a bunch of
individual handles to flippable matrices, instead we register
matrix/transpose_matrix pairs in a hash table for all built-in matrices
using the non-transpose matrix name as key.
---
I was wondering, is it really safe to only d
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
b/src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c
index f8be0df..217fa32 1006
On Wed, 18 Jun 2014 22:55:16 -0700
Kenneth Graunke wrote:
> On Wednesday, June 18, 2014 11:32:45 PM Axel Davy wrote:
> > In the case of XWayland, there's no accelerated indirect rendering.
> > For example GLX_ARB_create_context is not advertised by the server,
> > and according to the spec, we ar
On Wed, 2014-06-18 at 13:48 -0700, Ian Romanick wrote:
> I think this patch and 23 should be moved first in the series... the can
> certainly land before the other patches in the series.
Right. I'll push these two tomorrow if nobody says otherwise today.
Since you marked patch 23 for stable: do I
On Wed, 2014-06-18 at 13:38 -0700, Ian Romanick wrote:
> On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> > Check if non-zero streams are used. Fail to link if emitting to unsupported
> > streams or emitting to non-zero streams with output type other than
> > GL_POINTS.
> > ---
> > src/glsl/li
On Wed, 2014-06-18 at 11:16 -0700, Ian Romanick wrote:
> On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> > From: Samuel Iglesias Gonsalvez
> >
> > This implements parsing requirements for multi-stream support in
> > geometry shaders as defined in ARB_gpu_shader5.
> >
> > Signed-off-by: Samue
On Wed, 2014-06-18 at 12:56 -0700, Ian Romanick wrote:
> On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> > Inter-shader outputs must be on stream 0, which is the default.
> > ---
> > src/glsl/link_varyings.cpp | 12 +---
> > src/glsl/link_varyings.h | 7 +++
> > 2 files changed,
On Wed, 2014-06-18 at 14:43 -0700, Ian Romanick wrote:
> On 06/18/2014 05:03 AM, Iago Toral Quiroga wrote:
> > Also, as suggested by Ian Romanick, make it so we don't need a bunch of
> > individual handles to flippable matrices, instead we register
> > matrix/transpose_matrix pairs in a hash table
On Wednesday, June 18, 2014 11:32:45 PM Axel Davy wrote:
> In the case of XWayland, there's no accelerated indirect rendering.
> For example GLX_ARB_create_context is not advertised by the server,
> and according to the spec, we are not allowed to advertise it
> to the application because of that.
On Wed, Jun 18, 2014 at 11:27 PM, Axel Davy wrote:
> __DRIimageDriverExtension is used by GLX DRI3 and Wayland.
>
> This patch is a rewrite of
> http://lists.freedesktop.org/archives/mesa-dev/2014-May/060318.html
> and
> http://lists.freedesktop.org/archives/mesa-dev/2014-May/060317.html
>
> Signe
On Wed, Jun 18, 2014 at 11:32 PM, Axel Davy wrote:
> In the case of XWayland, there's no accelerated indirect rendering.
> For example GLX_ARB_create_context is not advertised by the server,
> and according to the spec, we are not allowed to advertise it
> to the application because of that.
>
> T
On Wed, Jun 18, 2014 at 6:28 PM, wrote:
> From: Roland Scheidegger
>
> Previously llvm detected cpu features automatically when the execution engine
> was created (based on host cpu). This is no longer the case, which meant llvm
> was then not able to emit some of the intrinsics we used as we di
At the very least, there are Apple MacBooks with NVAC (IGP) and NV96
chips, not sure if there are any intel + nv50 optimus setups. Of
course those laptops actually aren't particularly well-supported by
nouveau atm.
On Wed, Jun 18, 2014 at 11:45 PM, Axel Davy wrote:
> Is there any non-nvc0 Nvidia
Is there any non-nvc0 Nvidia cards in hybrid graphics laptops ?
If the answer is yes, then we probably need the same fix for nv50.
On 18/06/2014 23:34, Ilia Mirkin wrote :
Does nv50 need a similar fix? [BTW note that nv50 the chipset (not the
family), is unable to place memtype != 0 buffers int
On Thu, Jun 19, 2014 at 1:27 PM, Axel Davy wrote:
> __DRIimageDriverExtension is used by GLX DRI3 and Wayland.
>
> This patch is a rewrite of
> http://lists.freedesktop.org/archives/mesa-dev/2014-May/060318.html
> and
> http://lists.freedesktop.org/archives/mesa-dev/2014-May/060317.html
>
> Signed
Does nv50 need a similar fix? [BTW note that nv50 the chipset (not the
family), is unable to place memtype != 0 buffers into gart. nv84+ are
all fine.]
On Wed, Jun 18, 2014 at 11:27 PM, Axel Davy wrote:
> From: Dave Airlie
>
> We need to place shared buffers into GART.
>
> Signed-off-by: Dave Ai
In the case of XWayland, there's no accelerated indirect rendering.
For example GLX_ARB_create_context is not advertised by the server,
and according to the spec, we are not allowed to advertise it
to the application because of that.
This env var makes Mesa ignore this restriction, and
a GLX exten
This is easier than GLX DRI3 GPU offloading support,
because applications are not allowed to read the front
buffer.
We just need to send to the server buffers it can read,
and for that we use for every back buffer an intermediate
buffer with no tiling to which we copy before sending
the buffer to
The differences with DRI2 GPU offloading are:
. There's no logic for GPU offloading needed in the Xserver
. for DRI2, the card would render to a back buffer, and
the content would be copied to the front buffer (the same buffers
everytime). Here we can potentially use several back buffers and copy
t
From: Dave Airlie
We need to place shared buffers into GART.
Signed-off-by: Dave Airlie
Reviewed-by: Axel Davy
---
src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_miptree.c
b/src/gallium
V3: call flush_resource before flush
V4: Add new flags
Signed-off-by: Axel Davy
---
src/gallium/state_trackers/dri/drm/dri2.c | 55 +--
1 file changed, 52 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_tracke
DRI_PRIME is not very handy, because you have to launch the executable
with it set, which is not always easy to do.
By using drirc, the user specifies the target executable
and the device to use. After that the program will be launched everytime
on the target device.
For example if .drirc contains
This doesn't change anything to the intel DRI3 implementation,
but enables the gallium implementation to use dri2.stamp instead
of relying on the stamp shared with the st backend.
Signed-off-by: Axel Davy
---
src/glx/dri3_glx.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/glx/d
Signed-off-by: Axel Davy
---
src/mesa/drivers/dri/common/xmlconfig.c | 29 +
src/mesa/drivers/dri/common/xmlconfig.h | 7 ++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/common/xmlconfig.c
b/src/mesa/drivers/dri/common/xmlc
This improves GLX DRI3 GPU offloading significantly on CPU
bound benchmarks particularly.
No performance impact for DRI2 GPU offloading.
v2: Add missing tests
Signed-off-by: Axel Davy
Reviewed-by: Marek Olšák
---
src/gallium/drivers/radeonsi/si_blit.c | 19 +++
1 file changed, 1
v2: Fix the leak of device_name
v3: Rebased
It enables to use the DRI_PRIME env var to specify
which gpu to use.
Two syntax are supported:
If DRI_PRIME is 1 it means: take any other gpu than the default one.
If DRI_PRIME is the ID_PATH_TAG of a device: choose this device if
possible.
The ID_PATH_
It allows to blit two __DRIimages.
Signed-off-by: Axel Davy
---
include/GL/internal/dri_interface.h | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 4d57d0b..300156e 10064
__DRIimageDriverExtension is used by GLX DRI3 and Wayland.
This patch is a rewrite of
http://lists.freedesktop.org/archives/mesa-dev/2014-May/060318.html
and
http://lists.freedesktop.org/archives/mesa-dev/2014-May/060317.html
Signed-off-by: Axel Davy
Reviewed-by: Marek Olšák
Previous patches we
Thanks that was helpful.!
On Tue, Jun 17, 2014 at 12:35 PM, Thomas Helland
wrote:
> Hi Roshan,
>
> I've just gotten into the game myself, so I guess i can provide some
> newbie-info.
> I guess by "the list" you are referring to the suggestions for GSoC
> projects posted.
> I think the applicati
Am 19.06.2014 03:14, schrieb Dave Airlie:
> On 18 June 2014 23:50, Roland Scheidegger wrote:
>> Am 18.06.2014 01:54, schrieb Dave Airlie:
>>> On 18 June 2014 05:08, Roland Scheidegger wrote:
This looks ok to me though since tgsi currently doesn't have any double
opcodes (well the docs h
From: Roland Scheidegger
Previously llvm detected cpu features automatically when the execution engine
was created (based on host cpu). This is no longer the case, which meant llvm
was then not able to emit some of the intrinsics we used as we didn't specify
any sse attributes (only on avx suppor
On 19.06.2014 00:02, Bruno Jiménez wrote:
> Note: This is just a proof of concept.
> ---
> src/gallium/state_trackers/clover/api/transfer.cpp | 4 ++--
> src/gallium/state_trackers/clover/core/object.hpp | 4
> src/gallium/state_trackers/clover/core/resource.cpp | 2 ++
> 3 files changed,
On 18 June 2014 23:50, Roland Scheidegger wrote:
> Am 18.06.2014 01:54, schrieb Dave Airlie:
>> On 18 June 2014 05:08, Roland Scheidegger wrote:
>>> This looks ok to me though since tgsi currently doesn't have any double
>>> opcodes (well the docs have them...) it doesn't really apply to most
>>>
We already have transfer_inline_write.
Marek
On Thu, Jun 19, 2014 at 2:14 AM, Michel Dänzer wrote:
> On 18.06.2014 16:28, Eric Anholt wrote:
>>
>> I'm probably going to start out doing a gallium driver for simplicity,
>> to avoid having to do all the DRI crap we've got in brw_context.c and
>> te
Fixes gles3 Khronos CTS test:
egl_create_context.egl_create_context
Cc:
Signed-off-by: Anuj Phogat
---
src/egl/main/eglcontext.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/egl/main/eglcontext.c b/src/egl/main/eglcontext.c
index 70277ab..b8b30cb 100644
--
On 18.06.2014 16:28, Eric Anholt wrote:
>
> I'm probably going to start out doing a gallium driver for simplicity,
> to avoid having to do all the DRI crap we've got in brw_context.c and
> texture miptree validation and getting user data into VBOs and all that
> other almost-boilerplate. Long ter
>
> I'm working toward building a Mesa driver for Broadcom VC4 (aka
> Raspberry Pi). At the moment I'm still bringing up the DRM side of
> things, but I hope to be doing bits of userspace in the next few days.
> Current status is I have a skeleton DRM KMS driver that's going to talk
> to the firmw
On 06/18/2014 04:11 PM, Ian Romanick wrote:
From: Ian Romanick
Instead of catching the special case early, handle it by constructing a
fake gl_texture_image that will cause the values required by the OpenGL
4.0 spec to be returned.
Previously, calling
glGenTextures(1, &t);
glBindTex
On Wed, Jul 24, 2013 at 5:06 PM, Chad Versace
wrote:
> This patch is
> Reviewed-by: Chad Versace
> with the understanding that it depends on previous patches.
>
> I'll begin reviewing your Piglit tests now.
>
>
> On 07/24/2013 03:23 AM, Topi Pohjolainen wrote:
>>
>> Signed-off-by: Topi Pohjolaine
From: Ian Romanick
Instead of catching the special case early, handle it by constructing a
fake gl_texture_image that will cause the values required by the OpenGL
4.0 spec to be returned.
Previously, calling
glGenTextures(1, &t);
glBindTexture(GL_TEXTURE_2D, t);
glGetTexLevelParamet
From: Ian Romanick
There are no texture borders in any version of OpenGL ES or desktop
OpenGL core profile.
Fixes piglit's gl-3.2-texture-border-deprecated.
v2: Rebase on different initial change.
Signed-off-by: Ian Romanick
Reviewed-by: Brian Paul
Cc: "10.2
---
src/mesa/main/texparam.c |
From: Ian Romanick
There are no queries for GL_TEXTURE_LUMINANCE_SIZE,
GL_TEXTURE_INTENSITY_SIZE, GL_TEXTURE_LUMINANCE_TYPE, or
GL_TEXTURE_INTENSITY_TYPE in any version of OpenGL ES or desktop OpenGL
core profile.
NOTE: Without changes to piglit, this regresses
required-sized-texture-formats.
v
On 06/18/2014 05:03 AM, Iago Toral Quiroga wrote:
> Also, as suggested by Ian Romanick, make it so we don't need a bunch of
> individual handles to flippable matrices, instead we register
> matrix/transpose_matrix pairs in a hash table for all built-in matrices
> using the non-transpose matrix name
On 06/18/2014 02:05 PM, Ian Romanick wrote:
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
On Intel hardware when a geometry shader outputs GL_POINTS primitives we
only need to emit vertex control bits if it emits vertices to non-zero
streams, so use a flag to track this.
This flag will be s
On Wednesday, June 18, 2014 01:45:52 PM Ian Romanick wrote:
> On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> > ---
> > src/mesa/drivers/dri/i965/brw_context.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i9
We were printing messages for all diagnostic types, which was
spamming the console for some OpenCL programs.
---
src/gallium/drivers/radeon/radeon_llvm_emit.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_llvm_emit.c
b/src/gallium/driv
This patch is
Reviewed-by: Ian Romanick
Cc: "10.1 10.2"
Clearly this field should have been copied as long as it has existed.
Right?
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> ---
> src/mesa/program/program.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/program/
I think this patch and 23 should be moved first in the series... the can
certainly land before the other patches in the series.
This patch is
Reviewed-by: Ian Romanick
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> ---
> src/mesa/main/shaderobj.c | 1 +
> 1 file changed, 1 insertion(+)
>
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> ---
> src/mesa/drivers/dri/i965/brw_context.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
> index cfb0be0..6ba58d3 100644
> --- a/src/mesa/driv
On Wednesday, June 18, 2014 11:16:47 AM Ian Romanick wrote:
> On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> > From: Samuel Iglesias Gonsalvez
> >
> > This implements parsing requirements for multi-stream support in
> > geometry shaders as defined in ARB_gpu_shader5.
> >
> > Signed-off-by:
Reviewed-by: Ian Romanick
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> It should be possible to query the number of primitives written to each
> individual stream by a geometry shader in a single draw call. For that
> we need to have up to MAX_VERTEX_STREAM separate query objects.
> ---
>
Patches 14, 15, and 16 are
Reviewed-by: Ian Romanick
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> ---
> src/glsl/ir_print_visitor.cpp | 13 +
> src/glsl/ir_reader.cpp| 22 ++
> 2 files changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/src
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> Check if non-zero streams are used. Fail to link if emitting to unsupported
> streams or emitting to non-zero streams with output type other than GL_POINTS.
> ---
> src/glsl/linker.cpp | 148
> +++-
Patches 6, 7, 8, 9, and 10 are
Reviewed-by: Ian Romanick
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> ---
> src/glsl/link_varyings.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/glsl/link_varyings.h b/src/glsl/link_varyings.h
> index 4e485c3..167363e 100644
>
This patch should be split into several patches:
1. Modify ir_emit_vertex to have a stream. This patch also needs to update
ir_to_mesa.cpp and st_glsl_to_tgsi.cpp.
2. Modify ir_end_primitive to have a stream. This patch also needs to update
ir_to_mesa.cpp and st_glsl_to_tgsi.cpp.
3. Add the ne
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> On Intel hardware when a geometry shader outputs GL_POINTS primitives we
> only need to emit vertex control bits if it emits vertices to non-zero
> streams, so use a flag to track this.
>
> This flag will be set to TRUE when a geometry shader cal
Reviewed-by: Ian Romanick
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> Outputs that are linked to inputs in the next stage must be output to stream
> 0,
> otherwise we should fail to link.
> ---
> src/glsl/link_varyings.cpp | 8
> 1 file changed, 8 insertions(+)
>
> diff --git
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> Inter-shader outputs must be on stream 0, which is the default.
> ---
> src/glsl/link_varyings.cpp | 12 +---
> src/glsl/link_varyings.h | 7 +++
> 2 files changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/src/glsl/link_v
Reviewed-by: Ian Romanick
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> Configure hardware to read vertex data for all streams and have all streams
> write their varyings to the corresponsing output buffers.
> ---
> src/mesa/drivers/dri/i965/gen7_sol_state.c | 67
> +++
Reviewed-by: Ian Romanick
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> For now initialized to the default stream 0.
> ---
> src/glsl/link_varyings.cpp | 1 +
> src/mesa/main/mtypes.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/src/glsl/link_varyings.cpp b/src/glsl/link
It would be more precise to say that i915 uses the Draw module, which
can do these per-vertex operations on the CPU (some of them use LLVM):
- vertex fetching
- vertex shader
- geometry shader
- culling and clipping
- viewport transformation
- translates all primitives to either point, line, or tri
On 18/06/14 14:09, Tom Stellard wrote:
> On Tue, Jun 17, 2014 at 07:38:16PM +0100, Emil Velikov wrote:
>> Hi all,
>>
>> As a follow up to the static/shared pipe-drivers series here is the final
>> series (if anyone is interested I may take a look at egl + opencl) of
>> refactoring the gallium dri t
https://bugs.freedesktop.org/show_bug.cgi?id=73846
Roland Scheidegger changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
On Wed, Jun 18, 2014 at 10:47 AM, Emil Velikov wrote:
> On 18/06/14 08:28, Eric Anholt wrote:
>> To those who have been curious what I was up to: I wasn't sure when I
>> could announce my new projecct, I just got the ack day before yesterday,
>> and I've been a little busy.
>>
>> I'm working towar
On 06/18/2014 02:51 AM, Iago Toral Quiroga wrote:
> From: Samuel Iglesias Gonsalvez
>
> This implements parsing requirements for multi-stream support in
> geometry shaders as defined in ARB_gpu_shader5.
>
> Signed-off-by: Samuel Iglesias Gonsalvez
A few minor nits below. With those fixed, thi
On 18/06/14 15:07, Chia-I Wu wrote:
> On Wed, Jun 18, 2014 at 8:14 PM, Emil Velikov
> wrote:
[...]
>> Interesting, I do not see this as an attempt to define an API, but to
>> cleanup all the mayhem that our targets currently are:
>> * Cleanup the build system - drop symlinks, including the same
https://bugs.freedesktop.org/show_bug.cgi?id=73846
Vinson Lee changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=73846
Roland Scheidegger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 18/06/14 08:28, Eric Anholt wrote:
> To those who have been curious what I was up to: I wasn't sure when I
> could announce my new projecct, I just got the ack day before yesterday,
> and I've been a little busy.
>
> I'm working toward building a Mesa driver for Broadcom VC4 (aka
> Raspberry Pi
On 18/06/14 11:14, Christian König wrote:
> Hi Emil,
>
> This patch is Reviewed-by: Christian König
>
> But there is still something looking odd:
>> if NEED_RADEON_DRM_WINSYS
>> if !HAVE_GALLIUM_R300
>> -if !HAVE_GALLIUM_RADEONSI
>> STATIC_TARGET_LIB_DEPS += \
>> $(top_builddir)/src/
Looks good to me AFAICT. Thanks for the update.
Jose
From: srol...@vmware.com
Sent: 18 June 2014 00:36
To: Jose Fonseca; mesa-dev@lists.freedesktop.org
Cc: Roland Scheidegger
Subject: [PATCH] gallivm: fix SCALED -> NORM conversions
From: Roland Scheidegge
These statuses will help track whether the items are mapped
or if they should be promoted to or demoted from the pool
v2: Use the new is_item_in_pool util function,
as suggested by Tom Stellard
---
src/gallium/drivers/r600/compute_memory_pool.h | 7 ++-
src/gallium/drivers/r600/evergreen
This patch changes completely the way buffers are added to the
compute_memory_pool. Before this, whenever we were going to
map a buffer or write to or read from it, it would get placed
into the pool. Now, every unallocated buffer has its own
r600_resource until it is allocated in the pool.
NOTE: T
Note: This is just a proof of concept.
---
src/gallium/state_trackers/clover/api/transfer.cpp | 4 ++--
src/gallium/state_trackers/clover/core/object.hpp | 4
src/gallium/state_trackers/clover/core/resource.cpp | 2 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/gall
This function will be used when we want to map an item
that it's already in the pool.
v2: Use temporary variables to avoid so many castings in functions,
as suggested by Tom Stellard
---
src/gallium/drivers/r600/compute_memory_pool.c | 51 ++
src/gallium/drivers/r600/c
---
src/gallium/drivers/r600/compute_memory_pool.c | 146 +++--
src/gallium/drivers/r600/compute_memory_pool.h | 5 +
2 files changed, 91 insertions(+), 60 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_poo
All the *Enqueue* functions that read/write buffers (except
clEnqueueCopyBuffer) would map the associated resource, making
it to be demoted if it was in the pool.
But we possitively know that this transfer will end before
any kernel is launched, so there's no need to demote it.
---
src/gallium/dr
Now we will have a list with the items that are in the pool
(item_list) and the items that are outside it (unallocated_list)
---
src/gallium/drivers/r600/compute_memory_pool.c | 99 +-
src/gallium/drivers/r600/compute_memory_pool.h | 1 +
2 files changed, 49 insertions(+),
Acording to the OpenCL spec, it is possible to have a buffer mapped
for reading and at read from it using commands or buffers.
With this we can keep the mapping (that exists against the
temporary item) and read with a kernel (from the item we have
just added to the pool) without problems.
---
src
With this we can assure that mapped buffers will never change
its position when relocating the pool.
This patch should finally solve the mapping bug.
v2: Use the new is_item_in_pool util function,
as suggested by Tom Stellard
---
src/gallium/drivers/r600/evergreen_compute.c | 10 --
Hi,
This is my second attempt to fix the mapping bug adding all the
suggestions that Tom Stellard sent, and, so far, it seems that
it is resolved.
This series changes completely how OpenCL buffers are handled
by the r600g driver. Before this, we would add them directly to
a pool, and this pool wo
Every item that has been placed in the pool must have start_in_dw
different from -1.
---
src/gallium/drivers/r600/compute_memory_pool.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.h
b/src/gallium/drivers/r600/compute_memory_pool.h
index e9
---
src/gallium/drivers/r600/compute_memory_pool.c | 147 +++--
src/gallium/drivers/r600/compute_memory_pool.h | 10 +-
2 files changed, 46 insertions(+), 111 deletions(-)
diff --git a/src/gallium/drivers/r600/compute_memory_pool.c
b/src/gallium/drivers/r600/compute_memory_p
https://bugs.freedesktop.org/show_bug.cgi?id=80183
Roland Scheidegger changed:
What|Removed |Added
Attachment #101296|text/plain |application/zip
mime type|
On Wed, Jun 18, 2014 at 09:54:28AM +1000, Dave Airlie wrote:
> On 18 June 2014 05:08, Roland Scheidegger wrote:
> > This looks ok to me though since tgsi currently doesn't have any double
> > opcodes (well the docs have them...) it doesn't really apply to most
> > drivers (at least I assume you do
On Wed, Jun 18, 2014 at 8:14 PM, Emil Velikov wrote:
> On 18 June 2014 08:21, Chia-I Wu wrote:
>> Hi Emil,
>>
>> On Fri, Jun 13, 2014 at 3:56 AM, Emil Velikov
>> wrote:
>>> Hi all,
>>>
>>> These patches add support for building (grouping) the various targets per
>>> API, meaning that only one l
Am 18.06.2014 01:54, schrieb Dave Airlie:
> On 18 June 2014 05:08, Roland Scheidegger wrote:
>> This looks ok to me though since tgsi currently doesn't have any double
>> opcodes (well the docs have them...) it doesn't really apply to most
>> drivers (at least I assume you don't want to add suppor
On Tue, Jun 17, 2014 at 07:38:16PM +0100, Emil Velikov wrote:
> Hi all,
>
> As a follow up to the static/shared pipe-drivers series here is the final
> series (if anyone is interested I may take a look at egl + opencl) of
> refactoring the gallium dri targets into a single library/provider.
>
Hi
https://bugs.freedesktop.org/show_bug.cgi?id=80185
--- Comment #3 from rhatdan ---
In Fedora the allow_exemem boolean is not set, and this boolean would only
effect user space.
getsebool -a | grep execmem
boinc_execmem --> on
cluster_use_execmem --> off
cups_execmem --> off
deny_execmem --> off
https://bugs.freedesktop.org/show_bug.cgi?id=80185
--- Comment #2 from Laurent Bigonville ---
An other question might also arise is why would a failure of the mmap()
function considered as an error in one case and not in the case where SELinux
would prevent it to succeed?
--
You are receiving t
https://bugs.freedesktop.org/show_bug.cgi?id=80185
Laurent Bigonville changed:
What|Removed |Added
CC||l.bigonvi...@edpnet.be
--- Comment
https://bugs.freedesktop.org/show_bug.cgi?id=80185
Priority: medium
Bug ID: 80185
Assignee: mesa-dev@lists.freedesktop.org
Summary: Please do not hardcode SELinux identifiers in the code
Severity: normal
Classification: Unclassified
On 18 June 2014 08:21, Chia-I Wu wrote:
> Hi Emil,
>
> On Fri, Jun 13, 2014 at 3:56 AM, Emil Velikov
> wrote:
>> Hi all,
>>
>> These patches add support for building (grouping) the various targets per
>> API, meaning that only one library will be created for e.g. vdpau
>> (libvdpau_gallium) wit
Am 12.06.2014 18:27, schrieb Leo Liu:
Signed-off-by: Leo Liu
I've pushed everything upstream.
Thanks for the help,
Christian.
---
src/gallium/state_trackers/omx/vid_enc.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/src/gallium/st
Ok, pushed the patches.
Account requests usually take a while to complete, that's nothing to
worry about.
Regards,
Christian.
Am 18.06.2014 13:14, schrieb Grigori Goronzy:
On 18.06.2014 13:11, Christian König wrote:
@Grigori: Should I push it or did you got your account in the meantime?
N
Also, as suggested by Ian Romanick, make it so we don't need a bunch of
individual handles to flippable matrices, instead we register
matrix/transpose_matrix pairs in a hash table for all built-in matrices
using the non-transpose matrix name as key.
---
src/glsl/opt_flip_matrices.cpp | 145 +++
https://bugs.freedesktop.org/show_bug.cgi?id=80183
Priority: medium
Bug ID: 80183
Assignee: mesa-dev@lists.freedesktop.org
Summary: [llvmpipe] triangles with vertices that map to raster
positions > viewport width/height are not display
On 18.06.2014 13:11, Christian König wrote:
> @Grigori: Should I push it or did you got your account in the meantime?
>
No account yet. I wonder what's going on. Please push.
Best regards
Grigori
> Christian.
>
> Am 17.06.2014 22:26, schrieb Marek Olšák:
>> This looks good to me.
>>
>> Reviewed
@Grigori: Should I push it or did you got your account in the meantime?
Christian.
Am 17.06.2014 22:26, schrieb Marek Olšák:
This looks good to me.
Reviewed-by: Marek Olšák
Marek
On Wed, Jun 4, 2014 at 6:54 PM, Grigori Goronzy wrote:
This makes 4:2:2 video surfaces work in VDPAU.
---
sr
From: Greg Hunt
These cause a small slowdown when we are sending a large number of small
batches to the GPU.
Signed-off-by: Gregory Hunt
---
src/mesa/drivers/dri/i965/gen6_vs_state.c | 2 +-
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/gen7_gs_state.c
1 - 100 of 134 matches
Mail list logo
