Keith Whitwell wrote:
> Luca,
>
> This is an impressive body of work. I want to give Jose a chance to
> review the EGL/GLX extensions before pushing, but in the meantime I hope
> it's ok if I make a couple of quick suggestions/requests:
>
> Firstly, we're going to be evolving the TGSI instruction
Couple things.
First, if we're going to start autogenerating headers, can we do GL
API first? I've got a handful of patches against those Python scripts,
and I can always sit down in a couple days and bang out the rest of
it.
(While we're at it, since we're doomed to bring it up every couple
mont
On Friday 01 January 2010 06:42:18 Corbin Simpson wrote:
> Couple things.
>
> First, if we're going to start autogenerating headers, can we do GL
> API first?
As long as we first fix the Exchange integration in KMail (i.e. it's a bit
unfair to bring up mysterious unrelated features as a problem
On 01.01.2010 00:57, Brian Paul wrote:
> The BY_REGION modes indicate that it's OK for the GPU to discard the
> fragments in the region(s) which failed the occlusion test (perhaps
> skipping other per-fragment ops that would have otherwise occurred).
> See the spec at
> http://www.opengl.org/regist
Hi,
i found a tgsi bug running vega state tracker.
The bug happens because in tgsi_text.c line 991:
for (i = 0; i < TGSI_SEMANTIC_COUNT; i++)
TGSI_SEMANTIC_COUNT is bigger than semantic_name declared in tgsi_text.c:
936 static const char *semantic_names[TGSI_SEMANTIC_COUNT] =
937 {
938"POS
Igor Oliveira wrote on 2010-01-01 18:03:
> Hi,
>
> i found a tgsi bug running vega state tracker.
> The bug happens because in tgsi_text.c line 991:
> for (i = 0; i < TGSI_SEMANTIC_COUNT; i++)
>
> TGSI_SEMANTIC_COUNT is bigger than semantic_name declared in tgsi_text.c:
> 936 static const char *se
http://bugs.freedesktop.org/show_bug.cgi?id=25847
Summary: Enable OpenGL > 1.4 support in most commonly used
drivers
Product: Mesa
Version: 7.6
Platform: Other
OS/Version: All
Status: NEW
Severity: enhance
http://bugs.freedesktop.org/show_bug.cgi?id=25847
--- Comment #1 from Matt Turner 2010-01-01 13:50:17 PST
---
You fundamentally misunderstand how OpenGL support works in Mesa.
If a driver doesn't state that it supports OpenGL x.y, that means it _actually
doesn't support it_.
Please just c
http://bugs.freedesktop.org/show_bug.cgi?id=25847
--- Comment #2 from Ruslan 2010-01-01 13:56:04 PST ---
But why couldn't it fall back to software rendering if it doesn't support some
feature?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiv
http://bugs.freedesktop.org/show_bug.cgi?id=25847
--- Comment #3 from Ruslan 2010-01-01 13:57:43 PST ---
>You fundamentally misunderstand how OpenGL support works in Mesa.
Maybe there is some documentation which would make me understand it properly? I
couldn't find it.
--
Configure bugmai
Currently Gallium defines a specific filtering mode for anisotropic filtering.
This however prevents proper implementation of
GL_EXT_texture_filter_anisotropic.
The spec (written by nVidia) contains the following text:
<<<
A texture's maximum degree of anisotropy is specified independent
On Thu, 2009-12-31 at 01:37 -0800, Luca Barbieri wrote:
> This is a series of 4 patches that add the required infrastructure for
> writing Gallium demos and programs and include two such demos,
> galliumgears and galliumglobe.
>
> The first two patches have already been posted, but I am including
On Tue, 2009-12-29 at 15:41 -0800, Luca Barbieri wrote:
> > The reason why I didn't implement the glX*Gallium*Mesa functions is
> > because the glx* extensions are implemented by libGL, and a driver
> > driver never has chance to export those extensions. And libGL is used
> > for non-gallium driver
>
>
> This is great stuff, and it couldn't have been in better timing. I was
> just about to get the python gallium tests we have working with llvmpipe
> too, and your work will save me a bunch of time.
>
You can also use the framework to write tests in C/C++, which, using a bit
of framework over
14 matches
Mail list logo