Re: Initial DRI3000 protocol specs available
On 03/07/2013 05:17 PM, Keith Packard wrote:
* PGP Signed by an unknown key
James Jones jajo...@nvidia.com writes:
There didn't seem to be much interest outside of NVIDIA, so
besides fence sync, the ideas are tabled internally ATM.
This shouldn't surprise you though -- no-one else needs this kind of
synchronization, so it's really hard for anyone to evaluate it. And,
DRI2 offers 'sufficient' support for the various GL sync extensions.
I was referring to the multi-buffer/tear-free presentation part, not the
synchronization parts. I still rather surprised everyone thinks
implicit synchronization is a good idea though. I don't think we're the
only ones that have loosely defined command buffer processing in HW
anymore. Meh.
So, what I'd like to know is if you think nVidia could take advantage of
the Swap extension so that nVidia 3D applications could do the whole
Swap redirect plan? If so, then I'm a lot more interested in figuring
out how we can get apps using the necessary fencing to actually make it
work right.
Sorry, I've been ignoring this thread because of the DRI3000 title, so I
missed the point where it defined a generic swap mechanism in X
protocol. From my reading, applications do roughly this in the spec:
Pixmap pix[N] = MakeListOfPixmaps(N)
Window win = MakeWindow();
int n = 0;
while (1) {
// Stuff here to ensure pix[n] is idle.
Render(pix[n]);
SwapRegion(win, pix[n]);
}
I think I saw in one branch of the thread that you might allow
redirecting the swap request out to a composite manager rather than
processing in X.
Basically that's what I proposed (and Aaron presented some of at XDC) a
few years ago and got no feedback. However, my full proposal included:
-setting the list of pixmaps associated with a window up front, so that
the composite manager or GL applications could query them and do work
once to bind them in to GL. This is pretty expensive. With your
proposal, this could probably be done lazily and tracked in a cache-type
thing, but if applications wanted to be dumb and generate a new pixmap
for every frame, nothing is stopping them. Applications would do
something like:
Pixmap pix[N]
XCreateWindowPixmaps(win, N, pix /* out */);
up front, and composite managers would get an event notifying them that
win now has those N pixmaps associated with it. Swaps would be done
by indexing into that array rather than sending the actual pixmap ID.
-Using sync object lists in place of all the hard-coded timing
information. We've never been a fan of the OML style swap timing
semantics. It doesn't line up well with our HW. Why not allow
arbitrary fence objects to dictate when the swapping occurs? Then apps
that just want a simple vsync can just send a vsync fence. Apps that
want exact timing can query what types of counters are available and get
exact timing on different HW that supports different timers.
-I had a bunch of GLX proposals to solve that mess.
-Redirecting present operations (or swaps) to the composite manager
was central to the proposal.
It looks like a lot of the details and psuedo-code didn't make it in the
final public presentation, just a high-level overview. I'll see if I
can dig up more of that. Here's the URL to the presentation. Just skip
all the fence sync parts.
http://people.freedesktop.org/~aplattner/x-presentation-and-synchronization.pdf
Thanks,
-James
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Initial DRI3000 protocol specs available
Hi, On 7 March 2013 17:17, Keith Packard kei...@keithp.com wrote: James Jones jajo...@nvidia.com writes: There didn't seem to be much interest outside of NVIDIA, so besides fence sync, the ideas are tabled internally ATM. This shouldn't surprise you though -- no-one else needs this kind of synchronization, so it's really hard for anyone to evaluate it. And, DRI2 offers 'sufficient' support for the various GL sync extensions. At least for TEXTURE_2D, sure. TEXTURE_EXTERNAL still requires synchronisation (i.e. fences) beyond 'just smash some commands at the kernel and flush on context switches and we're all good'. Cheers, Daniel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
RE: how to reduce X building time?
Hi peter, After reading your reply, I also googled about the autoresume. It seems that it works like this:In the 1st time, I entered ./util/modular/build.sh --autoresum a.txt /usr, after it failed building,I did some modification, then reenter the ./util/modular/build.sh --autoresum a.txt /usr , it shouldresume from the previously failed component. I hope my understanding is right. Date: Fri, 8 Mar 2013 09:41:22 +1000 From: peter.hutte...@who-t.net To: wolfking2...@msn.com CC: xorg-devel@lists.x.org Subject: Re: how to reduce X building time? On Thu, Mar 07, 2013 at 06:32:23AM +, wolfking wrote: hi, all: I'm building the X on my PowerPC platform and have a problem: Everytime when I use the build.sh scricpt to build the X, the build.sh restart from thebeginning to compile, it wastes a lot of time to rebuild the components that it builtin the previous building process. I remember in the previous version of build.sh, I canuse the -r option to specify the component from where to begin building. But in current version of build.sh, this option is ignored, instead it provides -o option, and it onlycompiles the specified component, and ignores the followed components. Can someone tell mehow to reduce the building time? use --autoresume instead of -r Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] [xorg-dev][xserver] Full support of sRGB capable fbconfigs.
On 01/09/2013 05:46 AM, Tomasz Lis wrote:
From: Tomasz Lis tomasz@intel.com
Changes to correctly initialize the sRGB capability attribute and
transfer it between XServer and the client. Modifications include
extension string, transferring visual config attribs and fbconfig
attribs. Also, attribute is initialized in the modules which do not
really use it (xquartz and xwin).
This version advertises both ARB and EXT strings, and initializes
the capability to default value of FALSE. It has corrected required
GLX version and does not influence swrast. The sRGB capable attribute
is attached only to those configs which do have this capability.
Signed-off-by: Tomasz Lis tomasz@intel.com
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
---
glx/extension_string.c|2 ++
glx/extension_string.h|2 ++
glx/glxcmds.c | 26 ++
glx/glxdri2.c |7 +++
glx/glxdricommon.c|4 +++-
glx/glxscreens.h |3 +++
hw/xquartz/GL/visualConfigs.c |3 +++
hw/xwin/glx/indirect.c|2 ++
8 files changed, 44 insertions(+), 5 deletions(-)
diff --git a/glx/extension_string.c b/glx/extension_string.c
index 544ca1f..58f930f 100644
--- a/glx/extension_string.c
+++ b/glx/extension_string.c
@@ -71,9 +71,11 @@ static const struct extension_info known_glx_extensions[] = {
{ GLX(ARB_create_context), VER(0,0), N, },
{ GLX(ARB_create_context_profile), VER(0,0), N, },
{ GLX(ARB_create_context_robustness), VER(0,0), N, },
+{ GLX(ARB_framebuffer_sRGB),VER(0,0), N, },
{ GLX(ARB_multisample), VER(1,4), Y, },
{ GLX(EXT_create_context_es2_profile), VER(0,0), N, },
+{ GLX(EXT_framebuffer_sRGB),VER(0,0), N, },
{ GLX(EXT_import_context), VER(0,0), Y, },
{ GLX(EXT_texture_from_pixmap), VER(0,0), Y, },
{ GLX(EXT_visual_info), VER(0,0), Y, },
diff --git a/glx/extension_string.h b/glx/extension_string.h
index 7a4a8b1..3ce5593 100644
--- a/glx/extension_string.h
+++ b/glx/extension_string.h
@@ -39,8 +39,10 @@ enum {
ARB_create_context_bit = 0,
ARB_create_context_profile_bit,
ARB_create_context_robustness_bit,
+ARB_framebuffer_sRGB_bit,
ARB_multisample_bit,
EXT_create_context_es2_profile_bit,
+EXT_framebuffer_sRGB_bit,
EXT_import_context_bit,
EXT_texture_from_pixmap_bit,
EXT_visual_info_bit,
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index c1f4e22..5b7a628 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -913,7 +913,7 @@ __glXDisp_CopyContext(__GLXclientState * cl, GLbyte * pc)
enum {
GLX_VIS_CONFIG_UNPAIRED = 18,
-GLX_VIS_CONFIG_PAIRED = 20
+GLX_VIS_CONFIG_PAIRED = 22
};
enum {
@@ -1005,8 +1005,17 @@ __glXDisp_GetVisualConfigs(__GLXclientState * cl, GLbyte
* pc)
buf[p++] = modes-samples;
buf[p++] = GLX_SAMPLE_BUFFERS_SGIS;
buf[p++] = modes-sampleBuffers;
-buf[p++] = 0; /* copy over visualSelectGroup
(GLX_VISUAL_SELECT_GROUP_SGIX)? */
-buf[p++] = 0;
+/* Add attribute only if its value is not default. */
+if (modes-sRGBCapable != GL_FALSE) {
+buf[p++] = GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT;
+buf[p++] = modes-sRGBCapable;
+}
+/* Don't add visualSelectGroup (GLX_VISUAL_SELECT_GROUP_SGIX)?
+ * Pad the remaining place with zeroes, so that attributes count is
constant. */
+while (p GLX_VIS_CONFIG_TOTAL) {
+buf[p++] = 0;
+buf[p++] = 0;
+}
assert(p == GLX_VIS_CONFIG_TOTAL);
if (client-swapped) {
@@ -1017,7 +1026,7 @@ __glXDisp_GetVisualConfigs(__GLXclientState * cl, GLbyte
* pc)
return Success;
}
-#define __GLX_TOTAL_FBCONFIG_ATTRIBS (36)
+#define __GLX_TOTAL_FBCONFIG_ATTRIBS (37)
#define __GLX_FBCONFIG_ATTRIBS_LENGTH (__GLX_TOTAL_FBCONFIG_ATTRIBS * 2)
/**
* Send the set of GLXFBConfigs to the client. There is not currently
@@ -1109,6 +1118,15 @@ DoGetFBConfigs(__GLXclientState * cl, unsigned screen)
WRITE_PAIR(GLX_BIND_TO_MIPMAP_TEXTURE_EXT,
modes-bindToMipmapTexture);
WRITE_PAIR(GLX_BIND_TO_TEXTURE_TARGETS_EXT,
modes-bindToTextureTargets);
+/* Add attribute only if its value is not default. */
+if (modes-sRGBCapable != GL_FALSE) {
+WRITE_PAIR(GLX_FRAMEBUFFER_SRGB_CAPABLE_EXT, modes-sRGBCapable);
+}
+/* Pad the remaining place with zeroes, so that attributes count is
constant. */
+while (p __GLX_FBCONFIG_ATTRIBS_LENGTH) {
+WRITE_PAIR(0, 0);
+}
+assert(p == __GLX_FBCONFIG_ATTRIBS_LENGTH);
if (client-swapped) {
__GLX_SWAP_INT_ARRAY(buf, __GLX_FBCONFIG_ATTRIBS_LENGTH);
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index bce1bfa..ef7afb4 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
Re: Initial DRI3000 protocol specs available
On Fri, Mar 8, 2013 at 3:59 AM, James Jones jajo...@nvidia.com wrote: On 03/07/2013 05:17 PM, Keith Packard wrote: * PGP Signed by an unknown key James Jones jajo...@nvidia.com writes: There didn't seem to be much interest outside of NVIDIA, so besides fence sync, the ideas are tabled internally ATM. This shouldn't surprise you though -- no-one else needs this kind of synchronization, so it's really hard for anyone to evaluate it. And, DRI2 offers 'sufficient' support for the various GL sync extensions. I was referring to the multi-buffer/tear-free presentation part, not the synchronization parts. I still rather surprised everyone thinks implicit synchronization is a good idea though. I don't think we're the only ones that have loosely defined command buffer processing in HW anymore. Meh. It's not that other hw don't have that (or even other drivers for your hw, ie nouveau). Serializing through the kernel execution manager lets the kernel know the the expected order of rendering. If rendering in hw queue A depends on a result from a hw queue B (B renders to buffer, A textures from same buffer), the kernel can insert synchronization primitives to ensure that the A queue doesn't proceed before the B queue signals the fence. If A and B queues don't have any inter-dependencies, no synchronization is necessary and they can run in parallel or out of order. Kristian ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: how to reduce X building time?
On 8/03/13 23:33 , wolfking wrote: Hi peter, After reading your reply, I also googled about the autoresume. It seems that it works like this: In the 1st time, I entered ./util/modular/build.sh --autoresum a.txt /usr, after it failed building, I did some modification, then reenter the ./util/modular/build.sh --autoresum a.txt /usr , it should resume from the previously failed component. I hope my understanding is right. That's correct. --autoresume writes the list of modules into the file provided (a.txt in your case) and will pick up from there again Cheers, Peter Date: Fri, 8 Mar 2013 09:41:22 +1000 From: peter.hutte...@who-t.net To: wolfking2...@msn.com CC: xorg-devel@lists.x.org Subject: Re: how to reduce X building time? On Thu, Mar 07, 2013 at 06:32:23AM +, wolfking wrote: hi, all: I'm building the X on my PowerPC platform and have a problem: Everytime when I use the build.sh scricpt to build the X, the build.sh restart from thebeginning to compile, it wastes a lot of time to rebuild the components that it builtin the previous building process. I remember in the previous version of build.sh, I canuse the -r option to specify the component from where to begin building. But in current version of build.sh, this option is ignored, instead it provides -o option, and it onlycompiles the specified component, and ignores the followed components. Can someone tell mehow to reduce the building time? use --autoresume instead of -r Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11 1/2] nls/Makefile.am: Remove unneeded $(srcdir)
On 01/15/13 05:02 PM, Gaetan Nadon wrote: On 13-01-15 04:07 PM, Quentin Glidic wrote: Signed-off-by: Quentin Glidic sardemff7+...@sardemff7.net --- nls/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nls/Makefile.am b/nls/Makefile.am index 0eced4c..bef2d2b 100644 --- a/nls/Makefile.am +++ b/nls/Makefile.am @@ -38,7 +38,7 @@ locale.dir: locale.dir.pre if HAVE_PERL TESTS_ENVIRONMENT = $(PERL) -TESTS = $(srcdir)/compose-check.pl +TESTS = compose-check.pl endif HAVE_PERL Works with Automake 1.11. The check script code tests for the presence of the perl script and appends srcdir if needed. Only when we run a script manually in the makefile do we need to specify srcdir to support out-of-source build tree. Reviewed-by: Gaetan Nadonmems...@videotron.ca Okay, pushed both patches to libX11 master git repo now. Thanks for the fixes. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] MakeBigReq: don't move the last word, already handled by Data32
On 02/17/13 05:25 PM, Peter Hutterer wrote: From: Karl Tomlinson xm...@karlt.net MakeBigReq inserts a length field after the first 4 bytes of the request (after req-length), pushing everything else back by 4 bytes. The current memmove moves everything but the first 4 bytes back. If a request aligns to the end of the buffer pointer when MakeBigReq is invoked for that request, this runs over the buffer. Instead, we need to memmove minus the first 4 bytes (which aren't moved), minus the last 4 bytes (so we still align to the previous tail). The 4 bytes that fell out are already handled with Data32, which will handle the buffermax correctly. The case where req-length = 1 was already not functional. Reported by Abhishek Arya infe...@chromium.org. https://bugzilla.mozilla.org/show_bug.cgi?id=803762 Reviewed-by: Jeff Muizelaar jmuizel...@mozilla.com Reviewed-by: Peter Hutterer peter.hutte...@who-t.net Fixed the patch to still apply after my WORD64 removal deleted one of the clauses you were updating and pushed to git master. Thanks for the fix. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
