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 richardz...@amd.com 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
http://bugs.freedesktop.org/show_bug.cgi?id=25318
--- Comment #2 from Michel Dänzer mic...@daenzer.net 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
http://bugs.freedesktop.org/show_bug.cgi?id=25318
--- Comment #4 from Michel Dänzer mic...@daenzer.net 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.
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
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,
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:
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 b...@zhasha.com wrote:
I was perusing the commit log for mesa and stumbled upon the recently
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
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
On Sat, Nov 28, 2009 at 2:13 PM, Yang Zhao y...@yangman.ca 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
2009/11/28 Matt Turner matts...@gmail.com:
On Sat, Nov 28, 2009 at 2:13 PM, Yang Zhao y...@yangman.ca 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
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
On Sat, Nov 28, 2009 at 5:36 AM, Pierre Ossman pierre-l...@ossman.eu 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 richardz...@amd.com wrote:
Yes, you are right. When the compiler code was put there, as Alex
13 matches
Mail list logo
