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 set a
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
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
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
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
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:
http://bugs.freedesktop.org/show_bug.cgi?id=25847
--- Comment #1 from Matt Turner matts...@gmail.com 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
http://bugs.freedesktop.org/show_bug.cgi?id=25847
--- Comment #2 from Ruslan b7.10110...@gmail.com 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
http://bugs.freedesktop.org/show_bug.cgi?id=25847
--- Comment #3 from Ruslan b7.10110...@gmail.com 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.
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 them
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 drivers.
I
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
