Re: [Mesa3d-dev] Correct behavior of GL_DYNAMIC_DRAW in glBufferData?
Zou, Nanhai nanhai@intel.com writes: Hi, I have notice that in current driver implementation. When GL_DYNAMIC_DRAW flag is set in glBufferData, driver will not upload data to Graphics memory. Instead it will upload the _entire_ vertex/index buffer when glDrawElements/glDrawArray was called. We ripped out that awful code because it was hurting others, too. pgpTVz0lVoRsS.pgp Description: PGP signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] intel: Fix emit_linear_blit to use DWORD aligned width blits
On Sat, 06 Nov 2010 09:23:06 +, Peter Clifton pc...@cam.ac.uk wrote: Fixes corruption with glBufferSubData on my machine, Can someone review and push? Looks good. Thanks! pgpQalh4TlIgQ.pgp Description: PGP signature -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos
On Sun, 28 Mar 2010 17:52:16 -0400, RALOVICH, Kristóf kristof.ralov...@gmail.com wrote: Eric, please see the attached patch for piglit. The patch includes 2 new tests based on the demos I provided for mesa. Let me know if I can further help! The main thing I'm concerned about is that you seem to be looking for pixel-precise results. Do you expect that from this code? Generally in piglit we try to construct some environment that gets a few consistent results and probe a few representative pixels out of it. Beyond that, since you didn't use git send-email, the patch came out mangled and I couldn't apply it to try it out. pgpAc97XH7nTv.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] demos: import GLSL raytracing demos
On Wed, 24 Mar 2010 11:10:47 -0400, RALOVICH, Kristóf kristof.ralov...@gmail.com wrote: Brian, that was fast! Who do you think I should bug, to get these working on i965? Also as my time allows, I am planning to extend them with mouse input for orientation and arrow keys for moving to camera to become more interactive. Make a testcase for piglit, and I'd love to fix your bug. pgpmENl5jrS2e.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Separate demos repository
People that hang out on IRC have probably heard about my build system work. One of the first steps I've been working on finishing is splitting out the demos repository. We're currently distributing the Mesa progs/ separately from the main Mesa distribution, and most people aren't installing it, so from a distribution perspective it doesn't make sense to be in the same repository. On the other hand, for driver developers that are having to make clean on a regular basis, wiping out the programs (if you even use them) doesn't help since the programs aren't really changing. And if they are, when you're bisecting around trying an app, you don't want the app changing at the same time. So, I've made a branch in my Mesa repository for a split of the progs/ From Mesa. git://people.freedesktop.org/~anholt/mesa on the mesa-demos branch Open issues: Right now they don't install in general, but it would be easy to change if people are interested in a package that does. I've tested a bunch of them in tree and they seem fine. I've only tested the build on Linux with GL. The GLES stuff needs to get hooked up (I don't see a GLES implementation to test against or I would have). I don't know what to do about the progs/gallium. progs/gallium/unit looks like it should probably live in the Mesa tree next to the code that it's unit testing. progs/gallium/python/ though? None of the GLEW or GLUT is brought along with the apps. It looks to me like all OSes should have libGLEW and libfreeglut reasonably available. I'm not sure if we want the repository to contain all of previous Mesa history. Right now that history costs 145MB on disk for a deep checkout. If that's a problem for people, we could use the same tool that xcb did whose name I forget to to construct a history of just progs/ Where to go from here: If there isn't violent objection to this, I want to get this into place in /git/mesa/demos in a couple of weeks, and then remove those components from the main Mesa repository, plus the things that are only in there because progs depend on them (GLUT, GLEW). pgpLJ5BteCBjY.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] i965 shader regression [bisected]
On Sat, 13 Mar 2010 16:52:36 +0200, Maxim Levitsky maximlevit...@gmail.com wrote: This time I caught it early. 46450c1f3f93bf4dc96696fc7e0f0eb808d9c08a is first bad commit commit 46450c1f3f93bf4dc96696fc7e0f0eb808d9c08a Author: Eric Anholt e...@anholt.net Date: Wed Mar 10 17:38:33 2010 -0800 i965: Do FS SLT, SGT, and friends using CMP, SEL instead of CMP, MOV, MOV. :04 04 d6abcec74652e20faf81feac8486cfb8ef979494 d5b5c11b472e463525965d9673c0170b0eb206f1 Msrc (Revert helps restore correct behaviour) This breaks several shaders in my examples folder, that I downloaded from GLSL tutorial site. (http://www.lighthouse3d.com/opengl/glsl/) Please submit bug reports so I can't lose information like this! pgpexJZUTf6LE.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): intel: Remove the unused s8 spans code. Not hit during no_rast piglit.
On Mon, 08 Mar 2010 14:50:45 -0800, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt wrote: Module: Mesa Branch: master Commit: 7cbc4c07ee85782d5da3e2db3c4e072ca498ff07 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=7cbc4c07ee85782d5da3e2db3c4e072ca498ff07 Author: Eric Anholt e...@anholt.net Date: Thu Mar 4 15:33:21 2010 -0800 intel: Remove the unused s8 spans code. Not hit during no_rast piglit. Shaves 5.5k off of the driver. Do any of the piglit tests actually try using stencil without depth? It's an uncommon case, and it seems like it's the only way to hit this path. You mean as an FBO setup? That would be flagged as unsupported. pgp0v7REtpL2v.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. sf.net's mail interface is made of fail. Here's to changing to something credible. pgpL7T6euiQWh.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa removals
On Mon, 22 Feb 2010 08:38:49 -0800, Brian Paul bri...@vmware.com wrote: Starting a new thread on this... Here's a proposal of things to remove from the Mesa tree. GLU: glu/mini glu/mesa GLUT: glut/fbdev glut/ggi glut/directfb glut/dos glut/mini glut/os2 non-DRI drivers: drivers/allegro drivers/directfb drivers/d3d drivers/dos drivers/ggi drivers/glide drivers/svga DRI drivers: drivers/dri/fb drivers/dri/ffb drivers/dri/gamma progs/directfb progs/ggi progs/windml progs/miniglx Comments? Yes! pgpDUzbRyRC4M.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] piglit statistics of swrast, softpipe, r300c, and r300g
On Wed, 10 Feb 2010 21:50:14 +0100, Marek Olšák mar...@gmail.com wrote: Hi, I noticed that quite a lot of piglit tests fail with swrast and softpipe. I was asked for sending my stats to ML so that people working on the software rasterizers are aware of that (I guess they already know). Please see this page: http://storm.unas.cz/drivers_compared/ The parser tests and some pretty long tests are not included. The ratio pass/all is highest for r300c and lowest for more feature-rich r300g but swrast is worse than softpipe which is a shame. Tested with git master on 6th February 2010. r300g stats are the only ones not tested with pure git master but with my own additional patches in my private (localhost) repo. On my system, swrast fails a lot because it exposes ARGB visuals on a depth 24 buffer, which means the alpha bits get dropped when putimaging them to X. It seems like we need to fix up its visuals list to not do that. pgpgtLGEvdpB6.pgp Description: PGP signature -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6] piglit relax precision requirements
On Thu, 11 Feb 2010 01:54:37 +0100, Marek Olšák mar...@gmail.com wrote: Eric, yes, it does. I decided to resolve my precision issues using glDisable(GL_DITHER). The two patches disable dithering, the former in piglit and the latter in glean. I see no point in separating them to smaller ones but I can do that if you like. Since it's tricky to test dithering anyway, disabling it is preferable. Could you please push the first one if there are no objections? OK, pushed the piglit side. pgpbioMrCHerw.pgp Description: PGP signature -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/6] piglit relax precision requirements
On Sun, 7 Feb 2010 05:38:01 +0100, Marek Olšák mar...@gmail.com wrote: The attached patch series relaxes precision requirements for 6 tests to pass on r300g. Please review/push. Have you tried getting the glean components pushed to the glean project? I'd rather not carry functional differences from glean where we don't have to. Intel has issues on the cubemap tests at 2x2 and lower as well. I'm wondering -- are closed drivers the same in this respect? pgpWROcuAPens.pgp Description: PGP signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Intel-gfx] [RFC] reduce number of visuals exposed by Intel drivers
On Fri, 05 Feb 2010 13:01:50 -0800, Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to remove a bunch of the visuals and fbconfigs exposed by the Intel drivers. There are several categories of visuals that are likely not useful to anyone. A couple of our test suites (e.g., glean) like to run over every possible visual. As a result, the test suites take an extraordinary amount of time to run. I propose removing: * All 24-bit depth / 0-bit stencil visuals. These are compatible with the default state of a 24-bit depth / 8-bit stencil visual and offer no memory savings. This will eliminate 24 (of 72) visuals by itself. * All but one of the visuals with accumulation buffer. Accumulation is a software path in the Intel drivers (though this could be fixed), so I don't see any utility in offering multiple, optimized buffer configuration choices. This will eliminate an additional 23 visuals. This will leave the 25 visuals and 37 fbconfigs that are likely to be useful. Yes! pgppHpbqQmR94.pgp Description: PGP signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] piglit/fbo-3d: Fix the texture to pot depth.
On Thu, 4 Feb 2010 04:26:19 +0200, Pauli Nieminen suok...@gmail.com wrote: fbo-3d was assuming npot texture support which caused glTexImage3D to fail with r200 driver. Applied. Thanks! pgpp9c3r2hDUh.pgp Description: PGP signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa_7_7_branch - master merges
On Mon, 25 Jan 2010 13:04:10 +, José Fonseca jfons...@vmware.com wrote: mesa_7_7_branch and master are becoming quite different, because of all the gallium interface changes that have been going into master, so merging fixes from mesa_7_7_branch into master is becoming less and less of a trivial exercise. This is aggravated by the fact we are basing a release from the mesa_7_7_branch, so it's likely that we'll need to have temporary non-invasive bugfixes that should not go into master (which should receive instead the proper and potentially invasive fix). I see a few alternatives here: a) stop merging mesa_7_7_branch - master. bugfixes should be applied to both branches. preferably by the person that wrote the patch. This, please. I still hate the merge stable - master plan, because it means that the drivers of people other than the one doing the merge gets broken. pgpMF7pS9IABe.pgp Description: PGP signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] condition always evaluates to false
On Tue, 05 Jan 2010 23:13:54 +0100, Roel Kluin roel.kl...@gmail.com wrote:
These can never be true.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
src/gallium/drivers/i965/brw_wm_emit.c |2 +-
src/mesa/drivers/dri/i915/intel_tris.c |2 +-
src/mesa/drivers/dri/i965/brw_wm_emit.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
see commit f67748038935e609aa85450b20d550b4813c9429 for
the change in src/mesa/drivers/dri/i915/intel_tris.c
diff --git a/src/gallium/drivers/i965/brw_wm_emit.c
b/src/gallium/drivers/i965/brw_wm_emit.c
index 7e57d03..7e35ee1 100644
--- a/src/gallium/drivers/i965/brw_wm_emit.c
+++ b/src/gallium/drivers/i965/brw_wm_emit.c
@@ -691,7 +691,7 @@ static void emit_xpd( struct brw_compile *p,
{
GLuint i;
- assert(!(mask BRW_WRITEMASK_W) == BRW_WRITEMASK_X);
+ assert((mask BRW_WRITEMASK_W) != BRW_WRITEMASK_X);
for (i = 0 ; i 3; i++) {
if (mask (1i)) {
diff --git a/src/mesa/drivers/dri/i915/intel_tris.c
b/src/mesa/drivers/dri/i915/intel_tris.c
index 63c5ae9..a182f68 100644
--- a/src/mesa/drivers/dri/i915/intel_tris.c
+++ b/src/mesa/drivers/dri/i915/intel_tris.c
@@ -221,7 +221,7 @@ void intel_flush_prim(struct intel_context *intel)
intel-prim.count = 0;
offset = intel-prim.start_offset;
intel-prim.start_offset = intel-prim.current_offset;
- if (!intel-gen = 3)
+ if (intel-gen 3)
intel-prim.start_offset = ALIGN(intel-prim.start_offset, 128);
intel-prim.flush = NULL;
diff --git a/src/mesa/drivers/dri/i965/brw_wm_emit.c
b/src/mesa/drivers/dri/i965/brw_wm_emit.c
index cc1052f..91ac37c 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_emit.c
@@ -692,7 +692,7 @@ void emit_xpd(struct brw_compile *p,
{
GLuint i;
- assert(!(mask WRITEMASK_W) == WRITEMASK_X);
+ assert((mask WRITEMASK_W) != WRITEMASK_X);
I think this one actually meant:
assert(!(mask WRITEMASK_W));
The other fix looks good though.
pgpTWyc8Izkm7.pgp
Description: PGP signature
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Fix Viewport in _mesa_meta_GenerateMipmap
On Wed, 06 Jan 2010 23:30:46 +0100, Pierre Willenbrock pie...@pirsoft.de wrote: Hi list, the first of these two patches fixes _mesa_meta_GenerateMipmap to update the viewport and projection matrix after changing the destination mipmap level. Before, pixels would get clipped to the boundaries of the original DrawBuffer, which may be smaller than the second mipmap level. The second patch just pulls projection matrix and vertex array setup out of the main loop. The other way to fix this i can think of is to disable clipping to viewport. I could not figure out if that is even possible. Tested with swrast and i965. Pushed a testcase for this into piglit. pgpozsg4H6Ygi.pgp Description: PGP signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Piglit patch
On Sat, 12 Dec 2009 01:27:52 +0100, Maciej Cencora m.cenc...@gmail.com wrote: Dnia sobota, 21 listopada 2009 o 20:41:34 Maciej Cencora napisał(a): Hi, attached patch fixes texturing/s3tc-texsubimage test. It passes now on software rasterizer. R300 needs ~2% tolerance to pass. Regards, Maciej Cencora Any reason this patch hasn't been applied yet? Cheers, Maciej I tried it, and the software rastrization looked obviously wrong but was passing, so I shoved it into a branch and forgot about it. Does it look correct to you on r300? the test should probably be changed to check the whole drawing, not just one pixel from each quadrant of the texture. pgp6UDwsRu0YW.pgp Description: PGP signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 3/3] intel: Enable OES_read_format to encourage hitting the PBO accel readpixels.
On Tue, 08 Dec 2009 23:38:22 -0800, Ian Romanick i...@freedesktop.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
---
src/mesa/drivers/dri/intel/intel_buffers.c| 21 +
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c
b/src/mesa/drivers/dri/intel/intel_buffers.c
index 6b12d48..cee5cf6 100644
--- a/src/mesa/drivers/dri/intel/intel_buffers.c
+++ b/src/mesa/drivers/dri/intel/intel_buffers.c
@@ -362,6 +362,8 @@ intelDrawBuffer(GLcontext * ctx, GLenum mode)
static void
intelReadBuffer(GLcontext * ctx, GLenum mode)
{
+ struct intel_renderbuffer *irb;
+
if ((ctx-DrawBuffer != NULL) (ctx-DrawBuffer-Name == 0)) {
struct intel_context *const intel = intel_context(ctx);
const GLboolean was_front_buffer_reading =
@@ -390,6 +392,25 @@ intelReadBuffer(GLcontext * ctx, GLenum mode)
/* Generally, functions which read pixels (glReadPixels, glCopyPixels,
etc)
* reference ctx-ReadBuffer and do appropriate state checks.
*/
+
+ /* GL_OES_read_format */
+ irb = intel_renderbuffer(ctx-ReadBuffer-_ColorReadBuffer);
+ if (irb) {
+ switch (irb-texformat) {
+ case MESA_FORMAT_ARGB:
+ctx-ReadBuffer-ColorReadFormat = GL_BGRA;
+ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_BYTE;
+break;
+ case MESA_FORMAT_RGB565:
+ctx-ReadBuffer-ColorReadFormat = GL_BGR;
+ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_SHORT_5_6_5_REV;
+break;
+ default:
+ctx-ReadBuffer-ColorReadFormat = GL_RGBA;
+ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_BYTE;
+break;
+ }
+ }
After hacking around with FBOs and MESA_FORMAT_* all day long (my patch
series is coming soon!), I think this should go in a utility function
somewhere... perhaps in fbobject.c. For a given format, I *think* the
preferred read format / type will be the same everywhere. Does that
sound right?
So, for our driver right now we do blits for those two formats. For
others, the spans code will read them out into DataType's format, and if
we report something other than that (usually ABGR), we'll hit the
user with an extra conversion.
But maybe the right answer is to report the native format and say that
if going native - native is slower than native - abgr, then that
should get fixed.
The other question I had was whether a computed value like this really
deserves to live as a field updated with state changes instead of being
computed at Get time. The overall Mesa style seems to be compute it up
front just in case someone asks, but that doesn't seem like a great way
to get an efficient stack.
pgpG0J4ZEZRZX.pgp
Description: PGP signature
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 3/3] intel: Enable OES_read_format to encourage hitting the PBO accel readpixels.
On Wed, 09 Dec 2009 08:19:11 -0700, Brian Paul bri...@vmware.com wrote:
Eric Anholt wrote:
On Tue, 08 Dec 2009 23:38:22 -0800, Ian Romanick i...@freedesktop.org
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
---
src/mesa/drivers/dri/intel/intel_buffers.c| 21
+
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c
b/src/mesa/drivers/dri/intel/intel_buffers.c
index 6b12d48..cee5cf6 100644
--- a/src/mesa/drivers/dri/intel/intel_buffers.c
+++ b/src/mesa/drivers/dri/intel/intel_buffers.c
@@ -362,6 +362,8 @@ intelDrawBuffer(GLcontext * ctx, GLenum mode)
static void
intelReadBuffer(GLcontext * ctx, GLenum mode)
{
+ struct intel_renderbuffer *irb;
+
if ((ctx-DrawBuffer != NULL) (ctx-DrawBuffer-Name == 0)) {
struct intel_context *const intel = intel_context(ctx);
const GLboolean was_front_buffer_reading =
@@ -390,6 +392,25 @@ intelReadBuffer(GLcontext * ctx, GLenum mode)
/* Generally, functions which read pixels (glReadPixels,
glCopyPixels, etc)
* reference ctx-ReadBuffer and do appropriate state checks.
*/
+
+ /* GL_OES_read_format */
+ irb = intel_renderbuffer(ctx-ReadBuffer-_ColorReadBuffer);
+ if (irb) {
+ switch (irb-texformat) {
+ case MESA_FORMAT_ARGB:
+ ctx-ReadBuffer-ColorReadFormat = GL_BGRA;
+ ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_BYTE;
+ break;
+ case MESA_FORMAT_RGB565:
+ ctx-ReadBuffer-ColorReadFormat = GL_BGR;
+ ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_SHORT_5_6_5_REV;
+ break;
+ default:
+ ctx-ReadBuffer-ColorReadFormat = GL_RGBA;
+ ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_BYTE;
+ break;
+ }
+ }
After hacking around with FBOs and MESA_FORMAT_* all day long (my patch
series is coming soon!), I think this should go in a utility function
somewhere... perhaps in fbobject.c. For a given format, I *think* the
preferred read format / type will be the same everywhere. Does that
sound right?
I agree with that.
So, for our driver right now we do blits for those two formats. For
others, the spans code will read them out into DataType's format, and if
we report something other than that (usually ABGR), we'll hit the
user with an extra conversion.
But maybe the right answer is to report the native format and say that
if going native - native is slower than native - abgr, then that
should get fixed.
The other question I had was whether a computed value like this really
deserves to live as a field updated with state changes instead of being
computed at Get time. The overall Mesa style seems to be compute it up
front just in case someone asks, but that doesn't seem like a great way
to get an efficient stack.
We tend to keep derived state (marked with leading _underscore) for
things that will be frequently accessed. I wouldn't do that for
glGet() state.
Yeah, rewrote it based on that. The patch came out even smaller.
pgp6v3gWTF3o3.pgp
Description: PGP signature
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 1/3] mesa: Move OES_read_format state from Const to framebuffer state.
The spec quite reasonably says it's dependent on the current read surface, so it doesn't look like a Const. --- src/mesa/main/context.c|4 src/mesa/main/framebuffer.c|5 + src/mesa/main/get.c| 16 src/mesa/main/get_gen.py |4 ++-- src/mesa/main/mtypes.h |6 +++--- src/mesa/state_tracker/st_cb_get.c |4 ++-- 6 files changed, 20 insertions(+), 19 deletions(-) diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c index 03fc57e..5c20ce0 100644 --- a/src/mesa/main/context.c +++ b/src/mesa/main/context.c @@ -564,10 +564,6 @@ _mesa_init_constants(GLcontext *ctx) /* GL_ARB_draw_buffers */ ctx-Const.MaxDrawBuffers = MAX_DRAW_BUFFERS; - /* GL_OES_read_format */ - ctx-Const.ColorReadFormat = GL_RGBA; - ctx-Const.ColorReadType = GL_UNSIGNED_BYTE; - #if FEATURE_EXT_framebuffer_object ctx-Const.MaxColorAttachments = MAX_COLOR_ATTACHMENTS; ctx-Const.MaxRenderbufferSize = MAX_WIDTH; diff --git a/src/mesa/main/framebuffer.c b/src/mesa/main/framebuffer.c index 154deda..c9b4290 100644 --- a/src/mesa/main/framebuffer.c +++ b/src/mesa/main/framebuffer.c @@ -159,6 +159,11 @@ _mesa_initialize_framebuffer(struct gl_framebuffer *fb, const GLvisual *visual) fb-_ColorReadBufferIndex = BUFFER_FRONT_LEFT; } + + /* GL_OES_read_format */ + fb-ColorReadFormat = GL_RGBA; + fb-ColorReadType = GL_UNSIGNED_BYTE; + fb-Delete = _mesa_destroy_framebuffer; fb-_Status = GL_FRAMEBUFFER_COMPLETE_EXT; diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c index e8932f8..8ddd3ae 100644 --- a/src/mesa/main/get.c +++ b/src/mesa/main/get.c @@ -1767,11 +1767,11 @@ _mesa_GetBooleanv( GLenum pname, GLboolean *params ) break; case GL_IMPLEMENTATION_COLOR_READ_TYPE_OES: CHECK_EXT1(OES_read_format, GetBooleanv); - params[0] = INT_TO_BOOLEAN(ctx-Const.ColorReadType); + params[0] = INT_TO_BOOLEAN(ctx-ReadBuffer-ColorReadType); break; case GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES: CHECK_EXT1(OES_read_format, GetBooleanv); - params[0] = INT_TO_BOOLEAN(ctx-Const.ColorReadFormat); + params[0] = INT_TO_BOOLEAN(ctx-ReadBuffer-ColorReadFormat); break; case GL_NUM_FRAGMENT_REGISTERS_ATI: CHECK_EXT1(ATI_fragment_shader, GetBooleanv); @@ -3602,11 +3602,11 @@ _mesa_GetFloatv( GLenum pname, GLfloat *params ) break; case GL_IMPLEMENTATION_COLOR_READ_TYPE_OES: CHECK_EXT1(OES_read_format, GetFloatv); - params[0] = (GLfloat)(ctx-Const.ColorReadType); + params[0] = (GLfloat)(ctx-ReadBuffer-ColorReadType); break; case GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES: CHECK_EXT1(OES_read_format, GetFloatv); - params[0] = (GLfloat)(ctx-Const.ColorReadFormat); + params[0] = (GLfloat)(ctx-ReadBuffer-ColorReadFormat); break; case GL_NUM_FRAGMENT_REGISTERS_ATI: CHECK_EXT1(ATI_fragment_shader, GetFloatv); @@ -5437,11 +5437,11 @@ _mesa_GetIntegerv( GLenum pname, GLint *params ) break; case GL_IMPLEMENTATION_COLOR_READ_TYPE_OES: CHECK_EXT1(OES_read_format, GetIntegerv); - params[0] = ctx-Const.ColorReadType; + params[0] = ctx-ReadBuffer-ColorReadType; break; case GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES: CHECK_EXT1(OES_read_format, GetIntegerv); - params[0] = ctx-Const.ColorReadFormat; + params[0] = ctx-ReadBuffer-ColorReadFormat; break; case GL_NUM_FRAGMENT_REGISTERS_ATI: CHECK_EXT1(ATI_fragment_shader, GetIntegerv); @@ -7273,11 +7273,11 @@ _mesa_GetInteger64v( GLenum pname, GLint64 *params ) break; case GL_IMPLEMENTATION_COLOR_READ_TYPE_OES: CHECK_EXT1(OES_read_format, GetInteger64v); - params[0] = (GLint64)(ctx-Const.ColorReadType); + params[0] = (GLint64)(ctx-ReadBuffer-ColorReadType); break; case GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES: CHECK_EXT1(OES_read_format, GetInteger64v); - params[0] = (GLint64)(ctx-Const.ColorReadFormat); + params[0] = (GLint64)(ctx-ReadBuffer-ColorReadFormat); break; case GL_NUM_FRAGMENT_REGISTERS_ATI: CHECK_EXT1(ATI_fragment_shader, GetInteger64v); diff --git a/src/mesa/main/get_gen.py b/src/mesa/main/get_gen.py index a29962d..370e473 100644 --- a/src/mesa/main/get_gen.py +++ b/src/mesa/main/get_gen.py @@ -942,9 +942,9 @@ StateVars = [ # GL_OES_read_format ( GL_IMPLEMENTATION_COLOR_READ_TYPE_OES, GLint, - [ctx-Const.ColorReadType], , [OES_read_format] ), + [ctx-ReadBuffer-ColorReadType], , [OES_read_format] ), ( GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES, GLint, - [ctx-Const.ColorReadFormat], , [OES_read_format] ), + [ctx-ReadBuffer-ColorReadFormat], , [OES_read_format] ), #
[Mesa3d-dev] OES_read_format enabling
I'd like to get it either into this release or the point release after it -- giving people the tools to use OpenGL appropriately seems important. (idr noted that we don't need the extension enable in the driver, since it's always there) -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 2/3] st/mesa: Keep the renderbuffer preferred read format/type up to date.
This replaces the st_cb_get wrapper around glGet with using the FB's fields.
---
src/mesa/sources.mak|1 -
src/mesa/state_tracker/st_cb_fbo.c | 16 ++
src/mesa/state_tracker/st_cb_get.c | 97 ---
src/mesa/state_tracker/st_cb_get.h | 37 -
src/mesa/state_tracker/st_context.c |2 -
5 files changed, 16 insertions(+), 137 deletions(-)
delete mode 100644 src/mesa/state_tracker/st_cb_get.c
delete mode 100644 src/mesa/state_tracker/st_cb_get.h
diff --git a/src/mesa/sources.mak b/src/mesa/sources.mak
index 615a558..a0d7dbb 100644
--- a/src/mesa/sources.mak
+++ b/src/mesa/sources.mak
@@ -191,7 +191,6 @@ STATETRACKER_SOURCES = \
state_tracker/st_cb_bufferobjects.c \
state_tracker/st_cb_clear.c \
state_tracker/st_cb_flush.c \
- state_tracker/st_cb_get.c \
state_tracker/st_cb_drawpixels.c \
state_tracker/st_cb_fbo.c \
state_tracker/st_cb_feedback.c \
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index ead8e22..72d1238 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -637,8 +637,24 @@ st_DrawBuffers(GLcontext *ctx, GLsizei count, const GLenum
*buffers)
static void
st_ReadBuffer(GLcontext *ctx, GLenum buffer)
{
+ struct st_renderbuffer *strb;
+
(void) buffer;
check_create_front_buffers(ctx, ctx-ReadBuffer);
+
+ strb = st_renderbuffer(ctx-ReadBuffer-_ColorReadBuffer);
+ if (strb) {
+ if (strb-format == PIPE_FORMAT_A8R8G8B8_UNORM) {
+ ctx-ReadBuffer-ColorReadFormat = GL_BGRA;
+ if (_mesa_little_endian())
+ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_INT_8_8_8_8_REV;
+ else
+ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_INT_8_8_8_8;
+ } else {
+ ctx-ReadBuffer-ColorReadFormat = GL_RGBA;
+ ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_BYTE;
+ }
+ }
}
diff --git a/src/mesa/state_tracker/st_cb_get.c
b/src/mesa/state_tracker/st_cb_get.c
deleted file mode 100644
index 54c4f5a..000
--- a/src/mesa/state_tracker/st_cb_get.c
+++ /dev/null
@@ -1,97 +0,0 @@
-/**
- *
- * Copyright 2008 Tungsten Graphics, Inc., Cedar Park, Texas.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the
- * Software), to deal in the Software without restriction, including
- * without limitation the rights to use, copy, modify, merge, publish,
- * distribute, sub license, and/or sell copies of the Software, and to
- * permit persons to whom the Software is furnished to do so, subject to
- * the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
- * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
- * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
- * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
- * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
- * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- **/
-
-
-/**
- * glGet functions
- *
- * \author Brian Paul
- */
-
-#include main/imports.h
-#include main/context.h
-
-#include pipe/p_defines.h
-
-#include st_cb_fbo.h
-#include st_cb_get.h
-
-
-
-/**
- * Examine the current color read buffer format to determine
- * which GL pixel format/type combo is the best match.
- */
-static void
-get_preferred_read_format_type(GLcontext *ctx, GLint *format, GLint *type)
-{
- struct gl_framebuffer *fb = ctx-ReadBuffer;
- struct st_renderbuffer *strb = st_renderbuffer(fb-_ColorReadBuffer);
-
- /* defaults */
- *format = ctx-ReadBuffer-ColorReadFormat;
- *type = ctx-ReadBuffer-ColorReadType;
-
- if (strb) {
- /* XXX could add more cases here... */
- if (strb-format == PIPE_FORMAT_A8R8G8B8_UNORM) {
- *format = GL_BGRA;
- if (_mesa_little_endian())
-*type = GL_UNSIGNED_INT_8_8_8_8_REV;
- else
-*type = GL_UNSIGNED_INT_8_8_8_8;
- }
- }
-}
-
-
-/**
- * We only intercept the OES preferred ReadPixels format/type.
- * Everything else goes to the default _mesa_GetIntegerv.
- */
-static GLboolean
-st_GetIntegerv(GLcontext *ctx, GLenum pname, GLint *params)
-{
- GLint dummy;
-
- switch (pname) {
- case GL_IMPLEMENTATION_COLOR_READ_TYPE_OES:
- get_preferred_read_format_type(ctx, dummy, params);
- return GL_TRUE;
- case GL_IMPLEMENTATION_COLOR_READ_FORMAT_OES:
-
[Mesa3d-dev] [PATCH 3/3] intel: Enable OES_read_format to encourage hitting the PBO accel readpixels.
---
src/mesa/drivers/dri/intel/intel_buffers.c| 21 +
src/mesa/drivers/dri/intel/intel_extensions.c |1 +
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c
b/src/mesa/drivers/dri/intel/intel_buffers.c
index 6b12d48..cee5cf6 100644
--- a/src/mesa/drivers/dri/intel/intel_buffers.c
+++ b/src/mesa/drivers/dri/intel/intel_buffers.c
@@ -362,6 +362,8 @@ intelDrawBuffer(GLcontext * ctx, GLenum mode)
static void
intelReadBuffer(GLcontext * ctx, GLenum mode)
{
+ struct intel_renderbuffer *irb;
+
if ((ctx-DrawBuffer != NULL) (ctx-DrawBuffer-Name == 0)) {
struct intel_context *const intel = intel_context(ctx);
const GLboolean was_front_buffer_reading =
@@ -390,6 +392,25 @@ intelReadBuffer(GLcontext * ctx, GLenum mode)
/* Generally, functions which read pixels (glReadPixels, glCopyPixels, etc)
* reference ctx-ReadBuffer and do appropriate state checks.
*/
+
+ /* GL_OES_read_format */
+ irb = intel_renderbuffer(ctx-ReadBuffer-_ColorReadBuffer);
+ if (irb) {
+ switch (irb-texformat) {
+ case MESA_FORMAT_ARGB:
+ctx-ReadBuffer-ColorReadFormat = GL_BGRA;
+ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_BYTE;
+break;
+ case MESA_FORMAT_RGB565:
+ctx-ReadBuffer-ColorReadFormat = GL_BGR;
+ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_SHORT_5_6_5_REV;
+break;
+ default:
+ctx-ReadBuffer-ColorReadFormat = GL_RGBA;
+ctx-ReadBuffer-ColorReadType = GL_UNSIGNED_BYTE;
+break;
+ }
+ }
}
diff --git a/src/mesa/drivers/dri/intel/intel_extensions.c
b/src/mesa/drivers/dri/intel/intel_extensions.c
index 86dc42c..b403bb5 100644
--- a/src/mesa/drivers/dri/intel/intel_extensions.c
+++ b/src/mesa/drivers/dri/intel/intel_extensions.c
@@ -126,6 +126,7 @@ static const struct dri_extension card_extensions[] = {
{ GL_NV_blend_square,NULL },
{ GL_NV_vertex_program, GL_NV_vertex_program_functions },
{ GL_NV_vertex_program1_1, NULL },
+ { GL_OES_read_format,NULL },
{ GL_SGIS_generate_mipmap, NULL },
{ NULL, NULL }
};
--
1.6.5.4
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): intel: Use GTT mapping when available for swrast.
On Fri, 2009-10-30 at 19:10 -0600, Brian Paul wrote: Eric Anholt wrote: Module: Mesa Branch: master Commit: 7c8bed62e0165a0be3363f7abf81bf9e30341e00 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=7c8bed62e0165a0be3363f7abf81bf9e30341e00 Author: Eric Anholt e...@anholt.net Date: Fri Oct 30 15:33:11 2009 -0700 intel: Use GTT mapping when available for swrast. This improves piglit quick.tests runtime from 19:33 minutes to 6:06 on my GM45. It should also hide most of the A17 swizzling issues, though they'll still exist when swapping occurs (which is the kernel's problem either way). Eric, I'm getting a bus error with this change (at least I think it's this commit). progs/demos/readpix (press 'f' to read from front color buffer). Works here. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Importing real strtod code
On Thu, 2009-10-08 at 16:32 -0600, Brian Paul wrote: Chris Rankin wrote: --- On Thu, 8/10/09, tom fogal tfo...@alumni.unh.edu wrote: What about char *lang = getenv(LANG); setenv(LANG, POSIX, 1); strtod(...); setenv(LANG, lang, 1); i.e. push / pop the LANG value? The neater way to implement that solution would be to use char *oldLocale = setlocale(LC_NUMERI-C, NULL); setlocale(LC_NUMERIC, C); strtod(...); setlocale(LC_NUMERIC, oldLocale); However, I suspect that there would be a nasty performance penalty for repeatedly switching the locale, as well as there being multi-threading considerations for other functions. I think that we could just bracket the call to _slang_compile() with the set/restore-locale calls. The thread-unsafety seems like a showstopper. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 1/2] Revert Flush driver, not just tnl module.
This reverts commit df058298e1570eea8712f9bb051f674fab2eaf24. It didn't
explain why it was required, doesnt appear to be required, and is a major
performance penalty for cairo-gl firefox.
Conflicts:
src/mesa/main/fbobject.c
---
src/mesa/main/fbobject.c | 26 --
1 files changed, 0 insertions(+), 26 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 680fd22..a73a765 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -718,12 +718,6 @@ _mesa_BindRenderbufferEXT(GLenum target, GLuint
renderbuffer)
}
FLUSH_CURRENT(ctx, _NEW_BUFFERS);
- /* The above doesn't fully flush the drivers in the way that a
-* glFlush does, but that is required here:
-*/
- if (ctx-Driver.Flush)
- ctx-Driver.Flush(ctx);
-
if (renderbuffer) {
newRb = _mesa_lookup_renderbuffer(ctx, renderbuffer);
@@ -1294,11 +1288,6 @@ _mesa_DeleteFramebuffersEXT(GLsizei n, const GLuint
*framebuffers)
ASSERT_OUTSIDE_BEGIN_END(ctx);
FLUSH_CURRENT(ctx, _NEW_BUFFERS);
- /* The above doesn't fully flush the drivers in the way that a
-* glFlush does, but that is required here:
-*/
- if (ctx-Driver.Flush)
- ctx-Driver.Flush(ctx);
for (i = 0; i n; i++) {
if (framebuffers[i] 0) {
@@ -1532,11 +1521,6 @@ framebuffer_texture(GLcontext *ctx, const char *caller,
GLenum target,
}
FLUSH_CURRENT(ctx, _NEW_BUFFERS);
- /* The above doesn't fully flush the drivers in the way that a
-* glFlush does, but that is required here:
-*/
- if (ctx-Driver.Flush)
- ctx-Driver.Flush(ctx);
_glthread_LOCK_MUTEX(fb-Mutex);
if (texObj) {
@@ -1713,11 +1697,6 @@ _mesa_FramebufferRenderbufferEXT(GLenum target, GLenum
attachment,
FLUSH_CURRENT(ctx, _NEW_BUFFERS);
- /* The above doesn't fully flush the drivers in the way that a
-* glFlush does, but that is required here:
-*/
- if (ctx-Driver.Flush)
- ctx-Driver.Flush(ctx);
assert(ctx-Driver.FramebufferRenderbuffer);
ctx-Driver.FramebufferRenderbuffer(ctx, fb, attachment, rb);
@@ -1794,11 +1773,6 @@ _mesa_GetFramebufferAttachmentParameterivEXT(GLenum
target, GLenum attachment,
}
FLUSH_CURRENT(ctx, _NEW_BUFFERS);
- /* The above doesn't fully flush the drivers in the way that a
-* glFlush does, but that is required here:
-*/
- if (ctx-Driver.Flush)
- ctx-Driver.Flush(ctx);
switch (pname) {
case GL_FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE_EXT:
--
1.6.3.3
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 2/2] mesa: Remove another unexplained Flush call, this time from BindFramebuffer.
---
src/mesa/main/fbobject.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index a73a765..6e767bb 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1207,9 +1207,6 @@ _mesa_BindFramebufferEXT(GLenum target, GLuint
framebuffer)
}
FLUSH_CURRENT(ctx, _NEW_BUFFERS);
- if (ctx-Driver.Flush) {
- ctx-Driver.Flush(ctx);
- }
if (framebuffer) {
/* Binding a user-created framebuffer object */
--
1.6.3.3
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Remove gratuitous flushes from fbobject.c
Between these two patches, cairo-gl firefox's runtime drops from 120 seconds to under 90 seconds. Can anyone justify these flushes? -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): vbo: Fix array pointer calculation for MapBufferRange-mapped vertex data.
On Sat, 2009-08-29 at 11:24 -0700, Jose Fonseca wrote: Eric, This change broke softpipe on master (eg. terrain), and probably all gallium based drivers. I'm pretty sure the vbo module was working correctly without it, so there might be a different in the interpretation of the MapBufferRange semantics between the drivers, but I couldn't find it just by llooking at intel's and mesa state tracker implementation of MapBufferRange. Was there any particular bug this change fixed? Yes, garbage was drawn all over the screen when enabling VBOs in the VBO module. obj-Pointer should pretty clearly be the pointer to the mapped range, as if you're creating a temporary space (system memory or temporary buffer object) as part of MapRange, where else would it point -- to an unmapped address? It also then matches the ARB_map_buffer_range semantics. Looks like a quick fix in st_bufferobj_map_range. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 2/2] vbo: Avoid extra validation of DrawElements.
This saves mapping the index buffer to get a bounds on the indices that
drivers just drop on the floor in the VBO case (cache win), saves a bonus
walk of the indices in the CheckArrayBounds case, and other miscellaneous
validation. On intel it's a particularly a large win (50-100% in my app)
because even though we let the indices stay in both CPU and GPU caches, we
still end up waiting for the GPU to be done with the buffer before reading
from it.
Drivers supporting draw_prims must now handle min_index == ~0 indicating that
min/max_index are not computed, if they want to use these fields.
---
src/mesa/drivers/dri/i965/brw_draw.c| 52 +++---
src/mesa/drivers/dri/i965/brw_draw_upload.c |1 +
src/mesa/drivers/dri/r300/r300_draw.c |6 +
src/mesa/tnl/t_draw.c |3 +
src/mesa/vbo/vbo.h |5 +-
src/mesa/vbo/vbo_exec_array.c | 151 ++-
6 files changed, 107 insertions(+), 111 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 5152c3f..01e5f36 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -422,34 +422,6 @@ static GLboolean brw_try_draw_prims( GLcontext *ctx,
return retval;
}
-static GLboolean brw_need_rebase( GLcontext *ctx,
- const struct gl_client_array *arrays[],
- const struct _mesa_index_buffer *ib,
- GLuint min_index )
-{
- if (min_index == 0)
- return GL_FALSE;
-
- if (ib) {
- if (!vbo_all_varyings_in_vbos(arrays))
-return GL_TRUE;
- else
-return GL_FALSE;
- }
- else {
- /* Hmm. This isn't quite what I wanted. BRW can actually
- * handle the mixed case well enough that we shouldn't need to
- * rebase. However, it's probably not very common, nor hugely
- * expensive to do it this way:
- */
- if (!vbo_all_varyings_in_vbos(arrays))
-return GL_TRUE;
- else
-return GL_FALSE;
- }
-}
-
-
void brw_draw_prims( GLcontext *ctx,
const struct gl_client_array *arrays[],
const struct _mesa_prim *prim,
@@ -460,16 +432,20 @@ void brw_draw_prims( GLcontext *ctx,
{
GLboolean retval;
- /* Decide if we want to rebase. If so we end up recursing once
-* only into this function.
-*/
- if (brw_need_rebase( ctx, arrays, ib, min_index )) {
- vbo_rebase_prims( ctx, arrays,
- prim, nr_prims,
- ib, min_index, max_index,
- brw_draw_prims );
-
- return;
+ if (!vbo_all_varyings_in_vbos(arrays)) {
+ if (min_index == ~0)
+vbo_get_minmax_index(ctx, prim, ib, min_index, max_index);
+
+ /* Decide if we want to rebase. If so we end up recursing once
+ * only into this function.
+ */
+ if (min_index != 0) {
+vbo_rebase_prims(ctx, arrays,
+ prim, nr_prims,
+ ib, min_index, max_index,
+ brw_draw_prims );
+return;
+ }
}
/* Make a first attempt at drawing:
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index 4bdb373..a4457b8 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -411,6 +411,7 @@ static void brw_prepare_vertices(struct brw_context *brw)
*/
assert(input-offset input-bo-size);
} else {
+assert(min_index != ~0);
input-count = input-glarray-StrideB ? max_index + 1 - min_index : 1;
if (input-bo != NULL) {
/* Already-uploaded vertex data is present from a previous
diff --git a/src/mesa/drivers/dri/r300/r300_draw.c
b/src/mesa/drivers/dri/r300/r300_draw.c
index fcfd309..bc5a234 100644
--- a/src/mesa/drivers/dri/r300/r300_draw.c
+++ b/src/mesa/drivers/dri/r300/r300_draw.c
@@ -476,6 +476,12 @@ static void r300DrawPrims(GLcontext *ctx,
limits.max_indices = 65535;
limits.max_vb_size = 1024*1024;
+ /* This check should get folded into just the places that
+* min/max index are really needed.
+*/
+ if (min_index == ~0)
+ vbo_get_minmax_index(ctx, prim, ib, min_index, max_index);
+
if (min_index) {
vbo_rebase_prims( ctx, arrays, prim, nr_prims, ib, min_index,
max_index, r300DrawPrims );
return;
diff --git a/src/mesa/tnl/t_draw.c b/src/mesa/tnl/t_draw.c
index 2ec65d5..d093293 100644
--- a/src/mesa/tnl/t_draw.c
+++ b/src/mesa/tnl/t_draw.c
@@ -388,6 +388,9 @@ void _tnl_draw_prims( GLcontext *ctx,
prim[i].count);
}
+ if (min_index == ~0)
+ vbo_get_minmax_index(ctx, prim, ib, min_index, max_index);
+
if
[Mesa3d-dev] [PATCH] intel: Use a new DRI2 extension to throttle the number of outstanding frames.
This fixes jerkiness in doom3 and other apps since the kernel change to
throttle less absurdly, which led to a thundering herd of frames.
---
include/GL/internal/dri_interface.h| 12
src/glx/x11/dri2_glx.c |5 +
src/glx/x11/dri_common.c |7 +++
src/glx/x11/glxclient.h|4
src/mesa/drivers/dri/intel/intel_batchbuffer.c |5 +
src/mesa/drivers/dri/intel/intel_context.h |1 +
src/mesa/drivers/dri/intel/intel_screen.c |6 ++
src/mesa/drivers/dri/intel/intel_swapbuffers.c | 22 ++
src/mesa/drivers/dri/intel/intel_swapbuffers.h |2 ++
9 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 910c916..cca0369 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -79,6 +79,7 @@ typedef struct __DRIbufferRec __DRIbuffer;
typedef struct __DRIdri2ExtensionRec __DRIdri2Extension;
typedef struct __DRIdri2LoaderExtensionRec __DRIdri2LoaderExtension;
typedef struct __DRI2flushExtensionRec __DRI2flushExtension;
+typedef struct __DRI2postswapbuffersExtensionRec
__DRI2postswapbuffersExtension;
/*...@}*/
@@ -268,6 +269,17 @@ struct __DRI2flushExtensionRec {
void (*flush)(__DRIdrawable *drawable);
};
+/**
+ * Used by drivers that implement DRI2, called after a SwapBuffers is done
+ * in case the driver wants to do some throttling.
+ */
+#define __DRI2_POST_SWAPBUFFERS DRI2_PostSwapbuffers
+#define __DRI2_POST_SWAPBUFFERS_VERSION 1
+struct __DRI2postswapbuffersExtensionRec {
+__DRIextension base;
+void (*post_swapbuffers)(__DRIdrawable *drawable);
+};
+
/**
* XML document describing the configuration options supported by the
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index f4865ae..de59fd8 100644
--- a/src/glx/x11/dri2_glx.c
+++ b/src/glx/x11/dri2_glx.c
@@ -229,6 +229,11 @@ static void dri2SwapBuffers(__GLXDRIdrawable *pdraw)
__GLXDRIdrawablePrivate *priv = (__GLXDRIdrawablePrivate *) pdraw;
dri2CopySubBuffer(pdraw, 0, 0, priv-width, priv-height);
+
+#ifdef __DRI2_POSTSWAPBUFFERS
+if (pdraw-psc-dri2_postswapbuffers)
+
(*pdraw-psc-dri2_postswapbuffers-postswapbuffers)(pdraw-driDrawable);
+#endif
}
static void dri2WaitX(__GLXDRIdrawable *pdraw)
diff --git a/src/glx/x11/dri_common.c b/src/glx/x11/dri_common.c
index 6de4111..632bbf8 100644
--- a/src/glx/x11/dri_common.c
+++ b/src/glx/x11/dri_common.c
@@ -401,6 +401,13 @@ driBindExtensions(__GLXscreenConfigs *psc, int dri2)
}
#endif
+#ifdef __DRI2_POSTSWAPBUFFERS
+ if ((strcmp(extensions[i]-name, __DRI2_POSTSWAPBUFFERS) == 0) dri2)
{
+ psc-f = (__DRI2flushExtension *) extensions[i];
+ /* internal driver extension, no GL extension exposed */
+ }
+#endif
+
/* Ignore unknown extensions */
}
}
diff --git a/src/glx/x11/glxclient.h b/src/glx/x11/glxclient.h
index bf68d0f..9d230bf 100644
--- a/src/glx/x11/glxclient.h
+++ b/src/glx/x11/glxclient.h
@@ -529,6 +529,10 @@ struct __GLXscreenConfigsRec {
const __DRI2flushExtension *f;
#endif
+#ifdef __DRI2_FLUSH
+const __DRI2postswapbuffersExtension *dri2_postswapbuffers;
+#endif
+
#endif
/**
diff --git a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
index 0f87fc4..e94b836 100644
--- a/src/mesa/drivers/dri/intel/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/intel/intel_batchbuffer.c
@@ -196,6 +196,11 @@ _intel_batchbuffer_flush(struct intel_batchbuffer *batch,
const char *file,
struct intel_context *intel = batch-intel;
GLuint used = batch-ptr - batch-map;
+ if (intel-first_post_swapbuffers_batch == NULL) {
+ intel-first_post_swapbuffers_batch = intel-batch-buf;
+ drm_intel_bo_reference(intel-first_post_swapbuffers_batch);
+ }
+
if (used == 0) {
batch-cliprect_mode = IGNORE_CLIPRECTS;
return;
diff --git a/src/mesa/drivers/dri/intel/intel_context.h
b/src/mesa/drivers/dri/intel/intel_context.h
index 08bea88..e93eb1f 100644
--- a/src/mesa/drivers/dri/intel/intel_context.h
+++ b/src/mesa/drivers/dri/intel/intel_context.h
@@ -178,6 +178,7 @@ struct intel_context
GLboolean ttm;
struct intel_batchbuffer *batch;
+ drm_intel_bo *first_post_swapbuffers_batch;
GLboolean no_batch_wrap;
unsigned batch_id;
diff --git a/src/mesa/drivers/dri/intel/intel_screen.c
b/src/mesa/drivers/dri/intel/intel_screen.c
index 6bbc995..8154e65 100644
--- a/src/mesa/drivers/dri/intel/intel_screen.c
+++ b/src/mesa/drivers/dri/intel/intel_screen.c
@@ -225,6 +225,11 @@ static const __DRItexBufferExtension
intelTexBufferExtension = {
intelSetTexBuffer2,
};
+static const __DRI2postswapbuffersExtension intelPostSwapbuffersExtension = {
+{ __DRI_TEX_BUFFER,
[Mesa3d-dev] [PATCH] intel: Disable texenv program around _swrast_CopyPixels.
This fixes the mesa readpix demo with scale and bias enabled. I can't
justify why it should, though -- anyone have any explanation here?
Bug #20262.
---
src/mesa/drivers/dri/intel/intel_pixel_copy.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_pixel_copy.c
b/src/mesa/drivers/dri/intel/intel_pixel_copy.c
index 5d52335..96390ca 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_copy.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_copy.c
@@ -394,6 +394,8 @@ intelCopyPixels(GLcontext * ctx,
GLsizei width, GLsizei height,
GLint destx, GLint desty, GLenum type)
{
+ struct gl_fragment_program *fp_save;
+
if (INTEL_DEBUG DEBUG_PIXEL)
fprintf(stderr, %s\n, __FUNCTION__);
@@ -404,8 +406,15 @@ intelCopyPixels(GLcontext * ctx,
if (do_texture_copypixels(ctx, srcx, srcy, width, height, destx, desty,
type))
return;
#endif
-
DBG(fallback to _swrast_CopyPixels\n);
+ /* Disable the automatically generated fragment program when falling back
+* to software. Fixes readpix demo with scale/bias enabled.
+*/
+ fp_save = ctx-FragmentProgram._Current;
+ ctx-FragmentProgram._Current = NULL;
+ ctx-FragmentProgram._MaintainTexEnvProgram = GL_FALSE;
_swrast_CopyPixels(ctx, srcx, srcy, width, height, destx, desty, type);
+ ctx-FragmentProgram._Current = fp_save;
+ ctx-FragmentProgram._MaintainTexEnvProgram = GL_TRUE;
}
--
1.6.3.3
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] bug in piglit vbo-map-remap.c test?
On Thu, 2009-07-02 at 22:20 -0700, Vinson Lee wrote: I believe there's a bug in the piglit vbo-map-remap.c test. The test fails for me with a GL_INVALID_ENUM error that comes from glEnable(GL_VERTEX_ARRAY). GL_VERTEX_ARRAY is a client-side capability so the error seems valid. Mesa's been accepting array enums in Enable/Disable as if it was Enable/DisableClientState since the initial revision in CVS, it looks like. If this is in fact invalid and other vendors throw errors on it, I'd like to see Mesa follow suit. However, tests should be strict in what they test, so please apply. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): intel: Remove unneded pthread mutex in LOCK_HARDWARE.
On Tue, 2009-06-30 at 16:59 +0200, Michel Dänzer wrote: On Mon, 2009-06-29 at 10:57 -0700, Eric Anholt wrote: This code was originally introduced with the i915tex code dump, so it's not clear what it was there for. What exactly do you mean by 'i915tex code dump'? The i915tex driver (and Gallium, which was started by separating the API and HW specific parts of i915tex) was developed out in the open pretty much from day one, and the full history is still available in mesa Git. I spent a while digging, and all I could see was it coming in with the initial add of i915tex, and it not being there in i915. Was there another repo move that I missed? -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): intel: Remove unneded pthread mutex in LOCK_HARDWARE.
On Mon, 2009-06-29 at 19:11 +0100, Keith Whitwell wrote: On Mon, 2009-06-29 at 10:57 -0700, Eric Anholt wrote: Module: Mesa Branch: master Commit: de447afff26706e3bf8bdcd5cfb8b1daf49b4b21 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=de447afff26706e3bf8bdcd5cfb8b1daf49b4b21 Author: Eric Anholt e...@anholt.net Date: Mon Jun 29 09:48:28 2009 -0700 intel: Remove unneded pthread mutex in LOCK_HARDWARE. This would cause LOCK_HARDWARE to mutex all contexts in this process on both DRI1 and DRI2. On DRI1, LOCK_HARDWARE already does it for all processes on the system. On DRI2, LOCK_HARDWARE doesn't, but there shouldn't be any state outside the context that needs any additional protection. Notably, the bufmgr is protected by its own mutex and not LOCK_HARDWARE. This code was originally introduced with the i915tex code dump, so it's not clear what it was there for. It's there because the DRI1 code doesn't actually achieve the mutexing which it looks as if it should. For multi-threaded applications it was always possible to get two threads inside locked regions -- I have no idea how, but it certainly was and presumably still is possible. Sigh, DRI1. I'll put it back under DRI1-only checks. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): i965: Fall back or appropriately adjust offsets of drawing to tiled regions.
On Fri, 2009-06-19 at 17:58 +0200, Michel Dänzer wrote: On Wed, 2009-06-17 at 21:03 -0700, Eric Anholt wrote: Module: Mesa Branch: master Commit: 0f328c90dbc893e15005f2ab441d309c1c176245 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=0f328c90dbc893e15005f2ab441d309c1c176245 Author: Eric Anholt e...@anholt.net Date: Fri Jun 5 23:16:44 2009 + i965: Fall back or appropriately adjust offsets of drawing to tiled regions. 3D rendering to tiled textures was being done with non-tile-aligned offsets. The G4X hardware has fields to let us support it easily and correctly, while the pre-G4X hardware requires a path full of suffering, so we just fall back. FYI, this commit causes lockups on my GM45 when running 3D apps in a VMware Workstation guest OS. Seems stable with just this reverted, and I can't seem to notice any tiling related problems. Anything interesting in the GPU dump? I hit a hang with one of the piglit tests since this commit, need to sit down and look at it. If I can't get tiling fixed up soon, I'll just turn it back off until I can get it sorted out, even though it's a major performance win. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] DMA buffer management + KMS
On Mon, 2009-05-25 at 18:49 -0400, Owen Taylor wrote: On Mon, 2009-05-25 at 22:08 +0200, Nicolai Hähnle wrote: [ Even with the change, there still is a noticeable performance win from dropping the size of the DMA buffer in mesa - binding the 1M buffers into AGP space takes a measurable amount of time. ] Forgive me if you've mentioned it before, but what is your testcase? If I recall the discussions correctly (and admittedly I've been somewhat away for a while), the idea was to have big buffers so that games can just keep scheduling drawing commands virtually indefinitely (maybe even up to a full frame worth of draw calls). Obviously, if your testcase is in fact not one of those eyecandy-crazy shooters, then that's a bad idea for you. I've been testing with mutter/gnome-shell (GL based compositor, with UI elements in the GL scene graph as well.) It certainly doesn't look that much like a game; the vertex/state-change ratio is probably lower than for most games since there are no complex 3D models - the most vertex intensive thing it's doing is text (quad per glyph). But on the other hand, it's using maybe 1/1000th of the vertex buffer before it fills its command buffer and releases the DMA buffer, so that's a pretty big gap to make up if games are that different. Sounds like you've got your problems mostly figured out, but some notes on Mesa VBO management: What the 965 driver does is make our driver-internal VBOs moderately sized (64k or so, unless you need bigger for the particular arrays that are enabled), and make new ones when we fill one up while accumulating a batchbuffer. This is pretty cheap, and increasing size of the VBO allocation didn't help, but then we're caching buffers so that allocation's cheap anyway. Immediate-mode GL rendering is still overly slow and cache-hungry, because Mesa assumes that after every draw_prims, it can't remap the VBO again or it'll wait on the GPU. Because of this, we don't actually use VBOs in the VBO module (there's a function to enable real VBOs that we don't use), and instead use arrays that get copied to the driver-internal VBOs. But it doesn't need to worry about the waiting if the buffer hasn't been dispatched to the GPU, so we could just have a callback from the driver to the VBO module for I've flushed my batch, and now is the time to allocate a new VBO to avoid waiting, and then enable real VBO usage for immediate mode. The alternative for immediate mode would be implementing the ranged buffer mapping extension, which lets the VBO module do the right thing. I'm concerned that we have no testcases for that extension other than the VBO module, which is why I haven't just done that yet. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): mesa: Mark FBOs with compressed color attachments as FBO-incomplete.
On Fri, 2009-05-15 at 16:59 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt wrote: Module: Mesa Branch: master Commit: 0307e609aa3e707eeb40051bd664d36f2340ba9b URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=0307e609aa3e707eeb40051bd664d36f2340ba9b Author: Eric Anholt e...@anholt.net Date: Fri May 15 16:24:59 2009 -0700 mesa: Mark FBOs with compressed color attachments as FBO-incomplete. Both EXT_fbo and ARB_fbo agree on this. Fixes a segfault in the metaops mipmap generation in Intel for SGIS_generate_mipmap of S3TC textures in Regnum Online. Bug #21654. Hmm... What does this mean about our future ability to generate mipmaps for compressed texture? This is a known limitation of Mesa (see bug #19187), but it's one that we'd like to see fixed eventually. The hardware can't render to S3TC targets, so nothing. The trivial test I did for S3TC SGIS_generate_mipmap appeared to work, though. gen-compressed-teximage in piglit -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] intel issue with gears port using vertex buffer objects
On Mon, 2009-04-27 at 09:55 -0600, Brian Paul wrote: Brian Paul wrote: Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Clark wrote: I did a git bisect and found the revision where I see the biggest drop in performance (roughly 30% drop with my app): $ git bisect bad Bisecting: 0 revisions left to test after this [20f3497e4b6756e330f7b3f54e8acaa1d6c92052] i965: re-org of some of the new constant buffer code I think there may be some other performance regressions in there as the commit before this is also not as fast as mesa_7_4_branch although the above commit has the most noticeable drop. I think gears is the same speed before and after the commit so I'm not yet sure what part if my app is exercising the code that has the performance drop. I'll try to work up a small test program if I get time. I've been experiencing this with some of our internal test cases. The killer seems to be programs that do lots of state changes. glxgears does almost no state changes, so it's not surprising that it doesn't take a big hit. That's one of my commits. I'll take a look... OK, I've just pushed a commit which should restore performance back to what it was. Thanks for fixing it -- OA is now up to 80% of mesa 7.4's performance, instead of 25%. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] intel issue with gears port using vertex buffer objects
On Tue, 2009-04-21 at 23:57 +0800, Michael Clark wrote: Michel Dänzer wrote: On Sat, 2009-04-18 at 13:46 +0800, Michael Clark wrote: I have made a port of gears that uses the OpenGL ES 1.1 Common API subset (using glDrawElements instead of display lists and optionally using vertex buffer objects). It should be visually equivalent to gears.c, although the flat faces are rendered with GL_SMOOTH to avoid additional draw calls. While testing it, I noticed a severe screen corruption issue when using vertex buffer objects with the intel driver in ubuntu (both ubuntu 9.04 driver and ubuntu xorg-edgers 2.6.99.1+git20090416). I have verified the code is working with the nvidia-180 proprietary driver on another system so I believe it is an intel driver issue. I am wondering if the same issue exists upstream... The attached gearsvbo.c source code can be compiled with: gcc gearsvbo.c -o gearsvbo -lGL -lglut It can be run with or without vertex buffer objects (add -novbo command line option to disable). With the Intel driver I see a 40% speedup with glDrawElements alone. With vertex buffer objects enabled I see almost 200% speedup although the front-buffer doesn't appear to being cleared or swapped correctly (see attached png). Fixed in Git. Thanks. I just noticed the fix has arrived in ubuntu xorg-edgers as of mesa_7.4.1~git20090420+mesa-7-4-branch. Before trying this I built from mesa master earlier today and noticed a performance regression with the 965GM on one of my GL apps - going from 15fps to 7.5fps (both running on top of latest drm-intel 2.6.30-rc2). 7.4.1 doesn't exhibit the slow down. It seemed to be a timing issue as the app would no longer be using all cpu of a single core (noticeably less cpu than on the 7.4-branch version), and paradoxically, running another cpu intensive task would result in the fps increasing. I'll do some more testing (and double check the two builds were configured equivalently)... bisecting would be the best thing to do if you've got a performance drop and it's not a CPU-bound app. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] intel / DRI2: Track and flush front-buffer rendering
On Wed, 2009-04-01 at 22:15 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt wrote: On Wed, 2009-04-01 at 18:30 -0700, Ian Romanick wrote: Track whether or not front-buffer rendering may have occured. If there might be any pending front-buffer rendering waiting to get to the screen, flush it from glFlush and related paths in the driver. Signed-off-by: Ian Romanick ian.d.roman...@intel.com --- src/mesa/drivers/dri/intel/intel_buffers.c |2 ++ src/mesa/drivers/dri/intel/intel_context.c | 11 +++ src/mesa/drivers/dri/intel/intel_context.h | 10 ++ 3 files changed, 23 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_buffers.c b/src/mesa/drivers/dri/intel/intel_buffers.c index f1908cb..26dd818 100644 --- a/src/mesa/drivers/dri/intel/intel_buffers.c +++ b/src/mesa/drivers/dri/intel/intel_buffers.c @@ -204,6 +204,8 @@ intel_draw_buffer(GLcontext * ctx, struct gl_framebuffer *fb) intel_batchbuffer_flush(intel-batch); intel-front_cliprects = GL_TRUE; colorRegions[0] = intel_get_rb_region(fb, BUFFER_FRONT_LEFT); + + intel-front_buffer_dirty = GL_TRUE; Why is DrawBuffers the right place for this? It looks like some triangles, then glFlush, then some triangles, then glFlush, the last set of triangles wouldn't show up. /me puts a paper bag over his head. My goal was to set the bit in as few places as possible. I don't really care if we do extra flushes. I want to avoid setting the bit in 47 different places and missing one. I think setting the flag in DrawBuffers and only clearing it in intelFlush when the draw buffer is no long GL_FRONT is the right way to accomplish this. Thoughts? It means people doing glFlush with front buffer rendering get punished if they flush without having rendered. Seems fine to me. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] piglit texture test issue
On Mon, 2009-03-30 at 02:55 +0100, Dave Airlie wrote: Hey, Just wondering what should be done, but gen-teximage.c and gen-texsubimage.c at lesat both do glutSwapBuffers glFlush glReadPixels. Now glReadPixels defaults to reading from the backbuffer, and in theory after a swapbuffers the contents of the backbuffer are undefined. I'm sure the fix is to glReadPixels before the swapbuffers or glReadBuffer(GL_FRONT) before it. Since DRI2 + Front buffer rendering is hosed the second option isn't so pretty. Yeah, I also recently made one test do read of back before swap after running into the DRI2 problem. It's a lot nicer anyway imo since that means that nothing else on the screen can interfere with the results. Well, unless you're doing DRI1, but then you get what you deserve. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] DRI2 vs. ConfigureNotify events
On Tue, 2009-03-24 at 17:53 +0100, Michel Dänzer wrote:
Eric,
your mesa commit dd1c68f15123a889a3ce9d2afe724e272d163e32 ('dri2: Avoid
round-tripping on DRI2GetBuffers for the same set of buffers.') breaks
when the display connection doesn't receive ConfigureNotify events. This
can be reproduced by running a 3D application in a guest operating
system in VMware Workstation, which calls
XSelectInput(..., ExposureMask);
on the child window used for GL rendering. The GL driver ends up using
stale buffers / window size, so the output is cropped and misplaced.
I wrote up the attached patch to fix this by adding StructureNotifyMask
to the event mask of the DRI2 display connection; this fixes the problem
above, but on second thought I'm concerned about potential side effects
of this approach on display connections which are otherwise not
interested in ConfigureNotify events. If I'm reading the libX11 event
queue management code correctly, this could result in an unlimited
number of ConfigureNotify events queueing up on the client side. In
practice the number may usually be low, but there could be more subtle
side effects, e.g. because the queue would not empty up anymore.
So for Mesa 7.4, I suspect the safest course of action is to revert
dd1c68f15123a889a3ce9d2afe724e272d163e32. Something like the change
below could be used to at least limit the number of additional X server
round-trips to one per frame.
What do you think?
While I actually did the typing, the plan there (in particular the
understanding of the event code) came mostly from Keith. I've added him
to the Cc. Keith -- does this match your understanding of the event
code?
Ack on reverting the patch for 7.4, though if it's really not going to
work out I'd rather revert it from master as well. We can work around
the cost by suppressing the getbuffers for internal glViewport calls (it
was the plan before he came up with the clever hack).
commit 31cc890207e18f7f538502cca0b9492b4938b7e7
Author: Michel Dänzer daen...@vmware.com
Date: Tue Mar 24 17:35:29 2009 +0100
DRI2: Avoid changing buffers in the middle of a frame.
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index 9c8f110..de187f9 100644
--- a/src/glx/x11/dri2_glx.c
+++ b/src/glx/x11/dri2_glx.c
@@ -76,6 +76,7 @@ struct __GLXDRIdrawablePrivateRec {
int have_back;
int have_front;
int have_fake_front;
+GLboolean buffers_cached;
};
static void dri2DestroyContext(__GLXDRIcontext *context,
@@ -170,6 +171,7 @@ static __GLXDRIdrawable
*dri2CreateDrawable(__GLXscreenConfigs *psc,
pdraw-base.drawable = drawable;
pdraw-base.psc = psc;
pdraw-bufferCount = 0;
+pdraw-buffers_cached = GL_FALSE;
DRI2CreateDrawable(psc-dpy, xDrawable);
@@ -194,6 +196,8 @@ static void dri2CopySubBuffer(__GLXDRIdrawable *pdraw,
XRectangle xrect;
XserverRegion region;
+priv-buffers_cached = GL_FALSE;
+
/* Check we have the right attachments */
if (!(priv-have_front priv-have_back))
return;
@@ -228,6 +232,8 @@ static void dri2WaitX(__GLXDRIdrawable *pdraw)
XRectangle xrect;
XserverRegion region;
+priv-buffers_cached = GL_FALSE;
+
/* Check we have the right attachments */
if (!(priv-have_fake_front priv-have_front))
return;
@@ -254,6 +260,8 @@ static void dri2WaitGL(__GLXDRIdrawable *pdraw)
XRectangle xrect;
XserverRegion region;
+priv-buffers_cached = GL_FALSE;
+
if (!(priv-have_fake_front priv-have_front))
return;
@@ -291,6 +299,22 @@ dri2GetBuffers(__DRIdrawable *driDrawable,
DRI2Buffer *buffers;
int i;
+/**
+ * We want to avoid changing the buffers in the middle of a frame.
+ */
+if (pdraw-buffers_cached count == pdraw-bufferCount) {
+ for (i = 0; i count; i++) {
+ if (pdraw-buffers[i].attachment != attachments[i])
+ break;
+ }
+ if (i == count) {
+ *width = pdraw-width;
+ *height = pdraw-height;
+ *out_count = pdraw-bufferCount;
+ return pdraw-buffers;
+ }
+}
+
buffers = DRI2GetBuffers(pdraw-base.psc-dpy, pdraw-base.xDrawable,
width, height, attachments, count, out_count);
if (buffers == NULL)
@@ -321,6 +345,8 @@ dri2GetBuffers(__DRIdrawable *driDrawable,
Xfree(buffers);
+pdraw-buffers_cached = GL_TRUE;
+
return pdraw-buffers;
}
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
Re: [Mesa3d-dev] Mesa (master): Fix DRI2 accelerated EXT_texture_from_pixmap with GL_RGB format.
On Fri, 2009-03-20 at 19:23 +0100, Michel Dänzer wrote:
On Fre, 2009-03-20 at 10:45 -0700, Eric Anholt wrote:
Module: Mesa
Branch: master
Commit: 66175aac7609ad314f25fbdff0d3958af310dc24
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=66175aac7609ad314f25fbdff0d3958af310dc24
Author: Eric Anholt e...@anholt.net
Date: Wed Mar 18 12:07:09 2009 -0700
Fix DRI2 accelerated EXT_texture_from_pixmap with GL_RGB format.
This requires upgrading the interface so that the argument to
glXBindTexImageEXT isn't just dropped on the floor. Note that this only
fixes the accelerated path on Intel, as Mesa's texture format support is
missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as
a8r8gb8,
but in this case we're not doing the upload so we can't really work around
it
that way).
Fixes bugs with compositors trying to use shaders that use alpha channels,
on
windows without a valid alpha channel. Bug #19910 and likely others as
well.
Reviewed-by:Ian Romanick ian.d.roman...@intel.com
[...]
@@ -239,11 +239,23 @@ struct __DRItexBufferExtensionRec {
* Method to override base texture image with the contents of a
* __DRIdrawable.
*
- * For GLX_EXT_texture_from_pixmap with AIGLX.
+ * For GLX_EXT_texture_from_pixmap with AIGLX. Deprecated in favor of
+ * setTexBuffer2 in version 2 of this interface
*/
void (*setTexBuffer)(__DRIcontext *pDRICtx,
GLint target,
__DRIdrawable *pDraw);
+
+/**
+ * Method to override base texture image with the contents of a
+ * __DRIdrawable, including the required texture format attribute.
+ *
+ * For GLX_EXT_texture_from_pixmap with AIGLX.
+ */
+void (*setTexBuffer2)(__DRIcontext *pDRICtx,
+ GLint target,
+ GLint format,
+ __DRIdrawable *pDraw);
};
Why did you bother sending out the change for public review if you were
only going to take notice of your colleague's ack and ignore suggestions
from others?
I didn't think you were NAKing the patch. I'm not interested in
complicating API so that at some point old API can be removed, when the
overhead of implementing both is so low:
+void
+intelSetTexBuffer(__DRIcontext *pDRICtx, GLint target, __DRIdrawable
*dPriv)
+{
+ /* The old interface didn't have the format argument, so copy our
+* implementation's behavior at the time.
+*/
+ intelSetTexBuffer2(pDRICtx, target, GLX_TEXTURE_FORMAT_RGBA_EXT,
dPriv);
+}
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Fix DRI2 accelerated EXT_texture_from_pixmap with GL_RGB format.
This requires upgrading the interface so that the argument to
glXBindTexImageEXT isn't just dropped on the floor. Note that this only
fixes the accelerated path on Intel, as Mesa's texture format support is
missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as a8r8gb8,
but in this case we're not doing the upload so we can't really work around it
that way).
Fixes bugs with compositors trying to use shaders that use alpha channels, on
windows without a valid alpha channel. Bug #19910 and likely others as well.
---
include/GL/internal/dri_interface.h | 16 -
include/GL/internal/glcore.h |4 +++
src/glx/x11/glx_pbuffer.c| 19 +
src/glx/x11/glxclient.h |1 +
src/glx/x11/glxcmds.c| 18 +++
src/mesa/drivers/dri/i915/i830_texstate.c| 10 ++--
src/mesa/drivers/dri/i915/i915_texstate.c| 11 +++--
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 24 +++--
src/mesa/drivers/dri/intel/intel_screen.c|1 +
src/mesa/drivers/dri/intel/intel_tex.h |2 +
src/mesa/drivers/dri/intel/intel_tex_image.c | 15 +++-
11 files changed, 99 insertions(+), 22 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index a726b93..a83602b 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -231,7 +231,7 @@ struct __DRItexOffsetExtensionRec {
#define __DRI_TEX_BUFFER DRI_TexBuffer
-#define __DRI_TEX_BUFFER_VERSION 1
+#define __DRI_TEX_BUFFER_VERSION 2
struct __DRItexBufferExtensionRec {
__DRIextension base;
@@ -239,11 +239,23 @@ struct __DRItexBufferExtensionRec {
* Method to override base texture image with the contents of a
* __DRIdrawable.
*
- * For GLX_EXT_texture_from_pixmap with AIGLX.
+ * For GLX_EXT_texture_from_pixmap with AIGLX. Deprecated in favor of
+ * setTexBuffer2 in version 2 of this interface
*/
void (*setTexBuffer)(__DRIcontext *pDRICtx,
GLint target,
__DRIdrawable *pDraw);
+
+/**
+ * Method to override base texture image with the contents of a
+ * __DRIdrawable, including the required texture format attribute.
+ *
+ * For GLX_EXT_texture_from_pixmap with AIGLX.
+ */
+void (*setTexBuffer2)(__DRIcontext *pDRICtx,
+ GLint target,
+ GLint format,
+ __DRIdrawable *pDraw);
};
/**
diff --git a/include/GL/internal/glcore.h b/include/GL/internal/glcore.h
index 547b111..18f6576 100644
--- a/include/GL/internal/glcore.h
+++ b/include/GL/internal/glcore.h
@@ -178,4 +178,8 @@ typedef struct __GLcontextModesRec {
#define GLX_TEXTURE_2D_BIT_EXT 0x0002
#define GLX_TEXTURE_RECTANGLE_BIT_EXT 0x0004
+#define GLX_TEXTURE_FORMAT_NONE_EXT0x20D8
+#define GLX_TEXTURE_FORMAT_RGB_EXT 0x20D9
+#define GLX_TEXTURE_FORMAT_RGBA_EXT0x20DA
+
#endif /* __gl_core_h_ */
diff --git a/src/glx/x11/glx_pbuffer.c b/src/glx/x11/glx_pbuffer.c
index a602cd2..6bcf965 100644
--- a/src/glx/x11/glx_pbuffer.c
+++ b/src/glx/x11/glx_pbuffer.c
@@ -189,6 +189,21 @@ determineTextureTarget(const int *attribs, int numAttribs)
return target;
}
+
+
+static GLenum
+determineTextureFormat(const int *attribs, int numAttribs)
+{
+ GLenum target = 0;
+ int i;
+
+ for (i = 0; i numAttribs; i++) {
+ if (attribs[2 * i] == GLX_TEXTURE_FORMAT_EXT)
+return attribs[2 * i + 1];
+ }
+
+ return 0;
+}
#endif
/**
@@ -294,6 +309,9 @@ GetDrawableAttribute(Display * dpy, GLXDrawable drawable,
if (pdraw != NULL !pdraw-textureTarget)
pdraw-textureTarget =
determineTextureTarget((const int *) data, num_attributes);
+if (pdraw != NULL !pdraw-textureFormat)
+ pdraw-textureFormat =
+ determineTextureFormat((const int *) data, num_attributes);
}
#endif
@@ -374,6 +392,7 @@ CreateDrawable(Display * dpy, const __GLcontextModes *
fbconfig,
}
pdraw-textureTarget = determineTextureTarget(attrib_list, i);
+ pdraw-textureFormat = determineTextureFormat(attrib_list, i);
} while (0);
#endif
diff --git a/src/glx/x11/glxclient.h b/src/glx/x11/glxclient.h
index caf58bb..c42e80a 100644
--- a/src/glx/x11/glxclient.h
+++ b/src/glx/x11/glxclient.h
@@ -161,6 +161,7 @@ struct __GLXDRIdrawableRec {
__GLXscreenConfigs *psc;
GLenum textureTarget;
__DRIdrawable *driDrawable;
+GLenum textureFormat; /* EXT_texture_from_pixmap support */
};
/*
diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
index fc0e593..e5c0db4 100644
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -2631,11 +2631,19 @@ static void
Re: [Mesa3d-dev] [PATCH] Fix DRI2 accelerated EXT_texture_from_pixmap with GL_RGB format.
On Thu, 2009-03-19 at 14:34 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt wrote: This requires upgrading the interface so that the argument to glXBindTexImageEXT isn't just dropped on the floor. Note that this only fixes the accelerated path on Intel, as Mesa's texture format support is missing x8r8g8b8 support (right now, GL_RGB textures get uploaded as a8r8gb8, but in this case we're not doing the upload so we can't really work around it that way). Fixes bugs with compositors trying to use shaders that use alpha channels, on windows without a valid alpha channel. Bug #19910 and likely others as well. My only comment is that using 3 and 4 instead of GL_RGB and GL_RGBA in translate_tex_format and its callers is odd. It's not enough to make me NAK the patch, though. I was just following what the broken code before was trying to do. I'll change that in the push. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Use of GLEW in piglit?
On Mon, 2009-03-16 at 16:54 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm posting to mesa3d-dev because there doesn't appear to be a piglit mailing list. I have a couple tests that I'd like to add to piglit, but I've written them to use GLEW. Is that okay? I prefer GLEW over just defining GL_GLEXT_PROTOTYPES or trying to re-re-re-re-invent the wheel in piglit-util.c. I'd love to see GLEW added. I was just writing a test for EXT_tfp, and couldn't use glut for initialization and extension detection because I had to do GLX. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] patches to merge to mesa_7_4_branch
On Tue, 2009-03-10 at 21:53 -0700, Ian Romanick wrote: commit f085147258713741895945dcb81fdb251bb6c9cc Author: Eric Anholt e...@anholt.net Date: Thu Mar 5 08:25:22 2009 -0800 intel: Remove a gratuitous MI_FLUSH after clearing with a blit. I'd rather not do this one, to be conservative. It's not associated with any big performance win, and as we saw it already helped reveal one other bug. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): intel: make template wrappers for the spans templates.
On Thu, 2009-02-26 at 09:04 -0800, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Anholt wrote:
diff --git a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
index 1db7f55..eb898a1 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c
@@ -541,7 +541,7 @@ intelBitmap(GLcontext * ctx,
GLsizei width, GLsizei height,
const struct gl_pixelstore_attrib *unpack,
const GLubyte * pixels)
-{
+{/*
if (do_blit_bitmap(ctx, x, y, width, height,
unpack, pixels))
return;
@@ -549,7 +549,7 @@ intelBitmap(GLcontext * ctx,
if (intel_texture_bitmap(ctx, x, y, width, height,
unpack, pixels))
return;
-
+ */
if (INTEL_DEBUG DEBUG_PIXEL)
_mesa_printf(%s: fallback to swrast\n, __FUNCTION__);
Is commenting-out this block of code really what you intended?
Definitely not. Thanks!
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Revert change to allow DrawArrays/Elements with no vertex array enabled.
The 2.0 spec doesn't make things extremely clear, but expresses itself in pseudocode: If the vertex array isn't enabled, then nothing is called that provokes drawing. The manifestation of this bug was that a client drawing with no arrays enabled would get into the driver with a request to draw with _MaxElements being 0 and no inputs to the ff vertex program (since no arrays were enabled, so nothing was varying), and the driver failing all over the place. Bug #19911. --- src/mesa/main/api_validate.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/src/mesa/main/api_validate.c b/src/mesa/main/api_validate.c index 5c8955d..5253ae3 100644 --- a/src/mesa/main/api_validate.c +++ b/src/mesa/main/api_validate.c @@ -87,9 +87,8 @@ check_valid_to_render(GLcontext *ctx, char *function) return GL_FALSE; } - /* Always need vertex positions, unless a vertex program is in use */ - if (!ctx-VertexProgram._Current - !ctx-Array.ArrayObj-Vertex.Enabled + /* Always need vertex positions */ + if (!ctx-Array.ArrayObj-Vertex.Enabled !ctx-Array.ArrayObj-VertexAttrib[0].Enabled) return GL_FALSE; -- 1.5.6.5 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Cap array elements at 0 when passed an invalid pointer for an array object.
Otherwise, a pointer greater than the size would underflow and give a large
maximum element.
---
src/mesa/main/varray.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 106252e..3127c03 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -71,11 +71,17 @@ update_array(GLcontext *ctx, struct gl_client_array *array,
* Later in glDrawArrays we'll check if start + count _MaxElement to
* be sure we won't go out of bounds.
*/
- if (ctx-Array.ArrayBufferObj-Name)
- array-_MaxElement = ((GLsizeiptrARB) ctx-Array.ArrayBufferObj-Size
-- (GLsizeiptrARB) array-Ptr + array-StrideB
-- elementSize) / array-StrideB;
- else
+ if (ctx-Array.ArrayBufferObj-Name) {
+ GLsizeiptrARB offset = (GLsizeiptrARB) array-Ptr;
+ GLsizeiptrARB obj_size = (GLsizeiptrARB) array-BufferObj-Size;
+
+ if (offset obj_size) {
+array-_MaxElement = (obj_size - offset +
+ array-StrideB - elementSize) / array-StrideB;
+ } else {
+array-_MaxElement = 0;
+ }
+ } else
#endif
array-_MaxElement = 2 * 1000 * 1000 * 1000; /* just a big number */
--
1.5.6.5
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] i965: Don't upload VB state when the VP doesn't read any vertex data.
This showed up in bug #19911: When all VBs were disabled (because we were getting a DrawArrays with no arrays enabled, which was a bug), the VP got flagged as having no InputsRead. We would proceed to emit a VB state packet with -1 length, and the parser got angry with us. This doesn't fix the problem, as presumably the program is still trying to read this data. --- src/mesa/drivers/dri/i965/brw_draw_upload.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c b/src/mesa/drivers/dri/i965/brw_draw_upload.c index 02998d5..cce3eba 100644 --- a/src/mesa/drivers/dri/i965/brw_draw_upload.c +++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c @@ -469,6 +469,9 @@ static void brw_emit_vertices(struct brw_context *brw) brw_emit_query_begin(brw); + if (nr_enabled == 0) + return; + /* Now emit VB and VEP state packets. * * This still defines a hardware VB for each input, even if they -- 1.5.6.5 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] mesa: Bump maximum texture size to 4096.
idr said that in his review swrast was ready for it, and the 965 driver is
advertising it already though it has been resulting in many crashes due to
arrays using these defines not being big enough.
---
src/mesa/main/config.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
index c3feffd..9d0cd18 100644
--- a/src/mesa/main/config.h
+++ b/src/mesa/main/config.h
@@ -101,16 +101,16 @@
#define MAX_COLOR_TABLE_SIZE 256
/** Number of 1D/2D texture mipmap levels */
-#define MAX_TEXTURE_LEVELS 12
+#define MAX_TEXTURE_LEVELS 13
/** Number of 3D texture mipmap levels */
#define MAX_3D_TEXTURE_LEVELS 9
/** Number of cube texture mipmap levels - GL_ARB_texture_cube_map */
-#define MAX_CUBE_TEXTURE_LEVELS 12
+#define MAX_CUBE_TEXTURE_LEVELS 13
/** Maximum rectangular texture size - GL_NV_texture_rectangle */
-#define MAX_TEXTURE_RECT_SIZE 2048
+#define MAX_TEXTURE_RECT_SIZE 4096
/** Maximum number of layers in a 1D or 2D array texture -
GL_MESA_texture_array */
#define MAX_ARRAY_TEXTURE_LAYERS 64
@@ -166,7 +166,7 @@
#define MAX_TEXTURE_MAX_ANISOTROPY 16.0
/** For GL_EXT_texture_lod_bias (typically MAX_TEXTURE_LEVELS - 1) */
-#define MAX_TEXTURE_LOD_BIAS 11.0
+#define MAX_TEXTURE_LOD_BIAS 12.0
/** For GL_ARB_vertex_program */
/*...@{*/
--
1.5.6.5
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] intel: Expose more FBconfigs in the 3D driver.
On Sun, 2009-02-01 at 20:11 -0500, Ben Gamari wrote: What is the status of FBConfigs? I take it from the commit message of 24ff169486e315671c09cd8a57a311a935ccfff5 that 32-bit depth visuals are broken. Was this the result of this patch? Am I correct in assuming that the following repeated output from compiz is the result of the issue to whic that commit referred? compiz (core) - Warn: No GLXFBConfig for depth 32 compiz (core) - Info: Couldn't bind redirected window 0x5400026 to texture Just making sure it's a known issue. Has the exact cause in the server been identified? There was some seriously broken code in the X Server: commit 5100d829a4d71ce4a9fbc2b81694a1fb90066ccf Author: Eric Anholt e...@anholt.net Date: Mon Feb 2 10:13:46 2009 -0800 glx: Don't match fbconfigs to visuals with mismatched channel masks. This fixes at least one known bug, where the depth 32 visual would end up with a depth 24 fbconfig attached, angering compiz. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] dri2: Allow drivers to avoid round-trip on glViewport when no resize happened.
This is about a 5% win from doing two glViewport()s per frame in openarena.
---
include/GL/internal/dri_interface.h|8 +-
src/glx/x11/dri2_glx.c | 41
src/glx/x11/glxclient.h|1 +
src/mesa/drivers/dri/intel/intel_context.c | 36 +---
4 files changed, 75 insertions(+), 11 deletions(-)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 27cc1be..0ac03b5 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -636,7 +636,7 @@ struct __DRIbufferRec {
};
#define __DRI_DRI2_LOADER DRI_DRI2Loader
-#define __DRI_DRI2_LOADER_VERSION 1
+#define __DRI_DRI2_LOADER_VERSION 2
struct __DRIdri2LoaderExtensionRec {
__DRIextension base;
@@ -644,6 +644,12 @@ struct __DRIdri2LoaderExtensionRec {
int *width, int *height,
unsigned int *attachments, int count,
int *out_count, void *loaderPrivate);
+/**
+ * Optional extension, returns whether getBuffers needs to be called
+ * due to window system events.
+ */
+GLboolean (*needsGetBuffers)(__DRIdrawable *drawable,
+void *loaderPrivate);
};
/**
diff --git a/src/glx/x11/dri2_glx.c b/src/glx/x11/dri2_glx.c
index d16f809..6c36121 100644
--- a/src/glx/x11/dri2_glx.c
+++ b/src/glx/x11/dri2_glx.c
@@ -60,6 +60,9 @@ struct __GLXDRIdisplayPrivateRec {
int driMajor;
int driMinor;
int driPatch;
+
+unsigned long configureSeqno;
+Bool (*oldConfigProc)(Display *, XEvent *, xEvent *);
};
struct __GLXDRIcontextPrivateRec {
@@ -73,6 +76,7 @@ struct __GLXDRIdrawablePrivateRec {
__DRIbuffer buffers[5];
int bufferCount;
int width, height;
+unsigned long configureSeqno;
};
static void dri2DestroyContext(__GLXDRIcontext *context,
@@ -166,6 +170,7 @@ static __GLXDRIdrawable
*dri2CreateDrawable(__GLXscreenConfigs *psc,
pdraw-base.xDrawable = xDrawable;
pdraw-base.drawable = drawable;
pdraw-base.psc = psc;
+pdraw-configureSeqno = ~0;
DRI2CreateDrawable(psc-dpy, xDrawable);
@@ -249,9 +254,27 @@ dri2GetBuffers(__DRIdrawable *driDrawable,
return pdraw-buffers;
}
+static GLboolean dri2NeedsGetBuffers(__DRIdrawable *drawable,
+void *loaderPrivate)
+{
+__GLXDRIdrawablePrivate *pdraw = loaderPrivate;
+__GLXdisplayPrivate *dpyPriv = __glXInitialize(pdraw-base.psc-dpy);
+__GLXDRIdisplayPrivate *pdp;
+
+pdp = (__GLXDRIdisplayPrivate *)dpyPriv-dri2Display;
+
+if (pdraw-configureSeqno != pdp-configureSeqno) {
+ pdraw-configureSeqno = pdp-configureSeqno;
+ return GL_TRUE;
+}
+
+return GL_FALSE;
+}
+
static const __DRIdri2LoaderExtension dri2LoaderExtension = {
{ __DRI_DRI2_LOADER, __DRI_DRI2_LOADER_VERSION },
dri2GetBuffers,
+dri2NeedsGetBuffers,
};
static const __DRIextension *loader_extensions[] = {
@@ -365,6 +388,21 @@ static void dri2DestroyDisplay(__GLXDRIdisplay *dpy)
Xfree(dpy);
}
+static Bool dri2ConfigureNotifyProc(Display *dpy, XEvent *re, xEvent *event)
+{
+__GLXdisplayPrivate *dpyPriv = __glXInitialize(dpy);
+__GLXDRIdisplayPrivate *pdp;
+Bool ret;
+
+pdp = (__GLXDRIdisplayPrivate *)dpyPriv-dri2Display;
+
+ret = pdp-oldConfigProc(dpy, re, event);
+
+pdp-configureSeqno = re-xconfigure.serial;
+
+return ret;
+}
+
/*
* Allocate, initialize and return a __DRIdisplayPrivate object.
* This is called from __glXInitialize() when we are given a new
@@ -387,6 +425,9 @@ _X_HIDDEN __GLXDRIdisplay *dri2CreateDisplay(Display *dpy)
return NULL;
}
+pdp-oldConfigProc = XESetWireToEvent(dpy, ConfigureNotify,
+ dri2ConfigureNotifyProc);
+
pdp-driPatch = 0;
pdp-base.destroyDisplay = dri2DestroyDisplay;
diff --git a/src/glx/x11/glxclient.h b/src/glx/x11/glxclient.h
index 16f6074..bdc6287 100644
--- a/src/glx/x11/glxclient.h
+++ b/src/glx/x11/glxclient.h
@@ -602,6 +602,7 @@ extern void __glXSendLargeCommand(__GLXcontext *, const
GLvoid *, GLint,
const GLvoid *, GLint);
/* Initialize the GLX extension for dpy */
+extern __GLXdisplayPrivate * __glXGetPrivateFromDisplay(Display *dpy);
extern __GLXdisplayPrivate *__glXInitialize(Display*);
//
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
b/src/mesa/drivers/dri/intel/intel_context.c
index 0d9487b..06360e5 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -296,20 +296,36 @@ intel_viewport(GLcontext *ctx, GLint x, GLint y, GLsizei
w, GLsizei h)
__DRIcontext *driContext = intel-driContext;
void (*old_viewport)(GLcontext *ctx, GLint x, GLint y,
Re: [Mesa3d-dev] [PATCH] intel: Expose more FBconfigs in the 3D driver.
On Fri, 2009-01-30 at 00:03 +, Peter Clifton wrote: On Thu, 2009-01-29 at 15:08 -0800, Eric Anholt wrote: We can support any combination of (a8r8g8b8, x8r8g8b8, r5g6b5) x (z0,z24,z24s8) on either class of chipsets. The only restriction is no mixing bpp when also mixing tiling. This shouldn't be occurring currently. Slightly hijacking, since this isn't a direct comment on the above patch.. I think it might be useful to expose some combinations with 0 alpha bits. If we don't, there is no obvious way of flagging when you're mapping a 24bit depth X Pixmap onto a texture. The setTexBuffer hook can look at the fbconfig of the GLXPixmap the texture is targeting, but can't (as far as I could figure out) inspect what format the X server knows the data is in (we have cpp from DRI2, but that doesn't tell us if the alpha channel is used or not). That's what this patch was about -- exposing FBconfigs with 0 alpha bits, so that your compositor had some hope of doing the right thing. The other combinations were well, why not. Though the server is somehow killing the reporting of r5g6b5 on my a8r8g8b8 system. You also may want to look at what clutter is doing for an alternative method of expressing the information for TFP in case of emergency, using TexImage to create storage and then letting it get thrown away. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] fix for #18074?
Here's a pair of patches I came up with tonight when looking at #18074 and #14503. The first looks like we might end up with junk in a temporary if we wrote it, did a masked texld, then wrote to it again with a destination write mask. The second creates a mapping from register-Index to hardware temporary registers. I don't have the apps in question, so I haven't tested it. Searching for people reporting the message came up with these two bug reports plus cube, and I found that sauer did trigger it. However, sauer still fails on a bunch of its shaders due to texture indirections, so I can't place accurate blame for the nasty rendering I see. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] i915: Fix calc_live_regs to not mark things previously dead when writemasked.
This means we're now overestimating liveliness of regs, but better than the
other way around. It also makes fixing #18074 easier.
---
src/mesa/drivers/dri/i915/i915_fragprog.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index 4760906..46f1740 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -274,23 +274,28 @@ static void calc_live_regs( struct i915_fragment_program
*p )
const struct gl_fragment_program *program =
p-ctx-FragmentProgram._Current;
GLuint regsUsed = 0x;
GLint i;
-
+
+/* Work from the front marking regs as live when they're written to. */
+for (i = 0; i program-Base.NumInstructions; i++) {
+struct prog_instruction *inst = program-Base.Instructions[i];
+
+if (inst-DstReg.File == PROGRAM_TEMPORARY)
+regsUsed |= 1 inst-DstReg.Index;
+p-usedRegs[i] = regsUsed;
+}
+
+/* Work from the back, turning off the live bit until it's read. */
+regsUsed = 0;
for (i = program-Base.NumInstructions - 1; i = 0; i--) {
struct prog_instruction *inst = program-Base.Instructions[i];
int opArgs = _mesa_num_inst_src_regs(inst-Opcode);
int a;
-/* Register is written to: unmark as live for this and preceeding ops
*/
-if (inst-DstReg.File == PROGRAM_TEMPORARY)
-regsUsed = ~(1 inst-DstReg.Index);
-
for (a = 0; a opArgs; a++) {
-/* Register is read from: mark as live for this and preceeding ops
*/
if (inst-SrcReg[a].File == PROGRAM_TEMPORARY)
regsUsed |= 1 inst-SrcReg[a].Index;
}
-
-p-usedRegs[i] = regsUsed;
+p-usedRegs[i] = regsUsed;
}
}
@@ -302,7 +307,6 @@ static GLuint get_live_regs( struct i915_fragment_program
*p,
return p-usedRegs[nr];
}
-
/* Possible concerns:
*
--
1.5.6.5
--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] i915: Allow more than 16 temporaries to be used, if 16 are used at a time.
Bug #18074
---
src/mesa/drivers/dri/i915/i915_context.c |3 +-
src/mesa/drivers/dri/i915/i915_context.h |1 +
src/mesa/drivers/dri/i915/i915_fragprog.c | 82 +
src/mesa/drivers/dri/i915/i915_reg.h |4 +-
4 files changed, 76 insertions(+), 14 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_context.c
b/src/mesa/drivers/dri/i915/i915_context.c
index 9bff742..010cf0c 100644
--- a/src/mesa/drivers/dri/i915/i915_context.c
+++ b/src/mesa/drivers/dri/i915/i915_context.c
@@ -159,7 +159,8 @@ i915CreateContext(const __GLcontextModes * mesaVis,
* instruction can translate to more than one HW instruction, so
* we'll still have to check and fallback each time.
*/
- ctx-Const.FragmentProgram.MaxNativeTemps = I915_MAX_TEMPORARY;
+ ctx-Const.FragmentProgram.MaxTemps = I915_MAX_TEMPS;
+ ctx-Const.FragmentProgram.MaxNativeTemps = I915_MAX_NATIVE_TEMPS;
ctx-Const.FragmentProgram.MaxNativeAttribs = 11;/* 8 tex, 2 color, fog
*/
ctx-Const.FragmentProgram.MaxNativeParameters = I915_MAX_CONSTANT;
ctx-Const.FragmentProgram.MaxNativeAluInstructions = I915_MAX_ALU_INSN;
diff --git a/src/mesa/drivers/dri/i915/i915_context.h
b/src/mesa/drivers/dri/i915/i915_context.h
index 87bbf5f..a5df3fa 100644
--- a/src/mesa/drivers/dri/i915/i915_context.h
+++ b/src/mesa/drivers/dri/i915/i915_context.h
@@ -177,6 +177,7 @@ struct i915_fragment_program
* it's read. */
GLuint usedRegs[I915_MAX_INSN];
+ GLuint temp_reg_mapping[I915_MAX_TEMPS];
/* Helpers for i915_fragprog.c:
*/
GLuint wpos_tex;
diff --git a/src/mesa/drivers/dri/i915/i915_fragprog.c
b/src/mesa/drivers/dri/i915/i915_fragprog.c
index 46f1740..ef22beb 100644
--- a/src/mesa/drivers/dri/i915/i915_fragprog.c
+++ b/src/mesa/drivers/dri/i915/i915_fragprog.c
@@ -87,11 +87,7 @@ src_vector(struct i915_fragment_program *p,
/* Registers:
*/
case PROGRAM_TEMPORARY:
- if (source-Index = I915_MAX_TEMPORARY) {
- i915_program_error(p, Exceeded max temporary reg);
- return 0;
- }
- src = UREG(REG_TYPE_R, source-Index);
+ src = UREG(REG_TYPE_R, p-temp_reg_mapping[source-Index]);
break;
case PROGRAM_INPUT:
switch (source-Index) {
@@ -272,15 +268,17 @@ do {
\
static void calc_live_regs( struct i915_fragment_program *p )
{
const struct gl_fragment_program *program =
p-ctx-FragmentProgram._Current;
-GLuint regsUsed = 0x;
+GLuint regsUsed = 0;
GLint i;
/* Work from the front marking regs as live when they're written to. */
for (i = 0; i program-Base.NumInstructions; i++) {
struct prog_instruction *inst = program-Base.Instructions[i];
-if (inst-DstReg.File == PROGRAM_TEMPORARY)
+if (inst-DstReg.File == PROGRAM_TEMPORARY) {
+ assert(inst-DstReg.Index I915_MAX_TEMPS);
regsUsed |= 1 inst-DstReg.Index;
+ }
p-usedRegs[i] = regsUsed;
}
@@ -292,20 +290,83 @@ static void calc_live_regs( struct i915_fragment_program
*p )
int a;
for (a = 0; a opArgs; a++) {
-if (inst-SrcReg[a].File == PROGRAM_TEMPORARY)
+ if (inst-SrcReg[a].File == PROGRAM_TEMPORARY) {
+ assert(inst-SrcReg[a].Index I915_MAX_TEMPS);
regsUsed |= 1 inst-SrcReg[a].Index;
+ }
}
p-usedRegs[i] = regsUsed;
}
}
+/* Returns the set of live hw registers at the moment, by working from
+ * the set of live sw temporaries.
+ */
static GLuint get_live_regs( struct i915_fragment_program *p,
const struct prog_instruction *inst )
{
const struct gl_fragment_program *program =
p-ctx-FragmentProgram._Current;
GLuint nr = inst - program-Base.Instructions;
+GLuint live_sw_regs = p-usedRegs[nr];
+GLuint live_hw_regs = 0;
+
+while (live_sw_regs != 0) {
+ int sw_reg = ffs(live_sw_regs) - 1;
+
+ live_sw_regs = ~(1 sw_reg);
+ live_hw_regs |= 1 p-temp_reg_mapping[sw_reg];
+}
-return p-usedRegs[nr];
+/* Return invalid hw regs as live, as the consumer looking for a
+ * temporary will use ffs on the inverse.
+ */
+return 0x | live_hw_regs;
+}
+
+/**
+ * Creates the mapping from ARB program temporary indices to native indices.
+ *
+ * This lets us run some programs which would otherwise exceed our limits on
+ * number of temporaries. Note that this code relies on calc_live_regs
+ * marking live from first write through last read, as otherwise we might
+ * assign it two different hw regs and end up stomping on live stuff.
+ */
+static void
+create_temp_mapping(struct i915_fragment_program *p)
+{
+ const struct gl_fragment_program *program =
p-ctx-FragmentProgram._Current;
+ GLuint avail_hw_regs = 0x; /* 1 I915_MAX_NATIVE_TEMPS - 1 */
+ GLuint assigned_sw_indices = 0;
+ int i;
+
Re: [Mesa3d-dev] fix for #18074?
On Wed, 2009-01-07 at 10:07 +, Keith Whitwell wrote: On Wed, 2009-01-07 at 01:49 -0800, Eric Anholt wrote: Here's a pair of patches I came up with tonight when looking at #18074 and #14503. The first looks like we might end up with junk in a temporary if we wrote it, did a masked texld, then wrote to it again with a destination write mask. The second creates a mapping from register-Index to hardware temporary registers. I don't have the apps in question, so I haven't tested it. Searching for people reporting the message came up with these two bug reports plus cube, and I found that sauer did trigger it. However, sauer still fails on a bunch of its shaders due to texture indirections, so I can't place accurate blame for the nasty rendering I see. Is the purpose of the second patch to advertise more temps than the hardware actually supports then try and wiggle them all into hw regs by identifying live vs non-live regs? I guess one worry is that advertising greater capabilities than really exist may encourage some apps to switch to more complicated shaders (that really can't be squeezed into hardware) and end up on fallback paths where previously they would have been fine. I don't have specific examples to hand, but there have been equivalent issues in other situations -- if an app sees a certain capability advertised, it doesn't have any way of knowing that it only works under some circumstances not others. We have to advertise at least 16 temps. However, the fog code eats some of them. So we need to compress things down to hardware temps somehow, and 32 ended up being the number of -Index values I could handle in the instructions with simple uint32 code. We do still end up with the problem that someone using 32 temps and fog will exceed limits because of how the accounting in Mesa works. We could also do better by throwing things that are live only between phase boundaries into U regs instead of R regs, potentially getting us up to 22 native temporaries live at a time. I understand the predictability concern for developers. But it comes down to: Are we the exception in being unable to run shaders that the hardware is capable of? These apps all work on ATI and NVIDIA. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] mesa: Remove _Active and _UseTexEnvProgram flags from fragment programs.
There was a note in state.c about _Active deserving to die, and there were
potential issues with it due to i965 forgetting to set _UseTexEnvProgram.
Removing both simplifies things.
---
src/mesa/drivers/dri/i915/i915_context.c |1 -
src/mesa/drivers/dri/i915/i915_state.c|2 +-
src/mesa/drivers/dri/intel/intel_pixel_draw.c | 25 ++---
src/mesa/main/context.c |1 -
src/mesa/main/mtypes.h|2 --
src/mesa/main/state.c | 11 ---
src/mesa/swrast/s_aalinetemp.h|2 +-
src/mesa/tnl/t_context.c |2 +-
8 files changed, 5 insertions(+), 41 deletions(-)
diff --git a/src/mesa/drivers/dri/i915/i915_context.c
b/src/mesa/drivers/dri/i915/i915_context.c
index 9bff742..3d6af38 100644
--- a/src/mesa/drivers/dri/i915/i915_context.c
+++ b/src/mesa/drivers/dri/i915/i915_context.c
@@ -171,7 +171,6 @@ i915CreateContext(const __GLcontextModes * mesaVis,
ctx-Const.FragmentProgram.MaxNativeAddressRegs = 0; /* I don't think we
have one */
ctx-FragmentProgram._MaintainTexEnvProgram = GL_TRUE;
- ctx-FragmentProgram._UseTexEnvProgram = GL_TRUE;
driInitExtensions(ctx, i915_extensions, GL_FALSE);
diff --git a/src/mesa/drivers/dri/i915/i915_state.c
b/src/mesa/drivers/dri/i915/i915_state.c
index 9d04358..a53f120 100644
--- a/src/mesa/drivers/dri/i915/i915_state.c
+++ b/src/mesa/drivers/dri/i915/i915_state.c
@@ -569,7 +569,7 @@ i915_update_fog(GLcontext * ctx)
GLboolean enabled;
GLboolean try_pixel_fog;
- if (ctx-FragmentProgram._Active) {
+ if (ctx-FragmentProgram._Current) {
/* Pull in static fog state from program */
mode = ctx-FragmentProgram._Current-FogOption;
enabled = (mode != GL_NONE);
diff --git a/src/mesa/drivers/dri/intel/intel_pixel_draw.c
b/src/mesa/drivers/dri/intel/intel_pixel_draw.c
index 0d66935..2af839b 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_draw.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_draw.c
@@ -386,27 +386,6 @@ intelDrawPixels(GLcontext * ctx,
if (INTEL_DEBUG DEBUG_PIXEL)
_mesa_printf(%s: fallback to swrast\n, __FUNCTION__);
- if (ctx-FragmentProgram._Current == ctx-FragmentProgram._TexEnvProgram) {
- /*
- * We don't want the i915 texenv program to be applied to DrawPixels.
- * This is really just a performance optimization (mesa will other-
- * wise happily run the fragment program on each pixel in the image).
- */
- struct gl_fragment_program *fpSave = ctx-FragmentProgram._Current;
- /* can't just set current frag prog to 0 here as on buffer resize
- we'll get new state checks which will segfault. Remains a hack. */
- ctx-FragmentProgram._Current = NULL;
- ctx-FragmentProgram._UseTexEnvProgram = GL_FALSE;
- ctx-FragmentProgram._Active = GL_FALSE;
- _swrast_DrawPixels( ctx, x, y, width, height, format, type,
- unpack, pixels );
- ctx-FragmentProgram._Current = fpSave;
- ctx-FragmentProgram._UseTexEnvProgram = GL_TRUE;
- ctx-FragmentProgram._Active = GL_TRUE;
- _swrast_InvalidateState(ctx, _NEW_PROGRAM);
- }
- else {
- _swrast_DrawPixels( ctx, x, y, width, height, format, type,
- unpack, pixels );
- }
+ _swrast_DrawPixels(ctx, x, y, width, height, format, type,
+ unpack, pixels);
}
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index b59ad35..98c23bb 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -1225,7 +1225,6 @@ _mesa_initialize_context(GLcontext *ctx,
ctx-FragmentProgram._MaintainTexEnvProgram
= (_mesa_getenv(MESA_TEX_PROG) != NULL);
- ctx-FragmentProgram._UseTexEnvProgram =
ctx-FragmentProgram._MaintainTexEnvProgram;
ctx-VertexProgram._MaintainTnlProgram
= (_mesa_getenv(MESA_TNL_PROG) != NULL);
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index 9cb6159..3eca8a8 100644
--- a/src/mesa/main/mtypes.h
+++ b/src/mesa/main/mtypes.h
@@ -2011,8 +2011,6 @@ struct gl_fragment_program_state
/** Should fixed-function texturing be implemented with a fragment prog? */
GLboolean _MaintainTexEnvProgram;
- GLboolean _UseTexEnvProgram;
- GLboolean _Active; /** Use internal texenv program? */
/** Program to emulate fixed-function texture env/combine (see above) */
struct gl_fragment_program *_TexEnvProgram;
diff --git a/src/mesa/main/state.c b/src/mesa/main/state.c
index df1d197..6fe54c7 100644
--- a/src/mesa/main/state.c
+++ b/src/mesa/main/state.c
@@ -254,17 +254,6 @@ update_program(GLcontext *ctx)
_mesa_reference_vertprog(ctx, ctx-VertexProgram._Current, NULL);
}
- /* XXX: get rid of _Active flag.
-*/
-#if 1
- ctx-FragmentProgram._Active = ctx-FragmentProgram._Enabled;
- if (ctx-FragmentProgram._MaintainTexEnvProgram
- !ctx-FragmentProgram._Enabled) {
- if
[Mesa3d-dev] [PATCH] dri: Fix driWaitForMSC32 when divisor = 2 and msc 0.
We'd come up with a negative remainder, while we were looking for the positive
version of it in the loop conditional. And, since the did we hit our target
break was disabled for the target_msc == 0 (Just make the divisor/remainder
work) path, we'd never exit.
Simplify the code by just using int64_t all over instead of trying to do it
in a u32 space.
---
src/mesa/drivers/dri/common/vblank.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/src/mesa/drivers/dri/common/vblank.c
b/src/mesa/drivers/dri/common/vblank.c
index d610253..3f5586e 100644
--- a/src/mesa/drivers/dri/common/vblank.c
+++ b/src/mesa/drivers/dri/common/vblank.c
@@ -130,9 +130,9 @@ int driWaitForMSC32( __DRIdrawablePrivate *priv,
if ( divisor != 0 ) {
- unsigned int target = (unsigned int)target_msc;
- unsigned int next = target;
- unsigned int r;
+ int64_t target = (unsigned int)target_msc;
+ int64_t next = target;
+ int64_t r;
int dont_wait = (target_msc == 0);
do {
@@ -154,9 +154,9 @@ int driWaitForMSC32( __DRIdrawablePrivate *priv,
*msc = vblank_to_msc(priv, vbl.reply.sequence);
- dont_wait = 0;
- if (target_msc != 0 *msc == target)
+ if (!dont_wait *msc == next)
break;
+ dont_wait = 0;
/* Assuming the wait-done test fails, the next refresh to wait for
* will be one that satisfies (MSC % divisor) == remainder. The
@@ -165,11 +165,12 @@ int driWaitForMSC32( __DRIdrawablePrivate *priv,
* If this refresh has already happened, we add divisor to obtain
* the next refresh after the current one that will satisfy it.
*/
- r = (*msc % (unsigned int)divisor);
- next = (*msc - r + (unsigned int)remainder);
- if (next = *msc) next += (unsigned int)divisor;
+ r = ((uint64_t)*msc % divisor);
+ next = (*msc - r + remainder);
+ if (next = *msc)
+ next += divisor;
- } while ( r != (unsigned int)remainder );
+ } while (r != remainder);
}
else {
/* If the \c divisor is zero, just wait until the MSC is greater
--
1.5.6.5
--
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] fixing the fixes for blit operation clipping
Here's a patch series I'm working on for fixing #19139. The OGLC testcase fails still, and I think I'm going to just write myself some nice little visual testcases for piglit instead of continuing to guess at what's wrong. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] intel: Don't forget the source bitmap size when clipping the size we draw.
--- src/mesa/drivers/dri/intel/intel_pixel_bitmap.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c index 4988230..38581d9 100644 --- a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c +++ b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c @@ -171,6 +171,8 @@ do_blit_bitmap( GLcontext *ctx, unsigned int num_cliprects; drm_clip_rect_t *cliprects; int x_off, y_off; + GLsizei bitmap_width = width; + GLsizei bitmap_height = height; /* Update draw buffer bounds */ _mesa_update_state(ctx); @@ -277,7 +279,7 @@ do_blit_bitmap( GLcontext *ctx, /* May need to adjust this when padding has been introduced in * sz above: */ - if (get_bitmap_rect(width, height, unpack, + if (get_bitmap_rect(bitmap_width, bitmap_height, unpack, bitmap, srcx + px, srcy + py, w, h, (GLubyte *)stipple, -- 1.5.6.5 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] intel: don't clip to scissor-clipped read framebuffer bounds.
Mesa core also has this bug for CopyTexSubImage.
---
src/mesa/drivers/dri/intel/intel_pixel_copy.c |4 ++--
src/mesa/drivers/dri/intel/intel_tex_copy.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_pixel_copy.c
b/src/mesa/drivers/dri/intel/intel_pixel_copy.c
index 61d1296..1505af2 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_copy.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_copy.c
@@ -308,8 +308,8 @@ do_blit_copypixels(GLcontext * ctx,
/* Clip to source buffer. */
orig_srcx = srcx;
orig_srcy = srcy;
- if (!_mesa_clip_to_region(read_fb-_Xmin, read_fb-_Ymin,
- read_fb-_Xmax, read_fb-_Ymax,
+ if (!_mesa_clip_to_region(0, 0,
+ read_fb-Width, read_fb-Height,
srcx, srcy, width, height))
goto out;
/* Adjust dst coords for our post-clipped source origin */
diff --git a/src/mesa/drivers/dri/intel/intel_tex_copy.c
b/src/mesa/drivers/dri/intel/intel_tex_copy.c
index b893990..22d8f18 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_copy.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_copy.c
@@ -114,7 +114,7 @@ do_copy_texsubimage(struct intel_context *intel,
const GLint orig_y = y;
const struct gl_framebuffer *fb = ctx-DrawBuffer;
- if (_mesa_clip_to_region(fb-_Xmin, fb-_Ymin, fb-_Xmax, fb-_Ymax,
+ if (_mesa_clip_to_region(0, 0, fb-Width, fb-Height,
x, y, width, height)) {
GLshort src_pitch;
--
1.5.6.5
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] intel: Update mesa state in blit operations that want post-scissor draw bounds.
--- src/mesa/drivers/dri/intel/intel_pixel_bitmap.c |3 +++ src/mesa/drivers/dri/intel/intel_pixel_copy.c |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c index e3ce149..4988230 100644 --- a/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c +++ b/src/mesa/drivers/dri/intel/intel_pixel_bitmap.c @@ -172,6 +172,9 @@ do_blit_bitmap( GLcontext *ctx, drm_clip_rect_t *cliprects; int x_off, y_off; + /* Update draw buffer bounds */ + _mesa_update_state(ctx); + if (!dst) return GL_FALSE; diff --git a/src/mesa/drivers/dri/intel/intel_pixel_copy.c b/src/mesa/drivers/dri/intel/intel_pixel_copy.c index 1505af2..447c649 100644 --- a/src/mesa/drivers/dri/intel/intel_pixel_copy.c +++ b/src/mesa/drivers/dri/intel/intel_pixel_copy.c @@ -266,6 +266,9 @@ do_blit_copypixels(GLcontext * ctx, drm_clip_rect_t *cliprects; int x_off, y_off; + /* Update draw buffer bounds */ + _mesa_update_state(ctx); + /* Copypixels can be more than a straight copy. Ensure all the * extra operations are disabled: */ -- 1.5.6.5 -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Suggestion for caching of compiled shaders to speed up application startup
On Tue, 2008-12-09 at 21:03 +0200, Pekka Paalanen wrote: On Mon, 08 Dec 2008 14:48:33 +0100 Philipp Klaus Krause [EMAIL PROTECTED] wrote: - From time to time people say that they want support for precompiled shaders in the OpenGL API. The main point for this they bring forth is reducing loading times for their applications. I think this advantage of precompiled shaders can be had without support for it in the API: It can be inmplemented transparently in the driver. Is it just a theoretical gain, or do the people actually have public benchmark results showing that the net gain with cold/hot disk cache is is noticeable? A quick spin in Google gave me nothing, but I would not be surprised if I just missed the right keywords. Or is compiling shaders with Mesa so hideously slow that it would be a clear benefit even without benchmarking? I can also come up with another reason to have precompiled shaders: protecting the shader source code. I am not sure that makes any sense, though. sauerbraten with the ARB_[fv]p path just spent 60% of its 45-second startup time with a hot cache in mesa's program parsing, and it doesn't have that many programs. However, I'd love to see a conversion of mesa's ARB_[fv]p parsing to lex/yacc before we built a complicated infrastructure to work around the performance of the current homebrew code. Similarly for GLSL -- hopefully the GLSL rewrite can show some results soon. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] intel: Fix crash in automatic mipmap generation for glCopyTex{Sub, }Image.
The images aren't mapped at this point, so we want the generic Mesa path for
GenerateMipmapEXT that does the mapping/unmapping for us. Ideally Mesa would
just call it for us.
---
src/mesa/drivers/dri/intel/intel_tex_copy.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_tex_copy.c
b/src/mesa/drivers/dri/intel/intel_tex_copy.c
index dd932ae..b893990 100644
--- a/src/mesa/drivers/dri/intel/intel_tex_copy.c
+++ b/src/mesa/drivers/dri/intel/intel_tex_copy.c
@@ -167,7 +167,7 @@ do_copy_texsubimage(struct intel_context *intel,
/* GL_SGIS_generate_mipmap */
if (intelImage-level == texObj-BaseLevel texObj-GenerateMipmap) {
- intel_generate_mipmap(ctx, target, texObj);
+ ctx-Driver.GenerateMipmap(ctx, target, texObj);
}
return GL_TRUE;
--
1.5.6.5
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] intel: Fall back on rendering to a texture attachment with a border.
Fixes a segfault in oglconform fbo.c test.
---
src/mesa/drivers/dri/intel/intel_fbo.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
b/src/mesa/drivers/dri/intel/intel_fbo.c
index fce5e36..7453b96 100644
--- a/src/mesa/drivers/dri/intel/intel_fbo.c
+++ b/src/mesa/drivers/dri/intel/intel_fbo.c
@@ -620,7 +620,14 @@ intel_render_texture(GLcontext * ctx,
ASSERT(newImage);
- if (!irb) {
+ if (newImage-Border != 0) {
+ /* Fallback on drawing to a texture with a border, which won't have a
+ * miptree.
+ */
+ _mesa_reference_renderbuffer(att-Renderbuffer, NULL);
+ _mesa_render_texture(ctx, fb, att);
+ return;
+ } else if (!irb) {
irb = intel_wrap_texture(ctx, newImage);
if (irb) {
/* bind the wrapper to the attachment point */
--
1.5.6.5
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] mesa: Fix GenerateMipmapEXT(GL_TEXTURE_CUBE_MAP_ARB).
The ctx-Driver.GenerateMipmap() hook only expects cubemap face enums, not
CUBE_MAP_ARB, so walk all faces when we encounter that. Fixes oglconform
fbo.c segfault with both swrast and i965 drivers.
---
src/mesa/main/fbobject.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 4c92d1f..876d691 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1574,9 +1574,17 @@ _mesa_GenerateMipmapEXT(GLenum target)
texUnit = ctx-Texture.Unit[ctx-Texture.CurrentUnit];
texObj = _mesa_select_tex_object(ctx, texUnit, target);
- /* XXX this might not handle cube maps correctly */
_mesa_lock_texture(ctx, texObj);
- ctx-Driver.GenerateMipmap(ctx, target, texObj);
+ if (target == GL_TEXTURE_CUBE_MAP) {
+ int face;
+
+ for (face = 0; face 6; face++)
+ctx-Driver.GenerateMipmap(ctx,
+ GL_TEXTURE_CUBE_MAP_POSITIVE_X_ARB + face,
+ texObj);
+ } else {
+ ctx-Driver.GenerateMipmap(ctx, target, texObj);
+ }
_mesa_unlock_texture(ctx, texObj);
}
--
1.5.6.5
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] intel: Fix glCopyPixels blit acceleration for FBO destinations.
This was another opportunity to either get clipped to screen size or not get
clipped enough and draw outside of object boundaries.
---
src/mesa/drivers/dri/intel/intel_pixel_copy.c | 104 +---
1 files changed, 56 insertions(+), 48 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_pixel_copy.c
b/src/mesa/drivers/dri/intel/intel_pixel_copy.c
index 1b3cb5a..61d1296 100644
--- a/src/mesa/drivers/dri/intel/intel_pixel_copy.c
+++ b/src/mesa/drivers/dri/intel/intel_pixel_copy.c
@@ -260,6 +260,11 @@ do_blit_copypixels(GLcontext * ctx,
struct intel_context *intel = intel_context(ctx);
struct intel_region *dst = intel_drawbuf_region(intel);
struct intel_region *src = copypix_src_region(intel, type);
+ struct gl_framebuffer *fb = ctx-DrawBuffer;
+ struct gl_framebuffer *read_fb = ctx-ReadBuffer;
+ unsigned int num_cliprects;
+ drm_clip_rect_t *cliprects;
+ int x_off, y_off;
/* Copypixels can be more than a straight copy. Ensure all the
* extra operations are disabled:
@@ -277,71 +282,74 @@ do_blit_copypixels(GLcontext * ctx,
LOCK_HARDWARE(intel);
- if (intel-driDrawable-numClipRects) {
- __DRIdrawablePrivate *dPriv = intel-driDrawable;
- __DRIdrawablePrivate *dReadPriv = intel-driReadDrawable;
- drm_clip_rect_t *box = dPriv-pClipRects;
- GLint nbox = dPriv-numClipRects;
- GLint delta_x = 0;
- GLint delta_y = 0;
+ intel_get_cliprects(intel, cliprects, num_cliprects, x_off, y_off);
+ if (num_cliprects != 0) {
+ GLint delta_x;
+ GLint delta_y;
+ GLint orig_dstx;
+ GLint orig_dsty;
+ GLint orig_srcx;
+ GLint orig_srcy;
GLuint i;
- /* Do scissoring in GL coordinates:
- */
- if (ctx-Scissor.Enabled)
- {
-GLint x = ctx-Scissor.X;
-GLint y = ctx-Scissor.Y;
-GLuint w = ctx-Scissor.Width;
-GLuint h = ctx-Scissor.Height;
-GLint dx = dstx - srcx;
- GLint dy = dsty - srcy;
-
- if (!_mesa_clip_to_region(x, y, x+w-1, y+h-1, dstx, dsty, width,
height))
-goto out;
-
- srcx = dstx - dx;
- srcy = dsty - dy;
- }
+ /* XXX: We fail to handle different inversion between read and draw
framebuffer. */
+
+ /* Clip to destination buffer. */
+ orig_dstx = dstx;
+ orig_dsty = dsty;
+ if (!_mesa_clip_to_region(fb-_Xmin, fb-_Ymin,
+ fb-_Xmax, fb-_Ymax,
+ dstx, dsty, width, height))
+goto out;
+ /* Adjust src coords for our post-clipped destination origin */
+ srcx += dstx - orig_dstx;
+ srcy += dsty - orig_dsty;
+
+ /* Clip to source buffer. */
+ orig_srcx = srcx;
+ orig_srcy = srcy;
+ if (!_mesa_clip_to_region(read_fb-_Xmin, read_fb-_Ymin,
+ read_fb-_Xmax, read_fb-_Ymax,
+ srcx, srcy, width, height))
+goto out;
+ /* Adjust dst coords for our post-clipped source origin */
+ dstx += srcx - orig_srcx;
+ dsty += srcy - orig_srcy;
/* Convert from GL to hardware coordinates:
*/
- dsty = dPriv-h - dsty - height;
- srcy = dPriv-h - srcy - height;
- dstx += dPriv-x;
- dsty += dPriv-y;
- srcx += dReadPriv-x;
- srcy += dReadPriv-y;
-
- /* Clip against the source region. This is the only source
- * clipping we do. Dst is clipped with cliprects below.
- */
- {
- delta_x = srcx - dstx;
- delta_y = srcy - dsty;
-
- if (!_mesa_clip_to_region(0, 0, src-pitch, src-height,
- srcx, srcy, width, height))
-goto out;
+ if (fb-Name == 0) {
+/* copypixels to a system framebuffer */
+dstx = x_off + dstx;
+dsty = y_off + (fb-Height - dsty - height);
+ } else {
+/* copypixels to a user framebuffer object */
+dstx = x_off + dstx;
+dsty = y_off + dsty;
+ }
- dstx = srcx - delta_x;
- dsty = srcy - delta_y;
+ /* Flip source Y if it's a system framebuffer. */
+ if (read_fb-Name == 0) {
+srcx = intel-driReadDrawable-x + srcx;
+srcy = intel-driReadDrawable-y + (fb-Height - srcy - height);
}
+ delta_x = srcx - dstx;
+ delta_y = srcy - dsty;
/* Could do slightly more clipping: Eg, take the intersection of
- * the existing set of cliprects and those cliprects translated
- * by delta_x, delta_y:
- *
+ * the destination cliprects and the read drawable cliprects
+ *
* This code will not overwrite other windows, but will
* introduce garbage when copying from obscured window regions.
*/
- for (i = 0; i nbox; i++) {
+ for (i = 0; i num_cliprects; i++) {
GLint clip_x = dstx;
GLint clip_y = dsty;
GLint clip_w = width;
GLint clip_h = height;
-
[Mesa3d-dev] [PATCH] i965: Reduce fast-pathiness of brw_try_draw_prims, bringing in important checks.
Later primitives, even if they caused a full state validate, wouldn't check
that there was enough space in the batchbuffer, occasionally triggering the
sanity check. We also skipped the aperture space check, even if it would
mean bringing in new programs and associated state.
---
src/mesa/drivers/dri/i965/brw_draw.c | 103 +-
1 files changed, 52 insertions(+), 51 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index f893dd6..c3a26fc 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -49,7 +49,7 @@
#define FILE_DEBUG_FLAG DEBUG_BATCH
-static GLuint hw_prim[GL_POLYGON+1] = {
+static GLuint prim_to_hw_prim[GL_POLYGON+1] = {
_3DPRIM_POINTLIST,
_3DPRIM_LINELIST,
_3DPRIM_LINELOOP,
@@ -103,12 +103,9 @@ static GLuint brw_set_prim(struct brw_context *brw, GLenum
prim)
brw-intel.reduced_primitive = reduced_prim[prim];
brw-state.dirty.brw |= BRW_NEW_REDUCED_PRIMITIVE;
}
-
- brw_validate_state(brw);
- brw_upload_state(brw);
}
- return hw_prim[prim];
+ return prim_to_hw_prim[prim];
}
@@ -123,9 +120,9 @@ static GLuint trim(GLenum prim, GLuint length)
}
-static void brw_emit_prim( struct brw_context *brw,
- const struct _mesa_prim *prim )
-
+static void brw_emit_prim(struct brw_context *brw,
+ const struct _mesa_prim *prim,
+ uint32_t hw_prim)
{
struct brw_3d_primitive prim_packet;
@@ -136,7 +133,7 @@ static void brw_emit_prim( struct brw_context *brw,
prim_packet.header.opcode = CMD_3D_PRIM;
prim_packet.header.length = sizeof(prim_packet)/4 - 2;
prim_packet.header.pad = 0;
- prim_packet.header.topology = brw_set_prim(brw, prim-mode);
+ prim_packet.header.topology = hw_prim;
prim_packet.header.indexed = prim-indexed;
prim_packet.verts_per_instance = trim(prim-mode, prim-count);
@@ -258,11 +255,15 @@ static GLboolean brw_try_draw_prims( GLcontext *ctx,
struct brw_context *brw = brw_context(ctx);
GLboolean retval = GL_FALSE;
GLboolean warn = GL_FALSE;
+ GLboolean first_time = GL_TRUE;
GLuint i;
if (ctx-NewState)
_mesa_update_state( ctx );
+ if (check_fallbacks(brw, prim, nr_prims))
+ return GL_FALSE;
+
brw_validate_textures( brw );
/* Bind all inputs, derive varying and size information:
@@ -275,6 +276,7 @@ static GLboolean brw_try_draw_prims( GLcontext *ctx,
brw-vb.min_index = min_index;
brw-vb.max_index = max_index;
brw-state.dirty.brw |= BRW_NEW_VERTICES;
+
/* Have to validate state quite late. Will rebuild tnl_program,
* which depends on varying information.
*
@@ -289,59 +291,58 @@ static GLboolean brw_try_draw_prims( GLcontext *ctx,
return GL_TRUE;
}
- /* Flush the batch if it's approaching full, so that we don't wrap while
-* we've got validated state that needs to be in the same batch as the
-* primitives. This fraction is just a guess (minimal full state plus
-* a primitive is around 512 bytes), and would be better if we had
-* an upper bound of how much we might emit in a single
-* brw_try_draw_prims().
-*/
- intel_batchbuffer_require_space(intel-batch, intel-batch-size / 4,
- LOOP_CLIPRECTS);
- {
- /* Set the first primitive early, ahead of validate_state:
+ for (i = 0; i nr_prims; i++) {
+ uint32_t hw_prim;
+
+ /* Flush the batch if it's approaching full, so that we don't wrap while
+ * we've got validated state that needs to be in the same batch as the
+ * primitives. This fraction is just a guess (minimal full state plus
+ * a primitive is around 512 bytes), and would be better if we had
+ * an upper bound of how much we might emit in a single
+ * brw_try_draw_prims().
*/
- brw_set_prim(brw, prim[0].mode);
+ intel_batchbuffer_require_space(intel-batch, intel-batch-size / 4,
+ LOOP_CLIPRECTS);
- brw_validate_state( brw );
+ hw_prim = brw_set_prim(brw, prim[i].mode);
- /* Various fallback checks:
- */
- if (brw-intel.Fallback)
-goto out;
+ if (first_time || (brw-state.dirty.brw BRW_NEW_PRIMITIVE)) {
+first_time = GL_FALSE;
- if (check_fallbacks( brw, prim, nr_prims ))
-goto out;
+/* Various fallback checks: */
+if (brw-intel.Fallback)
+ goto out;
- /* Check that we can fit our state in with our existing batchbuffer, or
- * flush otherwise.
- */
- if (dri_bufmgr_check_aperture_space(brw-state.validated_bos,
- brw-state.validated_bo_count)) {
-static GLboolean warned;
-intel_batchbuffer_flush(intel-batch);
-
-/* Validate the state after we flushed the batch (which
Re: [Mesa3d-dev] [Intel-gfx] i965: aperture fixes 59b2c2adb cause lockups in foobillard at startup
On Tue, 2008-11-04 at 02:18 -0800, Keith Packard wrote: While doing a bunch of irq work, I was testing random programs against mesa master and found that foobillard (debian unstable version) was locking up on my GM45 laptop. I bisected and found that this patch was causing the trouble. I haven't looked to try and figure out what's going on. commit 59b2c2adbbece27ccf54e58b598ea29cb3a5aa85 Author: Eric Anholt [EMAIL PROTECTED] Date: Fri Oct 24 13:02:21 2008 -0700 i965: Fix check_aperture calls to cover everything needed for the prim at once. Previously, since my check_aperture API change, we would check each piece of state against the batchbuffer individually, but not all the state against the batchbuffer at once. In addition to not being terribly useful in assuring success, it probably also increased CPU load by calling check_aperture many times per primitive. Yep, we've got a report of it failing with blender as well, which I reproduced. It's really high on my to-fix list, but I think 8xx is higher since it's a kernel regression. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] i965: Fix up clip min_nr_entries, preferred_nr_entries, and max_threads.
The clip thread could potentially deadlock when processing tristrips since
being moved back to dual-thread mode, as the two threads could each have 4 VUEs
referenced and not be able to allocate another one since SF processing
wasn't able to continue (needing 5 entries before it freed 2).
In constrained URB mode, similar deadlock could even have occurred with
polygons (so we cut back max_threads if we can't handle it any primitive type).
---
src/mesa/drivers/dri/i965/brw_clip_state.c | 16 +++-
src/mesa/drivers/dri/i965/brw_urb.c|2 +-
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_clip_state.c
b/src/mesa/drivers/dri/i965/brw_clip_state.c
index 740c7cb..9b0d7ea 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_state.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_state.c
@@ -88,7 +88,21 @@ clip_unit_create_from_key(struct brw_context *brw,
clip.thread4.nr_urb_entries = key-nr_urb_entries;
clip.thread4.urb_entry_allocation_size = key-urb_size - 1;
- clip.thread4.max_threads = 1; /* 2 threads */
+ /* If we have enough clip URB entries to run two threads, do so.
+*/
+ if (key-nr_urb_entries = 10) {
+ /* Half of the URB entries go to each thread, and it has to be an
+ * even number.
+ */
+ assert(key-nr_urb_entries % 2 == 0);
+ clip.thread4.max_threads = 2 - 1;
+ } else {
+ assert(key-nr_urb_entries = 5);
+ clip.thread4.max_threads = 1 - 1;
+ }
+
+ if (INTEL_DEBUG DEBUG_SINGLE_THREAD)
+ clip.thread4.max_threads = 0;
if (INTEL_DEBUG DEBUG_STATS)
clip.thread4.stats_enable = 1;
diff --git a/src/mesa/drivers/dri/i965/brw_urb.c
b/src/mesa/drivers/dri/i965/brw_urb.c
index 5cc51ad..7673dd3 100644
--- a/src/mesa/drivers/dri/i965/brw_urb.c
+++ b/src/mesa/drivers/dri/i965/brw_urb.c
@@ -91,7 +91,7 @@ static const struct {
} limits[CS+1] = {
{ 16, 32, 1, 5 }, /* vs */
{ 4, 8, 1, 5 },/* gs */
- { 6, 8, 1, 5 },/* clp */
+ { 5, 10, 1, 5 }, /* clp */
{ 1, 8, 1, 12 }, /* sf */
{ 1, 4, 1, 32 }/* cs */
};
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Cleaning up 965 URB management
I spent a while today reading up on the URB and thread management issues on the 965, and I think I spotted a few bugs in the code. I'm hoping that someone else can review the fixes for correctness, as I'm still not entirely convinced of the changes. I separated them out for easier bisecting. The performance change of tweaking URB management seems pretty minimal so far, though I've only been using OA for testing (and it's not terribly high poly count). I've seen up to 5% improvement today from playing with it, and there's probably that much more from improving the preferred_nr_entries fields in brw_urb.c. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] i965: Fix up SF max_threads.
We were dividing the number of URB entries by two to get number of threads, which looks suspiciously like a copy'n'paste-o from brw_vs_state.c. Also, the maximum number of threads is 24, not 12. --- src/mesa/drivers/dri/i965/brw_sf_state.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_sf_state.c b/src/mesa/drivers/dri/i965/brw_sf_state.c index 4f925d1..506126f 100644 --- a/src/mesa/drivers/dri/i965/brw_sf_state.c +++ b/src/mesa/drivers/dri/i965/brw_sf_state.c @@ -172,7 +172,8 @@ sf_unit_create_from_key(struct brw_context *brw, struct brw_sf_unit_key *key, sf.thread4.nr_urb_entries = key-nr_urb_entries; sf.thread4.urb_entry_allocation_size = key-sfsize - 1; - sf.thread4.max_threads = MIN2(12, key-nr_urb_entries / 2) - 1; + /* Each SF thread produces 1 PUE, and there can be up to 24 threads */ + sf.thread4.max_threads = MIN2(24, key-nr_urb_entries) - 1; if (INTEL_DEBUG DEBUG_SINGLE_THREAD) sf.thread4.max_threads = 0; -- 1.5.6.5 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] i965: Update WM maximum threads for G4X.
---
src/mesa/drivers/dri/i965/brw_wm_state.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_wm_state.c
b/src/mesa/drivers/dri/i965/brw_wm_state.c
index 61fe97a..fd46161 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_state.c
@@ -67,8 +67,13 @@ wm_unit_populate_key(struct brw_context *brw, struct
brw_wm_unit_key *key)
if (INTEL_DEBUG DEBUG_SINGLE_THREAD)
key-max_threads = 1;
- else
- key-max_threads = 32;
+ else {
+ /* WM maximum threads is number of EUs times number of threads per EU. */
+ if (BRW_IS_G4X(brw))
+key-max_threads = 10 * 5;
+ else
+key-max_threads = 8 * 4;
+ }
/* CACHE_NEW_WM_PROG */
key-total_grf = brw-wm.prog_data-total_grf;
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] i965: Fix up VS max_threads for G4X and removing a magic number.
As far as I can read in the docs, VS threads can be 1:1 with the pairs of
VUE handles allocated for them. Also, G4X can run twice as many threads as
before (though we won't unless the we bump the preferred URB entries for VS).
---
src/mesa/drivers/dri/i965/brw_vs_state.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs_state.c
b/src/mesa/drivers/dri/i965/brw_vs_state.c
index 6e66f54..9425816 100644
--- a/src/mesa/drivers/dri/i965/brw_vs_state.c
+++ b/src/mesa/drivers/dri/i965/brw_vs_state.c
@@ -77,12 +77,19 @@ vs_unit_create_from_key(struct brw_context *brw, struct
brw_vs_unit_key *key)
{
struct brw_vs_unit_state vs;
dri_bo *bo;
+ int chipset_max_threads;
memset(vs, 0, sizeof(vs));
vs.thread0.kernel_start_pointer = brw-vs.prog_bo-offset 6; /* reloc */
vs.thread0.grf_reg_count = ALIGN(key-total_grf, 16) / 16 - 1;
vs.thread1.floating_point_mode = BRW_FLOATING_POINT_NON_IEEE_754;
+ /* Choosing multiple program flow means that we may get 2-vertex threads,
+* which will have the channel mask for dwords 4-7 enabled in the thread,
+* and those dwords will be written to the second URB handle when we
+* brw_urb_WRITE() results.
+*/
+ vs.thread1.single_program_flow = 0;
vs.thread3.urb_entry_read_length = key-urb_entry_read_length;
vs.thread3.const_urb_entry_read_length = key-curb_entry_read_length;
vs.thread3.dispatch_grf_start_reg = 1;
@@ -91,8 +98,13 @@ vs_unit_create_from_key(struct brw_context *brw, struct
brw_vs_unit_key *key)
vs.thread4.nr_urb_entries = key-nr_urb_entries;
vs.thread4.urb_entry_allocation_size = key-urb_size - 1;
- vs.thread4.max_threads = MIN2(MAX2(0, (key-nr_urb_entries - 6) / 2 - 1),
-15);
+
+ if (BRW_IS_G4X(brw))
+ chipset_max_threads = 32;
+ else
+ chipset_max_threads = 16;
+ vs.thread4.max_threads = CLAMP(key-nr_urb_entries / 2,
+ 1, chipset_max_threads) - 1;
if (INTEL_DEBUG DEBUG_SINGLE_THREAD)
vs.thread4.max_threads = 0;
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] i965: Add a big comment explaining my understanding of URB management.
It shouldn't offer anything new over what's in the docs (except for G4X notes), but here it's all in one place. --- src/mesa/drivers/dri/i965/brw_urb.c | 39 ++- 1 files changed, 38 insertions(+), 1 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_urb.c b/src/mesa/drivers/dri/i965/brw_urb.c index 1a00417..5cc51ad 100644 --- a/src/mesa/drivers/dri/i965/brw_urb.c +++ b/src/mesa/drivers/dri/i965/brw_urb.c @@ -42,7 +42,44 @@ #define SF 3 #define CS 4 -/* XXX: Are the min_entry_size numbers useful? +/** @file brw_urb.c + * + * Manages the division of the URB space between the various fixed-function + * units. + * + * See the Thread Initiation Management section of the GEN4 B-Spec, and + * the individual *_STATE structures for restrictions on numbers of + * entries and threads. + */ + +/* + * Generally, a unit requires a min_nr_entries based on how many entries + * it produces before the downstream unit gets unblocked and can use and + * dereference some of its handles. + * + * The SF unit preallocates a PUE at the start of thread dispatch, and only + * uses that one. So it requires one entry per thread. + * + * For CLIP, the SF unit will hold the previous primitive while the + * next is getting assembled, meaning that linestrips require 3 CLIP VUEs + * (vertices) to ensure continued processing, trifans require 4, and tristrips + * require 5. There can be 1 or 2 threads, and each has the same requirement. + * + * GS has the same requirement as CLIP, but it never handles tristrips, + * so we can lower the minimum to 4 for the POLYGONs (trifans) it produces. + * We only run it single-threaded. + * + * For VS, the number of entries may be 8, 12, 16, or 32 (or 64 on G4X). + * Each thread processes 2 preallocated VUEs (vertices) at a time, and they + * get streamed down as soon as threads processing earlier vertices get + * theirs accepted. + * + * Each unit will take the number of URB entries we give it (based on the + * entry size calculated in brw_vs_emit.c for VUEs, brw_sf_emit.c for PUEs, + * and brw_curbe.c for the CURBEs) and decide its maximum number of + * threads it can support based on that. in brw_*_state.c. + * + * XXX: Are the min_entry_size numbers useful? * XXX: Verify min_nr_entries, esp for VS. * XXX: Verify SF min_entry_size. */ -- 1.5.6.5 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] drm: Add 32-bit compatibility for DRM_IOCTL_UPDATE_DRAW.
This fixes vblank support for a 32-bit X Server on a 64-bit kernel.
Signed-off-by: Eric Anholt [EMAIL PROTECTED]
---
drivers/gpu/drm/drm_ioc32.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 90f5a8d..7128493 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -64,6 +64,8 @@
#define DRM_IOCTL_SG_ALLOC32 DRM_IOW( 0x38, drm_scatter_gather32_t)
#define DRM_IOCTL_SG_FREE32DRM_IOW( 0x39, drm_scatter_gather32_t)
+#define DRM_IOCTL_UPDATE_DRAW32DRM_IOW( 0x3f,
drm_update_draw32_t)
+
#define DRM_IOCTL_WAIT_VBLANK32DRM_IOWR(0x3a,
drm_wait_vblank32_t)
typedef struct drm_version_32 {
@@ -952,6 +954,37 @@ static int compat_drm_sg_free(struct file *file, unsigned
int cmd,
DRM_IOCTL_SG_FREE, (unsigned long)request);
}
+typedef struct drm_update_draw32 {
+ drm_drawable_t handle;
+ unsigned int type;
+ unsigned int num;
+ /* 64-bit version has a 32-bit pad here */
+ u64 data; /** Pointer */
+} __attribute__((packed)) drm_update_draw32_t;
+
+static int compat_drm_update_draw(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+ drm_update_draw32_t update32;
+ struct drm_update_draw __user *request;
+ int err;
+
+ if (copy_from_user(update32, (void __user *)arg, sizeof(update32)))
+ return -EFAULT;
+
+ request = compat_alloc_user_space(sizeof(*request));
+ if (!access_ok(VERIFY_WRITE, request, sizeof(*request)) ||
+ __put_user(update32.handle, request-handle) ||
+ __put_user(update32.type, request-type) ||
+ __put_user(update32.num, request-num) ||
+ copy_in_user(request-data, update32.data, sizeof(request-data)))
+ return -EFAULT;
+
+ err = drm_ioctl(file-f_path.dentry-d_inode, file,
+ DRM_IOCTL_UPDATE_DRAW, (unsigned long)request);
+ return err;
+}
+
struct drm_wait_vblank_request32 {
enum drm_vblank_seq_type type;
unsigned int sequence;
@@ -1033,6 +1066,7 @@ drm_ioctl_compat_t *drm_compat_ioctls[] = {
#endif
[DRM_IOCTL_NR(DRM_IOCTL_SG_ALLOC32)] = compat_drm_sg_alloc,
[DRM_IOCTL_NR(DRM_IOCTL_SG_FREE32)] = compat_drm_sg_free,
+ [DRM_IOCTL_NR(DRM_IOCTL_UPDATE_DRAW32)] = compat_drm_update_draw,
[DRM_IOCTL_NR(DRM_IOCTL_WAIT_VBLANK32)] = compat_drm_wait_vblank,
};
--
1.5.6.5
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] State of r300-bufmgr branch
On Sun, 2008-08-31 at 02:28 +0200, Nicolai Hähnle wrote: Dave, I'm leaving for a two-week workshop tomorrow, so here's a quick summary of what r300-bufmgr looks like to me. In fact, there's another potential problem, which is texture sharing between contexts. I didn't think this through, but it seems like having the bufmgr in the GL context is incorrect? Correct, as far as I can tell. It's on the list of things to fix for Intel that other issues have kept us from getting to so far. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.1 rc 4
On Tue, 2008-08-19 at 18:20 -0600, Brian Paul wrote: Dave Airlie wrote: On Sun, Aug 17, 2008 at 12:23:06 +0200, Stefan Dirsch wrote: Looks like dri_bufmgr.h/intel_bufmgr.h are missing in the tarball. Could this be? See my other reply on mesa3d-dev, they're from libdrm git master. So I see a couple of ways to resolve this, 1) Back out GEM, release 7.1, put GEM back in - preferred by me. That occured to me too and I think I prefer it as well. What I'd probably do then is create a mesa-7.2 branch, based on 7.1, which will be a stable, bug-fix branch without GEM. Sorry. When I did the merge, someone had told me that 7.1 had already been branched, and I didn't check before the merge. I agree, for 7.1 it should be without GEM. Could you just cut the branchpoint before my merge? If I've caused too much pain and you want everything that's happened in master except for GEM on the branch, I could do that work for you (just say so). Our plan for our quarterly release is to take whatever is the most 7.1-ish and include GEM on top of that. But the timeframe for that is the next couple of months, not the next couple of days. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Mesa3d-announce] Mesa 7.1 rc 4
On Wed, 2008-08-20 at 04:19 +0100, Dave Airlie wrote: It falls back gracefully though (I think TTM did as well, though this API is smaller in that it doesn't pass a huge gob of flags around), so if we think the libdrm bufmgr interface is stable there should be no problem. The problem is I am not that happy that the bufmgr interface is stable, its been changed quite a bit during GEM dev, and I forsee more changes to it to support other users... You missed the point it fails back gracefully at *runtime*, and if we do end up with a slight change to the interface in the kernel later we have code that could wait in hiding for the bits to be enabled in the kernel. On the subject of bufmgr interface stability, I'd wanted to put it in libdrm because I thought others were going to be using it, it's small, and we've got at least 3 components that want to use it textdata bss dec hex filename 9648 0 0964825b0 intel_bufmgr_fake.o (ex /home/anholt/src/drm/libdrm/intel/.libs/libdrm_intel.a) 6328 0 0632818b8 intel_bufmgr_gem.o (ex /home/anholt/src/drm/libdrm/intel/.libs/libdrm_intel.a) 1681 0 01681 691 mm.o (ex /home/anholt/src/drm/libdrm/intel/.libs/libdrm_intel.a) 726 0 0 726 2d6 /home/anholt/src/drm/libdrm/.libs/dri_bufmgr.o 18383 0 0 1838347cf (TOTALS) But last I heard, it looks like it's really too specific for dri_bufmgr to be usefully shared between drivers. At that point, it seems like libdrm is the wrong place for it, particularly if we're concerned about wanting to do ABI incompatible bumps (as we've done several times already). Should I move it out to a libdrm_intel.so and intel_bufmgr.h, so that I'm not burdening other people with my API and ABI issues? Don't we keep saying libdrm is the interface these days anyway? So if that part is sane we should just release what's in libdrm master now or soon. But maybe I'm forgetting (ignorance is bliss) some aspect of the pain we had with TTM... for instance there are two direct GEM ioctls in the intel mesa code, libdrm currently publishes files it shouldn't, the plan is to build libdrm against kernel published files, however these files aren't in the kernel so I can release a libdrm against them. As I said on irc, you build a house (even a house of cards) from the bottom, doing it in reverse is not a good plan. There is no point having released userspace bits with no kernel to support them. So there will not be a libdrm release with any of this stuff in it before the upstream bits are in the kernel. We tried that with TTM, and we had lots of pain. I can agree with that summary -- until the kernel accepts the interface, don't release. It's kind of a pain, but it's our fault for the development model we've had. Hopefully things get better. One thing I'd like to do is split the libdrm userspace component from the drm external kernel modules tree -- /git/mesa/libdrm perhaps. Then we don't have to worry about whether the driver can be built on specific kernels when we're just trying to get the userland component ready. I suppose the alternative would be for us to just back out the GEM stuff in the kernel module part and leave things they were so that external-tree developers can continue and those of us that need to integrated with the kernel work just in kernel trees Any opinions? -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] bug in fragment shader on i965
On Fri, 2008-06-06 at 09:45 +0200, Tomas Carnecky wrote: Some fragment shaders don't work right on i965. For example if I enable the 'neg' compiz plugin, all windows turn gray. And I tried my own plugin that does: MOV output.r, 1.0; and all windows turned red (or was it gray also? I don't remember...). I was told it's an issue in Mesa rather then the drivers. But I couldn't find any bug report describing that problem (not under mesa nor the xorg intel driver). Do you want me to open a new bug? If you tell me where in mesa the bug could be, I'll try to look into it myself (as time permits). I really need shaders. Even thought these work fine on my desktop (nvidia blob), I'd like to be able to hack when on my laptop. We're always interested in short samples of code that fails on our driver. Unfortunately, configure compiz and enable a magic set of plugins is kind of a high barrier to entry for bugfixing, and thus less likely to be poked at in one's spare time. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] autoconf: Attempt to figure out the PIC flags for the platform
On Fri, 2008-05-09 at 07:06 -0700, Dan Nicholson wrote: On Mon, May 5, 2008 at 8:05 PM, Dan Nicholson [EMAIL PROTECTED] wrote: This commit adds an autoconf macro, MESA_PIC_FLAGS, which sets the PIC flags according to platform and static/shared setting. The platform specifics are taken straight from libtool.m4 and stripped down to just the flags and platforms we cover in Mesa. This should hopefully make it possible to use autoconf on non-GCC platforms. The macro is added external to configure.ac in acinclude.m4 since it's pretty bloated. Note to BSDers: Previously, x86 defaulted to non-PIC on FreeBSD. I didn't carry that preference into this macro. Instead, you can just use --disable-pic where Sounds like the right thing to do anyway. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] autoconf: Add GLcore driver target
xorg-server.h])]) +CPPFLAGS=$save_cppflags + +if test $xserver_dri = yes; then +# Hack so that DRI sources are built into GLcore +WINDOW_SYSTEM=dri +DEFINES=$DEFINES -DIN_DRI_DRIVER +PKG_CHECK_MODULES([LIBDRM], [libdrm = $LIBDRM_REQUIRED]) +GLCORE_LIB_DEPS=$GLCORE_LIB_DEPS $DLOPEN_LIBS +fi +;; +*) +# Allow `make glcore' to be run from a prebuilt tree. Delay +# pkg-config checks until `make glcore' run. +XORG_CFLAGS='`pkg-config --cflags xorg-server`' +GLCORE_LIB_DEPS=-lm -lpthread +if test $mesa_driver = dri; then +GLCORE_LIB_DEPS=$GLCORE_LIB_DEPS $DLOPEN_LIBS +fi +;; +esac AC_SUBST([XORG_CFLAGS]) AC_SUBST([GLCORE_LIB_DEPS]) @@ -663,6 +712,11 @@ AC_ARG_ENABLE([glu], [enable OpenGL Utility library @:@default=enabled@:@])], [enable_glu=$enableval], [enable_glu=yes]) +dnl Don't build glu on glcore +if test x$enable_glu = xyes test $mesa_driver = glcore; then +AC_MSG_WARN([Disabling GLU since the driver is glcore]) +enable_glu=no +fi if test x$enable_glu = xyes; then SRC_DIRS=$SRC_DIRS glu @@ -706,10 +760,14 @@ AC_ARG_ENABLE([glw], [enable Xt/Motif widget library @:@default=enabled@:@])], [enable_glw=$enableval], [enable_glw=yes]) -dnl Don't build GLw on osmesa -if test x$enable_glw = xyes test $mesa_driver = osmesa; then -AC_MSG_WARN([Disabling GLw since the driver is OSMesa]) -enable_glw=no +dnl Don't build GLw on osmesa or glcore +if test x$enable_glw = xyes; then +case $mesa_driver in +osmesa|glcore) +AC_MSG_WARN([Disabling GLw since the driver is $mesa_driver]) +enable_glw=no +;; +esac fi if test x$enable_glw = xyes; then SRC_DIRS=$SRC_DIRS glw diff --git a/src/mesa/Makefile b/src/mesa/Makefile index 08d7235..8da3b79 100644 --- a/src/mesa/Makefile +++ b/src/mesa/Makefile @@ -33,6 +33,7 @@ default: depend beos) $(MAKE) beos || exit 1 ;; \ directfb) $(MAKE) directfb || exit 1 ;; \ fbdev)$(MAKE) fbdev || exit 1 ;; \ + glcore) $(MAKE) glcore || exit 1 ;; \ *) echo $$driver is invalid in DRIVER_DIRS 2; exit 1;; \ esac ; \ done @@ -45,6 +46,7 @@ install: default else \ $(MAKE) install-osmesa || exit 1 ; \ fi ;; \ + glcore) $(MAKE) install-glcore || exit 1 ;; \ dri)$(MAKE) install-libgl install-dri || exit 1 ;; \ *) $(MAKE) install-libgl || exit 1 ;; \ esac ; \ @@ -72,6 +74,12 @@ linux-solo: depend subdirs libmesa.a cd drivers/dri $(MAKE) +## +# Xorg GLcore module +glcore: depend subdirs libmesa.a + cd drivers/xorg $(MAKE) + + # # Stand-alone Mesa libGL, no built-in drivers (DirectFB) @@ -193,6 +201,9 @@ install-osmesa: default install-dri: cd drivers/dri $(MAKE) install +install-glcore: + cd drivers/xorg $(MAKE) install + ## NOT INSTALLED YET: ## $(INSTALL) -d $(DESTDIR)$(INSTALL_DIR)/include/GLES ## $(INSTALL) -m 644 include/GLES/*.h $(DESTDIR)$(INSTALL_DIR)/include/GLES -- 1.5.3.2 - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Support for DragonFly BSD
On Wed, 2008-04-09 at 13:25 -0700, Dan Nicholson wrote: On Wed, Apr 9, 2008 at 11:07 AM, Eric Anholt [EMAIL PROTECTED] wrote: On Wed, 2008-04-09 at 14:18 +0300, Hasso Tepper wrote: The attached patches add support for DragonFly BSD. dragonfly-mesa70.patch is applicable to both 7.0 branch and master, dragonfly-mesa-autoconf.patch just adds autoconf support for master only. 7.0 branch is fully tested, master isn't due to need for too many stuff from git (DRI2). configs/dragonfly* files are written using FreeBSD files as templates, differences are mainly various paths and the fact that -pthread is deprecated in DragonFly. AMD64 isn't tested, because DragonFly AMD64 port isn't functional yet (we hope to change it in near future). The change in mklib is necesary because 'pkg-config --libs libdrm' returns in my system -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -ldrm. The changes in src/glut/glx/Makefile and src/glw/Makefile are made because without this makedepend complained a lot about missing X11 headers. I committed all but the static config files to master. Is there any reason to have them, if the autoconf build works? I'm planning on deleting the FreeBSD ones anyway if nobody complains, as they're useless at this point as far as I can see (broken, and suck at integrating into the ports system) Eric, have you tried the autoconf build on FreeBSD? Is it applicable on any other BSDs? Did I even get the $host* variables right? If you didn't notice, I was just guessing on non-Linux platforms. I fixed it up for FreeBSD back in March. It was pretty easy to do, and much nicer than managing a pile of static config files. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Support for DragonFly BSD
On Wed, 2008-04-09 at 14:18 +0300, Hasso Tepper wrote: The attached patches add support for DragonFly BSD. dragonfly-mesa70.patch is applicable to both 7.0 branch and master, dragonfly-mesa-autoconf.patch just adds autoconf support for master only. 7.0 branch is fully tested, master isn't due to need for too many stuff from git (DRI2). configs/dragonfly* files are written using FreeBSD files as templates, differences are mainly various paths and the fact that -pthread is deprecated in DragonFly. AMD64 isn't tested, because DragonFly AMD64 port isn't functional yet (we hope to change it in near future). The change in mklib is necesary because 'pkg-config --libs libdrm' returns in my system -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -ldrm. The changes in src/glut/glx/Makefile and src/glw/Makefile are made because without this makedepend complained a lot about missing X11 headers. I committed all but the static config files to master. Is there any reason to have them, if the autoconf build works? I'm planning on deleting the FreeBSD ones anyway if nobody complains, as they're useless at this point as far as I can see (broken, and suck at integrating into the ports system) -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] No more C99 syntax goodies in gallium source
On Wed, 2008-02-20 at 09:56 +0900, José Fonseca wrote: On 2/20/08, Eric Anholt [EMAIL PROTECTED] wrote: On Wed, 2008-02-20 at 03:25 +0900, José Fonseca wrote: On 2/20/08, Ian Romanick [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Whitwell wrote: | Ian Romanick wrote: | José Fonseca wrote: | | Microsoft compilers don't support C99 syntax. The only native windows | | compilers that support C99 syntax are mingw32-gcc and Intel C/C++ | | compiler, but we can't seriously support windows platform by targeting | | these compilers alone and leave msvc out. | | In a word, NO. Frankly, I don't care to be restricted to 20 year old C | syntax just because Microsoft doesn't care to support the 10 year old C | syntax. | | Well, in the core parts of gallium this will hold. For the Cell driver | it doesn't matter so much... | | It's hardly ideal but we're basically grownups here and can probably | take it in our stride, especially given that the same restrictions have | been historically enforced in core Mesa. But this has not been the case in the hardware driver code. Isn't this code being folded into gallium (i.e., i965simple)? In that code we routinely use variadic macros, C99 array initializers, and C99 structure initializers...and it makes the code better. It actually was when I tried to compile this code with msvc and saw all the compile errors and all the necessary effort to fix it that I decided to write this thread. Basically, using -stc=c99 with gallium code hides this problem until it is quite big. Wait, are you saying that you're going to be enforcing msvc compatibility in the drivers as well? I would strongly object to that. On the drivers we care about, e.g., i965simple, I'm afraid it will have to be so... Drivers that third-parties create, or drivers we maintain but are clearly Linux only (e.g., cell), there is no point to enforce anything. Also the winsys drivers are platform specific, so they can use whatever features the platform they target have. C99 syntax is useful, and I admit that enforcing C89 even for the sake of portability is retrograde, nevertheless the C99 syntax is mostly syntactic sugar: - you can replace variadic macros with inline functions is most common uses - named strucuture initializers help reading, but you can achieve the same thing using a simple comment on each member. - you can easily avoid middle-of-scope variables declarations IMO, the best C99 feature has are library things like stdint.h types. But for those we can and we do provide equivalent definitions in the platforms that lack it. Also, if people care so deeply for C99, it might be worth considering C++, as it is supported. Even though for Windows Kernel mode, almost every single C++ feature is not advisable (http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx). So, at the of the day, you can only use pretty much what C99 gives you. Another suggestion given on IRC yesterday is compiling C99 code as C++ on MSVC. I have strong suspicion that it will bring a world of pain when linking to code outside gallium, but it is worth to check it. But for the meanwhile, please refrain of using C99 syntax on: - src/mesa/state_tracker/*.h - src/gallium/include - src/gallium/auxiliary - src/gallium/drivers/i915simple - src/gallium/drivers/i965simple It is OK to use C99 in - src/mesa - src/gallium/winsys - src/gallium/drivers/cell - etc. I'll soon disable -std=c99 and enable -pedantic inside src/gallium so that people get warnings when using c99 features. Again, I'm sorry to have to play the role of bad guy here. However, Windows support on gallium was an objective from the very beginning, and cross-platform portability implies sacrifices. Of course that, for those who don't care about windows portability, you're basically being asked to give up something without receiving nothing extra in return... But don't forget that the gallium source code was almost entirely coded by TG so far, so you *did* actually receive something already. Code doesn't come out of thin air -- it costs money. So I think it's not unfair to ask you in name of cooperation to do such sacrifice. I guess I had been unclear on the gallium plan. If existing DRI drivers get to continue living side-by-side with gallium stuff, then until gallium proves to be a significant win for our chipsets we can go ahead and ignore it, it sounds like. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http
Re: [Mesa3d-dev] Skipping -lpthreads for single-threaded apps
On Sat, 2007-12-15 at 11:07 -0700, Brian Paul wrote: Keith Packard wrote: The pthreads library introduces significant overhead for single-threaded applications, Just out of curiosity, have you made some measurements? As keithp noted, we were seeing 5-10% CPU time in pthread mutex operations depending on the app being profiled on 965. It's gone with the dri_bufmgr pthread removal I did, but I've later realized that we can't just do that, since buffer objects are shared between contexts (ugh), so the bufmgr internals will need to be protected from concurrent access and those costs will be coming back. We're already pulling in libpthread-stubs if XCB is being used, and when someone gets around to it libX11 will use it as well. Getting our required stubs in there sounds like the right plan. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH 0/10][RFC] Autoconf support for Mesa
On Mon, 2007-12-10 at 12:02 +0100, Alex Neundorf wrote: Maybe the most important is that autoconf is really mature, well understood and supports tons of platforms. People will know how to work with it because it's used everywhere. I think we could discuss that without end ;-) Just IMHO: cmake = 2.4.3 is mature (it builds e.g. ParaView, KDE4, cdrkit, OpenWengo, ...) it supports tons of platforms although autotools are used everywhere they are not well understood everywhere cmake is easier to understand (just one tool instead of automake+autoconf+libtool+m4+shell, ok, here we are talking just about autoconf...) I maintained a port of paraview for FreeBSD for a year or so. It convinced me that cmake was quite possibly the only tool worse than automake. Every single point release of cmake, the paraview build broke because some macro had changed in a minor yet incompatible way. And, while I can eventually figure out autotools issues, I basically got to wait until google figured out my problem for paraview. At least the automake maintainers only uselessly break things every minor release or so :/ -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] 965-ttm branch merged
As 965-fbo has been getting stabilized, I decided to go ahead and merge the 965-ttm branch. I chose to do a squash merge since there was a bunch of very noisy history as I flailed about trying to get it to work. I cherry-picked out what I could to get it down to what I think is just the change required to switch buffer managers. The details of how I got there be found in the 965-ttm branch of mesa, if schadenfreude is your sort of thing. As you'll see if you try it out, 965-ttm does result in a major performance regression. You can set INTEL_NO_TTM=1 in the environment to disable TTM mode and use classic userspace buffer management, which recovers some of the performance. Some sample timings (bigger is better): old 965-ttm-classic 965-ttm-ttm openarena 134 43.76.2 ipers 544000 152000 9300 There are a bunch of performance improvements in the works which should help bring things back up to what they used to be, and if we're not wrong then at the end we should actually see performance improvements using ttm on 965, like we have on 915. - Re-add no_fence_subdata I removed this performance hack from dri_bufmgr_fake because I didn't really need it for 915, and I haven't readded it yet for 965. It would bring back a chunk of the performance lost form old to 965-ttm-classic. Only needed for userspace suballocator. (~anholt/mesa 965-ttm-subdata-hack) - Re-alloc the state pool Even with the above, when we wrap around in our userspace suballocator, we have to wait for sync before we can start writing state at the start of the buffer again. The code didn't do this before, and we can make it not do it again. (~anholt/mesa 965-ttm-pool-realloc) - Re-add disable_backing_store to more places The 965 driver used to disable backing store on more buffers than after the merge, and we could bring that back. These were disabled because the dri_bufmgr interface doesn't have the equivalent of bmBufferData (release buffer memory and allocate new memory in the same buffer object with the same state), so some minor adjustments are necessary to ensure that the backing store disable remains on the relevant buffers. Additionally, there are locking complexities for doing this to the batchbuffer again with that code being shared with 915, since 915 and 965's locking around batchbuffer emit paths are different (I'm hoping to change this). - Rework state caching Right now we allocate state buffers out of a userspace suballocator. The problem is that these allocators are relatively small, and when we exceed their limits we have to throw them away and recalculate all of our state. Instead, we could make our state cache be a hash table of actual buffer objects rather than layering a buffer manager on a buffer manager, and we would avoid the no_fence_subdata hack and improve our cache hit rate. A version of this that I decided to throw out (~anholt/mesa 965-state-caching) was a modest performance improvement, and we can do better than that. - TTM relocation caching Primarily valuable on top of state caching rework, this was posted by keithp recently. Avoids redundant relocation writes to buffers and the associated fence waits. Should bring ttm performance to at or above classic performance. - Move buffer manager structures back to context instead of screen The motivation of moving it to the screen was that for classic mode, you could avoid the eviction process on context switch within a single process. It turns out that the pthread mutexes used for refcounting other structure protection are accounting for about 10% of a CPU in my testing, and we could avoid it by abandoning this unimplemented optimization for classic mode. However, we may be able to avoid this if we can get libGL to not link against libpthread on platforms with thread stubs. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] mesa: Changes to 'master'
On Mon, 2007-09-24 at 15:30 +0100, Keith Whitwell wrote: Keith Whitwell wrote: 2) Figure out what memory manager you are using and, if it is the fake one, disable any paths in the driver that rely on the assumption of persistent video-ram buffers, and provide alternatives. This would effectively mean switching between i915tex and i965 versions of CopyTexSubImage, texture uploads, etc, and turning off extensions like FBO's for the fake manager. I just took a look at the extension list -- it seems like you have **unconditionally** removed framebuffer objects and pixel buffer objects from the extension list??? This isn't really acceptable. People rely on that functionality, and removing it is a major regression. It's also needless in the TTM case, because FBOs and PBOs still work there. Ugh. I looked closer. Apologies, FBO/PBO code is still there, and gated on TTM as suggested. (sigh). Apologies again. It looks like most of what you need to do is key things like the CopyTexSubImage path, etc off intelScreen-ttm. I'll take a pass at putting together some fixes for this. Yes, that was exactly the intention for how i915-unification would work going forward. Thanks for catching that path, which I had missed in my initial review. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] 3D support for 2048x2048 on intel drivers
On Sun, 2007-07-22 at 23:38 +0200, Roland Scheidegger wrote: Chase Douglas wrote: I am writing because I would like to work on adding support for 3D acceleration at resolutions large enough for a dual monitor desktop. Unfortunately, though I have experience writing some kernel drivers, I have no experience with writing X drivers, and very little background (although I did take a 3D programming course focused on the opengl pipeline). The theory goes that one could create a framebuffer for each monitor and iterate over the framebuffers when doing operations. How can I start working on this? I can read code fairly well, but I don't know where to begin. I assume some code between the intel X driver and the mesa driver will have to split a screen into two framebuffers and tell the mesa driver of this fact. Other than that, I have no clue where the API functions reside in the code. If anyone can point me to a general set of functions and briefly what they do, I believe it would help immensely. You don't necessarily need to split the framebuffer into two pieces, you could do this without modifying the ddx code (except from allowing it dri to initialize), if you use private render buffers. Sounds simpler to me. Theory goes like this with private buffers: If your 3d window size exceeds 2048 pixels (in any direction), you'd need to create 2 (I don't think resolutions which would require 4 are possible) private buffers to render to instead of 1 (and 2 depth buffers too). Then whenever you have something to draw, you just send it twice to the hardware, (with different buffers, viewport adjusted etc.). You'd need to modify quite a bit of code to make that work correctly though (from non-rendering stuff like read/drawpixels to swrast fallbacks) currently. Then at swapbuffer time you'd just blit the two buffers to the framebuffer (the blitter has no trouble supporting large resolutions AFAIK) instead of just one. (private buffers are implemented in the i915tex_privbuffers branch, if you'd want to experiment with that - shameless plug...) The problem for us is that on the hardware with this limitation, we can't scan out from bigger than 2048 in the X direction either. But solving the 3D side of things would be the hardest step I think. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] origin branch...
On Sat, 2007-05-19 at 03:55 +0200, Roland Scheidegger wrote: Sorry guys looks like I pushed an origin branch (most famous git accident?)... Time to upgrade to 1.5 I guess... Daniel, can you get rid of it again? Done. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa 6.5.3 release candidate 2
On Sun, 2007-04-22 at 16:17 +0100, Alan Hourihane wrote: On Sun, 2007-04-22 at 09:05 -0600, Brian Paul wrote: On 4/22/07, Michel Dänzer [EMAIL PROTECTED] wrote: On Sat, 2007-04-21 at 16:06 -0600, Brian Paul wrote: I've uploaded a second release candidate: http://www.mesa3d.org/beta/ I think it would be useful in general, but in particular for packagers, if there was a GIT tag corresponding to each RC. I did a 'git-tag -a mesa_6_5_3_rc2' which seemed to work. But how do I push that to master? git-push didn't do anything. git-push --tags should do the trick That pushes all of your tags. So, if you tagged something as this-commit-is-junk months ago while debugging, even that goes up. git-push origin tagname shouldn't ever surprise you with what it does. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Problem with git xorg-server/mesa and dri + damage
On Fri, 2007-01-19 at 04:32 +0100, Hanno Böck wrote: When using latest mesa and xorg-server from git, I get this error: [EMAIL PROTECTED] ~ $ glxgears libGL warning: 3D driver claims to not support visual 0x4b X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 158 (DAMAGE) Minor opcode of failed request: 4 () Serial number of failed request: 37 Current serial number in output stream: 38 radeon 9600 M10, free dri/r300-driver, Gentoo Linux. As it notes that it may be cause of the damage extension, I tried disabling that and then it works. The issue is that the X Server is using the headers from damageproto to define the version it advertises. This is wrong -- the server should advertise whatever version it implements, and no higher. The solution for distros for now is to not ship new damageproto with old X Servers. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] git merge tip to branch, cvs interactions
On Mon, 2007-01-15 at 20:20 +, Keith Whitwell wrote: Michel Dänzer wrote: On Mon, 2007-01-15 at 17:35 +, Keith Whitwell wrote: So, I decided it would be neat to merge all the changes that have occurred on the Mesa mainline to the vbo branch where I've started working again. Naively, I thought something simple like: git checkout vbo_0_1_branch git pull Would do the trick, It should. but that has given me a gazillion conflicts in crazy places like the svga driver and what-have-you. Presumably some of these are artifacts of the CVS-git import and the fact that I'm playing on a branch that was originally created under CVS and has been pulled in as part of the import. Indeed. E.g. git-pull says some files were added on both branches, which is probably due to a CVS merge that wasn't properly converted into a git merge. What is the way forward? I'm pretty happy to create a new branch and drop the code into that, if necessary, but I'd like to know that my pulling problems will be over in that case. They should be. If you want to preserve the history on the new branch, you could try git-format-patch -o /tmp origin on the old branch to generate a patch series in /tmp and then git-am /tmp/00* on the new branch. Though that may end up requiring manual merging after many of the commits. If you know what branch was merged before the git conversion that's causing you your pain, one way forward might be to do: git-checkout master git pull -s ours . that-merged-branch git pull . my-branch Basically, you're recovering from the lack of information in the CVS merge commit by creating a new commit that records that that-merged-branch was merged, while making no changes to master since it was already merged. (After that step, I would run git-diff HEAD HEAD~1 to make sure it actually didn't result in any changes). I haven't actually tested this proposal to make sure it would work, so YMMV. Oh yes, and there is some magic to create a branch on the remote, right? Am I able to do this myself or to I have to ask a grownup? git push origin branchname:branchname -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
