On Mit, 2010-04-28 at 22:43 -0400, Chris Ball wrote:
> http://tinderbox.x.org/builds/2010-04-29-0001/logs/libGL/#build
>
> draw/draw_vs_ppc.c: In function 'vs_ppc_run_linear':
> draw/draw_vs_ppc.c:129: warning: passing argument 5 of 'shader->func' from
> incompatible pointer type
> draw/draw_vs_
https://bugs.freedesktop.org/show_bug.cgi?id=27841
b...@o-hand.com changed:
What|Removed |Added
Summary|GLX extension to mark |Implement
|backbuffe
https://bugs.freedesktop.org/show_bug.cgi?id=27841
--- Comment #2 from b...@o-hand.com 2010-04-29 03:22:24 PDT
---
(In reply to comment #1)
> There is a mechanism, but we have not implemented it in Mesa yet. I think
> GL_EXT_discard_framebuffer (link below), should suit your needs. The intende
https://bugs.freedesktop.org/show_bug.cgi?id=27884
Summary: make fails when compiling with LLVM
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=27841
Neil Roberts changed:
What|Removed |Added
CC||n...@linux.intel.com
--
Configure bugmai
https://bugs.freedesktop.org/show_bug.cgi?id=27884
José Fonseca changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=27841
--- Comment #3 from Kristian Høgsberg 2010-04-29 05:38:03
PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > There is a mechanism, but we have not implemented it in Mesa yet. I think
> > GL_EXT_discard_framebuffer (link below), sho
https://bugs.freedesktop.org/show_bug.cgi?id=27896
Summary: gallium/{llvm,soft}pipe: should set
MaxNativeParameters to nonzero
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
2010/4/29 Kristian Høgsberg :
> 2010/4/28 Chia-I Wu :
>> 2010/4/28 Kristian Høgsberg :
>>> 2010/4/27 Kristian Høgsberg :
>>> [ I hit send to early there... ]
review the patches, or at least just some of them. The overall
approach is
>>>
>>> 1. Add a API tag to GLcontext so we key off of
Was: "Merging GLES1/2 to mesa/main"
Chia-I Wu wrote:
2010/4/29 Kristian Høgsberg :
Yeah, I noticed... I don't have a good answer. I guess core mesa
doesn't generate on the fly because we don't want to require python as
part of the build process(?) and also so that when we distribute mesa,
al
Jakob,
A couple of these are a bit misleading - DX10 & DX11 aren't fully
supportable without further changes & extensions to gallium, so it seems
misleading to have these ever return true - at least until those changes
are done.
Would it make sense to have a UTIL_CHECK_NONIMPLEMENTED or similar t
On Thu, Apr 29, 2010 at 9:54 AM, Brian Paul wrote:
> Was: "Merging GLES1/2 to mesa/main"
>
> Chia-I Wu wrote:
>
>> 2010/4/29 Kristian Høgsberg :
>>
>
> Yeah, I noticed... I don't have a good answer. I guess core mesa
>>> doesn't generate on the fly because we don't want to require python as
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=27896
José Fonseca changed:
What|Removed |Added
AssignedTo|mesa-...@lists.freedesktop. |jfons...@vmware.com
|or
On 2010-04-29 17.11, Keith Whitwell wrote:
Jakob,
A couple of these are a bit misleading - DX10& DX11 aren't fully
supportable without further changes& extensions to gallium, so it seems
misleading to have these ever return true - at least until those changes
are done.
Would it make sense to
On 04/29/2010 08:23 PM, mesa-dev-requ...@lists.freedesktop.org wrote:
>
> On Thu, 2010-04-29 at 09:02 -0700, Jakob Bornecrantz wrote:
>> Module: Mesa
>> Branch: master
>> Commit: 110a956a645f900e100062fbbe19c5835f9b5476
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=110a956a645f90
We don't have such fined grain capabilities in Gallium drivers yet, so I
followed Keith's suggestion of tie the native program limits to the GLSL
and SM3 support exported by the driver.
I'm selling this as a short term fix. I think we should start thinking
in shader caps in gallium, and how fine g
On Thursday 29 April 2010 14:09:22 José Fonseca wrote:
> We don't have such fined grain capabilities in Gallium drivers yet, so I
> followed Keith's suggestion of tie the native program limits to the GLSL
> and SM3 support exported by the driver.
That seems like a pretty good solution to me for no
On Thu, Apr 29, 2010 at 8:30 PM, Zack Rusin wrote:
> It seems like all we'd really need is relate those things to
> the feature/api levels it exposes and document it.
>
Feature levels are a pretty bad match for D3D9-level chipsets since the
hardware is so divergent that you'd need a lot of them.
On Thursday 29 April 2010 15:44:35 Marek Olšák wrote:
> On Thu, Apr 29, 2010 at 8:30 PM, Zack Rusin
> mailto:za...@vmware.com>> wrote: It seems like all we'd
> really need is relate those things to
> the feature/api levels it exposes and document it.
>
> Feature levels are a pretty bad match for
I was getting at your former idea of replacing caps with feature levels. I
was also commenting on the proposed José's patch that we should have
fine-grained
On Thu, Apr 29, 2010 at 10:09 PM, Zack Rusin wrote:
> On Thursday 29 April 2010 15:44:35 Marek Olšák wrote:
> > On Thu, Apr 29, 2010 at 8:3
If there aren't any comments/concerns about this patch I'll probably
commit it tomorrow.
-Brian
>From 6b89acf14cac1028d1cfcd0e0d6419d3bfe32dd7 Mon Sep 17 00:00:00 2001
From: Brian Paul
Date: Thu, 29 Apr 2010 15:32:36 -0600
Subject: [PATCH] st/mesa: ignore gl_texture_object::BaseLevel when alloc
Can we stop the stupid already?
from what I can see nobody that is shipping a real driver that Linux
distros want is able to work with the current system.
By this I mean only vmware are seeing value in it and we are being
held hostage by it.
Here's the thing you should *always* be working on mas
We discussed the pros & cons of this several times, there was never consensus,
and there is always room for improvements, but I refuse to discuss them in such
terms, where you paint this absurd image of vmware bullying everybody around.
Jose
From: mesa-d
On Fri, Apr 30, 2010 at 10:42 AM, Jose Fonseca wrote:
> We discussed the pros & cons of this several times, there was never
> consensus, and there is always room for improvements, but I refuse to discuss
> them in such terms, where you paint this absurd image of vmware bullying
> everybody arou
On Thursday 29 April 2010 20:58:04 Dave Airlie wrote:
> On Fri, Apr 30, 2010 at 10:42 AM, Jose Fonseca wrote:
> > We discussed the pros & cons of this several times, there was never
> > consensus, and there is always room for improvements, but I refuse to
> > discuss them in such terms, where you
So in the spirit of being less of a dickhead,
Lets have a development model discussion. Can anyone who has an
interest in the development model please answer the two questions
below in their view/opinion.
a) what are the goals of the mesa project and development model?
to produce drivers for gra
Dave Airlie wrote:
>
> So in the spirit of being less of a dickhead,
>
> Lets have a development model discussion. Can anyone who has an
> interest in the development model please answer the two questions
> below in their view/opinion.
>
> a) what are the goals of the mesa project and development
>
>
> Dave,
>
> I'm sorry you're frustrated, but let's see if we can at least come to a
> better understanding of where we're each coming from.
>
> Your message seems to boil down to "cherry-pick fixes from master back
> to the stable branch" vs. "fix bugs in the stable branch and
> periodically me
On Fre, 2010-04-30 at 14:59 +1000, Dave Airlie wrote:
> >
> > I think you exagerate how many testing steps you have to do for each
> > and every fix. Absolutely, there are times when thorough testing is
> > needed. But lots of simple bug fixes/changes in 7.8 can be merged
> > into master without
29 matches
Mail list logo
