https://bugs.freedesktop.org/show_bug.cgi?id=67672
--- Comment #23 from Paolo Pedroni ---
Still failing in Mesa-10.3.0 + llvm-3.4 :-(
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.fr
To whom it may concern:
>
>
> I am Juliet Fru, a second year student of Computer Engineering at the
> University of Buea. I am interested in participating in the OPW this year.
> I've never worked on an open source project before; and I'll like to have
> this first experience with Xorg. I am profic
This shouldn't actually happen in a sensible app (the easiest way to
force it is to use a UBO in a shader without binding anything to the
binding point). When it *does* happen though, it makes a loop in the
dirty state, which causes an assertion failure in the state validator if
any debug flag is e
This is used to implement GLSL's atomicCounter() intrinsic. Previously
it *worked*, but the disassembly was bogus.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_disasm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/brw_disasm.c
b/src/mesa/drivers
This would have *almost never* actually been an issue, since other state
tends to get flagged at the same time as new ABOs -- but still bogus.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/
---
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index d473470..5f75c31 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface
https://bugs.freedesktop.org/show_bug.cgi?id=67672
--- Comment #24 from Paolo Pedroni ---
... and llvm-3.5 didn't help either.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedeskt
One further note: It's possible to provoke the same bad behavior in
the equivalent ABO path, by declaring an atomic counter but never
binding any buffer object to the binding point, so this isn't a real
fix.
-- Chris
On Tue, Sep 23, 2014 at 10:16 PM, Chris Forbes wrote:
> This shouldn't actually
https://bugs.freedesktop.org/show_bug.cgi?id=84242
Priority: medium
Bug ID: 84242
Assignee: mesa-dev@lists.freedesktop.org
Summary: Mesa-10.3: libOpenCL.so.1.0.0: ld: .eh_frame_hdr
table[5707] FDE at 00c45b8c overlaps
This patch looks good to me.
The wording in the bspec seems a little vague so I was wondering if
maybe the real restriction is that the offset must be 4-byte aligned
rather than being aligned to the bpp. However I tried it with a 16-bit
type and sure enough it works to have an offset aligned to tw
I just noticed this wording in the GL spec regarding buffer objects:
“Clients must align data elements consistent with the requirements of
the client platform, with an additional base-level requirement that an
offset within a buffer to a datum comprising N basic machine units be a
multiple of N.”
Thanks, Neil.
Yeah, I had the same thoughts regarding whether it is a valid offset. The
trace does render correctly on Nvidia proprietary driver, but renders even
worse on Intel Windows driver (blank white screen after the bubbles pass).
I believe it used to render correctly on Windows, but maybe
Break out these functions so that they can be shared with a other
state trackers. They will be used in subsequent patches for the new
VA-API state tracker.
Signed-off-by: Leo Liu
---
src/gallium/auxiliary/util/u_video.h | 74 +++
src/gallium/state_trackers/vdpau/su
From: Christian König
This patch is for application to query configuration,
such as profiles, entrypoints, and attributes
Signed-off-by: Christian König
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/va/config.c | 74 --
src/gallium/state_trackers/va/con
From: Christian König
This patch implements codec for mpeg2 h264 and vc1,
populates codec parameters and pass them to HW driver.
Signed-off-by: Christian König
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/va/context.c| 21 ++
src/gallium/state_trackers/va/picture.c| 352
From: Christian König
This patch implements context managements, relate it HW driver,
functions for video surface managements, and functions for
application data memory buffer managements.
implemented functions:
vlVa(Create|Destroy)Context
vlVa(Create|Destroy|Put)Surfaces
vlVa(Create|Destroy)Buf
This patch implements functions for images support,
which basically supports copy data between video
surface and user buffers, in this case supports
SW decode, and other video output
Signed-off-by: Leo Liu
---
src/gallium/state_trackers/va/image.c | 233 -
src/ga
From: Christian König
This patch adds a skeleton VA-API state tracker,
which is filled with live in the subsequent patches.
Signed-off-by: Christian König
Signed-off-by: Leo Liu
---
configure.ac | 35 ++-
src/gallium/Makefile.am| 4 +
s
Presumbly this will let clang and other compilers use the built-ins as
well.
Notice two changes specifically:
- in _mesa_next_pow_two_64(), always use __builtin_clzll and add a
static assertion that this is safe.
- in macros.h, remove the clang-specific definition since it should
b
Note that I had to add support for testing the packed attribute to
m4/ax_gcc_func_attribute.m4.
Reviewed-by: Jason Ekstrand [C bits]
Reviewed-by: Ian Romanick
---
v2: Define macros in scons according to a priori knowledge.
configure.ac | 4 +
m4/ax_gcc_func_
> [PATCH 03/12] mesa: Replace a priori knowledge of gcc builtins with configure
> tests.
Ugh, this revised patch was supposed to be 02/12.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat, Sep 20, 2014 at 10:22 AM, Jason Ekstrand wrote:
> Every register in i965 assembly implicitly has a concept of a "width".
> Usually, this is derived from the execution size of the instruction.
> However, when writing a compiler it turns out that it is frequently a
> useful to have the width
On Sat, Sep 20, 2014 at 10:22 AM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 14 ++
> src/mesa/drivers/dri/i965/brw_fs.h | 4 +++-
> 2 files changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drive
On Sat, Sep 20, 2014 at 10:22 AM, Jason Ekstrand wrote:
> This reworks both byte_offset() and offset() to be more intelligent. The
> byte_offset() funciton now supports offsets bigger than 32. The offset()
> function uses the byte_offset() function togehter with the register width
> and the type
From: Roland Scheidegger
ffeb77c7b0552a8624e46e65d6347240ac5ae84d had a typo which turned all signed
integer divisions into unsigned ones. Oops.
This gets us back the 51 little piglits
(all from glsl built-in-functions, fs/vs/gs-op-div-int-ivec2 and similar).
Cc: "10.2 10.3"
---
src/gallium/au
On Sat, Sep 20, 2014 at 10:22 AM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 27
> ++
> .../drivers/dri/i965/brw_schedule_instructions.cpp | 4 ++--
> 2 files changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/src/mesa/drivers/
On Sat, Sep 20, 2014 at 10:22 AM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 27
> +-
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 19 ---
> .../drivers/dri/i965/brw_schedule_instructions.cpp | 7 +++---
> 3 files
On Sat, Sep 20, 2014 at 10:23 AM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 24
> +++
> 1 file changed, 24 insertions(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
> b/src/mesa/drivers/dri/i965/brw_fs_reg_alloca
https://bugs.freedesktop.org/show_bug.cgi?id=67672
--- Comment #25 from Roland Scheidegger ---
Created attachment 106754
--> https://bugs.freedesktop.org/attachment.cgi?id=106754&action=edit
proposed fix
Could you try this fix? Note the error is actually with the _reference_, not
the actual dr
On Sat, Sep 20, 2014 at 10:23 AM, Jason Ekstrand wrote:
> Now that offset() can properly handle MRF registers, we can use an MRF
> fs_reg and let offset() handle incrementing it correctly for different
> dispatch widths. While this doesn't have any noticable effect currently,
> it does ensure tha
On Mon, Sep 22, 2014 at 1:42 PM, Matt Turner wrote:
> On Mon, Sep 22, 2014 at 1:40 PM, Jason Ekstrand wrote:
>> On Fri, Sep 19, 2014 at 5:34 PM, Matt Turner wrote:
>>> On Fri, Sep 19, 2014 at 1:10 PM, Jason Ekstrand
>>> > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
>>> > b/src/mesa/driver
On Sat, Sep 20, 2014 at 10:23 AM, Jason Ekstrand wrote:
> Since blorp is all 16-wide and nothing isn't, in general, very careful
> about register widtsh, we'll just set it all explicitly.
width
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
ht
On Sat, Sep 20, 2014 at 10:23 AM, Jason Ekstrand wrote:
> Signed-off-by: Jason Ekstrand
> ---
> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> b/src
On Sat, Sep 20, 2014 at 10:23 AM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
> b/src/mesa/drivers/dri/i965/brw_fs.cpp
> index e06e083..11f5323 10064
Subject: s/i966/i965/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat, Sep 20, 2014 at 10:23 AM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs.cpp | 3 +++
> src/mesa/drivers/dri/i965/brw_fs.h | 1 +
> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 7 ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 29
>
Sounds good.
The old commit wasn't crossported to stable branches right? As rule of thumb,
we should not crossport non-trivial patches we haven't ran through piglit to
stable releases.
Jose
From: srol...@vmware.com
Sent: 23 September 2014 18:30
To: Jo
On Sat, Sep 20, 2014 at 10:23 AM, Jason Ekstrand wrote:
> ---
> src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 24
> ++-
> src/mesa/drivers/dri/i965/intel_screen.h | 5 +
> 2 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/d
Am 23.09.2014 20:27, schrieb Jose Fonseca:
> Sounds good.
>
> The old commit wasn't crossported to stable branches right?
Yes it was...
> As rule of thumb, we should not crossport non-trivial patches we haven't ran
> through piglit to stable releases.
That's true. Well it did fix a crash so it
On Sat, Sep 20, 2014 at 10:22 AM, Jason Ekstrand wrote:
> This series does a bunch of refactoring of the i965 fs backend IR to add
> concepts of register width and instruction execution size. There's more to
> be done yet, but this gets us most of the way there. It also removes the
> assumption
On 15/09/14 15:48, Steven Newbury wrote:
> On Fri, 2014-09-12 at 18:20 -0400, Nick Sarnie wrote:
>> Trivial patch to create the pipe loader for ilo. All the code was
>> already there.
>>
>> Signed-off-by: Nick Sarnie
>> ---
>> src/gallium/targets/pipe-loader/Makefile.am | 14 ++
>> s
On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_eu_compact.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
> b/src/mesa/drivers/dri/i965/brw_eu_compact.c
> index 561
On Tue, Sep 23, 2014 at 11:49 AM, Jason Ekstrand wrote:
>
>
> On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
>>
>> ---
>> src/mesa/drivers/dri/i965/brw_eu_compact.c | 17 +++--
>> 1 file changed, 7 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_e
On Tue, Sep 23, 2014 at 11:43 AM, Matt Turner wrote:
> On Sat, Sep 20, 2014 at 10:22 AM, Jason Ekstrand
> wrote:
> > This series does a bunch of refactoring of the i965 fs backend IR to add
> > concepts of register width and instruction execution size. There's more
> to
> > be done yet, but thi
Hi Matt,
Is there any particular reason for this patch ? Afaics the macro sets
ifGNUmake which we are not really using.
-Emil
On 22/09/14 19:51, Matt Turner wrote:
> ---
> configure.ac| 2 +-
> m4/ax_check_gnu_make.m4 | 78
> +
> 2 f
On 22/09/14 19:51, Matt Turner wrote:
> Was only tracked to be printed at the end of configure, but configure
> quits if it can't build something we requested, rather than silently
> dropping it, so printing these directories has little use.
> ---
> I don't build gallium drivers often, so perhaps I
Patches 01-08 and 10 are (v2 for patch 03 and 03 :P)
Reviewed-by: Emil Velikov
Would prefer it we can hold off 11 and 12 until we get any yay/nay on
the topic.
Thanks
Emil
P.S. It seems that egl and gbm did not get the utils treatment,
including some parts of mapi. We can do that as a follow up
On Tue, Sep 23, 2014 at 12:06 PM, Emil Velikov wrote:
> Hi Matt,
>
> Is there any particular reason for this patch ? Afaics the macro sets
> ifGNUmake which we are not really using.
I'd prefer to use things from the autoconf archive rather than just
checking for program names. They typically do s
While on the topic of interesting platforms, we still have a few DJGPP
cases. Also let's not forget that gallium has its own getenv wrapper :P
I'll send some patches for those in a bit.
The series is
Reviewed-by: Emil Velikov
-Emil
On 22/09/14 19:22, Matt Turner wrote:
> Inexplicably added in c
On Fri, Sep 19, 2014 at 1:10 PM, Jason Ekstrand wrote:
> Previously, we were generating the fast-clear shader from GLSL. The
> problem is that fast clears require that we use a replicated write rather
> than a regular write instruction. In order to get this we had a
> complicated and somewhat fr
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Fri, Sep 19, 2014 at 5:41 PM, Matt Turner wrote:
> On Fri, Sep 19, 2014 at 1:10 PM, Jason Ekstrand wrote:
>> Previously we disabled compact_virtual_grfs when dumping optimizations.
>> The idea here was to make it easier to diff the dumped shader because you
>> didn't have a sudden renaming. H
On 23/09/14 17:44, Leo Liu wrote:
> From: Christian König
>
> This patch adds a skeleton VA-API state tracker,
> which is filled with live in the subsequent patches.
>
There are some pending patches (both from me and Matt) that will cause
some trivial clashes. I'm guessing that we'll get them in
On 23/09/14 20:20, Matt Turner wrote:
> On Tue, Sep 23, 2014 at 12:06 PM, Emil Velikov
> wrote:
>> Hi Matt,
>>
>> Is there any particular reason for this patch ? Afaics the macro sets
>> ifGNUmake which we are not really using.
>
> I'd prefer to use things from the autoconf archive rather than j
On 23/09/14 20:20, Matt Turner wrote:
> On Tue, Sep 23, 2014 at 12:06 PM, Emil Velikov
> wrote:
>> Hi Matt,
>>
>> Is there any particular reason for this patch ? Afaics the macro sets
>> ifGNUmake which we are not really using.
>
> I'd prefer to use things from the autoconf archive rather than j
On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
> The array was previously indexed in units of brw_compact_inst (8-bytes),
> but before compaction all instructions are uncompacted, so every odd
> element was unused.
> ---
> src/mesa/drivers/dri/i965/brw_eu_compact.c | 59
> ++
On Tue, Sep 23, 2014 at 12:55 PM, Emil Velikov wrote:
> On 23/09/14 20:20, Matt Turner wrote:
>> On Tue, Sep 23, 2014 at 12:06 PM, Emil Velikov
>> wrote:
>>> Hi Matt,
>>>
>>> Is there any particular reason for this patch ? Afaics the macro sets
>>> ifGNUmake which we are not really using.
>>
>>
On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_eu_compact.c | 215
> -
> 1 file changed, 210 insertions(+), 5 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
> b/src/mesa/drivers/dri/i965/brw_eu_compa
On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_eu_compact.c | 39
> ++
> 1 file changed, 24 insertions(+), 15 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_eu_compact.c
> b/src/mesa/drivers/dri/i965/brw_eu_compa
On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
> The spec says the type must be W (JIP is 16-bits after all), but we've
> been emitting it with a UD type all along and have experienced no
> adverse effects. Changing the type to D allows ELSE and ENDIF
> instructions to be compacted.
> ---
>
Assuming my half-dozen comments are addressed, 5-14 are
Reviewed-by: Jason Ekstrand
On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_eu_compact.c | 35
> ++
> 1 file changed, 35 insertions(+)
>
> diff --git a/src/mesa/drivers
On Tue, Sep 23, 2014 at 1:10 PM, Jason Ekstrand wrote:
> On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
>> +int jump = brw_inst_imm_d(brw, insn);
>> +int jump_compacted = jump / sizeof(brw_compact_inst);
>> +int jump_uncompacted = jump / sizeof(brw_inst);
On Tue, Sep 23, 2014 at 1:19 PM, Jason Ekstrand wrote:
> On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
>> int offset = 0;
>> @@ -1319,17 +1323,22 @@ brw_compact_instructions(struct brw_compile *p,
>> int start_offset,
>> offset += sizeof(brw_compact_inst);
>>} else {
>
On Tue, Sep 23, 2014 at 1:24 PM, Jason Ekstrand wrote:
> On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
>>
>> The spec says the type must be W (JIP is 16-bits after all), but we've
>> been emitting it with a UD type all along and have experienced no
>> adverse effects. Changing the type to D
On Tue, Sep 23, 2014 at 1:25 PM, Matt Turner wrote:
> On Tue, Sep 23, 2014 at 1:10 PM, Jason Ekstrand
> wrote:
> > On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
> >> +int jump = brw_inst_imm_d(brw, insn);
> >> +int jump_compacted = jump / sizeof(brw_compact_inst);
On Tue, Sep 23, 2014 at 1:28 PM, Matt Turner wrote:
> On Tue, Sep 23, 2014 at 1:19 PM, Jason Ekstrand
> wrote:
> > On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
> >> int offset = 0;
> >> @@ -1319,17 +1323,22 @@ brw_compact_instructions(struct brw_compile *p,
> >> int start_offset,
> >
On Tue, Sep 23, 2014 at 12:25 PM, Matt Turner wrote:
> On Fri, Sep 19, 2014 at 1:10 PM, Jason Ekstrand wrote:
>> Previously, we were generating the fast-clear shader from GLSL. The
>> problem is that fast clears require that we use a replicated write rather
>> than a regular write instruction.
On Tue, Sep 23, 2014 at 2:08 PM, Jason Ekstrand wrote:
> On Tue, Sep 23, 2014 at 1:28 PM, Matt Turner wrote:
>>
>> On Tue, Sep 23, 2014 at 1:19 PM, Jason Ekstrand
>> wrote:
>> > On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner wrote:
>> >> int offset = 0;
>> >> @@ -1319,17 +1323,22 @@ brw_compa
LLVM commit r218316 removes the JITMemoryManager class, which is
the parent for a seemingly important class in gallivm. In order to
fix the build, I've wrapped most of lp_bld_misc.cpp in
if HAVE_LLVM < 0x0306 and modifyed the
lp_build_create_jit_compiler_for_module() function to return false
for 3
On Tue, Sep 23, 2014 at 2:21 PM, Matt Turner wrote:
> On Tue, Sep 23, 2014 at 2:08 PM, Jason Ekstrand
> wrote:
> > On Tue, Sep 23, 2014 at 1:28 PM, Matt Turner wrote:
> >>
> >> On Tue, Sep 23, 2014 at 1:19 PM, Jason Ekstrand
> >> wrote:
> >> > On Thu, Aug 28, 2014 at 8:10 PM, Matt Turner
> wr
On Tue, Sep 23, 2014 at 2:43 PM, Matt Turner wrote:
> On Sat, Sep 20, 2014 at 10:22 AM, Jason Ekstrand wrote:
>> This series does a bunch of refactoring of the i965 fs backend IR to add
>> concepts of register width and instruction execution size. There's more to
>> be done yet, but this gets us
This change seems to cause compile failure with scons:
Compiling src/util/register_allocate.c ...
src/util/register_allocate.c:76:26: fatal error: main/imports.h: No such
file or directory
#include "main/imports.h"
Looks like it could be fixed by patching up the CPPPATH in the
SConscript file
Our current atan()-approximation is pretty inaccurate at 1.0, so
let's try to improve the situation by doing a direct approximation
without going through atan.
This new implementation uses an 11th degree polynomial to approximate
atan in the [-1..1] range, and the following identitiy to reduce the
I just pushed a quick fix to get things compiling again. I'm wondering
about that dependency too though.
-Brian
On 09/23/2014 04:26 PM, Roland Scheidegger wrote:
This change seems to cause compile failure with scons:
Compiling src/util/register_allocate.c ...
src/util/register_allocate.c:
On Wed, Sep 24, 2014 at 12:39 AM, Erik Faye-Lund wrote:
> This fixes the following piglit test:
> shaders/glsl-const-folding-01
Forgot to mention: no piglit regressions seen on Ivybridge.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://l
Actually I would definitely NAK this in the current state if it weren't
too late.
We cannot let mesa includes creep in there as that defeats the purpose
of the independent util code completely.
I did a quick look and it seems the only include it really needs from
mesa is bitset, which could be mov
Oh yes and missing ALIGN + MAX2 too. I guess we could easily move these
to util code. That plus the things I already mentioned should be all
needed I think. But I strongly believe either this needs to be done or
we should revert it.
Roland
Am 24.09.2014 00:44, schrieb Roland Scheidegger:
> Actual
This cleans up the debug flags to be consistently indented and use bit
shifting instead of hex-values and fixes a bug where the new DEBUG_NO8 flag
used the same value as the DEBUG_VUE flag. This was hidden by the numbers not
being aligned. Also removes gaps in the range where DEBUG_IOCTL (0x4) an
s/i915/i965/ in subject line?
Otherwise,
Reviewed-by: Chris Forbes
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Variables are used in later patches to implement
EXT_framebuffer_multisample_blit_scaled extension.
Signed-off-by: Anuj Phogat
---
src/mesa/main/mtypes.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 0d50be8..1cb3461 100644
---
Signed-off-by: Anuj Phogat
---
src/mesa/drivers/dri/i965/brw_context.c | 36 +
1 file changed, 36 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index 619f2d5..cabc79f 100644
--- a/src/mesa/drivers/dri
Extension enables doing a multisample buffer resolve and buffer
scaling using a single glBlitFrameBuffer() call. Currently, we
have this extension implemented in BLORP which is only used by
SNB and IVB. This patch implements the extension in meta path
which makes it available to Broadwell.
Impleme
On Tuesday, September 23, 2014 12:25:05 PM Matt Turner wrote:
> On Fri, Sep 19, 2014 at 1:10 PM, Jason Ekstrand wrote:
> > Previously, we were generating the fast-clear shader from GLSL. The
> > problem is that fast clears require that we use a replicated write rather
> > than a regular write ins
On Tuesday, September 23, 2014 10:50:08 AM Matt Turner wrote:
> On Mon, Sep 22, 2014 at 1:42 PM, Matt Turner wrote:
> > On Mon, Sep 22, 2014 at 1:40 PM, Jason Ekstrand
> > wrote:
> >> On Fri, Sep 19, 2014 at 5:34 PM, Matt Turner wrote:
> >>> On Fri, Sep 19, 2014 at 1:10 PM, Jason Ekstrand
> >>
On Sat, Sep 20, 2014 at 12:11:02PM +0200, Marek Olšák wrote:
> From: Marek Olšák
Patches 1-3 are:
Reviewed-by: Tom Stellard
>
> ---
> src/gallium/drivers/radeonsi/si_compute.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compu
On 09/23/2014 03:39 PM, Erik Faye-Lund wrote:
> Our current atan()-approximation is pretty inaccurate at 1.0, so
> let's try to improve the situation by doing a direct approximation
> without going through atan.
>
> This new implementation uses an 11th degree polynomial to approximate
> atan in th
https://bugs.freedesktop.org/show_bug.cgi?id=84145
--- Comment #11 from Michel Dänzer ---
(In reply to comment #10)
> Oh hrm. Perhaps this hunk, I can't remember what that did, but it seems
> potentially dodgy:
Reverting that doesn't fix it for me.
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=84145
--- Comment #12 from Ilia Mirkin ---
(In reply to comment #11)
> (In reply to comment #10)
> > Oh hrm. Perhaps this hunk, I can't remember what that did, but it seems
> > potentially dodgy:
>
> Reverting that doesn't fix it for me.
With haagch'
https://bugs.freedesktop.org/show_bug.cgi?id=84145
--- Comment #13 from Ilia Mirkin ---
Untested, but I think this should help:
diff --git a/src/mesa/state_tracker/st_atom_texture.c
b/src/mesa/state_tracker/st_atom_texture.c
index aa5be61..b48b739 100644
--- a/src/mesa/state_tracker/st_atom_text
On Fri, Sep 19, 2014 at 1:10 PM, Jason Ekstrand wrote:
> The original vgrf splitting code was written assuming that with the
> assumption that vgrfs came in two types: those that can be split into
> single registers and those that can't be split at all It was very
> conservative and bailed as soon
This is a nice clean up.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 20.09.2014 19:11, Marek Olšák wrote:
From: Marek Olšák
Reviewed-by: Michel Dänzer
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
mesa-dev
For 3d textures, NumLayers is set to 1, which is not what we want. This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84145
Signed-off-by: Ilia Mirkin
On Fri, Sep 19, 2014 at 07:57:00PM -0700, Matt Turner wrote:
> ---
> This also means I'll drop 05/20.
>
> v2: Just pass block to emit_before(), rather than trying to get rid
> of emit_before().
Reviewed-by: Topi Pohjolainen
___
mesa-dev mailing lis
On 24.09.2014 14:01, Ilia Mirkin wrote:
For 3d textures, NumLayers is set to 1, which is not what we want. This
fixes the newly added gl-layer-render-storage test (which constructs
immutable 3d textures). Fixes regression introduced in d82bd7eb060.
Bugzilla: https://bugs.freedesktop.org/show_bug
https://bugs.freedesktop.org/show_bug.cgi?id=84145
--- Comment #14 from smoki ---
Tried both patches, neither does not fix the bug.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.fre
https://bugs.freedesktop.org/show_bug.cgi?id=84145
--- Comment #15 from Ilia Mirkin ---
(In reply to comment #14)
> Tried both patches, neither does not fix the bug.
Which patches are "both patches"? Can you confirm whether
http://patchwork.freedesktop.org/patch/34010/ has any effect on your is
https://bugs.freedesktop.org/show_bug.cgi?id=84145
Benjamin Bellec changed:
What|Removed |Added
CC||b.bel...@gmail.com
--- Comment #16 fro
https://bugs.freedesktop.org/show_bug.cgi?id=84145
--- Comment #17 from smoki ---
Created attachment 106762
--> https://bugs.freedesktop.org/attachment.cgi?id=106762&action=edit
borked.jpg
(In reply to comment #15)
> (In reply to comment #14)
> > Tried both patches, neither does not fix the b
99 matches
Mail list logo
