From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 85376] Dolphin emulator has bad colors Date: Tue, 11 Nov 2014 20:33:50 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1623023848==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id C703C891A4 for ; Tue, 11 Nov 2014 12:33:49 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1623023848== Content-Type: multipart/alternative; boundary="1415738029.D15b8a0.24685"; charset="UTF-8" --1415738029.D15b8a0.24685 Date: Tue, 11 Nov 2014 20:33:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=85376 --- Comment #10 from Ilia Mirkin --- Some observations (from IRC, edited): In shader 21 (from attachment 109303), we see the following: MULLO_INT R5.x, [0x00000046 9.80909e-44].x, PV.x MULLO_INT R5.y, [0x00000078 1.68156e-43].x, PV.x that seems wrong the second PV.x uses the newly computed R5.x, no? instead of the previous R5.x before the mul happened so the 2nd and 3rd components get the compounded multiplication factor of .x and the respective .y and .z factor Starting with the R5.x value returned by the ADD_INT, the caluclation is: R5.y = ((R5.x *46) * 78); R5.z = (R5.x * 46) * 0xc8 6: UMUL TEMP[1].xyz, IMM[0].yzww, TEMP[1].xxxx i'm guessing the thing that splits it up into 3 instructions forgets that it's overwriting the source cayman_mul_int_instr cayman-specific, and doesn't do the tmp register dance vs the "regular" umul implementation (op2_trans) which will use a temp register if the dst mask has multiple dests. I wonder if all the cayman_* emit functions need this treatment. -- You are receiving this mail because: You are the assignee for the bug. --1415738029.D15b8a0.24685 Date: Tue, 11 Nov 2014 20:33:49 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 10 on bug 85376 from 
Some observations (from IRC, edited):

In shader 21 (from attachment 109303 [details]), we see the following:

<imirkin_> MULLO_INT          R5.x,  [0x00000046 9.80909e-44].x, PV.x
<imirkin_> MULLO_INT          R5.y,  [0x00000078 1.68156e-43].x, PV.x
<imirkin_> that seems wrong
<imirkin_> the second PV.x uses the newly computed R5.x, no?
<imirkin_> instead of the previous R5.x before the mul happened
<imirkin_> so the 2nd and 3rd components get the compounded multiplication
factor of .x and the respective .y and .z factor
<tstellar> Starting with the R5.x value returned by the ADD_INT, the
caluclation is: R5.y = ((R5.x *46) * 78); R5.z = (R5.x * 46) * 0xc8
<imirkin_>   6: UMUL TEMP[1].xyz, IMM[0].yzww, TEMP[1].xxxx
<imirkin_> i'm guessing the thing that splits it up into 3 instructions forgets
that it's overwriting the source
<imirkin_> cayman_mul_int_instr
<imirkin_> cayman-specific, and doesn't do the tmp register dance

vs the "regular" umul implementation (op2_trans) which will use a temp register
if the dst mask has multiple dests. I wonder if all the cayman_* emit functions
need this treatment.

You are receiving this mail because:
  • You are the assignee for the bug.
--1415738029.D15b8a0.24685-- --===============1623023848== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1623023848==--