From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 43341] CoreBreach: Crash in r600_update_derived_state
Date: Thu, 01 Dec 2011 03:04:57 +0000 [thread overview]
Message-ID: <bug-43341-502-bDpflZcv65@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-43341-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=43341
--- Comment #4 from Vadim <ptpzz@yandex.ru> 2011-11-30 19:04:57 PST ---
(In reply to comment #3)
> hello
> i am the game developer.
>
> the workaround for disabling indirect addressing is automatically applied if
> linking the shader fails because of the indirect adressing. e.g. this happens
> on the geforce 7100 under windows.
>
> if you let linking fail instead of crashing, the same code path will be used
> here.
Yes, the crash needs to be fixed, of course, but I'm afraid that just fixing it
won't make everything work as expected, because it happens too late. I'll check
this.
>
> i'm not sure whats with the talk about too many temps. this crash occurs on
> 5770 / 5670 which are very capable cards. with the proprietary nvidia/ati
> drivers this shader works fine even back to ancient hardware under
> windows/mac/linux e.g. Radeon 2400 or GeForce 7300.
The shader code with mesa is not as heavily optimized as with the proprietary
drivers. There are some optimization passes that do not support indirect
addressing currently, so they are disabled in this case, that's why this shader
breaks the limits.
> i don't want to make disable indirect addressing by default since i guess it
> will be slower on recent hardware.
>
I'm not sure that it will be slower. Code optimization with indirect addressing
is much harder, so I guess almost every compiler will produce more efficient
code without indirect addressing (at least in this case). It's definitely true
for mesa at the moment. Also I did a quick comparison of the generated code for
this shader with AMD GPU Shader Analyzer (that is, code generated by the AMD's
proprietary driver), here are some of the results for the HD5770:
w/o WORKAROUND: 2864 MPixels/sec
with WORKAROUND: 3629 MPixels/sec
I'm not an expert in shaders performance, but afaics many apps are trying to
avoid the indirect addressing, e.g. Unigine Heaven IIRR doesn't use it at all.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
next prev parent reply other threads:[~2011-12-01 3:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-29 17:49 [Bug 43341] New: CoreBreach: Crash in r600_update_derived_state bugzilla-daemon
2011-11-29 17:59 ` [Bug 43341] " bugzilla-daemon
2011-11-30 11:05 ` bugzilla-daemon
2011-11-30 15:52 ` bugzilla-daemon
2011-12-01 3:04 ` bugzilla-daemon [this message]
2011-12-01 12:13 ` bugzilla-daemon
2013-09-19 16:42 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-43341-502-bDpflZcv65@http.bugs.freedesktop.org/ \
--to=bugzilla-daemon@freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).