These built-ins have two out parameters, which makes implementing them
efficiently with our current compiler infrastructure difficult. Instead,
implement them in terms of the existing ir_binop_mul IR (to return the
low 32-bits) and a new ir_binop_mul64 which returns the high 32-bits.
---
Depends
---
src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp | 1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 10 ++
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 7 +++
3 files changed, 18 insertions(+)
diff --git
Fixed and landed on master now.
On Mon, Sep 23, 2013 at 8:05 AM, Eric Anholt e...@anholt.net wrote:
Chris Forbes chr...@ijw.co.nz writes:
Hardware requires the magnitude of the largest component to not exceed
1; brw_cubemap_normalize ensures that this is the case.
Unfortunately, we would
Am 26.09.2013 03:35, schrieb Marek Olšák:
Nothing too exciting, I'm just consolidating some code between r600g and
radeonsi. There are some small improvements though:
1) The CMASK buffer for MSAA colorbuffers is cleared with CP DMA instead of
using the CPU.
2) This series enables 2D tiling for
From: Christian König christian.koe...@amd.com
No need to keep a copy of the message in system memory anymore,
since it should now be in GART memory on newer chips.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/drivers/radeon/radeon_uvd.c | 97
From: Christian König christian.koe...@amd.com
Export only the absolutely necessary symbols in radeon vdpau targets.
Signed-off-by: Christian König christian.koe...@amd.com
---
src/gallium/targets/r300/vdpau/Makefile.am | 3 +++
src/gallium/targets/r600/vdpau/Makefile.am | 3 +++
Ping
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi, has anyone succeeded compiling Mesa 9.2 on Windows XP with MSVC ? No
mather what msvc compiler I use. (2008, 2010, 2012 with XP support). Even
tried patch MSVC 2010 with these patches: kb2820057, kb2836024 and kb
2740362. But still no luck.
Filip
On Don, 2013-09-26 at 03:35 +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
The function r600_choose_tiling is new and needs a review.
The only change in functionality is that it enables 2D tiling for compressed
textures on SI. It was probably accidentally turned off.
On Thu, Sep 26, 2013 at 12:19 PM, Michel Dänzer mic...@daenzer.net wrote:
On Don, 2013-09-26 at 03:35 +0200, Marek Olšák wrote:
From: Marek Olšák marek.ol...@amd.com
The function r600_choose_tiling is new and needs a review.
The only change in functionality is that it enables 2D tiling for
On 15 September 2013 00:10, Francisco Jerez curroje...@riseup.net wrote:
---
src/mesa/drivers/dri/i965/brw_defines.h | 2 +
src/mesa/drivers/dri/i965/brw_eu.h | 9 +
src/mesa/drivers/dri/i965/brw_eu_emit.c | 62
+
On 09/25/2013 11:09 PM, Matt Turner wrote:
These built-ins have two out parameters, which makes implementing them
efficiently with our current compiler infrastructure difficult. Instead,
implement them in terms of the existing ir_binop_mul IR (to return the
low 32-bits) and a new
On 09/25/2013 11:09 PM, Matt Turner wrote:
---
src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp | 1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 10 ++
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 7 +++
3 files changed, 18 insertions(+)
On 15 September 2013 00:10, Francisco Jerez curroje...@riseup.net wrote:
Analogous to the GLSL IR predicate with the same name. This patch
fixes the three dead code elimination passes and the VEC4/FS
instruction scheduling passes so they leave instructions with side
effects alone.
At some
On 09/26/2013 10:37 AM, Chad Versace wrote:
On 09/22/2013 10:37 AM, Ben Widawsky wrote:
Starting with Ivybridge, the hierarchical had relaxed requirements for
^^^
the hierarchical doesn't make sense. Just call it the HiZ buffer or
the hiz buffer.
its
On Thu, Sep 26, 2013 at 11:16:52AM -0700, Chad Versace wrote:
On 09/26/2013 10:37 AM, Chad Versace wrote:
On 09/22/2013 10:37 AM, Ben Widawsky wrote:
Starting with Ivybridge, the hierarchical had relaxed requirements for
^^^
the hierarchical doesn't
Niels Ole Salscheider niels_...@salscheider-online.de writes:
Events that are already signalled can be removed from the queue, too.
Signed-off-by: Niels Ole Salscheider niels_...@salscheider-online.de
I don't think this is right, with this patch we remove *all* events from
the command queue,
Niels Ole Salscheider niels_...@salscheider-online.de writes:
The OpenCL spec says:
Any blocking commands queued in a command-queue and clReleaseCommandQueue
perform an implicit flush of the command-queue. These blocking commands are
[...] or clWaitForEvents.
Are you sure we want to do this
On 09/22/2013 10:37 AM, Ben Widawsky wrote:
After the last patch, we can replace the region allocated in the miptree
creation with a more straightforward (and hopefully smaller resulting)
buffer based on the bspec's allocation formula.
Since I am relatively new to this part of the bspec, I
On 09/26/2013 06:10 AM, Filip Arlet wrote:
Hi, has anyone succeeded compiling Mesa 9.2 on Windows XP with MSVC ? No
mather what msvc compiler I use. (2008, 2010, 2012 with XP support).
Even tried patch MSVC 2010 with these patches: kb2820057, kb2836024 and
kb2740362. But still no luck.
Can
On 15 September 2013 00:19, Francisco Jerez curroje...@riseup.net wrote:
This can deal with all the 15 32-bit untyped atomic operations the
hardware supports, but only INC and PREDEC are going to be exposed
through the API for now.
---
src/mesa/drivers/dri/i965/brw_fs.h | 7 +++
On 15 September 2013 00:19, Francisco Jerez curroje...@riseup.net wrote:
This can deal with all the 15 32-bit untyped atomic operations the
hardware supports, but only INC and PREDEC are going to be exposed
through the API for now.
---
src/mesa/drivers/dri/i965/brw_vec4.h | 7 +++
On 15 September 2013 00:19, Francisco Jerez curroje...@riseup.net wrote:
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 25
---
src/mesa/drivers/dri/i965/brw_state.h | 2 --
src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 4 +++-
These built-ins have two out parameters, which makes implementing them
efficiently with our current compiler infrastructure difficult. Instead,
implement them in terms of the existing ir_binop_mul IR (to return the
low 32-bits) and a new ir_binop_mul64 which returns the high 32-bits.
v2: Rename
CSE would otherwise combine the two mul(8) emitted by [iu]mulExtended:
mul(8) acc0 x y
mach(8) null x y
mov(8) lsb acc0
...
mul(8) acc0 x y
mach(8) msb x y
Into:
mul(8) temp x y
mov(8) acc0 temp
mach(8) null x y
---
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp
index 7d9f605..c29703c
v2: Make accumulator's type match the type of the operation. Noticed by
Ken.
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs_channel_expressions.cpp | 1 +
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 10 ++
On Thu, Sep 26, 2013 at 3:00 PM, Matt Turner matts...@gmail.com wrote:
These built-ins have two out parameters, which makes implementing them
efficiently with our current compiler infrastructure difficult. Instead,
implement them in terms of the existing ir_binop_mul IR (to return the
low
Matt Turner matts...@gmail.com writes:
CSE would otherwise combine the two mul(8) emitted by [iu]mulExtended:
mul(8) acc0 x y
mach(8) null x y
mov(8) lsb acc0
...
mul(8) acc0 x y
mach(8) msb x y
Into:
mul(8) temp x y
mov(8) acc0
---
src/mesa/drivers/dri/common/dri_util.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index b95970d..fec05a0 100644
--- a/src/mesa/drivers/dri/common/dri_util.c
+++
The code it was referencing was removed in 2010.
---
src/mesa/drivers/dri/common/dri_util.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index fa520ea..b95970d 100644
---
In the process of doing the reworks necessary for the remaining
megadrivers changes, I found a lot of duplicated code. Here's a series
trying to reduce the insanity, though note that there's a missing piece in
patch 3/7.
Tested on i965 and softpipe, touch-tested classic swrast too.
The only important difference was not calling drmGetVersion, and making
the swrast extension vtable. That doesn't justify duplicating the other
330 lines of code.
XXX: The gallium scons copy of this isn't getting its cflags set, because
I'm not sure what the right way is to set cflags on a
i965, i915, radeon, r200, swrast, and nouveau were mostly trying to do the
same logic, except where they failed to. Notably, swrast had code that
appeared to try to enable GLES1/2 but forgot to set api_mask (thus
preventing any gles context from being created), and the non-intel drivers
didn't
The intel_screen.c used to be a dispatch to one of 3 driver functions, but
was down to 1, so it was kind of a waste. In addition, it was trying to
free all of the data that might have been partially freed in the kernel
3.6 check (which comes after intelInitContext, and thus might have had
This is part of the prep for megadrivers, which won't allow using a single
global symbol due to the fact that there will be multiple drivers built
into the same dri.so file. For that, we'll need screen init to take a
reference to the driver to set up this vtable.
---
If bufmgr didn't get created, then screen creation failed, and we never
should have got here in the first place. This was added by Chris Wilson
in 2010 with no explanation for why it would be needed.
---
src/mesa/drivers/dri/i915/intel_context.c | 6 --
On 09/26/2013 03:00 PM, Matt Turner wrote:
CSE would otherwise combine the two mul(8) emitted by [iu]mulExtended:
mul(8) acc0 x y
mach(8) null x y
mov(8) lsb acc0
...
mul(8) acc0 x y
mach(8) msb x y
Into:
mul(8) temp x y
mov(8)
On 09/26/2013 08:35 PM, Eric Anholt wrote:
i965, i915, radeon, r200, swrast, and nouveau were mostly trying to do the
same logic, except where they failed to. Notably, swrast had code that
appeared to try to enable GLES1/2 but forgot to set api_mask (thus
preventing any gles context from
On 09/26/2013 08:36 PM, Eric Anholt wrote:
If bufmgr didn't get created, then screen creation failed, and we never
should have got here in the first place. This was added by Chris Wilson
in 2010 with no explanation for why it would be needed.
---
src/mesa/drivers/dri/i915/intel_context.c |
On 09/26/2013 08:36 PM, Eric Anholt wrote:
The intel_screen.c used to be a dispatch to one of 3 driver functions, but
was down to 1, so it was kind of a waste. In addition, it was trying to
free all of the data that might have been partially freed in the kernel
3.6 check (which comes after
On 09/26/2013 08:35 PM, Eric Anholt wrote:
The code it was referencing was removed in 2010.
---
src/mesa/drivers/dri/common/dri_util.c | 4
1 file changed, 4 deletions(-)
diff --git a/src/mesa/drivers/dri/common/dri_util.c
b/src/mesa/drivers/dri/common/dri_util.c
index
42 matches
Mail list logo
