Chia-I Wu writes:
> On Tue, Jan 19, 2010 at 2:40 AM, Brian Paul wrote:
But it's not an application bug.
I could write a GL program that never calls glViewport and still draws
something meaningful before/after window resizing.
>>> If I understand correctly, the application will dra
Kristian Høgsberg writes:
> On Sun, Jan 17, 2010 at 11:18 PM, Francisco Jerez
> wrote:
>> Kristian Høgsberg writes:
>>> No, it sounds good, I'm happy that you're looking into this. I'll
>>> have a closer look tomorrow, but what I've had in mind for this kind
>>> of thing was that we could jus
2010/1/19 Kristian Høgsberg :
[snipped]
>> When we work on code in this area we should also consider the case of
>> using a rendering context that's bound to no window at all. That
>> could be useful for FBO rendering or just compiling shaders, etc.
>> Mesa would probably fail if this were attempt
On Fri, Jan 15, 2010 at 11:25 AM, Chia-I Wu wrote:
> I want to talk a little about the status of opengl-es-v2 branch and how I plan
> to merge it. If the timing is fine for everyone, I want to merge the branch
> to
> master next Tuesday or Wednesday.
If there is no objection, I am going to merge
On Tue, Jan 19, 2010 at 10:21 AM, Younes Manton wrote:
> On Mon, Jan 18, 2010 at 9:10 PM, Chia-I Wu wrote:
>> On Tue, Jan 19, 2010 at 7:58 AM, Luca Barbieri
>> wrote:
>>> The XImage backend keeps a transfer permanently and map/unmaps to do
>>> modifications.
>>> However, Gallium transfers can b
On Tue, Jan 19, 2010 at 2:45 AM, Brian Paul wrote:
>> This is a corner issue, but suppose two contexts are bound to the same
>> drawable. One of them wants a depth buffer while the other doesn't (or
>> wants a different depth size). There might be a race because one would
>> destroy the depth bu
On Tue, Jan 19, 2010 at 2:40 AM, Brian Paul wrote:
>>> But it's not an application bug.
>>> I could write a GL program that never calls glViewport and still draws
>>> something meaningful before/after window resizing.
>> If I understand correctly, the application will draw to an old buffer if
>> a
On Mon, Jan 18, 2010 at 9:10 PM, Chia-I Wu wrote:
> On Tue, Jan 19, 2010 at 7:58 AM, Luca Barbieri wrote:
>> The XImage backend keeps a transfer permanently and map/unmaps to do
>> modifications.
>> However, Gallium transfers can be implemented by making and keeping a
>> copy of the surface, flus
On Tue, Jan 19, 2010 at 7:58 AM, Luca Barbieri wrote:
> The XImage backend keeps a transfer permanently and map/unmaps to do
> modifications.
> However, Gallium transfers can be implemented by making and keeping a
> copy of the surface, flushing it back on transfer destruction.
> Thus, it should b
I think we should forbid recursive maps of the same buffer. Direct3D10
also forbids them:
http://msdn.microsoft.com/en-us/library/ee418691(VS.85).aspx
This has however some implications for draw module and the way state
trackers setup vertex buffers: either we force state trackers to never
pass t
The XImage backend keeps a transfer permanently and map/unmaps to do
modifications.
However, Gallium transfers can be implemented by making and keeping a
copy of the surface, flushing it back on transfer destruction.
Thus, it should be fixed to create and destroy a transfer every time
it maps the
What are the Gallium semantics for nested buffer maps and unmaps?
The current situation seems the following:
- Nouveau doesn't support nested mapping. It fully supports them with
a patch to libdrm I posted.
- r300 fully supports nested mapping
- VMware supports nested mapping, but only the outermo
> Either way, I anticipate having to build a function that, given a
> pipe_vertex_element and pipe_vertex_buffer, and a list of acceptable
> pipe_formats, internally magically modifies things inside so that all
> resulting VBOs are safe for HW.
As I mentioned on IRC, it may be possible to avoid th
So, with half-float vert attribs looming on the horizon, I want to
address, hopefully with some finality, vertex attrib formats.
Basically, should drivers be expected to use aux/translate on
pipe_vertex_buffers that have pipe_vertex_elements not supported in
HW?
If so, then there's probably a bit
On Mon, Jan 18, 2010 at 09:06:01PM +0100, Luca Barbieri wrote:
> As for REing the tables, it may not be possible.
> This is the code that apparently sets them up right now:
> /* vtxprog output routing */
> so_method(so, screen->curie, 0x1fc4, 1);
> so_data (so, 0x06144321);
>
> If you get this patch in, then you'll still have to fight with every
> other state tracker that doesn't prettify their TGSI. It would be a
> much better approach to attempt to RE the routing tables.
I don't think there any users of the Gallium interface that need more
than 8 vertex outputs/fragm
Actually, we don't even bother worrying about the rasterizer's routing
table until we've bound a pair of shaders and start drawing. Right
before the draw call, we re-generate, among other things, routing
tables for the vert shader and the rasterizer.
This is *incredibly* powerful, because it means
On Mon, Jan 18, 2010 at 1:45 PM, Brian Paul wrote:
> Chia-I Wu wrote:
>> On Fri, Jan 15, 2010 at 08:44:27AM -0700, Brian Paul wrote:
>>> Chia-I Wu wrote:
2010/1/15 Michel Dänzer :
Another question I have is, if depth/stencil should be shareable, how
about other buffers like multisam
Chia-I Wu wrote:
> On Fri, Jan 15, 2010 at 08:44:27AM -0700, Brian Paul wrote:
>> Chia-I Wu wrote:
>>> 2010/1/15 Michel Dänzer :
>>> Another question I have is, if depth/stencil should be shareable, how
>>> about other buffers like multisample buffer? (This is a real question that
>>> has
>>> bot
The patches implement gallium opcodes ddiv, dmul, dmax, dmin, dslt,
dsge, dseq, drcp, dqsrt and dmad and add tests to it.
They are applicable in gallium-double-opcode branch.
The next patchs i will add documentation and missing double opcodes
implementation like dfrac, dldexp and dfracexp.
Igor
F
On Sun, Jan 17, 2010 at 11:18 PM, Francisco Jerez wrote:
> Kristian Høgsberg writes:
>> No, it sounds good, I'm happy that you're looking into this. I'll
>> have a closer look tomorrow, but what I've had in mind for this kind
>> of thing was that we could just allocate the new buffers up front i
Chia-I Wu wrote:
> On Fri, Jan 15, 2010 at 08:36:55AM -0700, Brian Paul wrote:
If an OpenGL application does not call glViewport upon window resize, is
it consider an application bug?
>>> Yes, the OpenGL viewport isn't automatically adapted on a window resize.
>> But it's not an applicati
> But the assertion should be changed to "num instructions > 0" and not
> removed. I'll fix that.
OK.
Programs without END should be rejected by the parser anyway though.
--
Throughout its 18-year history, RSA Conference
On 18.01.2010 19:15, Luca Barbieri wrote:
> Breakpoint 3, _mesa_ProgramStringARB (target=34820, format=34933,
> len=70, string=0x85922ba) at shader/arbprogram.c:434
> 434 GET_CURRENT_CONTEXT(ctx);
> $31 = 0x85922ba "!!ARBfp1.0\n\nOPTION
> ARB_precision_hint_fastest;\n\n\n\nEND\
Luca Barbieri wrote:
> Breakpoint 3, _mesa_ProgramStringARB (target=34820, format=34933,
> len=70, string=0x85922ba) at shader/arbprogram.c:434
> 434 GET_CURRENT_CONTEXT(ctx);
> $31 = 0x85922ba "!!ARBfp1.0\n\nOPTION
> ARB_precision_hint_fastest;\n\n\n\nEND\n"
>
> Not sure why
Alan Coopersmith wrote:
> Signed-off-by: Alan Coopersmith
> ---
> src/glsl/cl/sl_cl_parse.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/glsl/cl/sl_cl_parse.c b/src/glsl/cl/sl_cl_parse.c
> index e9b3707..61f50db 100644
> --- a/src/glsl/cl/sl_cl_parse.c
> +++
Marek Olšák wrote:
> Hi,
>
> the first patch enables EXT_framebuffer_multisample in st/mesa. This
> extension appears to alias ARB_fbo functions and there's no other
> checking for multisampling in st/mesa where ARB_fbo is being enabled, so
> fbo_multisample could be enabled by default.
That p
Breakpoint 3, _mesa_ProgramStringARB (target=34820, format=34933,
len=70, string=0x85922ba) at shader/arbprogram.c:434
434GET_CURRENT_CONTEXT(ctx);
$31 = 0x85922ba "!!ARBfp1.0\n\nOPTION
ARB_precision_hint_fastest;\n\n\n\nEND\n"
Not sure why Sauerbraten does this, but it doe
Alan Coopersmith wrote:
> Sun cc 5.9 and later (__SUNPRO_C >= 0x590) support __attribute__ calls
> for aligned, always_inline, noinline, pure, const, and malloc.
>
> This commit includes updates to files that were regenerated by gl_XML.py
> after adding the __SUNPRO_C checks to it
>
> Signed-off-
Alan Coopersmith wrote:
> Signed-off-by: Alan Coopersmith
> ---
> configure.ac |9 -
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index d01d0f1..f121002 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -96,7 +96,14 @@ esac
>
Alan Coopersmith wrote:
> Signed-off-by: Alan Coopersmith
> ---
> src/mesa/sources.mak |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
> index a4d09c7..70fae92 100644
> --- a/src/mesa/sources.mak
> +++ b/src/mesa/sources.m
Alan Coopersmith wrote:
> Signed-off-by: Alan Coopersmith
Signed-off-by: Brian Paul
You, can commit Alan, right?
-Brian
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and br
Luca Barbieri wrote:
> Sauerbraten triggers this assert.
> ---
> src/mesa/state_tracker/st_atom_shader.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom_shader.c
> b/src/mesa/state_tracker/st_atom_shader.c
> index 176f3ea..fce533a 100
Marcin Slusarz wrote:
> ---
> src/gallium/state_trackers/dri/dri_context.c |5 +
> src/gallium/state_trackers/dri/dri_screen.c | 10 ++
> 2 files changed, 15 insertions(+), 0 deletions(-)
Committed. I just tweaked your commment and fixed the indentation.
-Brian
Marcin Slusarz wrote:
> glXDestroyContext does not destroy the context if it's still
> connected to some window. Unbind context from window to test it.
> ---
> without this patch valgrind prints:
> in use at exit: 4,009,194 bytes in 1,615 blocks
> with this patch (and few others):
> in use at exit:
Marcin Slusarz wrote:
> ---
> src/mesa/state_tracker/st_mesa_to_tgsi.c |9 +
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
Committed. Thanks.
-Brian
--
Throughout its 18-year history, RSA Conference
This requires the arb_half_float_vertex Mesa branch, plus some unreleased
gallium support work by Dave Airlie.
You may need to fix an assertion in st_pipe_vertex_format too.
---
src/gallium/drivers/nv40/nv40_vbo.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --gi
So, basically, you allocate the rasterizer units according to the
vertex shader, and when the fragment shader comes up, you say "write
rasterizer output 4 to fragment input 100"?
The current nouveau drivers can't do this.
There are "routing" registers in hardware, but I think the nVidia
propri
On Mon, Jan 18, 2010 at 10:52 AM, Marek Olšák wrote:
> On Mon, Jan 18, 2010 at 3:22 PM, Luca Barbieri
> wrote:
>>
>> > I think this is not necessary and fixing the rasterizer setup in the
>> > driver
>> > would by better than fixing the state tracker.
>> >
>> > In r300g, we dynamically allocate r
On Mon, Jan 18, 2010 at 3:22 PM, Luca Barbieri wrote:
> > I think this is not necessary and fixing the rasterizer setup in the
> driver
> > would by better than fixing the state tracker.
> >
> > In r300g, we dynamically allocate rasterizer units based on vertex shader
> > outputs. If the vertex sh
Cool!
I'll add nv40 support (and Gallium support if it's still missing).
nv50 also supports this in hardware, and maybe nv30 too.
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best an
> I think this is not necessary and fixing the rasterizer setup in the driver
> would by better than fixing the state tracker.
>
> In r300g, we dynamically allocate rasterizer units based on vertex shader
> outputs. If the vertex shader uses slots 1, 5, 20, 100, the driver maps
> them to units
On Sat, 2010-01-16 at 10:10 +, Jakob Bornecrantz wrote:
> On 16 jan 2010, at 09.47, Chia-I Wu wrote:
> > On Sat, Jan 16, 2010 at 05:49:44AM +, Jakob Bornecrantz wrote:
> >
> >>> +/* XXX this is WIP! */
> >>> +#define SM_VERSION_MAJOR 0
> >>> +#define SM_VERSION_MINOR 0
> >>> +#define ST_VE
43 matches
Mail list logo
