On Fri, Feb 5, 2010 at 12:15 AM, Mike Lothian wrote:
> On 21 December 2009 22:02, Keith Whitwell wrote:
>> I put i965g on a branch initially, but there's no particular reason for it
>> being there - other drivers are being developed on master and it would be
>> preferable to have it up-to-date
On Thu, Feb 4, 2010 at 6:39 PM, Keith Whitwell
wrote:
> On Tue, Feb 2, 2010 at 11:45 PM, Brian Paul wrote:
>> Xavier Chantry wrote:
>>> On Tue, Feb 2, 2010 at 12:01 PM, Francisco Jerez
>>> wrote:
For a long time the gallium pipe drivers for nvidia fixed function cards
(nv0x, nv1x and,
We've had a couple of cleanups that we've wanted to do in gallium for
as long as I can remember. One of which is to remove all the random
context-creation calls and funnel them through something sensible like
a context_create() call in pipe_screen.
The gallium-screen-context branch does exactly t
Brian Paul wrote on 2010-02-04 22:07:
> michal wrote:
>
>> Brian Paul wrote on 2010-02-03 17:58:
>>
>>> Keith Whitwell wrote:
>>>
>>>
>> Michal,
>>
>> why do you need this for linear interpolator and not perspective? I
>> think d3d mobile let you disable perspectiv
Jesse,
Can you take a look at the attached patch? I'd really like to be able
to build mesa and the DRI drivers on current distros (eg Ubuntu 9.10)
without having to pull in heaps of dependencies. The patch adds
#ifdefs to protect against the newer DRI2 protocol changes, meaning I
can build-test
On Thu, 2010-02-04 at 21:23 -0800, Chia-I Wu wrote:
> Hi Keith,
>
> Thanks for having a closer look.
>
> On Thu, Feb 4, 2010 at 9:31 PM, Keith Whitwell
> wrote:
> >> As st_api.h can be implemented parallelly with st_public.h, a possible
> >> route I
> >> would like to take is to (in this order)
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
On Fri, Feb 5, 2010 at 7:40 PM, José Fonseca wrote:
> On Thu, 2010-02-04 at 21:23 -0800, Chia-I Wu wrote:
>> On Thu, Feb 4, 2010 at 9:31 PM, Keith Whitwell
>> wrote:
>> >> As st_api.h can be implemented parallelly with st_public.h, a possible
>> >> route I
>> >> would like to take is to (in this
michal wrote on 2010-02-05 11:05:
> Brian Paul wrote on 2010-02-04 22:07:
>
>> michal wrote:
>>
>>
>>> Brian Paul wrote on 2010-02-03 17:58:
>>>
>>>
Keith Whitwell wrote:
>>> Michal,
>>>
>>> why do you need this for linear in
On Fri, 5 Feb 2010 10:08:44 +
Keith Whitwell wrote:
> Jesse,
>
> Can you take a look at the attached patch? I'd really like to be able
> to build mesa and the DRI drivers on current distros (eg Ubuntu 9.10)
> without having to pull in heaps of dependencies. The patch adds
> #ifdefs to prot
michal wrote:
> michal wrote on 2010-02-05 11:05:
>> Brian Paul wrote on 2010-02-04 22:07:
>>
>>> michal wrote:
>>>
>>>
Brian Paul wrote on 2010-02-03 17:58:
> Keith Whitwell wrote:
>
>
>
Michal,
why
A couple symbols are missing from the osmesa.def file. On Windows,
this causes OSMesaGetProcAddress to be named "_osmesagetprocaddr...@4",
which breaks some of our code to dynamically load OpenGL.
The attached patch fixes the symbol names, verified via depends.exe.
It's against 7_7_branch but pro
From 99fbfe43dad3efae04749ab9da164c0e849bd836 Mon Sep 17 00:00:00 2001
From: Tom Fogal
Date: Fri, 5 Feb 2010 13:11:25 -0700
Subject: [PATCH] Fix a typo in mesa3d.org HTML.
---
docs/repository.html |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/docs/repository.html b/do
tom fogal wrote:
> A couple symbols are missing from the osmesa.def file. On Windows,
> this causes OSMesaGetProcAddress to be named "_osmesagetprocaddr...@4",
> which breaks some of our code to dynamically load OpenGL.
>
> The attached patch fixes the symbol names, verified via depends.exe.
> It
Committed. Thanks.
-Brian
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management service
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd like to remove a bunch of the visuals and fbconfigs exposed by the
Intel drivers. There are several categories of visuals that are likely
not useful to anyone. A couple of our test suites (e.g., glean) like to
run over every possible visual. As
I'm cool with that. There's actually a couple Gallium fbconfig things
I wanna bring up, but I'll start another thread for those.
On Fri, Feb 5, 2010 at 1:01 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'd like to remove a bunch of the visuals and fbconfigs expose
On Fri, Feb 5, 2010 at 4:01 PM, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'd like to remove a bunch of the visuals and fbconfigs exposed by the
> Intel drivers. There are several categories of visuals that are likely
> not useful to anyone. A couple of our test s
Two things...
Are accumbufs still slow in Gallium-land? Should we still mark them as slow?
How many multisamples should we actually pretend/advertise? Should we
have a cap to check the number of multisamples supported? Should we
just say that four samples are done for the fbconfig/visual, and the
Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'd like to remove a bunch of the visuals and fbconfigs exposed by the
> Intel drivers. There are several categories of visuals that are likely
> not useful to anyone. A couple of our test suites (e.g., glean) like to
> ru
http://bugs.freedesktop.org/show_bug.cgi?id=25994
Jesse Barnes changed:
What|Removed |Added
AssignedTo|jbar...@virtuousgeek.org|i...@freedesktop.org
--
Configure bug
This lets us link EGL apps with libGL without pulling in X dependencies.
---
configs/autoconf.in |2 +
configure.ac| 99 +++
src/gallium/state_trackers/egl/Makefile |1 +
src/glx/x11/Makefile|
These two patches move things around in GLX a bit. To make it possible
to use libGL with EGL on framebuffer without pulling in X dependencies
this patch make the GLX entry points and all the indirect API a
./configure time option. When disabled, libGL is essentially just glapi
and needs libEGL to
On 05.02.2010 22:48, Corbin Simpson wrote:
> Two things...
>
> Are accumbufs still slow in Gallium-land? Should we still mark them as slow?
>
> How many multisamples should we actually pretend/advertise? Should we
> have a cap to check the number of multisamples supported? Should we
> just say th
Signed-off-by: Alan Coopersmith
---
src/gallium/auxiliary/util/u_atomic.h | 36 -
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_atomic.h
b/src/gallium/auxiliary/util/u_atomic.h
index 540112f..e4750c0 100644
--- a/sr
From: Alan Coopersmith [alan.coopersm...@sun.com]
Sent: Saturday, February 06, 2010 3:37
To: mesa3d-dev@lists.sourceforge.net
Cc: Alan Coopersmith
Subject: [Mesa3d-dev] [PATCH] Gallium: Add Solaris atomic function
definitions to u_atomic.h
Signed-off
Jose Fonseca wrote:
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include
>
> It's probably fine for Solaris, but putting OS includes inside extern "C"
> sometimes causes problems -- it does with certain MS headers.
>
> Other than that it looks fine.
Hmm, hadn't thought about it - do
I think nested extern "C" is alright. The problem I hit was that the header
provided some optional C++ interfaces, and the compiler barfed at having C++
inside extern "C" { .. }.
Jose
From: alan.coopersm...@sun.com [alan.coopersm...@sun.com]
Sent: Saturd
28 matches
Mail list logo
