similar to: [PATCH 1/2] allow path to envyas binary to be specified

rendercheck -f a8r8g8b8 passes as much as on a GK208, and xv appears to work. Very lightly tested. Instead of sticking coordinates into pushbufs, the vertex shader is modified to read them from a constbuf, indexed by vertex id. This approach could be used for all nvc0 generations, but I didn't want to rock the boat. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Note: this

I believe I've addressed all the feedback from the first time around, and also made fixes necessary for GM20x based on testing results. I believe now it should actually work for all GM10x and GM20x. Further, GP10x should be very easy to add, but without someone to actually test I didn't want to claim support for it. Ilia Mirkin (7): exa: add GM10x acceleration support hwdefs: update

Evan Cheng-2 wrote: > > Well, how many possible permutations are there? Is it possible to > model each case as a separate physical register? > > Evan > I don't think so. There are 4x4x4x4 = 256 permutations. For example: * xyzw: default * zxyw * yyyy: splat Even if can model each of these 256 cases as a separate physical register, how can I model the use of r0.xyzw in

On Wednesday 24 September 2008 15:23, Mon Ping Wang wrote: > To my knowledge, I don't think there is an easy way to get the MVT > information from a MachineOperand. Why do you need it for? In my See the thread I started on this very topic. Spilling is one place you'd like to have this information. > mind, the MachineInstr and its associated operands represent a >

Yes, Another reason this is useful is for register-type specific representations of said register. For example, all my registers are 128bit vector registers, however, if I am only dealing with 32 bit vector registers, I can add write/read masks that tell the underlying hardware not to work on the whole register, but just a subset of the components. 32bit scalar mov: mov r1.x___, r0.x000 64bit

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedestkop.org> --- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp index b8d0d3e..d566c99

v4: Updated the wait dependancy bars based on tex component masks. This patch adds proper delays to maxwell exa shaders. Tested with rendercheck -f a8r8g8b8. I am still wondering whether the rd's are required. We could still wait on the write bars instead. eg. see "sched (st 0xf wr 0x1 wt 0x2) (st 0xf wr 0x1 wt 0x2) (st 0xf)" in exacmnv110.fp Trello:

https://bugs.freedesktop.org/show_bug.cgi?id=96565 Bug ID: 96565 Summary: Clive Barker's Jericho displays strange,vivid colors when motion blur enabled Product: Mesa Version: 11.2 Hardware: Other OS: All Status: NEW Keywords: bisected, regression Severity: normal

https://bugs.freedesktop.org/show_bug.cgi?id=90348 Bug ID: 90348 Summary: Spilling failure of b96 merged value Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

Removed explicit depar instructions as they're not used by the blob anymore. Signed-off-by: Aaryaman Vasishta <jem456.vasishta at gmail.com> --- src/shader/exac8nv110.fp | 5 ++--- src/shader/exac8nv110.fpc | 10 ++++------ src/shader/exacanv110.fp | 5 ++--- src/shader/exacanv110.fpc | 10 ++++------ src/shader/exacmnv110.fp | 5 ++--- src/shader/exacmnv110.fpc | 10 ++++------

Sorry for the late response, been busy with some personal stuff + work... On Tue, Jun 13, 2017 at 6:52 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Mon, Jun 12, 2017 at 5:46 PM, Samuel Pitoiset > <samuel.pitoiset at gmail.com> wrote: > > > > > > On 06/10/2017 09:14 AM, Aaryaman Vasishta wrote: > >> > >> See the 'wt' on the

This patch adds proper delays to maxwell exa shaders. rendercheck tests seem consistent with/without this patch. I haven't extensively tested them though. Trello: https://trello.com/c/6LPB2EIS/174-update-maxwell-shaders-with-proper-delays Signed-off-by: Aaryaman Vasishta <jem456.vasishta at gmail.com> --- src/shader/exac8nv110.fp | 10 +++++----- src/shader/exac8nv110.fpc | 18

v2: Add missing delays This patch adds proper delays to maxwell exa shaders. rendercheck tests seem consistent with/without this patch. I haven't extensively tested them though. Trello: https://trello.com/c/6LPB2EIS/174-update-maxwell-shaders-with-proper-delays Signed-off-by: Aaryaman Vasishta <jem456.vasishta at gmail.com> --- src/shader/exac8nv110.fp | 10 +++++-----

On Tue, Jun 6, 2017 at 7:15 AM, Samuel Pitoiset <samuel.pitoiset at gmail.com> wrote: > Nice work! > > See my comments below, and double-check if some of them can be applied to > the shaders I didn't review yet. > > I recommend you to test your work because if one sched code is wrong, you > are likely going to kill your card and reboot your box. :-) > > >

Hi, On Wed, Jun 28, 2017 at 12:53 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > BTW, you can drop those explicit "depbar" ops. I think they're only > needed when you're doing something weird with barriers. Blob doesn't > use them (anymore) > Gotcha. Should I remove them in the same patch or a different one? It seems like the depbar removal is

On Thu, Jun 8, 2017 at 5:01 AM, Samuel Pitoiset <samuel.pitoiset at gmail.com> wrote: > > > On 06/07/2017 06:58 PM, Aaryaman Vasishta wrote: > >> >> >> On Tue, Jun 6, 2017 at 7:15 AM, Samuel Pitoiset < >> samuel.pitoiset at gmail.com <mailto:samuel.pitoiset at gmail.com>> wrote: >> >> Nice work! >> >> See my

We have received an email in Ubuntu alerting us that something strange was going on during the r-base 2.7.1 rc build (see [1]). It seems that there is an error during the convertion of R-FAQ.texi to pdf. The following excerpt, taken from [2], shows the problem: /bin/sh: line 0: test: too many arguments TEXINPUTS=".:$TEXINPUTS" /usr/bin/texi2dvi --texinfo="@set UseExternalXrefs

Alex, From my experience in working with GPU vector registers; there is no support for swizzles in the manner that you would normally code them, and in my case I have 6^4 permutations on src registers and 24 combinations in the dst registers. The way that I ended up handling this was to have different register classes for 1, 2, 3 and 4 component vectors. This made the generic cases very simple

On 06/10/2017 09:14 AM, Aaryaman Vasishta wrote: > See the 'wt' on the first fmul in exacanv110.fp, exacmnv110.fp and > exasanv110.fp. Any ideas on what could be causing the first fmul to > require $r0 and/or $r1? 'tex nodep $r4 $r2 0x0 0x1 t2d 0xf' is actually: 'tex nodep $r4:$r7 $r2 0x0 0x1 t2d 0xf' Very confusing, I know. > > Cheers, > Aaryaman

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New nouveau DDX release. Ben Skeggs (1): Bump version to 1.0.12 Ilia Mirkin (14): copy: don't bother trying to create copy on pre-nva3 allow path to envyas binary to be specified kepler: remove unnecessary texbars, add live-only tex for nvf0 use defined method names where available nv50: explicitly disable