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 fa520
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: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.
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 b
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
> m
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 --
src/mesa/drivers/dri/i965/intel_context
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.
---
src/mesa/drivers/dri/common/d
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
driverPr
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 sup
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 s
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 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
--- a/src/mesa/drivers/dri/common/dri_ut
---
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
+++ b/src/mesa/drivers/dri/common/dri_ut
Matt Turner 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 temp
>
On Thu, Sep 26, 2013 at 3:00 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 ne
v2: Make accumulator's type match the type of the operation. Noticed by
Ken.
Reviewed-by: Kenneth Graunke
---
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.c
---
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 10064
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
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
On 15 September 2013 00:19, Francisco Jerez 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 +++-
> src/mesa/drivers/dri/i965/brw
On 15 September 2013 00:19, Francisco Jerez 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 +++
> src/mesa/driv
On 15 September 2013 00:19, Francisco Jerez 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 +++
> src/mesa/driver
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 you
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 would
Niels Ole Salscheider 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 just to please the spec?
Niels Ole Salscheider writes:
> Events that are already signalled can be removed from the queue, too.
>
> Signed-off-by: Niels Ole Salscheider
I don't think this is right, with this patch we remove *all* events from
the command queue, signalled or not, every time the command queue is
flushed.
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"
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".
On 15 September 2013 00:10, Francisco Jerez 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 point it might b
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 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 allocation. Following a "simple" formula i
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 ir_binop
On 15 September 2013 00:10, Francisco Jerez 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
> +
> src/mesa/drivers/dri/i965/brw_fs.cpp
On Thu, Sep 26, 2013 at 12:19 PM, Michel Dänzer wrote:
> On Don, 2013-09-26 at 03:35 +0200, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> 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
On Don, 2013-09-26 at 03:35 +0200, Marek Olšák wrote:
> From: Marek Olšák
>
> 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.
[...]
> 19 files
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
Ping
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
From: Christian König
Export only the absolutely necessary symbols in radeon vdpau targets.
Signed-off-by: Christian König
---
src/gallium/targets/r300/vdpau/Makefile.am | 3 +++
src/gallium/targets/r600/vdpau/Makefile.am | 3 +++
src/gallium/targets/radeonsi/vdpau/Makefile.am | 3 +++
From: Christian König
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
---
src/gallium/drivers/radeon/radeon_uvd.c | 97 ++---
1 file changed, 53 insertions(+), 44 de
39 matches
Mail list logo
