Although popcount is a routine that has had huge optimization attention over
the years and yields itself to some very cool approaches, our usage of it in
Mesa is afaik never on a critical performance path. That may change one day,
eg a software rasterizer may find itself doing many popcounts
Hi,
Did anyone record the video of the Gallium session held on Nov 13? I
read the articles about it, would be great to see the video..
Thanks
kammal
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
Attached an updated patch.
* Increased PIPE_MAX_VERTEX_SAMPLERS to 16.
* Removed PIPE_CAP_MAX_VERTEX_TEXTURES since there's already an
equivalent PIPE_CAP_MAX_VERTEX_TEXTURE_UNITS.
* Added PIPE_CAP_MAX_COMBINED_SAMPLERS to query maximum texture image
units accessible from vertex and fragment
Hi Kammal,
I have the raw material and finally made some progress yesterday on
editing the material. I will post an update later this week with a
pointer to the new videos.
Regards,
Jens
On Nov 30, 2009, at 5:03 AM, Kamalneet Singh wrote:
Hi,
Did anyone record the video of the Gallium
I don't really want to discourage anyone from following their interests, but my
point is that any reasonably performant implementation is sufficient for the
current usage in Gallium and one that is 3x faster or slower isn't going to
make any difference to our overall performance at this point.
I've tried to ask linux folk if this is also true for linux, but the
answer is unclear at this time.
Signed-off-by: Robert Noland rnol...@2hip.net
---
.../winsys/drm/vmware/core/vmw_screen_ioctl.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git
Sorry for popping out so late in the game, but I just realized this now
while working in related code: instead of adding new entrypoints,
wouldn't it be better to keep the current ones, but add an argument,
PIPE_SHADER_xxx ?
This would simplify both state tracker and pipe drivers considerably,
For the most part in gallium we've treated fragment vs vertex as part of the
function name rather than as an argument, so this is consistent.
So far it seems hardware isn't very regular at this granularity -- it's not
like you just end up doing the same thing for fragment
R600, FWIW, has fully unified shaders. I think NV50 does too. Doesn't really
matter too much though.
Posting from a mobile, pardon my terseness. ~ C.
On Nov 30, 2009 11:18 AM, Keith Whitwell kei...@vmware.com wrote:
For the most part in gallium we've treated fragment vs vertex as part of the
On Mon, Nov 30, 2009 at 11:21:47AM -0600, Robert Noland wrote:
I've tried to ask linux folk if this is also true for linux, but the
answer is unclear at this time.
EINTR will be returned to userspace if the syscall needs to be restarted.
Cheers,
Daniel
pgpVdhj3BqJ3Y.pgp
Description: PGP
On Tue, 2009-12-01 at 10:37 +1100, Daniel Stone wrote:
On Mon, Nov 30, 2009 at 11:21:47AM -0600, Robert Noland wrote:
I've tried to ask linux folk if this is also true for linux, but the
answer is unclear at this time.
EINTR will be returned to userspace if the syscall needs to be
On 1 dec 2009, at 00.24, Robert Noland wrote:
On Tue, 2009-12-01 at 10:37 +1100, Daniel Stone wrote:
On Mon, Nov 30, 2009 at 11:21:47AM -0600, Robert Noland wrote:
I've tried to ask linux folk if this is also true for linux, but the
answer is unclear at this time.
EINTR will be returned to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vinson Lee wrote:
Module: Mesa
Branch: mesa_7_7_branch
Our agreed process is that bug fixes, especially ones with low
probability of breaking other things, are supposed to go into the oldest
open tree *first*. In this case, and the case of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mesa 7.6.1-rc2 available for testing at
ftp://freedesktop.org/pub/mesa/7.6.1/
md5sums:
afc6bb9054126d4718e2da321e6ec1c3 MesaDemos-7.6.1-rc2.tar.bz2
0b476cf2c7cffabea44462836df2c319 MesaDemos-7.6.1-rc2.tar.gz
571997ca6ae98ce888fb9567221fedb4
It should be straightforward to handle this - it just means merging 7.6-7.7
and then 7.7-master.
Vinson - is there any problem doing your bugfixing against the 7.6 branch, and
then having the changes flow into master as above?
Keith
From: Ian Romanick
15 matches
Mail list logo
