[Bug 12786] New: apply 3D texture after 2D texture works incorrectly on 915 platform
http://bugs.freedesktop.org/show_bug.cgi?id=12786 Summary: apply 3D texture after 2D texture works incorrectly on 915 platform Product: Mesa Version: CVS Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] System Environment: -- --Platform: FC6 --Xf86_video_intel:56ae767180da4a8bd4b7a4c35b92e019ab67d753 --Mesa:03ff9c96bf73b53c6c95f2db0aa79cfb1ff9eb3b --DRM:f0fd53f86b30e230f3f34b49b54392d20f053a89 --Kernel:2.6.22 Bug detailed description: -- create a 2D texture with border, and apply it to a QUARDS clean color buffer then create a 3D texture, with border color set to green, and apply it to a new QUARDS. since the GL_TEXTURE_WRAP_S is set to GL_CLAMP_TO_EDGE, the left/right edge should not use the color of border But it turns out, the QUARDS is drawn as a triangle, which is wrong. Reproduce steps: start X compile and run attached test case Current result: a triangle is drawn Expected result: QUARDS is drawn correctly and the left/right edge should not use the color of border -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRI interface changes
Michel Dänzer wrote: On Fri, 2007-10-12 at 10:19 +0100, Keith Whitwell wrote: Michel Dänzer wrote: On Thu, 2007-10-11 at 18:44 -0400, Kristian Høgsberg wrote: On 10/11/07, Keith Whitwell [EMAIL PROTECTED] wrote: 3) Share buffers with a reference counting scheme. When a client notices the buffer needs a resize, do the resize and adjust refcounts - other clients continue with the older buffer. What happens when a client on the older buffer calls swapbuffers -- I'm sure we can figure out what the correct behaviour should be. 3) Sounds like the best solution and it's basically what I'm proposing. I agree, it looks like this can provide the benefits of shared drawable-private renderbuffers (support for cooperative rendering schemes, no waste of renderbuffer resources) without compromising the general benefits of private renderbuffers. Yes, I'm just interested to understand what happens when one of the clients on the old, orphaned buffer calls swapbuffers... All the buffers should be swapped, right? Large and small? How does that work? If the answer is that we just do the swap on the largest buffer, then you have to wonder what the point of keeping the smaller ones around is? To make 3D drivers nice and simple by not having to deal with fun stuff like cliprects? :) Understood. I'm thinking about a further simplification - rather than keep the old buffers around after the first client requests a resize, just free them. If/when other clients submit commands targeting the old-sized buffers, throw those commands away. Seriously though, as I understand Kristian's planned scheme, all buffer swaps will be done by the DRM, and I presume it'll only take the currently registered back renderbuffer into account, so the contents of any previous back renderbuffers will be lost. I think that's fine, and should address your concerns? See above -- if the contents of the previous back renderbuffers are going to be lost, what is the point in keeping those buffers around? Or doing any further rendering into them? Keith - 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/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRI interface changes
On Fri, 2007-10-12 at 11:53 -0400, Kristian Høgsberg wrote: Finally, along with the X server patches, this does land new features. With these patches I can land the X server work to enable GLX 1.4 support and the visual cleanup, we just wont be able to advertise any GLXPixmap or GLXPbuffer capable fbconfigs yet. Okay, that makes sense then. Thanks for clarifying this. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - 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/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging DRI interface changes
On 10/12/07, Michel Dänzer [EMAIL PROTECTED] wrote:
...
The DRI driver interface changes I'm proposing here should not be
affected by these issues though. Detecting that the buffers changed
and allocating and attaching new ones is entirely between the DRI
driver and the DRM. When we're ready to add the TTM functionality to
a driver we add the new createNewScreen entry point I mentioned and
that's all we need to change. So, in other words, I believe we can
move forward with this merge while we figure out the semantics of the
resizing-while-rendering case.
Meanwhile though, these changes already drop support for existing
loaders, right? That's rather inconvenient for AIGLX, not so much for
libGL. I don't suppose it would be reasonably possible to retain support
for __driCreateNewScreen_20050727, at least until there's an xserver
release that supports the new one? If not, I wonder if it might be worth
holding off a bit longer until the changes will provide real benefits
such as new GLX features, as otherwise they would seem to require
inter-component lockstep for little gain.
They do drop support, yes, but of course, I'm committing a series of X
server patches along with this to let AIGLX load the new driver API.
This means that you can't load a git dri driver with any released X
server, which is the inconvenience you're referring to I guess. I do
think it's worth moving forward with this though. Personally, I get
these patches off of my plate and can focus on the next steps. We get
the patches upstream which will get them tested, and I think this is
important, since there's a lot more work in the pipeline from
everybody, so any early testing we can do is very much worth it.
Finally, along with the X server patches, this does land new features.
With these patches I can land the X server work to enable GLX 1.4
support and the visual cleanup, we just wont be able to advertise any
GLXPixmap or GLXPbuffer capable fbconfigs yet.
Apart from that, the changes look good to me, with one exception:
b068af2f3b890bec26a186e9d0bdd3d44c17cd4d ('Key drm_i915_flip_t typedef
off of the ioctl #define instead.'). DRM_IOCTL_I915_FLIP was already
defined before drm_i915_flip_t and friends were introduced.
Yup, my bad, I didn't install the libdrm pkg-config file.
cheers,
Kristian
-
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/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
New DRI interface changes landed
Hi, I've committed the new DRI interface that will enable GLX 1.4 and redirected rendering. The interface is not backwards compatible, so the git X server will not be able to load older DRI drivers for AIGLX and the DRI drivers from Mesa git wont work with older X servers. So to get AIGLX running, get and install git mesa, the compile the X server against that. Furthermore, the X server now needs the 1.4.9 version of glproto, since I added support for GLX_SGIX_pbuffer. I only tagged 1.4.9 in git, but didn't do tarballs or send out a release yet. Will do that as soon as possible. cheers, Kristian - 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/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
