Bug 32544 - [r300g] LLVM support for software TLS implementation doesn't work
Summary: [r300g] LLVM support for software TLS implementation doesn't work
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-20 23:20 UTC by Drill
Modified: 2011-01-24 02:54 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
fixes llvm support for TLS not working in r300g (1.32 KB, patch)
2010-12-24 01:39 UTC, Drill
Details | Splinter Review
another fix (916 bytes, patch)
2010-12-24 08:55 UTC, Drill
Details | Splinter Review

Description Drill 2010-12-20 23:20:08 UTC
Hello. A month ago I started to use --enable-gallium-llvm while compiling mesa git version and got a great performance increase - glxgears showed 800 fps vs 250 without LLVM.
  But in newer git versions (starting from the end of November or so) this option stopped to help me - I've got 250 fps both with --enable-gallium-llvm and without today.
  So is LLVM support (as I understood) for TLS implementation working in r300g? Or the problem only on my side...

Kernel: 2.6.36 x86-64 (Archlinux 64)
Videocard: ATI Radeon X1270 (RS690)
Comment 1 Marek Olšák 2010-12-22 10:22:58 UTC
I don't have a problem with r300g/LLVM.

Could you possibly bisect the issue on your machine?
Comment 2 Drill 2010-12-23 08:51:05 UTC
(In reply to comment #1)
> I don't have a problem with r300g/LLVM.
> 
> Could you possibly bisect the issue on your machine?

Unfortunately can't imagine how to do this at the moment.

The strange thing, is that i compile and use the old git version (from 15.11.2010) version in absolutely the same environment as the newest one git version with the same options. But, as already mentioned, i'm getting on old 800 fps, and only 250 on new one :(

Forget to mention before - i'm using llvm 2.8 .
Comment 3 Drill 2010-12-24 01:37:46 UTC
I've managed to fix the problem (at least I have good fps again).
The problem appeared after this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=efc82aef35a2aac5d2ed9774f6d28f2626796416 . 

gallivm object wasn't created in draw_create() function, so llvm object couldn't be created. So I created gallivm in draw_create() and llvm seems to be working.
Comment 4 Drill 2010-12-24 01:39:14 UTC
Created attachment 41413 [details] [review]
fixes llvm support for TLS not working in r300g

Not sure if this is consistent with the rest of the code.
Comment 5 Marek Olšák 2010-12-24 07:28:15 UTC
I wonder if there's a way to fix it without touching the code of Draw.
Comment 6 Drill 2010-12-24 08:55:30 UTC
Created attachment 41428 [details] [review]
another fix

There is another variant then - to do all the changes in gallium/drivers/r300/r300_context.c : in function r300_create_context create gallivm and call draw_create_gallivm directly instead of draw_create .
Comment 7 Marek Olšák 2010-12-24 09:40:54 UTC
Fixed with commit 88550083b3857184445075e70fed8b2eed4952a1. Closing.
Comment 8 Brian Paul 2011-01-04 08:24:46 UTC
I think the first patch is actually the better one.  It lets all drivers that utilize the draw module to get LLVM acceleration when LLVM is present and avoids having LLVM code in each of the drivers.

If there's no objections, I'll revert commit 88550083b3857184445075e70fed8b2eed4952a1 and apply the first attached patch.
Comment 9 Marek Olšák 2011-01-04 08:44:28 UTC
Yeah, go ahead...
Comment 10 Michel Dänzer 2011-01-04 08:47:51 UTC
(In reply to comment #8)
> If there's no objections, I'll revert commit
> 88550083b3857184445075e70fed8b2eed4952a1 and apply the first attached patch.

So long as you make sure the resources allocated by gallivm_create and lp_build_init are freed when appropriate. :)
Comment 11 Michel Dänzer 2011-01-24 02:54:12 UTC
Jakob pushed a driver-independent solution in commit 4c73030d47f39441d718157f7d9a59c136bbfac0 ('draw: Init llvm if not provided').


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.