On Mon, 2010-03-08 at 13:16 +0100, Roland Scheidegger wrote:
> On 07.03.2010 20:26, Marek Olšák wrote:
> > This branch is aimed to address the following issues:
> > * Extensions are advertised in both st/mesa and st/dri, doing the same
> > thing in two places.
> > * The inability to disable extens
On Tue, 2010-03-02 at 04:02 +0100, Roland Scheidegger wrote:
> On 02.03.2010 00:18, Joakim Sindholt wrote:
> > On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
> >> Hi,
> >>
> >> this branch turns vertex element into a cso, so instead of
> >&
On Mon, 2010-03-01 at 19:02 +0100, Roland Scheidegger wrote:
> Hi,
>
> this branch turns vertex element into a cso, so instead of
> set_vertex_elements there's now the triad of
> create/bind/delete_vertex_elements_state. I have converted all the
> drivers except nouveau (I didn't do it because Chr
On Sun, 2010-02-28 at 20:25 +0100, Jerome Glisse wrote:
> Hi,
>
> I am a bit puzzled, how a pipe driver should handle
> draw callback failure ? On radeon (pretty sure nouveau
> or intel hit the same issue) we can only know when one
> of the draw_* context callback is call if we can do
> the render
Let's assume I have an array of vertex elements that indicate
position/color in vertex buffer #3. Let's also for the sake of argument
say that there is nothing else in my vertex elements. No other buffers
are being pointed to. Is it legal for me to
pipe_context::set_vertex_buffers with an array siz
I think instead of targeting newbies, it would be preferable to have a
proper API documentation first. We're severely lacking in the "what
flags go here" department, and generally it would be nice to have a key
that explains exactly what each argument for each function is. It's
normally not too har
It sounds like you're ignoring the case where gallium is not built with
gcc (i.e. doesn't have __builtin_popcount available). We still need an
implementation to fall back on.
On Mon, 2009-11-30 at 01:00 -0800, Keith Whitwell wrote:
> Although popcount is a routine that has had huge optimization at
wrote:
> 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 th
irement of knowing CHAR_BIT (from limits.h, amount
of bits in a char)?
>From f0df6fb47f9854b31d5d2cb02fc5c9371e67f912 Mon Sep 17 00:00:00 2001
From: Joakim Sindholt
Date: Sat, 28 Nov 2009 19:06:22 +0100
Subject: [PATCH] u_math: simple util_bitcount speedup
Thanks to the person behind:
http://
I've heard a little talk here and there and glisse pointed out I should
take it to the ML.
The basic idea is that instead of binding 1 winsys, 1 state tracker and
a couple of pipes into every single library we churn out, we define some
sort of API between winsys and state_tracker so that we can sp
On Fri, 2009-10-23 at 11:17 -0400, Alex Deucher wrote:
> On Fri, Oct 23, 2009 at 2:37 AM, Maciej Cencora wrote:
> > Hi,
> >
> > as you may already know r300 classic driver is in pretty good shape these
> > days, but there's one thing that causes major slowdowns in many games: lack
> > of
> > hard
To at least give some feedback:
I think this is a great initiative and I wish I could be there. You
should do this in northern Europe more often. VMWare has offices in
Sweden, right? ;)
In any case, if you can get it on video it would be fantastic, and if
you could live stream it, I would consider
On Wed, 2009-09-02 at 10:58 -0600, tom fogal wrote:
> writes:
> > On Wed, 2009-09-02 at 09:05 -0700, Keith Whitwell wrote:
> > > On Wed, 2009-09-02 at 08:48 -0700, Jos Fonseca wrote:
> > > > On Wed, 2009-09-02 at 05:11 -0700, Chris Wilson wrote:
> > > > > By rearranging the bitfields within the key
so can someone tell me what I'm doing wrong?
libGL error: dlopen ./r300_dri.so failed (./r300_dri.so: undefined
symbol: LLVMBuildNot)
>From ff1dd87762a98cc93a800fe96e7a96357e5f69d3 Mon Sep 17 00:00:00 2001
From: Joakim Sindholt
Date: Sat, 29 Aug 2009 15:07:01 +0200
Subject: [PATCH] l
Hello there people, this is my first time posting to a mailing list, so
please bear with me if I don't get it right.
To whomever wrote ./src/gallium/auxiliary/gallivm/Makefile, is there a
specific reason for using clang and not gcc/g++ in the snippit below?
gallivm_builtins.cpp: llvm_builtins.c
15 matches
Mail list logo
