On Sat, Nov 28, 2009 at 5:36 AM, Pierre Ossman wrote:
> I'm sorry this reply is so late. I completely forgot about this
> thread...
>
> On Mon, 2 Nov 2009 10:35:16 -0500
> "Li, RichardZ" wrote:
>
>>
>> Yes, you are right. When the compiler code was put there, as Alex said,
>> we hope to get every
Is there anything in the spec or mesa internals that say this isn't
allowed? I was trying to fix what seems like an unrelated HW errata
with no luck, but it might as well be used if it's useful. I'll apply
if no one raises any concerns.
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/stat
2009/11/28 Matt Turner :
> On Sat, Nov 28, 2009 at 2:13 PM, Yang Zhao wrote:
>> The speed-up is definitely there, but __builtin_popcount() will still
>> be drastically faster when architecture-specific optimizations are
>> enabled:
>
> I don't think this is the case (except for with SSE4's popcnt
On Sat, Nov 28, 2009 at 2:13 PM, Yang Zhao wrote:
> The speed-up is definitely there, but __builtin_popcount() will still
> be drastically faster when architecture-specific optimizations are
> enabled:
I don't think this is the case (except for with SSE4's popcnt
instruction, which your CFLAGS se
Results from my 2 GHz Core 2.
__builtin_popcount(): 11.709 seconds
fast_bitcount(): 3.956 seconds
kr_bitcount(): 24.276 seconds
naive(): 38.493 seconds
Nothing even compares to fast_bitcount.
Matt
--
Let Crystal Reports
2009/11/28 Joakim Sindholt :
> I was perusing the commit log for mesa and stumbled upon the recently
> added util_bitcount. It uses a rather naïve algorithm and I thought I'd
> look into it as someone mentioned this problem to me before.
> This is what I found, should anyone be interested:
> http:/
The test results are in:
__builtin_popcount(): 12.677 seconds
fast_bitcount(): 7.218 seconds
kr_bitcount(): 33.172 seconds
naive(): 59.345 seconds
also, the patch you committed says for (bits, n, bits++). Notice the
commas are not semicolons.
On Sat, 2009-11-28 at 10:16 -0800, Corbin Simpson wrot
Do your test again. I just pushed a fairly fast variable-length bitcount.
Sorry for not pushing it earlier.
Posting from a mobile, pardon my terseness. ~ C.
On Nov 28, 2009 10:12 AM, "Joakim Sindholt" wrote:
I was perusing the commit log for mesa and stumbled upon the recently
added util_bitcou
I was perusing the commit log for mesa and stumbled upon the recently
added util_bitcount. It uses a rather naïve algorithm and I thought I'd
look into it as someone mentioned this problem to me before.
This is what I found, should anyone be interested:
http://graphics.stanford.edu/~seander/bithack
I am only barely just started on r600g, and I think I may be already down
the wrong path.
Just like with r300g, sharing compilers would be totally kosher, especially
since we have all these different shader types that really should have only
one IR and compiler pipeline.
Posting from a mobile, pa
That means we need an additional cap bit to support
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS because it's no longer a simple sum of max
vertex and fragment samplers. For i965 max vertex/fragment/combined samplers
would be then 16.
--
Michal Krol
Od: Keith Whi
http://bugs.freedesktop.org/show_bug.cgi?id=25318
--- Comment #4 from Michel Dänzer 2009-11-28 05:56:08 PST
---
Not sure this is really unexpected... Obviously a translucent cube creates a
lot more work on screen updates for compiz and consequently the drivers and
GPU.
--
Configure bugma
http://bugs.freedesktop.org/show_bug.cgi?id=25318
--- Comment #3 from dman777 2009-11-28 04:17:16 PST ---
(In reply to comment #2)
> What exactly does 'opacity enabled' mean? Assuming it's about translucent
> windows, is the blur plugin enabled in compiz, or other plugins which may
> interac
http://bugs.freedesktop.org/show_bug.cgi?id=25318
--- Comment #2 from Michel Dänzer 2009-11-28 03:35:38 PST
---
What exactly does 'opacity enabled' mean? Assuming it's about translucent
windows, is the blur plugin enabled in compiz, or other plugins which may
interact with translucency?
-
I'm sorry this reply is so late. I completely forgot about this
thread...
On Mon, 2 Nov 2009 10:35:16 -0500
"Li, RichardZ" wrote:
>
> Yes, you are right. When the compiler code was put there, as Alex said,
> we hope to get everything worked. Certainly emit alu instruction based
> on write-mask
15 matches
Mail list logo
