https://bugs.freedesktop.org/show_bug.cgi?id=84186
Michel Dänzer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Signed-off-by: Timothy Arceri
---
Note: This doesn't work for interface blocks, I'm still
trying to figure out whats missing for that to work.
Piglit test:
http://lists.freedesktop.org/archives/piglit/2014-December/013857.html
No piglit regressions.
src/glsl/ast_to_hir.cpp | 1 +
1 file c
https://bugs.freedesktop.org/show_bug.cgi?id=79039
Bug 79039 depends on bug 78775, which changed state.
Bug 78775 Summary: [BDW regression]white screen when change Half Life 1
resolution
https://bugs.freedesktop.org/show_bug.cgi?id=78775
What|Removed |Added
---
https://bugs.freedesktop.org/show_bug.cgi?id=87657
--- Comment #2 from Alexander von Gluck ---
Created attachment 111258
--> https://bugs.freedesktop.org/attachment.cgi?id=111258&action=edit
EGL fix v2
I finally think I see what happened. The GCI student attempted to get the
final libEGL.so f
https://bugs.freedesktop.org/show_bug.cgi?id=87654
--- Comment #4 from Alexander von Gluck ---
Created attachment 111257
--> https://bugs.freedesktop.org/attachment.cgi?id=111257&action=edit
Fix v2
I finally think I see what happened. The GCI student attempted to get the
final libEGL.so from
On Tue, Dec 23, 2014 at 10:42 PM, Dave Airlie wrote:
>>> +#define TGSI_OPCODE_DRCP208 /* eg, cayman */
>>> +#define TGSI_OPCODE_DSQRT 209 /* eg, cayman also has DRSQ
>>> */
>>
>>
>> Adding DRSQ seems like a good idea, at least for graphics with floats its
>> more freq
On 24.12.2014 02:49, Tom Stellard wrote:
> Rather than building a new one every compile. This should reduce some
> of the overhead of compiling shaders.
Thanks, though unfortunately it doesn't seem to make much difference for
piglit for me.
> One consequence of this change is that we lose the M
>> + // fprintf(stderr, "%f %f\n", src[0].d[0], src[1].d[0]);
>
>
> leftover debug print
dropped,
>> enum tgsi_exec_datatype {
>> TGSI_EXEC_DATA_FLOAT,
>> TGSI_EXEC_DATA_INT,
>> - TGSI_EXEC_DATA_UINT
>> + TGSI_EXEC_DATA_UINT,
>> + TGSI_EXEC_DATA_DOUBLE,
>
>
> One comma too many
f
On 2014-12-22 09:17, Emil Velikov wrote:
On 22/12/14 14:36, Alexander von Gluck IV wrote:
From: Adrián Arroyo Calle
* Builds perfect and it loads the driver.
* It still reports EGL_NOT_INITIALIZED
---
src/egl/drivers/dri2/SConscript |8 +++-
src/egl/drivers/dri2/platform_haiku
On 2014-12-22 08:45, kallisti5 wrote:
On 2014-12-22 08:41, Matt Turner wrote:
On Mon, Dec 22, 2014 at 6:36 AM, Alexander von Gluck IV
wrote:
From: Emil Velikov
Attempt to get a egl_dri2 SConscript
- Drop going into the gallium egl-static
- Promote the main library to a shared one.
- Conve
On 2014-12-22 09:24, Emil Velikov wrote:
On 22/12/14 14:36, Alexander von Gluck IV wrote:
From: Adrián Arroyo Calle
---
src/egl/drivers/dri2/egl_dri2.c |7 ++
src/egl/drivers/dri2/platform_haiku.cpp | 172
+--
src/egl/main/SConscript
On 2014-12-22 08:41, Matt Turner wrote:
On Mon, Dec 22, 2014 at 6:36 AM, Alexander von Gluck IV
wrote:
From: Emil Velikov
Attempt to get a egl_dri2 SConscript
- Drop going into the gallium egl-static
- Promote the main library to a shared one.
- Convert libEGL_Haiku into a conv. library -
On 2014-12-22 08:36, Alexander von Gluck IV wrote:
From: Adrián Arroyo Calle
---
include/EGL/eglplatform.h | 10 ++-
src/SConscript |3 +-
src/egl/drivers/dri2/SConscript | 24 +
src/egl/drivers/dri2/platform_haiku.cpp
https://bugs.freedesktop.org/show_bug.cgi?id=87654
--- Comment #3 from Alexander von Gluck ---
Created attachment 111250
--> https://bugs.freedesktop.org/attachment.cgi?id=111250&action=edit
Potential windows fix, v1. Needs testing
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=87654
--- Comment #2 from Alexander von Gluck ---
I think the attached patch will fix the build issue on windows. It looks as
though the egl dri2 code shouldn't be built on Windows based on the
pre-402c80837 code.
scons/gallium.py:env['dri'] =
On Tue, 23 Dec 2014 22:50:30 +0100, Dave Airlie wrote:
This patch adds support for a set of double opcodes
to TGSI. It is an update of work done originally
by Michal Krol on the gallium-double-opcodes branch.
The opcodes have a hint where they came from in the
header file.
v2: add unsigned/in
https://bugs.freedesktop.org/show_bug.cgi?id=87657
--- Comment #1 from Alexander von Gluck ---
I'm looking into this one in addition to #87654.
SCons build was / is testing fine on Arch Linux.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=87658
Bug ID: 87658
Summary: [llvmpipe] SEGV in sse2_has_daz on ancient Pentium4-M
Product: Mesa
Version: 10.3
Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=87657
Bug ID: 87657
Summary: dri_interface.h:51:17: error: drm.h: No such file or
directory
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=87654
--- Comment #1 from Alexander von Gluck ---
I was just looking at this :-)
The EGL scons code is a bit of a mess.
I wonder if Windows is seeing this due to:
diff --git a/src/SConscript b/src/SConscript
index 2657bba..eb4cd3c 100644
--- a/src/SC
https://bugs.freedesktop.org/show_bug.cgi?id=87654
Bug ID: 87654
Summary: undefined reference to `_eglBuiltInDriverGALLIUM'
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
K
From: Dave Airlie
These act like flt32 except they take up two slots, and you
can only add 2 x flt64 constants in one slot.
The main reason they are different is we don't want to match half a flt64
constants against a flt32 constant in the matching code, we need to make
sure we treat both parts
May as well get the gallium side of the fp64 work discussed
while the mesa side is stuck in unreviewed limbo.
So any suggestions for opcode changes or new opcodes I've missed
I pretty much took a union of SM5 and radeon hw as a first pass,
I have noticed that radeon allows modifiers to work on do
This patch adds support for a set of double opcodes
to TGSI. It is an update of work done originally
by Michal Krol on the gallium-double-opcodes branch.
The opcodes have a hint where they came from in the
header file.
v2: add unsigned/int <-> double
v2.1: update docs.
This is based on code by M
On Tue, Dec 23, 2014 at 11:34 AM, Ian Romanick wrote:
> On 12/23/2014 08:26 AM, Matt Turner wrote:
>> On 12/22/14, Ian Romanick wrote:
>>> On 12/21/2014 03:24 PM, Matt Turner wrote:
total instructions in shared programs: 5877012 -> 5876617 (-0.01%)
instructions in affected programs:
On Mon, Dec 22, 2014 at 07:29:30PM -0800, Ben Widawsky wrote:
> I couldn't find any other callers which have a DW operand in a mul.
>
> Signed-off-by: Ben Widawsky
>
> ---
> It would be good if someone else can take a look
> ---
> src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 --
> 1 fil
On 12/23/2014 11:19 AM, Julien Cristau wrote:
> On Sun, Dec 21, 2014 at 12:08:44 -0800, Ian Romanick wrote:
>
>> From: Ian Romanick
>>
>> Signed-off-by: Ian Romanick
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87516
>> ---
>> src/mesa/main/shaderapi.c | 26
On 12/23/2014 08:26 AM, Matt Turner wrote:
> On 12/22/14, Ian Romanick wrote:
>> On 12/21/2014 03:24 PM, Matt Turner wrote:
>>> total instructions in shared programs: 5877012 -> 5876617 (-0.01%)
>>> instructions in affected programs: 33140 -> 32745 (-1.19%)
>>>
>>> From before the commit that
Rather than building a new one every compile. This should reduce some
of the overhead of compiling shaders.
One consequence of this change is that we lose the MachineInstrs dumps
when dumping the shaders via R600_DEBUG. The LLVM IR and assembly is
still dumped, and if you still want to see the M
---
src/gallium/drivers/radeon/r600_pipe_common.c | 11 +--
src/gallium/drivers/radeon/radeon_llvm_emit.c | 21 ++---
src/gallium/drivers/radeon/radeon_llvm_emit.h | 2 +-
src/gallium/drivers/radeonsi/si_pipe.c| 9 +++--
4 files changed, 27 insertions(+), 16 d
On Sun, Dec 21, 2014 at 12:08:44 -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> Signed-off-by: Ian Romanick
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87516
> ---
> src/mesa/main/shaderapi.c | 26 --
> 1 file changed, 20 insertions(+), 6 deletions(-)
On Tue, Dec 23, 2014 at 10:45:27AM -0800, Matt Turner wrote:
> On Mon, Dec 22, 2014 at 7:29 PM, Ben Widawsky
> wrote:
> > This patch addresses the errata on GEN8+ which disallows the mul/mach macro
> > to
> > have a modifier on src1. This was previously listed as a FINISHME.
>
> To be clear, I d
On Mon, Dec 22, 2014 at 7:29 PM, Ben Widawsky
wrote:
> "A source modifier must not be used on src1 for the macro operation. This
> applies to both mul and mach of the macro. If source modifier is required, an
> additional mov instruction may be used before the macro."
>
> Today, we only use MACH i
On Tue, Dec 23, 2014 at 10:38:36AM -0800, Matt Turner wrote:
> On Mon, Dec 22, 2014 at 7:29 PM, Ben Widawsky
> wrote:
> > The fancy DW * DW = QW that was enabled earlier in the series for the fs
> > does
> > not work for the vec4 paths. vec4 paths use ALIGN16 mode, which is
> > restricted
> > fr
On Mon, Dec 22, 2014 at 7:29 PM, Ben Widawsky
wrote:
> This patch addresses the errata on GEN8+ which disallows the mul/mach macro to
> have a modifier on src1. This was previously listed as a FINISHME.
To be clear, I don't think this is an errata. It's just a natural
consequence of needing for f
On Mon, Dec 22, 2014 at 7:29 PM, Ben Widawsky
wrote:
> As it turns out, I have other uses for this tiny convenience function. Simple
> extraction for use by others. Matt was right for not liking the macro in the
> initial patch.
>
> While doing this, add it to a few easy to spot users of this func
On Mon, Dec 22, 2014 at 7:29 PM, Ben Widawsky
wrote:
> The fancy DW * DW = QW that was enabled earlier in the series for the fs does
> not work for the vec4 paths. vec4 paths use ALIGN16 mode, which is restricted
> from the extended precision granted by gen8.
>
> This is based on a similar patch f
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Ah, I see.
I was assuming that a necessary dirty bit had not been set.
But the right dirty bit had been set and was being ignored.
Watching the right dirty bit is going to look a bit different in 10.3 or
10.4.
It will need to use ".cache = CACHE_NEW_WM_PROG" in brw_texture_surfaces
instead of addi
On 12/22/14, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky
> ---
> src/mesa/drivers/dri/i965/intel_extensions.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
> b/src/mesa/drivers/dri/i965/intel_extensions.c
> index
On 12/22/14, Ben Widawsky wrote:
> This patch uses the new QWORD type introduced on Gen8. This allows us to
> perform
> the operation without requiring the additional MACH.
>
> Similar to Gen7, it seems we must demote SIMD16 to 2 SIMD8s. On the bright
> side,
> we get the results in 3 instructions
On 12/22/14, Ben Widawsky wrote:
> From: Matt Turner
>
> v2 by Ben:
> Keep the Gen8 code:
> Gen8 will be fixed later. The intent is to limit the platform impact of
> the
> patch to fixing just Gen7. The original Gen7 code as written by Matt did
> not
> work properly on Gen8 (I can't remembe
Reviewed-by: Mike Stroyan
On Mon, Dec 22, 2014 at 9:28 PM, Chris Forbes wrote:
>
> Reviewed-by: Chris Forbes
>
> On Tue, Dec 23, 2014 at 3:58 PM, Kenneth Graunke
> wrote:
> > This was probably missed when moving from a fixed binding table layout
> > to a dynamic one that changes based on the s
On 12/22/14, Ben Widawsky wrote:
> From: Matt Turner
>
> In order to do a full 32x32 integer multiply using the MUL/MACH macro, the
> operation must be split into 2 SIMD8 operations. This is required even if
> you
> don't care about the high bits. My interpretation of the requirement is that
> th
On 12/22/14, Ian Romanick wrote:
> On 12/21/2014 03:24 PM, Matt Turner wrote:
>> total instructions in shared programs: 5877012 -> 5876617 (-0.01%)
>> instructions in affected programs: 33140 -> 32745 (-1.19%)
>>
>> From before the commit that allows VF constant propagation (which hurt
>> some
On 12/22/14, Ian Romanick wrote:
> On 12/21/2014 03:24 PM, Matt Turner wrote:
>> + } else if (value.type == BRW_REGISTER_TYPE_VF) {
>> + value.fixed_hw_reg.dw1.ud &= ~0x80808080;
>
> What's the magic constant? Sign bits of all the vector float values?
Yes. The 32-bit VF immediate co
On 12/22/14, Ian Romanick wrote:
> What does this unreachable() gains compared to an assert()?
Now that you mention it, probably nothing. I'll change it to plain assert().
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=86701
--- Comment #4 from nerdopol...@verizon.net ---
That other report seems to be when there was a bug in software rendering that
ended up being fixed, as software rendering was working mostly until it was
dropped. Without software rendering, many cli
Hi,
Not sure there's anything to maintain, but sure, I'll maintain it.
Best,
OG.
On Sun, Dec 21, 2014 at 8:51 PM, Emil Velikov wrote:
> On 20 December 2014 at 14:21, Olivier Galibert wrote:
>> Here is an implementation I've written myself, so no license issues.
>>
> Thanks OG,
>
> Afaics
49 matches
Mail list logo
