Bug 64193

Can you post the output of glxgears with R600_DEBUG=vs,ps,fs environment variable, before and after this commit ?

Created attachment 78827 [details]
R600_DEBUG=vs,ps,fs glxgears working before packetize commit

Created attachment 78828 [details]
R600_DEBUG=vs,ps,fs glxgears rendering dark on packetize commit

Can you cherry pick this patch : https://bugs.freedesktop.org/attachment.cgi?id=78786 (from bugid 64096) on top of 25f259cde28860ea76c2f5628010968945a28edb and post the output of R600_DEBUG=vs,ps,fs again please ?

(In reply to comment #4)
> Can you cherry pick this patch :
> https://bugs.freedesktop.org/attachment.cgi?id=78786 (from bugid 64096) on
> top of 25f259cde28860ea76c2f5628010968945a28edb and post the output of
> R600_DEBUG=vs,ps,fs again please ?

glxgears looks normal with the patch, though it doesn't fix other demos/games eg.
nexuiz just hung and gloss renders almost OK but the sides are matt with no reflection.

I'll attach the debug as requested and one from heads I did this morning as well where it is rendering dark.

FWIW when llvm is on packetize mesa doesn't build on head so for these it's been (random choice) set on 

e2b985dc0f93a195d984aa7c88669ab67160c6c4

Created attachment 78854 [details]
R600_DEBUG=vs,ps,fs glxgears rendering OK on packetize with patch

Created attachment 78855 [details]
R600_DEBUG=vs,ps,fs glxgears rendering dark on heads

The suggested patch also fixes gears and 0ad for me. But I still see the problem in chromium browser with webgl enabled, where the map is not displayed.

As mentioned by Vadim on IRC:
it seems many instructions in bytecode generated for RS880 have (incorrect) OMOD = 2, that is, ALU WORD1 bit 7 is set where it shouldn't be set

I looked a bit more into it and AFAICS it's not just a single wrong bit, looks like r700 alu encoding is used for all r600  chips with llvm backend currently(In reply to comment #9)
> As mentioned by Vadim on IRC:
> it seems many instructions in bytecode generated for RS880 have (incorrect)
> OMOD = 2, that is, ALU WORD1 bit 7 is set where it shouldn't be set

I looked a bit more into it and AFAICS it's not just a single wrong bit, looks like r700 alu encoding is used for all r600 chips with llvm backend currently

It looks like the special handling for R600 encoding is missing from the backend.  I think an earlier change to the code emitter made this code dead and then I deleted it in a more recent commit.

yes, there must be something else wrong because the patch seems to be applied in release_33 branch, but the problem somehow came back.

Created attachment 79304 [details] [review]
Possible Fix - Patch 1

Created attachment 79305 [details] [review]
Possible Fix - Patch 2

Do these two patches fix the problem?

hard to say, because mesa is broken again:

  CXX      gallivm/lp_bld_debug.lo
gallivm/lp_bld_debug.cpp: In member function 'virtual void raw_debug_ostream::write_impl(const char*, size_t)':
gallivm/lp_bld_debug.cpp:116:40: warning: cast from type 'const char*' to type 'char*' casts away qualifiers [-Wcast-qual]
gallivm/lp_bld_debug.cpp: In function 'size_t disassemble(const void*, llvm::raw_ostream&)':
gallivm/lp_bld_debug.cpp:216:64: error: no matching function for call to 'llvm::Target::createMCAsmInfo(std::string&) const'
gallivm/lp_bld_debug.cpp:216:64: note: candidate is:
In file included from gallivm/lp_bld_debug.cpp:38:0:
/usr/src/dri-project/llvm/Release-x86_64/include/llvm/Support/TargetRegistry.h:269:16: note: llvm::MCAsmInfo* llvm::Target::createMCAsmInfo(const llvm::MCRegisterInfo&, llvm::StringRef) const
/usr/src/dri-project/llvm/Release-x86_64/include/llvm/Support/TargetRegistry.h:269:16: note:   candidate expects 2 arguments, 1 provided
gmake[3]: *** [gallivm/lp_bld_debug.lo] Fehler 1

(In reply to comment #15)
> hard to say, because mesa is broken again:
> 

Try again, this should be fixed now.

Thanks, this fixes gears and 0ad for me again.

Chrome still doesn't show background with WebGL on maps.google.com (this worked before the R600: Packetize instructions commit).

At least GPU hangs with Chrome are fixed now (will close the bug).

Tom, can you please also update llvm 3.3 branch if you haven't done yet?

(In reply to comment #14)
> Created attachment 79305 [details] [review] [review]
> Possible Fix - Patch 2
> 
> Do these two patches fix the problem?

Fixed for me  - testing with nexuiz and etqw.

Created attachment 79339 [details]
R600_DEBUG output with swimming dolphin

Regarding WebGL problem. Steps to reproduce: go to http://www.ibiblio.org/e-notes/webgl/webgl.htm and click on the dophin. Before said commit, dolphin renders fine, after that, nothing is rendered at all.

Attached is the R600_DEBUG output with/without swimming dolphin.

Created attachment 79340 [details]
R600_DEBUG output with only while water

Note: this compares llvm/mesa state from ~29th Apr with llvm/release_33 and mesa from today.

Marc, where is the dump without the dolphin ? Is this the "only while water" dump ?

sorry, this was a typo. I mean only *white* water (means only white background, nothing is shown)

As of today, http://www.ibiblio.org/e-notes/webgl/webgl.htm works again with firefox. (Chrome has webgl init error, but maybe a chrome bug). So I guess this was fixed otherwise.