[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Eric Anholt changed: What|Removed |Added Depends on||27143 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29044] GLSL compiler tracker
https://bugs.freedesktop.org/show_bug.cgi?id=29044 Eric Anholt changed: What|Removed |Added Blocks||28138 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Merge criteria for glsl2 branch
I personally do not care about Gallium breakage as long as the classic drivers do not break. This is because any Gallium breakage in that case would necessarily be from Gallium bugs, which I'd rather find sooner than later. Posting from a mobile, pardon my terseness. ~ C. On Jul 21, 2010 6:58 PM, "Ian Romanick" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As everyone knows, a group of us at Intel have been rewriting Mesa's GLSL compiler. The work started out-of-tree as a stand alone compiler. We moved all of our work to the glsl2 branch in the Mesa tree as soon as we had some actual code being generated. This was about month ago. Since that time we have implemented quite a bit more code generation and a complete linker. The compiler is not done, but it gets closer every day. I think now is the time to start discussing merge criteria. It is well known that the Intel graphics team favors quarterly releases. In order to align with other people's release schedules, we'd really like to have the new compiler in a Mesa release at the end of Q3 (end of September / beginning of October). That's just over two months from now. In order to have a credible release, the compiler needs to be merged to master before then. A reasonable estimate puts the end of August as the latest possible merge time. Given how far the compiler has come in the last month, I have a lot of faith in being able to hit that target. We have developed our own set of merge requirements, and these are listed below. Since this is such a large subsystem, we want to solicit input from the other stakeholders. * No piglit regressions, except draw_buffers-05.vert, compared to master in swrast, i965, or i915. * Any failing tests do not crash (segfault, assertion failure, etc.). draw_buffers-05.vert is specifically excluded because I'm not sure the test is correct. One of the items on the TODO list is proper support for GLSL ES. That work won't happen until the last couple weeks of August, so I don't think any sort of ES testing is suitable merge criteria. Unless, of course, the tests in question should also work on desktop GLSL. We haven't and, for all practical purposes, can't test with Gallium or other hardware drivers. The new compiler generates the same assembly IR that the current compiler generates. We haven't added any instructions. It does, however, generate different combinations of instructions, different uses of registers, and so on. We don't expect there to be significant impact on other hardware, but there may be some. The optimizer in r300 will certainly see different sequences of instructions than it is accustomed to seeing. I can't foresee what impact this will have on that driver. I have put up the results of master and the glsl2 branch at http://people.freedesktop.org/~idr/results/. This run off compiler.tests from the glsl2 branch of Eric's piglit repository. A few of the failures (half a dozen or so) on master seem to be mutex related in the GLX code. Kristian is working on fixing that. :) We're already very close to our proposed merge criteria. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxHpJUACgkQX1gOwKyEAw9xfACfZkCpOE0Qo3+OXVJztiPVKpss FPwAn1NvXiSqXZk+XyWpRgPNfI5QtI18 =2Qs1 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] opencl (clover) patches question
Normally I wouldn't mind opening a new branch for your patches, but I don't have commit access to that repo and don't know the code. Zack? Posting from a mobile, pardon my terseness. ~ C. On Jul 21, 2010 6:10 PM, "Anthony Waters" wrote: mesa-dev, I've done some work with mesa's implementation of opencl (clover) (bug fixes and features), is it acceptable to email the patches to this list? I noticed a patch from 6+ months ago was never applied http://www.mail-archive.com/mesa3d-...@lists.sourceforge.net/msg10561.html from another author. It would be best if this patch was applied first (part of my patches address the same concerns so it would be ideal for me to work off of them and merge my changes). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Merge criteria for glsl2 branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As everyone knows, a group of us at Intel have been rewriting Mesa's GLSL compiler. The work started out-of-tree as a stand alone compiler. We moved all of our work to the glsl2 branch in the Mesa tree as soon as we had some actual code being generated. This was about month ago. Since that time we have implemented quite a bit more code generation and a complete linker. The compiler is not done, but it gets closer every day. I think now is the time to start discussing merge criteria. It is well known that the Intel graphics team favors quarterly releases. In order to align with other people's release schedules, we'd really like to have the new compiler in a Mesa release at the end of Q3 (end of September / beginning of October). That's just over two months from now. In order to have a credible release, the compiler needs to be merged to master before then. A reasonable estimate puts the end of August as the latest possible merge time. Given how far the compiler has come in the last month, I have a lot of faith in being able to hit that target. We have developed our own set of merge requirements, and these are listed below. Since this is such a large subsystem, we want to solicit input from the other stakeholders. * No piglit regressions, except draw_buffers-05.vert, compared to master in swrast, i965, or i915. * Any failing tests do not crash (segfault, assertion failure, etc.). draw_buffers-05.vert is specifically excluded because I'm not sure the test is correct. One of the items on the TODO list is proper support for GLSL ES. That work won't happen until the last couple weeks of August, so I don't think any sort of ES testing is suitable merge criteria. Unless, of course, the tests in question should also work on desktop GLSL. We haven't and, for all practical purposes, can't test with Gallium or other hardware drivers. The new compiler generates the same assembly IR that the current compiler generates. We haven't added any instructions. It does, however, generate different combinations of instructions, different uses of registers, and so on. We don't expect there to be significant impact on other hardware, but there may be some. The optimizer in r300 will certainly see different sequences of instructions than it is accustomed to seeing. I can't foresee what impact this will have on that driver. I have put up the results of master and the glsl2 branch at http://people.freedesktop.org/~idr/results/. This run off compiler.tests from the glsl2 branch of Eric's piglit repository. A few of the failures (half a dozen or so) on master seem to be mutex related in the GLX code. Kristian is working on fixing that. :) We're already very close to our proposed merge criteria. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxHpJUACgkQX1gOwKyEAw9xfACfZkCpOE0Qo3+OXVJztiPVKpss FPwAn1NvXiSqXZk+XyWpRgPNfI5QtI18 =2Qs1 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] opencl (clover) patches question
mesa-dev, I've done some work with mesa's implementation of opencl (clover) (bug fixes and features), is it acceptable to email the patches to this list? I noticed a patch from 6+ months ago was never applied http://www.mail-archive.com/mesa3d-...@lists.sourceforge.net/msg10561.html from another author. It would be best if this patch was applied first (part of my patches address the same concerns so it would be ideal for me to work off of them and merge my changes). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium depth clamp support
On 07/21/2010 05:19 PM, Marek Olšák wrote: On Thu, Jul 22, 2010 at 12:17 AM, Roland Scheidegger mailto:srol...@vmware.com>> wrote: Marek Olšák wrote: Hi, there is a new branch gallium-depth-clamp in the main repository which implements ARB_depth_clamp in Gallium. Wine uses this extension to disable clipping when it's requested from a D3D9 app, so it's an important one. There is a new state "depth_clamp" in pipe_clip_state, and a new cap PIPE_CAP_DEPTH_CLAMP. If you think this feature should be mandatory in Gallium instead, it's ok with me. There are several reasons I put the enable bit in pipe_clip_state, but the most important one is that Z clipping must be disabled in hardware first for it to work. It also implements depth_clamp handling in cso_cache and wires up ARB_depth_clamp in st/mesa. The support in Draw has also been implemented, and both softpipe and llvmpipe pass piglit/depth_clamp and piglit/depth-clamp-range. http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp One thing I was wondering does it actually make sense to call it depth clamp? I think d3d10 name for once (which calls this functionality depth clip though of course this means enable/disable is reversed) makes more sense - this disables near/far plane clipping, hence the necessity to clamp to 0/1. I guess having this in clip state is ok - d3d10 puts depth clip into rasterizer state, but then again d3d10 doesn't have any clip state... Depth clip does sound better to me, but honestly I don't care how we call it. If you like the D3D naming, so be it. There's two aspects to the GL extension: - near/far Z clipping - fragment Z clamping during interpolation I think pipe_clip_state::depth_clamp should become pipe_clip_state::depth_clip. Then, I'd probably add the second part of this as pipe_rasterizer_state::depth_clamp to enable/disable fragment Z clamping. GL would set both pieces of state in tandem. I think we should have two pieces of state to avoid interdependencies between clip state and rasterization state in the drivers. I'm not sure how this is expressed in Direct3D. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium depth clamp support
On Thu, Jul 22, 2010 at 12:17 AM, Roland Scheidegger wrote: > Marek Olšák wrote: > >> Hi, >> >> there is a new branch gallium-depth-clamp in the main repository which >> implements ARB_depth_clamp in Gallium. Wine uses this extension to disable >> clipping when it's requested from a D3D9 app, so it's an important one. >> >> There is a new state "depth_clamp" in pipe_clip_state, and a new cap >> PIPE_CAP_DEPTH_CLAMP. If you think this feature should be mandatory in >> Gallium instead, it's ok with me. There are several reasons I put the enable >> bit in pipe_clip_state, but the most important one is that Z clipping must >> be disabled in hardware first for it to work. It also implements depth_clamp >> handling in cso_cache and wires up ARB_depth_clamp in st/mesa. >> >> The support in Draw has also been implemented, and both softpipe and >> llvmpipe pass piglit/depth_clamp and piglit/depth-clamp-range. >> >> http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp >> > > One thing I was wondering does it actually make sense to call it depth > clamp? I think d3d10 name for once (which calls this functionality depth > clip though of course this means enable/disable is reversed) makes more > sense - this disables near/far plane clipping, hence the necessity to clamp > to 0/1. > I guess having this in clip state is ok - d3d10 puts depth clip into > rasterizer state, but then again d3d10 doesn't have any clip state... > Depth clip does sound better to me, but honestly I don't care how we call it. If you like the D3D naming, so be it. -Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium depth clamp support
Marek Olšák wrote: Hi, there is a new branch gallium-depth-clamp in the main repository which implements ARB_depth_clamp in Gallium. Wine uses this extension to disable clipping when it's requested from a D3D9 app, so it's an important one. There is a new state "depth_clamp" in pipe_clip_state, and a new cap PIPE_CAP_DEPTH_CLAMP. If you think this feature should be mandatory in Gallium instead, it's ok with me. There are several reasons I put the enable bit in pipe_clip_state, but the most important one is that Z clipping must be disabled in hardware first for it to work. It also implements depth_clamp handling in cso_cache and wires up ARB_depth_clamp in st/mesa. The support in Draw has also been implemented, and both softpipe and llvmpipe pass piglit/depth_clamp and piglit/depth-clamp-range. http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp One thing I was wondering does it actually make sense to call it depth clamp? I think d3d10 name for once (which calls this functionality depth clip though of course this means enable/disable is reversed) makes more sense - this disables near/far plane clipping, hence the necessity to clamp to 0/1. I guess having this in clip state is ok - d3d10 puts depth clip into rasterizer state, but then again d3d10 doesn't have any clip state... Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29148] KWin segfaults when OpenGL desktop effects are enabled
https://bugs.freedesktop.org/show_bug.cgi?id=29148 --- Comment #6 from Chris Haumesser 2010-07-21 14:47:50 PDT --- The problem persists for me, too. Exact same symptoms as in comment 2, using 7.9.0+git20100720.bab484a5 meas version (latest in xorg-edgers ppa). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): dri2: Remove an unused variable.
On 07/21/2010 04:29 PM, Carl Worth wrote:
Module: Mesa
Branch: master
Commit: c0ca2bfb2ad8cf7fb9d756b5ae52cb77236ff605
URL:
http://cgit.freedesktop.org/mesa/mesa/commit/?id=c0ca2bfb2ad8cf7fb9d756b5ae52cb77236ff605
Author: Carl Worth
Date: Wed Jul 21 13:17:05 2010 -0700
dri2: Remove an unused variable.
To quiet a compiler warning.
---
src/glx/dri2.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/src/glx/dri2.c b/src/glx/dri2.c
index ab530ba..6b8b2b9 100644
--- a/src/glx/dri2.c
+++ b/src/glx/dri2.c
@@ -88,7 +88,6 @@ static Bool
DRI2WireToEvent(Display *dpy, XEvent *event, xEvent *wire)
{
XExtDisplayInfo *info = DRI2FindDisplay(dpy);
- XExtDisplayInfo *glx_info = __glXFindDisplay(dpy);
XextCheckExtension(dpy, info, dri2ExtensionName, False);
___
mesa-commit mailing list
mesa-com...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-commit
It's used if X_DRI2SwapBuffers is defined, we can silence out
the warning another way if you want. I pushed a revert from
your patch.
Cheers,
Jerome
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29148] KWin segfaults when OpenGL desktop effects are enabled
https://bugs.freedesktop.org/show_bug.cgi?id=29148 --- Comment #5 from Alain Perrot 2010-07-21 14:34:03 PDT --- After a reboot, KDE failed again to start a session with OpenGL effects enabled... No segfault, screen freezed on KDE start screen, mouse cursor moving. KDE starts without a problem with XRender effects. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium depth clamp support
On Wed, Jul 21, 2010 at 3:54 PM, Keith Whitwell wrote: > On Wed, 2010-07-21 at 01:49 -0700, Marek Olšák wrote: > > Hi, > > > > there is a new branch gallium-depth-clamp in the main repository which > > implements ARB_depth_clamp in Gallium. Wine uses this extension to > > disable clipping when it's requested from a D3D9 app, so it's an > > important one. > > > > There is a new state "depth_clamp" in pipe_clip_state, and a new cap > > PIPE_CAP_DEPTH_CLAMP. If you think this feature should be mandatory in > > Gallium instead, it's ok with me. There are several reasons I put the > > enable bit in pipe_clip_state, but the most important one is that Z > > clipping must be disabled in hardware first for it to work. It also > > implements depth_clamp handling in cso_cache and wires up > > ARB_depth_clamp in st/mesa. > > > > The support in Draw has also been implemented, and both softpipe and > > llvmpipe pass piglit/depth_clamp and piglit/depth-clamp-range. > > > > http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp > > > > Please review. > > > > -Marek > > > Marek, > > This looks like a useful change. > > I'm not sure it's actually going go give the expected results for > softpipe/llvmpipe or other users of the path you've put into the draw > module. > > In particular it looks like the spec calls for clamping depth on a > per-pixel basis, where as this is doing it per-vertex. > > The difference is that the spec would allow a triangle with one distant > vertex to hit the far plane and then be clamped to it, whereas your > change means that the triangle as a whole will be altered to be in front > of the depth plane and touch it at one vertex. > > Basically, I think the draw change needs to reduced to just disabling > depth clipping, and (if you like) a clamp(depth, 0, 1) introduced into > softpipe/llvmpipe. Or just don't advertise the cap for > softpipe/llvmpipe. > You're absolutely right. Ok then, I've corrected the Draw changes and committed the patches without advertising the cap for software pipes. -Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29148] KWin segfaults when OpenGL desktop effects are enabled
https://bugs.freedesktop.org/show_bug.cgi?id=29148 --- Comment #4 from Alain Perrot 2010-07-21 13:28:34 PDT --- I still had problem with version 7.9.0+git20100719.3750ebd5-0ubuntu0sarvatt of mesa packages from Xorg-edgers PPA (which, given the version string, I suppose contain the commit you point to): kwin did not segfault, but the whole desktop freezed, with the mouse cursor still moving. I could still switch to a terminal (Ctrl Alt F1) and restart a new X (sudo service kdm restart). But the newest version 7.9.0+git20100720.bab484a5-0ubuntu0sarvatt of mesa packages seems to work so far. [Well, some 3D effects that used to work with mesa/r600 and KDE 4.4.x are now unsupported (ie. the cover flow window switching) or dead slow (ie. the session start/end shading) with KDE 4.5, but that's a another issue.] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29148] KWin segfaults when OpenGL desktop effects are enabled
https://bugs.freedesktop.org/show_bug.cgi?id=29148 --- Comment #3 from Kristian Høgsberg 2010-07-21 13:04:31 PDT --- This commit should fix it: commit 3750ebd540510324ef5ada769537ae05309adadb Author: Kristian Høgsberg Date: Mon Jul 19 09:37:07 2010 -0400 glx: Fix drawable lookup in DRI2 event handler DRI2 events are sent to the X drawable ID used to create the DRI2 drawable, not the GLX drawable ID. So when an event comes in, we need to look up the __GLXDRIdrawable by its X drawable ID, which needs a new hash table. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29148] KWin segfaults when OpenGL desktop effects are enabled
https://bugs.freedesktop.org/show_bug.cgi?id=29148 Chris Haumesser changed: What|Removed |Added CC||c...@wryfi.net --- Comment #2 from Chris Haumesser 2010-07-21 12:10:45 PDT --- I can confirm this bug as well. Since upgrading to mesa 7.9.0+git20100716 via xorg-edgers, compositing in KDE has stopped working (I may have skipped a couple of versions in between). The last known working version for me was also the 20100714 build. When I run kwin from a terminal, the following is printed when trying to enable compositing from System Settings: kwin(6143) KWin::Workspace::slotReconfigure: Workspace::slotReconfigure() kwin(6143) KWin::Extensions::init: Extensions: shape: 0x "11" composite: 0x "4" render: 0x "b" fixes: 0x "40" kwin(6143) KWin::CompositingPrefs::detect: glx version is 1 . 4 kwin(6143) KWin::CompositingPrefs::initGLXContext: Error: couldn't find RGB GLX visual kwin(6143) KDecorationPlugins::loadPlugin: kwin : path "/usr/lib/kde4/kwin3_oxygen.so" for "kwin3_oxygen" kwin(6143) KWin::Extensions::init: Extensions: shape: 0x "11" composite: 0x "4" render: 0x "b" fixes: 0x "40" kwin(6143) KWin::Workspace::setupCompositing: OpenGL compositing kwin(6143): GLX_SGIX_fbconfig or required GLX functions missing kwin(6143): Failed to initialize compositing, compositing disabled Software : - Kubuntu Lucid, AMD64 - Linux 2.6.34.1 - KDE SC 4.4.5 - Mesa 7.9.0 (master) from Xorg-edgers PPA repository Hardware : - Mobility Radeon HD 3400 Series (RV620) - ThinkPad T400 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29199] Using negation as an argument to a shader function sometimes negates twice
https://bugs.freedesktop.org/show_bug.cgi?id=29199 --- Comment #1 from Neil Roberts 2010-07-21 11:41:33 PDT --- Created an attachment (id=37276) View: https://bugs.freedesktop.org/attachment.cgi?id=37276 Review: https://bugs.freedesktop.org/review?bug=29199&attachment=37276 Add a shader which does a negation as one of the arguments to dot This is basically doing: vec3 a_vec; vec3 b_vec; /* some random calculations */ float result = dot(-a_vec, b_vec); But for some reason it currently gets compiled as if it was: vec3 a_vec; vec3 b_vec; /* some random calculations */ float result = dot(--a_vec, b_vec); Ie, the negation gets done twice. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29199] New: Using negation as an argument to a shader function sometimes negates twice
https://bugs.freedesktop.org/show_bug.cgi?id=29199 Summary: Using negation as an argument to a shader function sometimes negates twice Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: n...@linux.intel.com In some situations (I'm not exactly sure what) if you use the unary negate operator in one of the arguments to a function then Mesa generates opcodes which do the negation twice (once in a MOV and once as part of a swizzle). For example, something like this: vec3 vec_a; vec3 vec_b; /* */ float result = dot(-vec_a, vec_b); generates the following instructions: MOV TEMP[1].xyz, TEMP[1].-x-y-z-w; <-- negation once with MOV MOV (-1 -0 -0 -0) DP3 TEMP[0].w, TEMP[1].-x-y-z-w, UNIFORM[1]; <-- negation again with swizzle DP3 -1 = (1 0 0) . (-1 0 0) Attached is a test for piglit. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29192] Kwin crashed after checking an advanced setting in Desktop Effects
https://bugs.freedesktop.org/show_bug.cgi?id=29192 --- Comment #2 from Leonardo La Malfa 2010-07-21 08:30:46 PDT --- > This second report looks just like bug 29170, and your issue could very well > be related to it. Can you try the mesa patch there and see if it helps? Sure, I'd like to. Unfortunately, I've never applied any patch, sorry to be a nuysance. When I click on your attachment (is that the right file?) I get some code. What's the correct way to go about it? Many thanks! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Unified pipe_context::draw_vbo thoughts
On Mon, 2010-07-19 at 00:46 -0700, Chia-I Wu wrote:
> [change the subject because of typo and it is not about the patch]
>
> On Sun, Jul 18, 2010 at 7:31 PM, Keith Whitwell wrote:
> > If we're reorganising these interfaces, there are a couple of things I'd
> > like to see done differently. In particular, within your draw_info
> > struct there are a couple of entities which are often better handled as
> > persistent state - namely the primitive mode and index buffer binding.
> >
> > Right now we've got a single call which sets as much state as
> > glMultiDrawElementsIndexed, but which can only draw a single primitive.
> >
> > The ways out of this situation are to either move state out of
> > per-primitive transaction, or to modify the interface to accept >1
> > primitive at a time.
> >
> > My preference would be to move primitive mode & index buffer (and other
> > stuff too?) out of your info struct and turn them into new dynamic state
> > calls.
> > Having done that, it may still be worth considering passing >1 of your
> > info structs to the new unified entrypoints...
> I considered moving the index buffer state out, but I am not sure how to
> formulate int. Consider having a method that supports glMultiDrawElements.
> If
> the indices pointers point to different buffers in client memory, we need
> multiple index buffers.
I think the meaning of those pointers when an element array object is
bound is just different offsets into that buffer, as below.
> Even if all indices pointers are offsets to the
> currently bound index buffer, which may not be aligned to the index size, it
> seems to me that multiple index buffers are still desired.
I don't really see why that's the case -- GL itself is happy having just
a single element array binding point - we're just discussing promoting
the same concept into gallium.
So basically I think you're worrying about something which isn't an
actual requirement.
> As i965 does not seem to support multiple index buffers, I am favoring single
> index buffer, and skiping direct support for glMultiDrawElements in
> pipe_context at the moment. Then, the index buffer state would look like
>
> struct pipe_index_buffer
> {
> unsigned index_size;/**< size of an index, in bytes */
> unsigned offset;/**< offset to start of data in buffer */
> struct pipe_resource *buffer; /**< the actual buffer */
> };
This looks good.
> pipe_context::draw_vbo is unchanged, but pipe_draw_info is changed to
>
> struct pipe_draw_info
> {
> unsigned mode;
> unsigned start;
> unsigned count;
>
> unsigned first_instance;
> unsigned instance_count;
>
> int index_bias;
> unsigned min_index;
> unsigned max_index;
> };
>
> The last 3 fields are redundant for non-indexed drawing, but they still make
> sense (min_index == start, max_index == start + count - 1). Having the fields
> in the struct and having a single draw_vbo allow us to support indexed and
> non-indexed drawing in a single loop in st_draw_vbo.
>
> The struct can be extended to include "index buffer index" if multiple index
> buffers are desired. The purpose of using a struct here as the argument is
> that it is easier to be passed around inside a pipe driver and is easier to
> extend.
>
> I keep mode in the struct so that if in the future, the imaginary
> glMultiModeMultiDrawElementsInstancedBaseVertex is introduced, we can support
> it by changing draw_vbo to take an array of pipe_draw_info. Hardware (i965)
> also seems to send the primitive type along with the draw command.
It does, but the driver also sets up a bunch of hardware state in a
primitive dependent fashion.
I don't really feel strongly about primitive in/out of the struct, but
it does seem to be something which ends up being treated as state inside
most drivers - ie changes to primitive or reduced_primitive end up
triggering an update_state(), while usually the rest of the data there
does not.
> This is my current thoughts. Suggestions appreciated.
I like this a lot. I don't mind either way on mode, so this looks like
a good change to me.
I guess if we move enough stuff into state, the number of arguments to
this call get small enough that it no longer seems necessary to use a
struct...
Keith
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29192] Kwin crashed after checking an advanced setting in Desktop Effects
https://bugs.freedesktop.org/show_bug.cgi?id=29192 Nick Bowler changed: What|Removed |Added CC||nbow...@draconx.ca -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium depth clamp support
On Wed, 2010-07-21 at 06:54 -0700, Keith Whitwell wrote: > On Wed, 2010-07-21 at 01:49 -0700, Marek Olšák wrote: > > Hi, > > > > there is a new branch gallium-depth-clamp in the main repository which > > implements ARB_depth_clamp in Gallium. Wine uses this extension to > > disable clipping when it's requested from a D3D9 app, so it's an > > important one. > > > > There is a new state "depth_clamp" in pipe_clip_state, and a new cap > > PIPE_CAP_DEPTH_CLAMP. If you think this feature should be mandatory in > > Gallium instead, it's ok with me. There are several reasons I put the > > enable bit in pipe_clip_state, but the most important one is that Z > > clipping must be disabled in hardware first for it to work. It also > > implements depth_clamp handling in cso_cache and wires up > > ARB_depth_clamp in st/mesa. > > > > The support in Draw has also been implemented, and both softpipe and > > llvmpipe pass piglit/depth_clamp and piglit/depth-clamp-range. > > > > http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp > > > > Please review. > > > > -Marek > > > Marek, > > This looks like a useful change. > > I'm not sure it's actually going go give the expected results for > softpipe/llvmpipe or other users of the path you've put into the draw > module. > > In particular it looks like the spec calls for clamping depth on a > per-pixel basis, where as this is doing it per-vertex. > > The difference is that the spec would allow a triangle with one distant > vertex to hit the far plane and then be clamped to it, whereas your > change means that the triangle as a whole will be altered to be in front > of the depth plane and touch it at one vertex. > > Basically, I think the draw change needs to reduced to just disabling > depth clipping, and (if you like) a clamp(depth, 0, 1) introduced into > softpipe/llvmpipe. Or just don't advertise the cap for > softpipe/llvmpipe. > > Keith > > > > > > I would > > It adds an extra branch to the clipmask computation, but it's not like > that code is tuned at this point anyway... I' Hmm, random thoughts... Just ignore, please. Keith :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Gallium depth clamp support
On Wed, 2010-07-21 at 01:49 -0700, Marek Olšák wrote: > Hi, > > there is a new branch gallium-depth-clamp in the main repository which > implements ARB_depth_clamp in Gallium. Wine uses this extension to > disable clipping when it's requested from a D3D9 app, so it's an > important one. > > There is a new state "depth_clamp" in pipe_clip_state, and a new cap > PIPE_CAP_DEPTH_CLAMP. If you think this feature should be mandatory in > Gallium instead, it's ok with me. There are several reasons I put the > enable bit in pipe_clip_state, but the most important one is that Z > clipping must be disabled in hardware first for it to work. It also > implements depth_clamp handling in cso_cache and wires up > ARB_depth_clamp in st/mesa. > > The support in Draw has also been implemented, and both softpipe and > llvmpipe pass piglit/depth_clamp and piglit/depth-clamp-range. > > http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp > > Please review. > > -Marek Marek, This looks like a useful change. I'm not sure it's actually going go give the expected results for softpipe/llvmpipe or other users of the path you've put into the draw module. In particular it looks like the spec calls for clamping depth on a per-pixel basis, where as this is doing it per-vertex. The difference is that the spec would allow a triangle with one distant vertex to hit the far plane and then be clamped to it, whereas your change means that the triangle as a whole will be altered to be in front of the depth plane and touch it at one vertex. Basically, I think the draw change needs to reduced to just disabling depth clipping, and (if you like) a clamp(depth, 0, 1) introduced into softpipe/llvmpipe. Or just don't advertise the cap for softpipe/llvmpipe. Keith I would It adds an extra branch to the clipmask computation, but it's not like that code is tuned at this point anyway... I' ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29192] Kwin crashed after checking an advanced setting in Desktop Effects
https://bugs.freedesktop.org/show_bug.cgi?id=29192 --- Comment #1 from Nick Bowler 2010-07-21 06:44:54 PDT --- (In reply to comment #0) > I'm a Kubuntu user, and when I checked "Use VSync" setting in System > Settings>Desktop Effects>Advanced, Kwin crashed. I filed a bug against Kwin > (https://bugs.kde.org/show_bug.cgi?id=245238), but developers pointed out it > was a driver bug, and encouraged me to file a bug here against the driver. > > As pointed out during the exchange, there seems to be a general problem when > re/creating a gl context on the driver, as also bug 244820 > (https://bugs.kde.org/show_bug.cgi?id=244820) seems to confirm, which appears > to have a different backtrace but similar context. As for the backtrace of my > bug report, I'll paste it over here for ease of reference: This second report looks just like bug 29170, and your issue could very well be related to it. Can you try the mesa patch there and see if it helps? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29192] Kwin crashed after checking an advanced setting in Desktop Effects
https://bugs.freedesktop.org/show_bug.cgi?id=29192 Julien Cristau changed: What|Removed |Added Product|xorg|Mesa Component|App/other |GLX AssignedTo|xorg-t...@lists.x.org |mesa-...@lists.freedesktop. ||org QAContact|xorg-t...@lists.x.org | -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Gallium depth clamp support
Hi, there is a new branch gallium-depth-clamp in the main repository which implements ARB_depth_clamp in Gallium. Wine uses this extension to disable clipping when it's requested from a D3D9 app, so it's an important one. There is a new state "depth_clamp" in pipe_clip_state, and a new cap PIPE_CAP_DEPTH_CLAMP. If you think this feature should be mandatory in Gallium instead, it's ok with me. There are several reasons I put the enable bit in pipe_clip_state, but the most important one is that Z clipping must be disabled in hardware first for it to work. It also implements depth_clamp handling in cso_cache and wires up ARB_depth_clamp in st/mesa. The support in Draw has also been implemented, and both softpipe and llvmpipe pass piglit/depth_clamp and piglit/depth-clamp-range. http://cgit.freedesktop.org/mesa/mesa/log/?h=gallium-depth-clamp Please review. -Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
