Bug 34206 - [r300g] Unigine Sanctuary: glow around fires is distorted and displaced
Summary: [r300g] Unigine Sanctuary: glow around fires is distorted and displaced
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium minor
Assignee: Default DRI bug account
QA Contact:
URL: http://unigine.com/download/#sanctuary
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-12 03:42 UTC by Pavel Ondračka
Modified: 2011-04-12 13:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
screenshot (190.18 KB, image/jpeg)
2011-02-12 03:42 UTC, Pavel Ondračka
Details
output of RADEON_DEBUG=fp,vp and RADEON_DEBUG=fp,vp,noopt (228.38 KB, application/x-bzip2)
2011-02-12 03:44 UTC, Pavel Ondračka
Details
screenshot with NVIDIA driver (590.60 KB, image/png)
2011-02-12 03:48 UTC, Pavel Ondračka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Ondračka 2011-02-12 03:42:50 UTC
Created attachment 43291 [details]
screenshot

There should be roughly spherical glow around candles and fires in Unigine Sanctuary (at least that is how it looks with NVIDIA when the same settings is used), but with r300g it is distorted and displaced and can only be viewed from some angles. Also it is completely gone when RADEON_DEBUG=noopt or RADEON_NO_TCL=1 is used. 

GPU: RV530
mesa: a6b7393eb8b4ef14c0d9ba8d64e57ed8ca82a9f7

Sanctuary version: 2.3
Unigine settings: all options disabled or set to lowest possible
Comment 1 Pavel Ondračka 2011-02-12 03:44:22 UTC
Created attachment 43292 [details]
output of RADEON_DEBUG=fp,vp and RADEON_DEBUG=fp,vp,noopt
Comment 2 Pavel Ondračka 2011-02-12 03:48:53 UTC
Created attachment 43293 [details]
screenshot with NVIDIA driver

This is how it looks like with proprietary drivers when the same settings are used.
Comment 3 Tom Stellard 2011-02-12 08:07:00 UTC
Is this a regression?  Any chance you can bisect it?
Comment 4 Pavel Ondračka 2011-02-12 08:29:56 UTC
(In reply to comment #3)
> Is this a regression?  Any chance you can bisect it?

No, I don't think so, I suppose this bug is present since Sanctuary 2.3 is working (73e8a2738743035e1347571ba630747d2ec33a2d). I haven't spot this before because this distorted glow wasn't present in the 2.2 version (the glow wasn't present there at all like now when running with RADEON_DEBUG=noopt and there were some others much more visible bugs at that time). 

However I'll try to manually apply 73e8a2738743035e1347571ba630747d2ec33a2d to some older mesa versions to see if it was better at some time.
Comment 5 Marek Olšák 2011-02-12 10:25:31 UTC
I don't think it ever worked.
Comment 6 Pavel Ondračka 2011-02-12 11:26:59 UTC
The distorted glow is present since "r300/compiler: use peephole and constant folding for vertex shaders too", there was no glow at all before. So I suppose this explains why there is no glow with noopt.
Comment 7 Marek Olšák 2011-03-29 16:59:52 UTC
I think the glow is broken because the WPOS input is unassigned. Glow is a screen-space effect and as such must either use (or emulate) gl_FragCoord.
Comment 8 Pavel Ondračka 2011-04-12 13:41:34 UTC
No glow at all with current mesa master and working glow with floating2 branch.
I consider this fixed.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.