https://bugs.freedesktop.org/show_bug.cgi?id=27841
--- Comment #3 from Kristian Høgsberg k...@bitplanet.net 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
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 k...@bitplanet.net:
2010/4/28 Chia-I Wu olva...@gmail.com:
2010/4/28 Kristian Høgsberg k...@bitplanet.net:
2010/4/27 Kristian Høgsberg k...@bitplanet.net:
[ I hit send to early there... ]
review the patches, or at least just some of them. The overall
approach is
Was: Merging GLES1/2 to mesa/main
Chia-I Wu wrote:
2010/4/29 Kristian Høgsberg k...@bitplanet.net:
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
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
On Thu, Apr 29, 2010 at 9:54 AM, Brian Paul bri...@vmware.com wrote:
Was: Merging GLES1/2 to mesa/main
Chia-I Wu wrote:
2010/4/29 Kristian Høgsberg k...@bitplanet.net:
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
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
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
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 now.
On Thu, Apr 29, 2010 at 8:30 PM, Zack Rusin 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 D3D9-level chipsets since the
hardware is so divergent that you'd need
On Thursday 29 April 2010 15:44:35 Marek Olšák wrote:
On Thu, Apr 29, 2010 at 8:30 PM, Zack Rusin
za...@vmware.commailto: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
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 za...@vmware.com wrote:
On Thursday 29 April 2010 15:44:35 Marek Olšák wrote:
On Thu, Apr
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 bri...@vmware.com
Date: Thu, 29 Apr 2010 15:32:36 -0600
Subject: [PATCH] st/mesa: ignore
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:
On Thursday 29 April 2010 20:58:04 Dave Airlie wrote:
On Fri, Apr 30, 2010 at 10:42 AM, Jose Fonseca jfons...@vmware.com 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
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
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 model?
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 merge to
18 matches
Mail list logo
