I bisected the rendering problem to commit adding xmm0 zeroing code to
transform functions.
4c31632817a0bde28ad6c9ee8032d838ce4b7bfb is first bad commit
commit 4c31632817a0bde28ad6c9ee8032d838ce4b7bfb
Author: Arthur HUILLET
Date: Tue Jun 30 12:46:27 2009 +0200
mesa: fix transform_points_3d
On Monday 01 February 2010 21:28:53 Igor Oliveira wrote:
> Hi again,
>
> Third version: removing debug messages
Nicely done, I just committed the patches. Thanks!
(a small nitpick, in future try to be a bit more descriptive in your commit
log :) ).
z
-
On Mon, Feb 1, 2010 at 7:34 PM, Chia-I Wu wrote:
> On Tue, Feb 2, 2010 at 2:49 AM, Mike Stroyan wrote:
>> Here is a version of the patch that uses EGL_DRIVERS_PATH and checks
>> for setuid/setgid
>> before using EGL_DRIVER or EGL_DRIVERS_PATH.
> The patch seems to be missing :)
Here is the miss
On Tue, Feb 2, 2010 at 6:06 AM, Mike Stroyan wrote:
> The progs/es2/xegl/tri.c demo fails using, eglQuerySurface() with
> EGL_SURFACE_TYPE.
> Only eglGetConfigAttrib can query EGL_SURFACE_TYPE.
> This patch replaces that with querying EGL_CONFIG_ID, then using that
> ID to call eglChooseConfig and
On Tue, Feb 2, 2010 at 2:49 AM, Mike Stroyan wrote:
> Here is a version of the patch that uses EGL_DRIVERS_PATH and checks
> for setuid/setgid
> before using EGL_DRIVER or EGL_DRIVERS_PATH.
The patch seems to be missing :)
I want to avoid suffix matching somehow.
> I am not clear about the m
Hi,
I am resenting the patches, i fixed some bugs in ureg functions and
did some clean up in shaders cache code. i tested it with all
progs/openvg files.
Igor
On Mon, Feb 1, 2010 at 1:02 PM, Zack Rusin wrote:
> On Monday 01 February 2010 10:19:53 Igor Oliveira wrote:
>> Hello,
>>
>> Theses pat
A possible limitation of this scheme is that it doesn't readily map to
hardware that can configure its own interpolators to behave either as
GENERIC, COLOR (or some other semantic) dynamically.
However, it seems to me that at least ARB_fragment_program only
requires and supports 2 COLOR registers
Hi again,
Third version: removing debug messages
Igor
On Mon, Feb 1, 2010 at 10:08 PM, Igor Oliveira
wrote:
> Hi,
>
>
> I am resenting the patches, i fixed some bugs in ureg functions and
> did some clean up in shaders cache code. i tested it with all
> progs/openvg files.
>
> Igor
>
> On Mon, F
Christoph Bumiller wrote:
> On 01.02.2010 21:44, Brian Paul wrote:
>> Christoph Bumiller wrote:
>>> I just noticed that alienarena fails to create an FBO for depth
>>> rendering
>>> because on st_validate_framebuffer, the depth attachment contains a pt
>>> in the stObj with format XR8G8B8_UNORM, wh
http://bugs.freedesktop.org/show_bug.cgi?id=26317
--- Comment #9 from Brian Paul 2010-02-01 16:36:35
PST ---
Fixed on mesa 7.7 branch with commit e0d01c9d7f46ccd531f8dd1a04c5ac067200ef1e
A regression test has been added to glean/glsl1 test.
--
Configure bugmail: http://bugs.freedesktop.
The progs/es2/xegl/tri.c demo fails using, eglQuerySurface() with
EGL_SURFACE_TYPE.
Only eglGetConfigAttrib can query EGL_SURFACE_TYPE.
This patch replaces that with querying EGL_CONFIG_ID, then using that
ID to call eglChooseConfig and using that config to call
eglGetConfigAttrib() with EGL_SURFA
On 01.02.2010 20:23, Brian Paul wrote:
> Speaking of texture formats and texture sampling, one area of Gallium
> that's under-specified is what (x,y,z,w) values are returned by TEX
> instructions when sampling from each of the various texture formats.
>
> A while back I started a table comparing
On 01.02.2010 21:44, Brian Paul wrote:
> Christoph Bumiller wrote:
>> I just noticed that alienarena fails to create an FBO for depth
>> rendering
>> because on st_validate_framebuffer, the depth attachment contains a pt
>> in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp)
>> repo
This++. I've been scratching my head at some of these; having them specified
would be great.
Posting from a mobile, pardon my terseness. ~ C.
On Feb 1, 2010 11:25 AM, "Brian Paul" wrote:
Speaking of texture formats and texture sampling, one area of Gallium
that's under-specified is what (x,y,z,
> Where the semantic indicates some relationship to actual system resources, I
> agree that the number is constrained by the number of those system resources.
> In the case of the gallium "GENERIC" semantic, there is explicitly no system
> resource that semantic is referring to and hence no lim
Christoph Bumiller wrote:
I just noticed that alienarena fails to create an FBO for depth rendering
because on st_validate_framebuffer, the depth attachment contains a pt
in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp)
reports as not supported in screen->is_format_supported if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Bumiller wrote:
> I just noticed that alienarena fails to create an FBO for depth rendering
> because on st_validate_framebuffer, the depth attachment contains a pt
> in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp)
> repor
Luca,
Where the semantic indicates some relationship to actual system resources, I
agree that the number is constrained by the number of those system resources.
In the case of the gallium "GENERIC" semantic, there is explicitly no system
resource that semantic is referring to and hence no limi
Speaking of texture formats and texture sampling, one area of Gallium
that's under-specified is what (x,y,z,w) values are returned by TEX
instructions when sampling from each of the various texture formats.
A while back I started a table comparing OpenGL to D3D:
texture componentsOpenGL
> I haven't tried to probe crazy high numbers, but within reason, my experience
> is that the numbers are unconstrained.
No, according to that document if you use TEXCOORD[n] then n < NUM_TEXCOORDS.
<<
TEXCOORD[n] Texture coordinates float4
[...]
n is an optional integer between 0 and th
olv,
Here is a version of the patch that uses EGL_DRIVERS_PATH and checks
for setuid/setgid
before using EGL_DRIVER or EGL_DRIVERS_PATH.
>>> I want to avoid suffix matching somehow.
I am not clear about the motive for a less than exact check for the
library suffix in EGL_DRIVER.
Are you intere
I propose that the following language be added to the spec:
"""
Gallium has no explicit mechanism for linking shaders. Shaders are
implicitly linked in a pipeline at render time. Thus, linking must not
fail and the pipe driver is permitted to change shader semantics to
preserve linking.
If a shad
On 01.02.2010 18:37, Roland Scheidegger wrote:
> On 31.01.2010 18:41, Christoph Bumiller wrote:
>
>> On 31.01.2010 01:37, Roland Scheidegger wrote:
>>
>>> Marek Olšák wrote:
>>>
>>>
6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
the fragme
On Mon, Feb 1, 2010 at 10:35 AM, tom fogal wrote:
> Mike Stroyan writes:
>> The changes to load EGL drivers by pattern matching had the side
>> effect of not looking in the directories specified by LD_LIBRARY_PATH
>> or -rpath or ldconfig .
>
> This is silly. If you give dlopen a library name:
On 01.02.2010 17:31, Keith Whitwell wrote:
> Christoph, Luca,
>
> Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware
> we end up implementing it by passing both front and back colors to the
> fragment shader and selecting between them using the FACE variable. If we
>
Luca,
I haven't tried to probe crazy high numbers, but within reason, my experience
is that the numbers are unconstrained. Certainly, within the range you're
suggesting for gallium, there is no constraint in DX9. No doubt where there
is a system-interpreted meaning attached to a semantic, t
I just noticed that alienarena fails to create an FBO for depth rendering
because on st_validate_framebuffer, the depth attachment contains a pt
in the stObj with format XR8G8B8_UNORM, which nv50 (contrary to sp)
reports as not supported in screen->is_format_supported if usage is ZS.
This happens
On 31.01.2010 18:41, Christoph Bumiller wrote:
> On 31.01.2010 01:37, Roland Scheidegger wrote:
>> Marek Olšák wrote:
>>
>>> 6) GL_ARB_shadow_ambient and texture compare-fail values. A comment in
>>> the fragment constants reads, "Since Gallium doesn't support
>>> GL_ARB_shadow_ambie
Mike Stroyan writes:
> The changes to load EGL drivers by pattern matching had the side
> effect of not looking in the directories specified by LD_LIBRARY_PATH
> or -rpath or ldconfig .
This is silly. If you give dlopen a library name:
dlopen("libWhatever.so", flags);
then *it* will automa
> DX9 semantic indexes are apparently unlimited
According to http://msdn.microsoft.com/en-us/library/ee418355%28VS.85%29.aspx,
this is not the case.
Here is the relevant text:
<<
These semantics have meaning when attached to a vertex-shader
parameters. These semantics are supported in both Direct
On Monday 01 February 2010 10:19:53 Igor Oliveira wrote:
> Hello,
>
> Theses patchs switch all shaders code implemeted using TGSI assembly
> by tgsi_ureg.
Hey Igor,
very nice work!
Since I don't have the conformance framework anymore, did you test your
changes with the examples that we have? B
DX9 semantic indexes are apparently unlimited, and you can definitely specify
COLOR 0..3, I haven't tried to go further.
Keith
From: luca.barbi...@gmail.com [luca.barbi...@gmail.com] On Behalf Of Luca
Barbieri [l...@luca-barbieri.com]
Sent: Monday, Februa
On Mon, Feb 1, 2010 at 5:31 PM, Keith Whitwell wrote:
> Christoph, Luca,
>
> Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware
> we end up implementing it by passing both front and back colors to the
> fragment shader and selecting between them using the FACE variabl
Christoph, Luca,
Twoside lighting has is a bit of a special case GL-ism. On a lot of hardware
we end up implementing it by passing both front and back colors to the fragment
shader and selecting between them using the FACE variable. If we removed the
implicit fixed-function support for two-s
I've just started another feature branch, gallium-embedded.
The objectives of this branch are two-fold:
- remove all inlines and os dependencies from src/gallium/include/pipe
headers, so that gallium interfaces become pure interfaces and therefore
everything else becomes optional
- move all OS
http://bugs.freedesktop.org/show_bug.cgi?id=26317
Andre Maasikas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
> I can't really use a routing table state to produce a cso, because the hw
> routing table I generate depends on rasterizer state, e.g. I must not
> put in back face colour (we have a 2 to 1 mapping here) if twoside
> is disabled.
>
> Also, I'm routing based on the scalar *components* the FP reads
Hello,
Theses patchs switch all shaders code implemeted using TGSI assembly
by tgsi_ureg.
Igor
From 6ff667cff0b3d6460a2bb0d6845348b6a2c6e6e2 Mon Sep 17 00:00:00 2001
From: Igor Oliveira
Date: Mon, 1 Feb 2010 11:11:36 -0400
Subject: [PATCH 1/2] vega: change tgsi asm by tgsi_ureg functions
---
s
On 01.02.2010 15:32, Luca Barbieri wrote:
> An overview of the possible options.
> Let's call vertex shader outputs "v" and fragment shader inputs "f"
> Let v -> f mean that v connects to f.
> NUM_INTERPOLATORS is the number of available interpolators. It is
> usually between 8 and 32.
>
> 1. Curre
On Mon, Feb 1, 2010 at 3:38 PM, Keith Whitwell wrote:
> This seems like a very different idea of semantics. These aren't intended to
> be hardware resources, and there is no concept of querying the driver to
> figure out how many the hardware supports. Further, the indices for
> different sem
This seems like a very different idea of semantics. These aren't intended to
be hardware resources, and there is no concept of querying the driver to figure
out how many the hardware supports. Further, the indices for different
semantic names are considered to be disjoint, permitting FOG[0], C
An overview of the possible options.
Let's call vertex shader outputs "v" and fragment shader inputs "f"
Let v -> f mean that v connects to f.
NUM_INTERPOLATORS is the number of available interpolators. It is
usually between 8 and 32.
1. Current Gallium
v -> f if and only if v == f
Any values of v
> In GL, there doesn't seem to be a requirement for sequential usage - an app
> using ARB_vp/fp could explicitly pass TEXCOORD[10] and ignore 0..9 if it
> wanted to. In ARB_vp, that effectively means the shader would be using
> discontiguous register numbers, ie OUTPUT[0], OUTPUT[10], etc.
Yes
Luca,
In GL, there doesn't seem to be a requirement for sequential usage - an app
using ARB_vp/fp could explicitly pass TEXCOORD[10] and ignore 0..9 if it wanted
to. In ARB_vp, that effectively means the shader would be using discontiguous
register numbers, ie OUTPUT[0], OUTPUT[10], etc.
In
Brian added a util function for copying the framebuffer state and adjusting all
the refcounts...
Keith
From: Corbin Simpson [mostawesomed...@gmail.com]
Sent: Sunday, January 31, 2010 11:11 AM
To: Jose Fonseca
Cc: Mesa3D-Development
Subject: Re: [Mesa3d-dev
45 matches
Mail list logo
