The next patch will introduce an optimization that only works when
integers are not represented as floating point values.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser_extras.cpp | 2 +-
src/glsl/ir_optimization.h | 2 +-
src/glsl/opt_algebraic.cpp | 8 +---
src/glsl/test
The IR is not supposed to support implicit type conversions; we just
failed to validate it.
Signed-off-by: Kenneth Graunke
---
src/glsl/ir_validate.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/glsl/ir_validate.cpp b/src/glsl/ir_validate.cpp
index 527acea..71defc8 100644
--- a/s
The i965 MUL instruction doesn't natively support 32-bit by 32-bit
integer multiplication; additional instructions (MACH/MOV) are required.
However, we can avoid those if we know one of the operands can be
represented in 16 bits or less. The vector backend's is_16bit_constant
static helper functio
This makes the function available from core Mesa code, including the
GLSL compiler.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.h | 6 --
src/mesa/main/macros.h | 11 +++
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/sr
Integer shifts are basically always well supported and efficient; that
isn't always true of integer division, and sometimes even integer
multiplication isn't without issues.
On some Intel hardware, INTDIV can't be used in SIMD16 mode. It also
doesn't support immediate operands (on any generation)
The next few patches will introduce an optimization that only works when
integers are not represented as floating point values.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_parser_extras.cpp| 6 --
src/glsl/ir_optimization.h | 3 ++-
src/glsl/linker.cpp
Performance warnings are logged via KHR_debug in addition to when the
INTEL_DEBUG=perf environment variable is set. Without this, messages in
debug contexts would have "(null)" for the reason.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
1 file changed, 1 inse
ir_binop_ubo_load takes unsigned integer operands. However, the array
index used to compute these offsets may be a signed integer. (For
example, see Piglit's spec/glsl-1.40/uniform_buffer/fs-bvec-array).
For some reason, we were missing an ir_binop_i2u cast, and ir_validator
was failing to catch
The vector backend already implemented this optimization, but
surprisingly, we never bothered to implement it in the scalar backend.
In addition to saving two instructions, this eliminates a use of the
accumulator as an explicit source, which is unsupported in SIMD16 mode
on Gen7+, which could hel
On 04/05/2014 01:13 AM, Ian Romanick wrote:
> I've been thinking about this a bit, and I think this is more complex
> than it needs to be. I don't have a complete design, but here are some
> thoughts on the matter.
>
> When linking is all done, we just want the UniformRemapTable. It's
> entires s
On 04/05/2014 01:18 AM, Ian Romanick wrote:
> On 03/27/2014 11:45 PM, Tapani Pälli wrote:
>> Patch refactors the existing uniform processing so explicit locations
>> are taken in to account during variable processing. These locations
>> are temporarily stored in gl_uniform_storage before actual loc
I'll move this patch after 7/30 to avoid things being temporarily broken.
On Thu, Apr 3, 2014 at 3:34 AM, Brian Paul wrote:
> On 04/02/2014 02:04 AM, Chris Forbes wrote:
>>
>> These formats can be cast to others (with different component types or
>> sizes) via ARB_texture_view or ARB_shader_image
Yes, that will work -- will do.
On Mon, Apr 7, 2014 at 5:29 PM, Kenneth Graunke wrote:
> On 04/02/2014 01:05 AM, Chris Forbes wrote:
>> None of the other 3-component 16bpc formats are directly supported, so
>> they get promoted to XRGB equivalents. *Not* promoting RGB16F the same
>> way makes tex
On 04/02/2014 01:05 AM, Chris Forbes wrote:
> None of the other 3-component 16bpc formats are directly supported, so
> they get promoted to XRGB equivalents. *Not* promoting RGB16F the same
> way makes texture views much more fiddly -- we don't want to have to do
> crazy copying behind the scenes.
On 04/05/2014 12:58 AM, Ian Romanick wrote:
> On 04/04/2014 02:42 PM, Ian Romanick wrote:
>> On 03/27/2014 11:45 PM, Tapani Pälli wrote:
>>> Patch adds a preprocessor define for the extension and stores
>>> explicit location data for uniforms during AST->HIR conversion.
>>> It also sets layout toke
On 04/05/2014 12:33 AM, Ian Romanick wrote:
> On 03/27/2014 11:45 PM, Tapani Pälli wrote:
>> Hi;
>>
>> Patches implement the extension, no Piglit regressions and all the tests
>> for the extension pass (I've planned some more tests which are not yet
>> in though).
>>
>> Changes shortly:
>>
>>-
On 04/02/2014 01:04 AM, Chris Forbes wrote:
> Previously, we would unpack the texels to floats using *_TO_FLOAT_TEX,
> and then pack them into the desired format using FLOAT_TO_*. Unfortunately,
> this isn't quite the inverse operation, and so some texel values would
> end up off-by-one.
These fun
From: Chia-I Wu
Given
mov vgrf7, vgrf9.xyxz
add vgrf9.xyz, vgrf4.xyzw, vgrf5.xyzw
add vgrf10.x, vgrf6.xyzw, vgrf7.
the last instruction would be wrongly changed to
add vgrf10.x, vgrf6.xyzw, vgrf9.
during copy propagation.
The issue is that when deciding if a record should be
Am 05.04.2014 03:46, schrieb Emil Velikov:
In the presence of LLVM the final library exports every symbol from
the llvm namespace. Resolve this by using a version script (w/o the
version/name tag).
Considering that there are only ~25 symbols, explicitly list them
to minimize the chances of rogue
Am 05.04.2014 03:47, schrieb Emil Velikov:
Cc: Christian König
Signed-off-by: Emil Velikov
Reviewed-by: Christian König
---
src/gallium/targets/r600/omx/Makefile.am | 8 +---
src/gallium/targets/radeonsi/omx/Makefile.am | 8 +---
2 files changed, 2 insertions(+), 14 deletio
Am 05.04.2014 03:46, schrieb Emil Velikov:
Using export-symbols-regex is the least desirable method of restricting
the exported symbols, as is completely messes up with the symbol table.
radeon_drm_winsys_create is not needed, avoid exporting it.
Please add that anyway, we are going to need OM
Am 05.04.2014 11:47, schrieb Emil Velikov:
On 05/04/14 10:34, Christian König wrote:
Am 05.04.2014 03:46, schrieb Emil Velikov:
Using export-symbols-regex is the least desirable method of restricting
the exported symbols, as is completely messes up with the symbol table.
Why? As far as I can t
Am 05.04.2014 11:16, schrieb Maarten Lankhorst:
op 05-04-14 03:46, Emil Velikov schreef:
Rather than having multiple (almost) identical version scripts use
a single one.
Cc: Maarten Lankhorst
Cc: Christian König
Signed-off-by: Emil Velikov
---
src/gallium/Automake.inc
Am 05.04.2014 03:46, schrieb Emil Velikov:
Using export-symbols-regex is the least desirable method of restricting
the exported symbols, as is completely messes up with the symbol table.
Why? As far as I can tell it does exactly what it is supposed to do.
Christian.
Cc: Christian König
Sig
On Sat, Apr 5, 2014 at 5:07 AM, Emil Velikov wrote:
> Hi all,
>
> This is the final round cleaning up the exported symbols mayhem for
> gallium.
> IIRC the only place in mesa that needs some love is src/mapi.
>
> Highlights:
> - Drops __dri2ConfigOptions for both classic and gallium drivers.
> Pr
https://bugs.freedesktop.org/show_bug.cgi?id=77102
Ilia Mirkin changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |nouveau@lists.freedesktop.o
https://bugs.freedesktop.org/show_bug.cgi?id=77102
Stefan Ringel changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NOTABUG
Hi Jon,
Sorry about this breakage. I assumed that the library extensions are handled
consistently across mesa. Seems like I was wrong.
Guessing that you meant to send this to the mesa-dev ?
On 06/04/14 15:59, Jon TURNEY wrote:
> Partially revert bba9c28 "configure: use LIB_EXT rather than hardco
https://bugs.freedesktop.org/show_bug.cgi?id=77102
Ilia Mirkin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=77102
--- Comment #2 from Stefan Ringel ---
Created attachment 96975
--> https://bugs.freedesktop.org/attachment.cgi?id=96975&action=edit
vainfo valgrind
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=77102
--- Comment #3 from Stefan Ringel ---
Created attachment 96976
--> https://bugs.freedesktop.org/attachment.cgi?id=96976&action=edit
vdpauinfo valgrind
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=77102
--- Comment #1 from Stefan Ringel ---
Created attachment 96974
--> https://bugs.freedesktop.org/attachment.cgi?id=96974&action=edit
vdpainfo gdb
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=77102
Priority: medium
Bug ID: 77102
Assignee: mesa-dev@lists.freedesktop.org
Summary: gallium nouveau has no profile in vdpau and libva
Severity: normal
Classification: Unclassified
33 matches
Mail list logo
