https://bugs.freedesktop.org/show_bug.cgi?id=82255
--- Comment #12 from Ilia Mirkin imir...@alum.mit.edu ---
The source data is messed up. Just look at the luma/chroma planes that you
captured.
The overall image is 1280x544. Which means that each field is 1280x272. And
chroma would be 640x136
https://bugs.freedesktop.org/show_bug.cgi?id=82255
--- Comment #13 from Emil Velikov emil.l.veli...@gmail.com ---
Created attachment 105558
-- https://bugs.freedesktop.org/attachment.cgi?id=105558action=edit
dump vdpau texture data
(In reply to comment #12)
The source data is messed up. Just
https://bugs.freedesktop.org/show_bug.cgi?id=82255
--- Comment #14 from Emil Velikov emil.l.veli...@gmail.com ---
Created attachment 105560
-- https://bugs.freedesktop.org/attachment.cgi?id=105560action=edit
Ilia's earlier patch
The patch that you've linked earlier on IRC works like a champ
When constant folding a MAD operation, we first fold the multiply and
generate an ADD. However we do so without making sure that the immediate
can be handled in the saturate case. If it can't, load the immediate in
a separate instruction.
Reported-by: Tiziano Bacocco tizb...@gmail.com
The mt address is about to be used more, make sure it's set
appropriately.
Reported-by: Emil Velikov emil.l.veli...@gmail.com
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
---
The current code... makes no sense. Use nouveau_bo_ref to attach the bo
to the exposed resource so as to have the proper lifetime guarantees.
Tested-by: Emil Velikov emil.l.veli...@gmail.com
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
---
With VP2, nv50_miptree is faked because the underlying bo's have to be
laid out in a certain way. This is done by adjusting the address. Make
sure that blits (and everything else for consistency) use the mt address
rather than the bo address as a base.
This fixes retrieving chroma plane with
The set of variable defs does not need to be ordered in any way, and
removing/adding elements is a fairly common operation in various
optimization passes.
This shortens runtime of piglit test fp-long-alu to ~11s from ~22s
No piglit regressions observed on nvc0!
Signed-off-by: Tobias Klausmann
https://bugs.freedesktop.org/show_bug.cgi?id=82255
Ilia Mirkin imir...@alum.mit.edu changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=83079
Ilia Mirkin imir...@alum.mit.edu changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
10 matches
Mail list logo