Re: [Mesa3d-dev] Inter-StateTracker communication
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_VERSION_MAJOR 0 +#define ST_VERSION_MINOR 0 This is an internal Gallium API. As long as the Gallium API isn't stable there is no need to make this API stable so for now please remove any versioning from the API. I think the state trackers (libGL.so, libOpenVG.so, ...) are distributed separately from state tracker managers (libEGL.so). Shouldn't we need them? Both yes and no. The Linux GL ABI specifies exactly what libGL can contain (glx implementation + gl dispatch table) the rest needs to be inside the DRI driver (mesa and st). The libGL ABI defines what a libGL *must* contain. It *may* contain basically whatever else it pleases. :) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
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 1,2,3,4. But what if the fragment shader has inputs 1, 2, 5, 20, 100? If you remap the fragment shader to 1, 2, 3, 4, 5, then they will mismatch. You would need to either: 1. Generate shaders in the driver for the fragment/vertex combination instead of each one separately 2. Require that vertex shader outputs match fragment shader inputs exactly (1) makes the driver much more complex and slow. I think we should try to make it possible to avoid this, unless the hardware absolutely requires it. (2) will probably break the existing fixed pipeline and ARB_fp/vp support, and also make the driver more complex than necessary. Does r300g compile both fragment and vertex shader together? Also note that all Gallium-capable hardware should support 8 varying slots, so anything that uses only texture coordinates should not need any remapping. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] ARB_half_float_vertex support branch
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 and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
On Mon, Jan 18, 2010 at 10:52 AM, Marek Olšák mar...@gmail.com wrote: On Mon, Jan 18, 2010 at 3:22 PM, Luca Barbieri l...@luca-barbieri.com 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 shader uses slots 1, 5, 20, 100, the driver maps them to units 1,2,3,4. But what if the fragment shader has inputs 1, 2, 5, 20, 100? If you remap the fragment shader to 1, 2, 3, 4, 5, then they will mismatch. You would need to either: 1. Generate shaders in the driver for the fragment/vertex combination instead of each one separately 2. Require that vertex shader outputs match fragment shader inputs exactly (1) makes the driver much more complex and slow. I think we should try to make it possible to avoid this, unless the hardware absolutely requires it. (2) will probably break the existing fixed pipeline and ARB_fp/vp support, and also make the driver more complex than necessary. Does r300g compile both fragment and vertex shader together? Also note that all Gallium-capable hardware should support 8 varying slots, so anything that uses only texture coordinates should not need any remapping. I was talking about the rasterizer (interpolator) units, which, on r300, are quite flexible and can read an arbitrary vertex shader output and write it to an arbitrary fragment shader input (= register address). Given this flexibility, fragment and vertex shaders are compiled separately in r300g and semantic indices don't matter, just the total number of varyings. I think DX9 required this flexibility when mapping VS to PS, so it's likely most DX9 hw supports this. Alex -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
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 proprietary driver (at least without GLSL) leaves them unaltered after initialization and I don't think we really know how they would work. They are also very likely limited to at most 256 values (maybe even less, such as 16), even if they can actually be made to work. The way the current pre-nv50 driver works is that there are 8 slots, each of which has an interpolator and a fixed associated vertex shader output and fixed fragment input. This seems a rather obvious way to design hardware, and so shouldn't be uncommon. Thus, the inputs/outputs can't be packed, because that will break if the fragment shader doesn't use a vertex output. And there is no way to correct that when the fragment program comes up, other than recompiling the vertex shader, which would be very desirable to avoid having to do. Non-GLSL programs can only use the 8 texcoords, so there is no problem there since hardware supports 8 slots. Thus, I think my proposed solution is the simplest and most efficient approach. Any other solution would require much more, and slower, code in the Gallium drivers for nv30, nv40, and maybe Intel too. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] nv40: add support for ARB_half_float_vertex
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 --git a/src/gallium/drivers/nv40/nv40_vbo.c
b/src/gallium/drivers/nv40/nv40_vbo.c
index e85d6b4..211f3bd 100644
--- a/src/gallium/drivers/nv40/nv40_vbo.c
+++ b/src/gallium/drivers/nv40/nv40_vbo.c
@@ -11,6 +11,10 @@
#define FORCE_SWTNL 0
+#ifndef NV40TCL_VTXFMT_TYPE_HALF
+#define NV40TCL_VTXFMT_TYPE_HALF 3
+#endif
+
static INLINE int
nv40_vbo_format_to_hw(enum pipe_format pipe, unsigned *fmt, unsigned *ncomp)
{
@@ -21,6 +25,12 @@ nv40_vbo_format_to_hw(enum pipe_format pipe, unsigned *fmt,
unsigned *ncomp)
case PIPE_FORMAT_R32G32B32A32_FLOAT:
*fmt = NV40TCL_VTXFMT_TYPE_FLOAT;
break;
+ case PIPE_FORMAT_R16X16_FLOAT:
+ case PIPE_FORMAT_R16G16_FLOAT:
+ case PIPE_FORMAT_R16G16B16X16_FLOAT:
+ case PIPE_FORMAT_R16G16B16A16_FLOAT:
+ *fmt = NV40TCL_VTXFMT_TYPE_HALF;
+ break;
case PIPE_FORMAT_R8_UNORM:
case PIPE_FORMAT_R8G8_UNORM:
case PIPE_FORMAT_R8G8B8_UNORM:
@@ -41,21 +51,25 @@ nv40_vbo_format_to_hw(enum pipe_format pipe, unsigned *fmt,
unsigned *ncomp)
switch (pipe) {
case PIPE_FORMAT_R8_UNORM:
case PIPE_FORMAT_R32_FLOAT:
+ case PIPE_FORMAT_R16X16_FLOAT:
case PIPE_FORMAT_R16_SSCALED:
*ncomp = 1;
break;
case PIPE_FORMAT_R8G8_UNORM:
case PIPE_FORMAT_R32G32_FLOAT:
+ case PIPE_FORMAT_R16G16_FLOAT:
case PIPE_FORMAT_R16G16_SSCALED:
*ncomp = 2;
break;
case PIPE_FORMAT_R8G8B8_UNORM:
case PIPE_FORMAT_R32G32B32_FLOAT:
+ case PIPE_FORMAT_R16G16B16X16_FLOAT:
case PIPE_FORMAT_R16G16B16_SSCALED:
*ncomp = 3;
break;
case PIPE_FORMAT_R8G8B8A8_UNORM:
case PIPE_FORMAT_R32G32B32A32_FLOAT:
+ case PIPE_FORMAT_R16G16B16A16_FLOAT:
case PIPE_FORMAT_R16G16B16A16_SSCALED:
*ncomp = 4;
break;
--
1.6.3.3
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] st/mesa: fix memory leak in st_translate_mesa_program
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 consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glxgears: unbind current context before destroying it
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: 36,415 bytes in 430 blocks Committed. Thanks. -Brian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] st/dri: fix optionCache memory leaks
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 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 2/2] st: don't assert on empty fragment program
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 100644 --- a/src/mesa/state_tracker/st_atom_shader.c +++ b/src/mesa/state_tracker/st_atom_shader.c @@ -79,8 +79,6 @@ translate_fp(struct st_context *st, stfp-num_input_slots = numIn; - assert(stfp-Base.Base.NumInstructions 1); - st_translate_fragment_program(st, stfp, stfp-input_to_slot); } } How do we end up with a shader that has only one instruction (or none)? Is it an END instruction? I'd like to learn more about what's happening before committing this. -Brian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Remove hardcoded -Wall from Radeon DRI makefiles
Alan Coopersmith wrote: Signed-off-by: Alan Coopersmith alan.coopersm...@sun.com Signed-off-by: Brian Paul bri...@vmware.com You, can commit Alan, right? -Brian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Add -I$(TOP)/src/mesa/shader needed when building shader/lex.yy.o
Alan Coopersmith wrote: Signed-off-by: Alan Coopersmith alan.coopersm...@sun.com --- 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.mak @@ -377,5 +377,6 @@ GLSL_LIBS = \ INCLUDE_DIRS = \ -I$(TOP)/include \ -I$(TOP)/src/mesa \ + -I$(TOP)/src/mesa/shader \ -I$(TOP)/src/gallium/include \ -I$(TOP)/src/gallium/auxiliary Hmmm, why hasn't this been necessary before? Can the #include in question be something like #include shader/foo.h instead? That would follow the existing conventions. -Brian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Check if gcc supports -fvisibility=hidden before adding to CFLAGS
Alan Coopersmith wrote: Signed-off-by: Alan Coopersmith alan.coopersm...@sun.com --- 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 dnl Add flags for gcc and g++ if test x$GCC = xyes; then -CFLAGS=$CFLAGS -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden +CFLAGS=$CFLAGS -Wall -Wmissing-prototypes -std=c99 -ffast-math + +# Enable -fvisibility=hidden if using a gcc that supports it +save_CFLAGS=$CFLAGS +AC_MSG_CHECKING([whether $(CC) supports -fvisibility=hidden]) +CFLAGS=$CFLAGS -fvisibility=hidden +AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]), +[CFLAGS=$save_CFLAGS ; AC_MSG_RESULT([no])]); # Work around aliasing bugs - developers should comment this out CFLAGS=$CFLAGS -fno-strict-aliasing I'm not the configure guy, but this looks OK to me. -Brian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Sun compilers now support some gcc __attribute__ values
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-by: Alan Coopersmith alan.coopersm...@sun.com Signed-off-by: Brian Paul bri...@vmware.com -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 2/2] st: don't assert on empty fragment program
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 does, at least on my system (Ubuntu Karmic, nv40 driver) and it should be legal. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/2] st/mesa: EXT_framebuffer_multisample and CopyTex[Sub]Image acceleration
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 patch looks OK. The second patch enables hardware-accelerated CopyTex[Sub]Image in cases when the RGB and RGBA destination formats are used regardless of source formats. The idea is that if the colorbuffer is of RGB or RGBA format, the format conversion for copying between two different surfaces is basically done in texture units (using swizzles), therefore there is no reason to use software fallback. Without this patch, openarena fallbacks to software when bloom is enabled. Did you read the comment at line 1498? I remember specifically adding this check to fix some issues when copying an RGBA framebuffer to a RGB texture. -Brian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] inline is portable standard, __inline is not
Alan Coopersmith wrote:
Signed-off-by: Alan Coopersmith alan.coopersm...@sun.com
---
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
+++ b/src/glsl/cl/sl_cl_parse.c
@@ -345,7 +345,7 @@ struct parse_state {
};
-static __inline unsigned int
+static inline unsigned int
_emit(struct parse_context *ctx,
unsigned int *out,
unsigned char b)
I'm going to simply remove the __inline directive. It makes no
difference in this case with gcc -O3.
-Brian
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 2/2] st: don't assert on empty fragment program
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 Sauerbraten does this, but it does, at least on my system (Ubuntu Karmic, nv40 driver) and it should be legal. OK, GL_ARB_fragment_programs says a fragment program does not have to write a color result (so the color is undefined). But the assertion should be changed to num instructions 0 and not removed. I'll fix that. -Brian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 2/2] st: don't assert on empty fragment program
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\n Not sure why Sauerbraten does this, but it does, at least on my system (Ubuntu Karmic, nv40 driver) and it should be legal. Probably depth writes only enabled for things like shadows? Roland -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Event-based buffer validation for DRI2.
On Sun, Jan 17, 2010 at 11:18 PM, Francisco Jerez curroje...@riseup.net wrote: Kristian Høgsberg k...@bitplanet.net 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 in the X server. Then, instead of an invalidate event and a subsequent DRI2GetBuffers, we'll just have a here are your new buffers event, so we avoid the round trip. Yeah that's sensible, the only problem I see with doing things that way is that it doesn't give the driver an opportunity to flush its rendering queues before swapping buffers, so some of it could be lost buried in the old buffers. Right. Another option is to tell the client about new buffers in the DRI2SwapBuffer/DRI2CopyRegion reply instead - or to kill two birds with one stone, make DRI2SwapBuffers/DRI2CopyRegion one-way requests (that is, requests without a reply) and then send an event instead. This lets the client do other things while waiting for the server to reply, and we'll wait for the event to arrive in the GetBuffers callback from the driver if it hasn't already. The event will always be sent in response to either DRI2SwapBuffer or DRI2CopyRegion, which addresses your concern about sending the event to everybody. The client must wait for the event before it starts rendering the next frame since it could receive new buffers and in any case the server needs to submit the back-front blit first (which is the reason DRI2CopyRegion is a round-trip). That would be the ideal solution as far as I know, and if we're changing things, this is what we should go for. cheers, Kristian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Implement double opcodes: ddiv, dmul, dmax, dmin, dslt, dsge, dseq, drcp, dqsrt and dmad
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
From 0762c16db13543aa79c77c1c8ebbcfdc581fc8b1 Mon Sep 17 00:00:00 2001
From: Igor Oliveira igor.olive...@openbossa.org
Date: Mon, 18 Jan 2010 13:54:19 -0400
Subject: [PATCH 1/6] gallium: add double opcodes ddiv, dmul, dmax, dmin, dslt, dsge, dseq, drcp and dqsrt
---
src/gallium/include/pipe/p_shader_tokens.h | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/gallium/include/pipe/p_shader_tokens.h b/src/gallium/include/pipe/p_shader_tokens.h
index 5975146..ccfe41c 100644
--- a/src/gallium/include/pipe/p_shader_tokens.h
+++ b/src/gallium/include/pipe/p_shader_tokens.h
@@ -323,7 +323,16 @@ struct tgsi_property_data {
#define TGSI_OPCODE_D2F 146
#define TGSI_OPCODE_DMOV147
#define TGSI_OPCODE_DADD148
-#define TGSI_OPCODE_LAST149
+#define TGSI_OPCODE_DDIV149
+#define TGSI_OPCODE_DMUL150
+#define TGSI_OPCODE_DMAX151
+#define TGSI_OPCODE_DMIN152
+#define TGSI_OPCODE_DSLT153
+#define TGSI_OPCODE_DSGE154
+#define TGSI_OPCODE_DSEQ155
+#define TGSI_OPCODE_DRCP156
+#define TGSI_OPCODE_DSQRT 157
+#define TGSI_OPCODE_LAST158
#define TGSI_SAT_NONE0 /* do not saturate */
#define TGSI_SAT_ZERO_ONE1 /* clamp to [0,1] */
--
1.6.3.3
From 1139cb4c0cdfa7e8b1a1af7e6876f8f4ed3098df Mon Sep 17 00:00:00 2001
From: Igor Olivera igor.olive...@openbossa.org
Date: Mon, 18 Jan 2010 13:56:58 -0400
Subject: [PATCH 2/6] tgsi: implement double opcodes
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 127
src/gallium/auxiliary/tgsi/tgsi_info.c | 11 +++-
2 files changed, 137 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.c b/src/gallium/auxiliary/tgsi/tgsi_exec.c
index b9ea761..c66c41a 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_exec.c
@@ -180,6 +180,96 @@ micro_dmov(union tgsi_double_channel *dst,
}
static void
+micro_ddiv(union tgsi_double_channel *dst,
+ const union tgsi_double_channel *src)
+{
+ dst-d[0] = src[0].d[0]/src[1].d[0];
+ dst-d[1] = src[0].d[1]/src[1].d[1];
+ dst-d[2] = src[0].d[2]/src[1].d[2];
+ dst-d[3] = src[0].d[3]/src[1].d[3];
+}
+
+static void
+micro_dmul(union tgsi_double_channel *dst,
+ const union tgsi_double_channel *src)
+{
+ dst-d[0] = src[0].d[0]*src[1].d[0];
+ dst-d[1] = src[0].d[1]*src[1].d[1];
+ dst-d[2] = src[0].d[2]*src[1].d[2];
+ dst-d[3] = src[0].d[3]*src[1].d[3];
+}
+
+static void
+micro_dmax(union tgsi_double_channel *dst,
+ const union tgsi_double_channel *src)
+{
+ dst-d[0] = src[0].d[0] src[1].d[0] ? src[0].d[0] : src[1].d[0];
+ dst-d[1] = src[0].d[1] src[1].d[1] ? src[0].d[1] : src[1].d[1];
+ dst-d[2] = src[0].d[2] src[1].d[2] ? src[0].d[2] : src[1].d[2];
+ dst-d[3] = src[0].d[3] src[1].d[3] ? src[0].d[3] : src[1].d[3];
+}
+
+static void
+micro_dmin(union tgsi_double_channel *dst,
+ const union tgsi_double_channel *src)
+{
+ dst-d[0] = src[0].d[0] src[1].d[0] ? src[0].d[0] : src[1].d[0];
+ dst-d[1] = src[0].d[1] src[1].d[1] ? src[0].d[1] : src[1].d[1];
+ dst-d[2] = src[0].d[2] src[1].d[2] ? src[0].d[2] : src[1].d[2];
+ dst-d[3] = src[0].d[3] src[1].d[3] ? src[0].d[3] : src[1].d[3];
+}
+
+static void
+micro_dslt(union tgsi_double_channel *dst,
+ const union tgsi_double_channel *src)
+{
+ dst-d[0] = src[0].d[0] src[1].d[0] ? 1.0F : 0.0F;
+ dst-d[1] = src[0].d[1] src[1].d[1] ? 1.0F : 0.0F;
+ dst-d[2] = src[0].d[2] src[1].d[2] ? 1.0F : 0.0F;
+ dst-d[3] = src[0].d[3] src[1].d[3] ? 1.0F : 0.0F;
+}
+
+static void
+micro_dsge(union tgsi_double_channel *dst,
+ const union tgsi_double_channel *src)
+{
+ dst-d[0] = src[0].d[0] = src[1].d[0] ? 1.0F : 0.0F;
+ dst-d[1] = src[0].d[1] = src[1].d[1] ? 1.0F : 0.0F;
+ dst-d[2] = src[0].d[2] = src[1].d[2] ? 1.0F : 0.0F;
+ dst-d[3] = src[0].d[3] = src[1].d[3] ? 1.0F : 0.0F;
+}
+
+static void
+micro_dseq(union tgsi_double_channel *dst,
+ const union tgsi_double_channel *src)
+{
+ dst-d[0] = src[0].d[0] == src[1].d[0] ? 1.0F : 0.0F;
+ dst-d[1] = src[0].d[1] == src[1].d[1] ? 1.0F : 0.0F;
+ dst-d[2] = src[0].d[2] == src[1].d[2] ? 1.0F : 0.0F;
+ dst-d[3] = src[0].d[3] == src[1].d[3] ? 1.0F : 0.0F;
+}
+
+static void
+micro_drcp(union tgsi_double_channel *dst,
+ const union tgsi_double_channel *src)
+{
+ dst-d[0] = 1.0F/src-d[0];
+ dst-d[1] = 1.0F/src-d[1];
+ dst-d[2] = 1.0F/src-d[2];
+ dst-d[3] = 1.0F/src-d[3];
+}
+
+static void
Re: [Mesa3d-dev] Inter-StateTracker communication
On Mon, Jan 18, 2010 at 1:45 PM, Brian Paul bri...@vmware.com 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 mic...@daenzer.net: 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 bothered me for a while. I am eager for an answer here.) Yes, I believe the GLX spec indicates that all ancillary buffers associated with a window are to be sharable. Thanks. This helps a lot. 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 buffer of the other. But this should probably be solved by making either of the context incompatible with the drawable. The GLX spec says something about framebuffer and context compatibility in terms of RGB vs. CI and some other things. Both GLX contexts and GLX drawables are generally created with the same GLX visual (or FB config). But if a context created w/out Z were successfully bound a window without a Z buffer, the Z buffer would not be magically destroyed. Note that the issues of framebuffer/context compatibility is probably much more lax nowadays since we have things like framebuffer objects that may have any kind of combination of ancillary buffers. 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 attempted today, but that should get fixed. I just implemented this for then intel DRI driver. It is indeed very useful and quite straight forward. My take on the MESA_screen_surface + EGL is that we shouldn't try to wrap the KMS API in a GL extension. It's a complicated API that is still evolving. Instead, being able to bind a native GEM/TTM buffer to a GL render buffer along with an extension to make a context current without requiring a surface/drawable is a perfect companion to the KMS API. I'm finishing up a branch with this work now and will post an announcement/description later. cheers, Kristian -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
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 we only have to compile the shaders once, and load the rasterizer tables based on those shaders. I even baked up a CSO to cache the tables, but it turned out to be an overall slowdown. 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. Also FYI the r300-r500 rasterizer can only handle, off the top of my head, 16 sets of vectors total (8 colors, 8 texcoords) so you're not the only ones with this kind of limitation. The situation gets better for r600 and nv50. ~ C. On Mon, Jan 18, 2010 at 8:27 AM, Luca Barbieri l...@luca-barbieri.com wrote: 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 proprietary driver (at least without GLSL) leaves them unaltered after initialization and I don't think we really know how they would work. They are also very likely limited to at most 256 values (maybe even less, such as 16), even if they can actually be made to work. The way the current pre-nv50 driver works is that there are 8 slots, each of which has an interpolator and a fixed associated vertex shader output and fixed fragment input. This seems a rather obvious way to design hardware, and so shouldn't be uncommon. Thus, the inputs/outputs can't be packed, because that will break if the fragment shader doesn't use a vertex output. And there is no way to correct that when the fragment program comes up, other than recompiling the vertex shader, which would be very desirable to avoid having to do. Non-GLSL programs can only use the 8 texcoords, so there is no problem there since hardware supports 8 slots. Thus, I think my proposed solution is the simplest and most efficient approach. Any other solution would require much more, and slower, code in the Gallium drivers for nv30, nv40, and maybe Intel too. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Only fools are easily impressed by what is only barely beyond their reach. ~ Unknown Corbin Simpson mostawesomed...@gmail.com -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
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/fragment inputs and don't use sequential values starting at 0, except the GLSL linker without this patch. ARB_fragment_program and ARB_vertex_program is limited to texcoord slots, and Mesa should advertise only 8 of them. Also users of this interface will likely only use as many as they need, sequentially. Vega, xorg seem to only use up to 2 slots. g3dvl up to 8 (starting from 0, of course). Cards with less than 8 slots may sometimes still have problems, but such cards will probably be DX8 cards that don't work anyway. Furthermore, even if you can route things, usings vertex outputs and fragment inputs with lower indices may be more efficient anyway. 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); so_method(so, screen-curie, 0x1fc8, 2); so_data (so, 0xedcba987); so_data (so, 0x0021); so_method(so, screen-curie, 0x1fd0, 1); so_data (so, 0x00171615); so_method(so, screen-curie, 0x1fd4, 1); so_data (so, 0x001b1a19); This makes me think that only 4 bits might be used for the values (look at the arithmetic progressions of 4-bit values), so that there is a limit of 16 vertex output/fragment inputs. If GLSL starts at index 10, we are still in trouble because less than 8 varyings will be available. Also leaving vertex outputs/fragment inputs unused by starting at high values may be bad for performance even if supported, as it may lead to a bigger register file and thus less simultaneous GPU threads running. In other words, having GLSL start at index 10 is easily avoided, and causes problems nothing else causes, so why not just stop doing that? -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] glsl: put varyings in texcoord slots
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); so_method(so, screen-curie, 0x1fc8, 2); so_data (so, 0xedcba987); so_data (so, 0x0021); so_method(so, screen-curie, 0x1fd0, 1); so_data (so, 0x00171615); so_method(so, screen-curie, 0x1fd4, 1); so_data (so, 0x001b1a19); This makes me think that only 4 bits might be used for the values (look at the arithmetic progressions of 4-bit values), so that there is a limit of 16 vertex output/fragment inputs. Looking at the so_data values, 1fcx is 4 bits, 1fdx is 8 bits. It's also a little strange to have 24 slots for 16 possible values. If GLSL starts at index 10, we are still in trouble because less than 8 varyings will be available. Shader model 4 requires at least 32 interpolated values. Subsequent versions will want more and more. Any start index is going to blow up someday unless it's a very large value (which 10 isn't). OG. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] pipe_vertex_buffer and format translate
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 more code that can be built up to automate the process. Also it kind of sucks because we can't translate on bind (the st could remap and change VBO data behind our backs) and so we must translate on every single draw. Obviously there's ways to alleviate this, but they all require a tad more typing than I'm going to commit to right now. If not, then can we add a new target/usage/whatever to is_format_supported, or rename it to is_texture_format_supported and add is_vertex_format_supported? Let the state tracker worry about this nonsense. 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. Thoughts? -- Corbin Simpson mostawesomed...@gmail.com -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] pipe_vertex_buffer and format translate
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 this, as long as the GPU supports fp32, some flavor of int8, and some flavor of int16: 1. For int8/int16 add a vertex shader constant and add a mul to multiply input by it. Use that to correct the scaling. 2. Use another couple of constants and sge+mad to correct signedness (v = v + (v = c0) * c1; where e.g. c0 = 0x80 and c1 = -0x100) 3. For fp16, use -is_vertex_format_supported to not expose the GL extension 4. For int32 and fp64 (and fp16 if the app uses it despite the extension not being advertised), fallback to the draw module. Using int32, fp64 or unsupported fp16 is rare and stupid, and the application deserves it. The constants may be inlined to trade off vertex shader length for number of shaders to compile. This should cover all cards: nv30, nv40 and r300 are covered, i915 uses draw, and DX10 gpus should support everything. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Gallium semantics for nested pipe_buffer map/unmap?
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 outermost map can be for writing (strange...) - In OpenGL, nested mapping is disallowed Those who support nested maps do it by using a map counter. All drivers seem to ignore the range and just map the whole buffer. Note that nesting with map_range would require to keep a LIFO stack of mappings in the driver since unmap does not take the address as a parameter. What does the Gallium interface specify, or what do we want it to be? It seems that whatever is chosen as the interface, some drivers will need to be fixed. I see two possible avenues: 1. Ban nested mapping. This is somewhat uncomfortable for those who need to map multiple buffers at once, which may or may not be the same one. 2. Fully allow nested mapping, even with unpaired map/unmap, but add an address parameter to unmap. Drivers are required to reuse the same mapping for non-range maps, but may not do so for map_range. In that case, they can check whether the address being unmapped is the whole buffer mapping and if so lower the map count, and otherwise directly call munmap or the equivalent. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium semantics for nested pipe_buffer map/unmap?
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 the same buffer twice in set_vertex_buffers, or the draw module has to check this and map the buffer only once. Also, pipe_screen::buffer_map_range should be modified to return the pointer to the range, like the GL extension. Jose On Mon, 2010-01-18 at 15:56 -0800, Luca Barbieri wrote: 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 outermost map can be for writing (strange...) - In OpenGL, nested mapping is disallowed Those who support nested maps do it by using a map counter. All drivers seem to ignore the range and just map the whole buffer. Note that nesting with map_range would require to keep a LIFO stack of mappings in the driver since unmap does not take the address as a parameter. What does the Gallium interface specify, or what do we want it to be? It seems that whatever is chosen as the interface, some drivers will need to be fixed. I see two possible avenues: 1. Ban nested mapping. This is somewhat uncomfortable for those who need to map multiple buffers at once, which may or may not be the same one. 2. Fully allow nested mapping, even with unpaired map/unmap, but add an address parameter to unmap. Drivers are required to reuse the same mapping for non-range maps, but may not do so for map_range. In that case, they can check whether the address being unmapped is the whole buffer mapping and if so lower the map count, and otherwise directly call munmap or the equivalent. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] egl_g3d ximage backend transfer usage is broken
On Tue, Jan 19, 2010 at 7:58 AM, Luca Barbieri l...@luca-barbieri.com 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 be fixed to create and destroy a transfer every time it maps the surface. Thanks, that should be an easy fix. But I do wonder if a pipe transfer is always supposed to be temporary? Its operations, transfer_map and transfer_unmap, kind of hinted me that the pipe transfer can be used repeatedly. -olv -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] egl_g3d ximage backend transfer usage is broken
On Mon, Jan 18, 2010 at 9:10 PM, Chia-I Wu olva...@gmail.com wrote: On Tue, Jan 19, 2010 at 7:58 AM, Luca Barbieri l...@luca-barbieri.com 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 be fixed to create and destroy a transfer every time it maps the surface. Thanks, that should be an easy fix. But I do wonder if a pipe transfer is always supposed to be temporary? Its operations, transfer_map and transfer_unmap, kind of hinted me that the pipe transfer can be used repeatedly. -olv It was my understanding that the transfer happened on destroy and that was how the nouveau implementations were written. You can probably find the original thread, IIRC it was Michael Danzer that did the interface and softpipe. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Inter-StateTracker communication
On Tue, Jan 19, 2010 at 2:40 AM, Brian Paul bri...@vmware.com 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 resize happened and it did not call glViewport. Right? Are you talking about a specific driver, or in general? In general, it depends on how rendering finds its way to the buffer. If rendering to a surface goes through some kind of handle, reallocating the buffer doesn't change the handle so renering should go to the new buffer. What I had in mind was all DRI2 drivers. I doubt that the handles point to the new buffers automatically, but I am not 100% sure. In that case, we need to call DRI2GetBuffers in buffer swap (for back rendering) or flush frontbuffer (for front rendering), and copy the contents of the old buffer to the new one at a suitable position. Off-hand I'm not sure what happens with DRI2. I could try to look later when I get some time. Anyone else know? But in the example I alluded to, my app would detect the resize (probably a ConfigureNotify event) and draw a new image and still not call glViewport(). Remember that glViewport() _only_ specifies an X/Y transformation of vertex coords from NDC to window space. It says nothing about the window size or clipping or anything like that. Yes, this is what I thought what it should be from the application's point of view. It seems to me that some heuristics are assumed in DRI2 drivers because of performance concern. I think the DRI2 patches Francisco Jerez sent yesterday can solve the issue. (CCed Francisco so that he could provide some insights) -olv -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Inter-StateTracker communication
On Tue, Jan 19, 2010 at 2:45 AM, Brian Paul bri...@vmware.com 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 buffer of the other. But this should probably be solved by making either of the context incompatible with the drawable. The GLX spec says something about framebuffer and context compatibility in terms of RGB vs. CI and some other things. Both GLX contexts and GLX drawables are generally created with the same GLX visual (or FB config). But if a context created w/out Z were successfully bound a window without a Z buffer, the Z buffer would not be magically destroyed. Note that the issues of framebuffer/context compatibility is probably much more lax nowadays since we have things like framebuffer objects that may have any kind of combination of ancillary buffers. I am leaning toward having the state trackers create the buffers they need from the pipe screen, except for color buffers (front/back/left/right) that are potentially visible to the users. egl_g3d is working this way. The requirement by GLX for the buffers to be shareable disallows this. But I think OpenGL state tracker can be made to satisfy both needs. 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 attempted today, but that should get fixed. On the GLX side, glXMakeContextCurrent requires the context and draw/read drawbles to be all non-NULL or all NULL at the same time. The restriction also needs to be lifted, right? It looks to me that fooMakeCurrent mixes two operations in one function. While working on st_api.h, I want to support it through two state tracker callbacks /* bind the context to the framebuffers */ st_context-bind_framebuffers(st_context, draw, read); /* notify the state tracker the new current context */ st_api-notify_current_context(st_api, st_context); instead of st_api-make_current(st_api, st_context, draw, read); I want that because I think it is clearer. With fooMakeCurrent being overloaded with even more semantics, I feel stronger for that now. (In case you are interested, it is listed as issue 3 in the st_api repo) -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Is pipe transfer supposed to be temporary?
On Tue, Jan 19, 2010 at 10:21 AM, Younes Manton youne...@gmail.com wrote: On Mon, Jan 18, 2010 at 9:10 PM, Chia-I Wu olva...@gmail.com wrote: On Tue, Jan 19, 2010 at 7:58 AM, Luca Barbieri l...@luca-barbieri.com 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 be fixed to create and destroy a transfer every time it maps the surface. Thanks, that should be an easy fix. But I do wonder if a pipe transfer is always supposed to be temporary? Its operations, transfer_map and transfer_unmap, kind of hinted me that the pipe transfer can be used repeatedly. It was my understanding that the transfer happened on destroy and that was how the nouveau implementations were written. You can probably find the original thread, IIRC it was Michael Danzer that did the interface and softpipe. The ximage backend uses only softpipe and that is why I didn't notice that. softpipe seems to work well with permanent pipe transfers, but I think it is vital to use the interface correctly. -olv -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] opengl-es-v2 status and merge plan
On Fri, Jan 15, 2010 at 11:25 AM, Chia-I Wu olva...@gmail.com 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 it tomorrow. (roughly Tuesday night in U.S. time) -olv -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Inter-StateTracker communication
2010/1/19 Kristian Høgsberg k...@bitplanet.net: [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 attempted today, but that should get fixed. I just implemented this for then intel DRI driver. It is indeed very useful and quite straight forward. My take on the MESA_screen_surface + EGL is that we shouldn't try to wrap the KMS API in a GL extension. It's a complicated API that is still evolving. Instead, being able to bind a native GEM/TTM buffer to a GL render buffer along with an extension to make a context current without requiring a surface/drawable is a perfect companion to the KMS API. I'm finishing up a branch with this work now and will post an announcement/description later. That sounds cool. I am looking forward to it. If you are working on it for Wayland, I want to share a little about Android's take on EGL. In Android, the display server serves the role of a traditional display server, as well as the window compositor. There is a single libEGL on Android that does not have any special extension. The display server and the clients use the standard EGL the same way. As we know, EGL works with surfaces. They are created from native windows/pixmaps. A common problem is that, a native window/pixmap usually has different structures in the server and in the clients. There is no EGLNativeWindowType that can be passed to eglCreateWindowSurface in both the server and the clients. Android's approach to the problem is to define EGLNativeWindowType and EGLNativePixmapType as two interfaces. The server wraps the fb device in EGLNativeWindowType interface and creates an EGLSurface for it. Everything on screen is composited through OpenGL ES. The clients can also wrap its window drawble in the same interface to create an EGLSurface for 3D rendering. For texture-from-pixmap, Android uses the EGLImage extensions. An EGLImage can be created from native pixmaps, texture objects, renderbuffers, or VGImage. Once created, the EGLImage can be used as texture images, renderbuffer storage, or VGImage. It allows pixel sharing between the display server and rendering APIs. OpenMax even allows its video frames to be used as EGLImage for composited hardware video decoding. When Mesa gains EGLImage support (hopefully, two or three months away), I do think the GEM objects may be passed to EGL to create EGLImages. For your usage, for example, GL_OES_EGL_image may then be used to turn EGLImages to renderbuffers. -olv -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Event-based buffer validation for DRI2.
Kristian Høgsberg k...@bitplanet.net writes: On Sun, Jan 17, 2010 at 11:18 PM, Francisco Jerez curroje...@riseup.net wrote: Kristian Høgsberg k...@bitplanet.net 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 in the X server. Then, instead of an invalidate event and a subsequent DRI2GetBuffers, we'll just have a here are your new buffers event, so we avoid the round trip. Yeah that's sensible, the only problem I see with doing things that way is that it doesn't give the driver an opportunity to flush its rendering queues before swapping buffers, so some of it could be lost buried in the old buffers. Right. Another option is to tell the client about new buffers in the DRI2SwapBuffer/DRI2CopyRegion reply instead - or to kill two birds with one stone, make DRI2SwapBuffers/DRI2CopyRegion one-way requests (that is, requests without a reply) and then send an event instead. This lets the client do other things while waiting for the server to reply, and we'll wait for the event to arrive in the GetBuffers callback from the driver if it hasn't already. The event will always be sent in response to either DRI2SwapBuffer or DRI2CopyRegion, which addresses your concern about sending the event to everybody. The client must wait for the event before it starts rendering the next frame since it could receive new buffers and in any case the server needs to submit the back-front blit first (which is the reason DRI2CopyRegion is a round-trip). That last proposal has a clear advantage: it needs *zero* protocol changes: It could be implemented sending SwapBuffers and GetBuffers in one go, without waiting for the responses. Instead we handle them asynchronously with some async handlers. If it hasn't arrived yet by the time we start drawing again, we XSync(). However, IMHO, we still want a DRI2InvalidateBuffers-like event, because: * That solution wouldn't make event-driven GL applications very happy, the succession of events could be something like: 1/ A frame is drawn, the app flushes and then it waits for events. 2/ We get the GetBuffers reply and install our new buffers. 3/ The user attempts a resize and the application reacts redrawing the exposed areas... Helplessly, because we're still on the pre-resize buffers, and they aren't big enough to hold it. * It breaks up when there are several contexts bound to the same drawable, because only the one calling SwapBuffers gets buffer updates. As I see it, forcing a buffer update on each flush or not, asynchronously or not, is somewhat orthogonal with having the server send buffer invalidation events to clients, and we probably want both eventually. That would be the ideal solution as far as I know, and if we're changing things, this is what we should go for. cheers, Kristian pgpDvgpvNYBtf.pgp Description: PGP signature -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Inter-StateTracker communication
Chia-I Wu olva...@gmail.com writes: On Tue, Jan 19, 2010 at 2:40 AM, Brian Paul bri...@vmware.com 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 resize happened and it did not call glViewport. Right? Are you talking about a specific driver, or in general? In general, it depends on how rendering finds its way to the buffer. If rendering to a surface goes through some kind of handle, reallocating the buffer doesn't change the handle so renering should go to the new buffer. What I had in mind was all DRI2 drivers. I doubt that the handles point to the new buffers automatically, but I am not 100% sure. Yeah, the handles keep pointing to the old buffers until the X server is asked to allocate the new ones, with DRI2GetBuffers. So, if the glViewport() hack happened to fail for a given application, it would never be able to draw outside the subwindow it originally took up. In that case, we need to call DRI2GetBuffers in buffer swap (for back rendering) or flush frontbuffer (for front rendering), and copy the contents of the old buffer to the new one at a suitable position. Off-hand I'm not sure what happens with DRI2. I could try to look later when I get some time. Anyone else know? But in the example I alluded to, my app would detect the resize (probably a ConfigureNotify event) and draw a new image and still not call glViewport(). Remember that glViewport() _only_ specifies an X/Y transformation of vertex coords from NDC to window space. It says nothing about the window size or clipping or anything like that. Yes, this is what I thought what it should be from the application's point of view. It seems to me that some heuristics are assumed in DRI2 drivers because of performance concern. I think the DRI2 patches Francisco Jerez sent yesterday can solve the issue. (CCed Francisco so that he could provide some insights) Right, that's what I meant to do. -olv pgpORCVA1dExO.pgp Description: PGP signature -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
