| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As of now, the width field is no longer used for anything. The width field
"seemed like a good idea at the time" but is actually entirely redundant
with the instruction's execution size. Initially, it gave us the ability
to easily set the instructions execution size based entirely on register
widths. With the builder, we can easiliy set the sizes explicitly and the
width field doesn't have as much purpose. At this point, it's just
redundant information that can get out of sync so it really needs to go.
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Francisco Jerez <currojerez@riseup.net>
|
| |
|
|
|
| |
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Acked-by: Francisco Jerez <currojerez@riseup.net>
|
| |
|
|
|
|
|
|
| |
Shortly, offset() will depend on the builder so we need it moved to some
place where it has access to that.
Reviewed-by: Iago Toral Quiroga <itoral@igali.com>
Acked-by: Francisco Jerez <currojerez@riseup.net>
|
| |
|
|
|
|
| |
This is now unused. Saves a whole bit of memory per instruction.
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
| |
|
|
|
|
| |
v2: Use set_ prefix.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
| |
|
|
|
|
| |
v2: Use set_ prefix.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
| |
|
|
|
|
| |
v2: Use set_ prefix.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
| |
|
|
|
|
| |
Used in the next commit.
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
|
| |
|
|
| |
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
| |
|
|
|
|
|
| |
stride == 0 implies that the register has one channel per vector
component.
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
| |
|
|
|
|
|
|
| |
The effective_width field was an ill-concieved hack to get around issues in
the LOAD_PAYLOAD instruction. Now that the LOAD_PAYLOAD instruction is far
more sane, this field can die.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
| |
|
|
|
|
|
|
|
|
| |
This commit adds a new is_copy_payload helper to fs_inst that takes the
place of the similarly named functions in cse and register coalesce. The
two is_copy_payload functions in CSE and register coalesce were subtly
different and potentially subtly broken. The new version unifies the two
and should be more correct.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
| |
|
|
|
|
|
|
|
| |
Previously, we had a special case for uniforms and immediates and then a
bunch of asserts for various other pessimal things. This commit changes it
so that it explicitly does something on each register file. Some of them
are disallowed and others are treated properly.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
| |
|
|
|
|
|
| |
Immediates are generally uniform, they yield the same value to both
halves of any instruction.
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
| |
|
|
|
|
| |
v2: Style fixes.
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
| |
|
|
| |
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an instruction has a side effect, it impacts the available options when
reordering an instruction. As the EOT flag is an implied write to the render
target in the FS, it can be considered a side effect.
This patch shouldn't actually have any impact on the current code since the EOT
flag implies that the opcode is already one with side effects,
FS_OPCODE_FB_WRITE. The next patch however will introduce an optimization
whereby the EOT flag can occur with an opcode SHADER_OPCODE_TEX, and as that
instruction will perform the same implied write to the render target, it cannot
be reordered.
v2: Remove extra whitespace (Matt)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
provided on construction.
Using 'ralloc*(this, ...)' is wrong if the object has automatic
storage or was allocated through any other means. Use normal dynamic
memory instead.
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
| |
|
|
| |
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
| |
|
|
|
|
| |
It will also be useful in the VEC4 back-end.
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
| |
|
|
|
|
| |
The fs_visitor argument of fs_inst::regs_read() wasn't used at all.
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
|
|
One should be able to manipulate i965 IR without pulling the whole
FS/VEC4 visitor classes -- Optimization passes and other
transformations would ideally be visitor-agnostic. Among other issues
this avoids a circular dependency between the header file where such
visitor-agnostic code will be defined and the main FS/VEC4 header
where both IR (layer below) and visitor (layer above) happen to be
defined.
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
