[Mesa3d-dev] [PATCH] intel: intel_miptree_depth_offsets() returns byte offsets
This fixes a regression with 3D textures, introduced by
e5f50f2fa32c50807da3a8f13733f0fbc7868f94.
intel_miptree_depth_offsets() returns byte offsets
---
src/mesa/drivers/dri/intel/intel_mipmap_tree.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
index 1b645c7..9be7e02 100644
--- a/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/intel/intel_mipmap_tree.c
@@ -442,7 +442,7 @@ intel_miptree_image_data(struct intel_context *intel,
height = (height + 3) / 4;
intel_region_data(intel,
dst->region,
- dst_offset + dst_depth_offset[i] * dst->cpp, /*
dst_offset */
+ dst_offset + dst_depth_offset[i], /* dst_offset */
0, 0, /* dstx, dsty */
src,
src_row_pitch,
@@ -479,10 +479,10 @@ intel_miptree_image_copy(struct intel_context *intel,
for (i = 0; i < depth; i++) {
intel_region_copy(intel,
-dst->region, dst_offset + dst_depth_offset[i] *
dst->cpp,
+dst->region, dst_offset + dst_depth_offset[i],
0,
0,
-src->region, src_offset + src_depth_offset[i] *
src->cpp,
+src->region, src_offset + src_depth_offset[i],
0, 0, width, height);
}
--
1.5.6.3
-
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=100&url=/___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Fwd: Re: glxinfo and "client glx vendor string" with ATI cards]
On Mon, Jul 28, 2008 at 10:36 AM, Corbin Simpson <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Alex Deucher wrote: >> On Mon, Jul 28, 2008 at 4:22 AM, Alexandre Conrad <[EMAIL PROTECTED]> wrote: >>> Hey Corbin, >>> >>> I'm forwarding this email to the public ML. Thanks for the feedback. >>> >>> Regrads, >>> >>> Original Message >>> Subject: Re: [Mesa3d-dev] glxinfo and "client glx vendor string" with >>> ATI cards >>> Date: Fri, 25 Jul 2008 10:50:07 -0700 >>> From: Corbin Simpson <[EMAIL PROTECTED]> >>> To: Alexandre Conrad <[EMAIL PROTECTED]> >>> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> >>> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> >>> <[EMAIL PROTECTED]> >>> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Alexandre Conrad wrote: Philipp Klaus Krause wrote: >> """ >> Maybe this affects only the fglrx driver since I get this with my NVIDIA >> card: >> >> :~$ glxinfo | grep "client glx vendor" >> client glx vendor string: NVIDIA Corporation >> """ >> >> So the NVIDIA drivers (proprietary) seem to put some information here >> (thus enabling flash hardware accel). So I'm really not trying to make >> things incorrect, I'm just trying to make things more accurate by >> filling in more "fields" as it might have been "forgotten". Again, I'm >> not pointing my finger towards Mesa, I want to figure out who fills in >> this data. >> >> BTW, What does "SGI" stands for? >> > Nvidia uses their own GLX, so they put "NVIDIA corporation" in the > string. Everyone else uses the GLX initially made by SGI. SGI was a > vendor of highend graphics workstations, they played an important role > in OpenGL standardization. Lately they're more into supercomputing than > graphics. "Silicon Graphics" rang my bell but I was just unsure how they were related with "client glx vendor string" thing. That and why nvidia has something else than "SGI" makes sens to me now. > GLX is included in the Mesa tarball. You could change the vendor string > in /src/glx/x11/glxcmds.c (currently :static const char > __glXGLXClientVendorName[] = "SGI";). Great. I'll try to hack this, although I'm not sure to have the compiling skills... Thank you so much Philipp and Michel for your help and suggestions. This definitly cleared things up. I'll point this thread to Adobe. >>> Howdy. Sorry for getting here late. :3 >>> >>> One more caveat: >>> >>> Flash requires the following extensions to be present, even if it is not >>> actually using them, before it will enable OpenGL mode: >>> >>> - - GL_ARB_multitexture (done) >>> - - GL_EXT_framebuffer_object (FBO -> mem manager) >>> - - GL_ARB_shader_objects >>> - - GL_ARB_shading_language_100 (GLSL) >>> - - GL_ARB_fragment_shader (done) >>> >>> So we need a memory manager for DRI, and also GLSL, before we can get >>> HW-accelerated Flash. (Thank God they don't just check for OGL 2.0!) >>> >>> There was also a blocker bug with Mesa-based libGL on the Adobe side, >>> but it's been handled. >>> >>> Oh, and finally, the only reason they're not using Xv is because only >>> one DDX driver (nouveau) provides the RGB colorspace needed for Xv -- >>> theoretically, all of the textured-video Xv implementations could >>> support RGB, and this would be fairly easy (I've already got a >>> half-baked patch sitting around for this on xf86-video-ati...) >> >> Actually the radeon overlay Xv adapter exposes RGB surfaces as well. >> Do RGB Xv surfaces really give you anything over using render? > > Ish. If more drivers supported the RGB Xv formats, we might be able to > talk the Adobe guy into adding Xv acceleration into Flash. As is, Flash > is RGB-based, and they're not interested in bundling a YUV conversion > library just for Xv. (Never mind that they're ALREADY doing YUV->RGB in > software for Flash Video...) > > It's just a thought, since I bet we could equip all the DDX drivers with > RGB Xv a LOT faster than we could support GLSL and FBOs in Mesa. That's > really the only reason I brought it up. > > Hmm. Now that I think about it, there's a lot of reasons to use Xv in > Flash. In video mode, especially full-screen, it would be a lot faster > to draw the video controls in YUV mode, and just pass a YUV panel into > Xv, than to do the software conversion. But then again, we don't have > Flash source code, so this is the best short-term solution I can come up > with. Why not use Xv for YUV data, and render for RGB data? Both are available and accelerated on most chips. All RGB Xv support gives you is scaling. With render you not only get scaling, but transforms in general and composite ops. In fact, anholt even proposed adding YUV src formats to render. Alex - This SF.Net email is sponsored by the Moblin Your Move Developer's ch
Re: [Mesa3d-dev] [Fwd: Re: glxinfo and "client glx vendor string" with ATI cards]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Deucher wrote: > On Mon, Jul 28, 2008 at 4:22 AM, Alexandre Conrad <[EMAIL PROTECTED]> wrote: >> Hey Corbin, >> >> I'm forwarding this email to the public ML. Thanks for the feedback. >> >> Regrads, >> >> Original Message >> Subject: Re: [Mesa3d-dev] glxinfo and "client glx vendor string" with >> ATI cards >> Date: Fri, 25 Jul 2008 10:50:07 -0700 >> From: Corbin Simpson <[EMAIL PROTECTED]> >> To: Alexandre Conrad <[EMAIL PROTECTED]> >> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> >> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> >> <[EMAIL PROTECTED]> >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Alexandre Conrad wrote: >>> Philipp Klaus Krause wrote: >>> > """ > Maybe this affects only the fglrx driver since I get this with my NVIDIA > card: > > :~$ glxinfo | grep "client glx vendor" > client glx vendor string: NVIDIA Corporation > """ > > So the NVIDIA drivers (proprietary) seem to put some information here > (thus enabling flash hardware accel). So I'm really not trying to make > things incorrect, I'm just trying to make things more accurate by > filling in more "fields" as it might have been "forgotten". Again, I'm > not pointing my finger towards Mesa, I want to figure out who fills in > this data. > > BTW, What does "SGI" stands for? > Nvidia uses their own GLX, so they put "NVIDIA corporation" in the string. Everyone else uses the GLX initially made by SGI. SGI was a vendor of highend graphics workstations, they played an important role in OpenGL standardization. Lately they're more into supercomputing than graphics. >>> "Silicon Graphics" rang my bell but I was just unsure how they were >>> related with "client glx vendor string" thing. That and why nvidia has >>> something else than "SGI" makes sens to me now. >>> GLX is included in the Mesa tarball. You could change the vendor string in /src/glx/x11/glxcmds.c (currently :static const char __glXGLXClientVendorName[] = "SGI";). >>> Great. I'll try to hack this, although I'm not sure to have the >>> compiling skills... >>> >>> Thank you so much Philipp and Michel for your help and suggestions. This >>> definitly cleared things up. I'll point this thread to Adobe. >> Howdy. Sorry for getting here late. :3 >> >> One more caveat: >> >> Flash requires the following extensions to be present, even if it is not >> actually using them, before it will enable OpenGL mode: >> >> - - GL_ARB_multitexture (done) >> - - GL_EXT_framebuffer_object (FBO -> mem manager) >> - - GL_ARB_shader_objects >> - - GL_ARB_shading_language_100 (GLSL) >> - - GL_ARB_fragment_shader (done) >> >> So we need a memory manager for DRI, and also GLSL, before we can get >> HW-accelerated Flash. (Thank God they don't just check for OGL 2.0!) >> >> There was also a blocker bug with Mesa-based libGL on the Adobe side, >> but it's been handled. >> >> Oh, and finally, the only reason they're not using Xv is because only >> one DDX driver (nouveau) provides the RGB colorspace needed for Xv -- >> theoretically, all of the textured-video Xv implementations could >> support RGB, and this would be fairly easy (I've already got a >> half-baked patch sitting around for this on xf86-video-ati...) > > Actually the radeon overlay Xv adapter exposes RGB surfaces as well. > Do RGB Xv surfaces really give you anything over using render? Ish. If more drivers supported the RGB Xv formats, we might be able to talk the Adobe guy into adding Xv acceleration into Flash. As is, Flash is RGB-based, and they're not interested in bundling a YUV conversion library just for Xv. (Never mind that they're ALREADY doing YUV->RGB in software for Flash Video...) It's just a thought, since I bet we could equip all the DDX drivers with RGB Xv a LOT faster than we could support GLSL and FBOs in Mesa. That's really the only reason I brought it up. Hmm. Now that I think about it, there's a lot of reasons to use Xv in Flash. In video mode, especially full-screen, it would be a lot faster to draw the video controls in YUV mode, and just pass a YUV panel into Xv, than to do the software conversion. But then again, we don't have Flash source code, so this is the best short-term solution I can come up with. Or I guess we could just keep on pluggin' and ignore Flash-specific needs for now. ~ C. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiN2W0ACgkQeCCY8PC5utBolgCcDG7jVBYBlb1ibyigXVGs9xdp kEoAn08behFXqrT6EbEv1ymE+zhDEfvj =Pqdp -END PGP SIGNATURE- - 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 i
[Mesa3d-dev] [PATCH] Allow not building any drivers
I was asked to commit this patch, but I wanted to check first. Does this look ok? thanks, robert. 0001-autoconf-disable-dri-drivers-build-if-being-asked.patch Description: application/mbox 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=100&url=/___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Fwd: Re: glxinfo and "client glx vendor string" with ATI cards]
On Mon, Jul 28, 2008 at 4:22 AM, Alexandre Conrad <[EMAIL PROTECTED]> wrote: > Hey Corbin, > > I'm forwarding this email to the public ML. Thanks for the feedback. > > Regrads, > > Original Message > Subject: Re: [Mesa3d-dev] glxinfo and "client glx vendor string" with > ATI cards > Date: Fri, 25 Jul 2008 10:50:07 -0700 > From: Corbin Simpson <[EMAIL PROTECTED]> > To: Alexandre Conrad <[EMAIL PROTECTED]> > References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Alexandre Conrad wrote: >> Philipp Klaus Krause wrote: >> """ Maybe this affects only the fglrx driver since I get this with my NVIDIA card: :~$ glxinfo | grep "client glx vendor" client glx vendor string: NVIDIA Corporation """ So the NVIDIA drivers (proprietary) seem to put some information here (thus enabling flash hardware accel). So I'm really not trying to make things incorrect, I'm just trying to make things more accurate by filling in more "fields" as it might have been "forgotten". Again, I'm not pointing my finger towards Mesa, I want to figure out who fills in this data. BTW, What does "SGI" stands for? >>> Nvidia uses their own GLX, so they put "NVIDIA corporation" in the >>> string. Everyone else uses the GLX initially made by SGI. SGI was a >>> vendor of highend graphics workstations, they played an important role >>> in OpenGL standardization. Lately they're more into supercomputing than >>> graphics. >> >> "Silicon Graphics" rang my bell but I was just unsure how they were >> related with "client glx vendor string" thing. That and why nvidia has >> something else than "SGI" makes sens to me now. >> >>> GLX is included in the Mesa tarball. You could change the vendor string >>> in /src/glx/x11/glxcmds.c (currently :static const char >>> __glXGLXClientVendorName[] = "SGI";). >> >> Great. I'll try to hack this, although I'm not sure to have the >> compiling skills... >> >> Thank you so much Philipp and Michel for your help and suggestions. This >> definitly cleared things up. I'll point this thread to Adobe. > > Howdy. Sorry for getting here late. :3 > > One more caveat: > > Flash requires the following extensions to be present, even if it is not > actually using them, before it will enable OpenGL mode: > > - - GL_ARB_multitexture (done) > - - GL_EXT_framebuffer_object (FBO -> mem manager) > - - GL_ARB_shader_objects > - - GL_ARB_shading_language_100 (GLSL) > - - GL_ARB_fragment_shader (done) > > So we need a memory manager for DRI, and also GLSL, before we can get > HW-accelerated Flash. (Thank God they don't just check for OGL 2.0!) > > There was also a blocker bug with Mesa-based libGL on the Adobe side, > but it's been handled. > > Oh, and finally, the only reason they're not using Xv is because only > one DDX driver (nouveau) provides the RGB colorspace needed for Xv -- > theoretically, all of the textured-video Xv implementations could > support RGB, and this would be fairly easy (I've already got a > half-baked patch sitting around for this on xf86-video-ati...) Actually the radeon overlay Xv adapter exposes RGB surfaces as well. Do RGB Xv surfaces really give you anything over using render? Alex - 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=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 16123] kwin KDE 4.0.x artifacts
http://bugs.freedesktop.org/show_bug.cgi?id=16123 Michel Dänzer <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Michel Dänzer <[EMAIL PROTECTED]> 2008-07-28 02:01:49 PST --- Fixed on the master and 7.0 branches. commit 57aea290e1e0a26d1e74df6cff777eb9f038f1f8 Author: Michel Dänzer <[EMAIL PROTECTED]> Date: Mon Jul 28 10:49:43 2008 +0200 r300: Fix off-by-one error in calculation of scissor cliprect. Fixes http://bugs.freedesktop.org/show_bug.cgi?id=16123 . -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - 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=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Fwd: Re: glxinfo and "client glx vendor string" with ATI cards]
Hey Corbin, I'm forwarding this email to the public ML. Thanks for the feedback. Regrads, Original Message Subject: Re: [Mesa3d-dev] glxinfo and "client glx vendor string" with ATI cards Date: Fri, 25 Jul 2008 10:50:07 -0700 From: Corbin Simpson <[EMAIL PROTECTED]> To: Alexandre Conrad <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandre Conrad wrote: > Philipp Klaus Krause wrote: > >>> """ >>> Maybe this affects only the fglrx driver since I get this with my NVIDIA >>> card: >>> >>> :~$ glxinfo | grep "client glx vendor" >>> client glx vendor string: NVIDIA Corporation >>> """ >>> >>> So the NVIDIA drivers (proprietary) seem to put some information here >>> (thus enabling flash hardware accel). So I'm really not trying to make >>> things incorrect, I'm just trying to make things more accurate by >>> filling in more "fields" as it might have been "forgotten". Again, I'm >>> not pointing my finger towards Mesa, I want to figure out who fills in >>> this data. >>> >>> BTW, What does "SGI" stands for? >>> >> Nvidia uses their own GLX, so they put "NVIDIA corporation" in the >> string. Everyone else uses the GLX initially made by SGI. SGI was a >> vendor of highend graphics workstations, they played an important role >> in OpenGL standardization. Lately they're more into supercomputing than >> graphics. > > "Silicon Graphics" rang my bell but I was just unsure how they were > related with "client glx vendor string" thing. That and why nvidia has > something else than "SGI" makes sens to me now. > >> GLX is included in the Mesa tarball. You could change the vendor string >> in /src/glx/x11/glxcmds.c (currently :static const char >> __glXGLXClientVendorName[] = "SGI";). > > Great. I'll try to hack this, although I'm not sure to have the > compiling skills... > > Thank you so much Philipp and Michel for your help and suggestions. This > definitly cleared things up. I'll point this thread to Adobe. Howdy. Sorry for getting here late. :3 One more caveat: Flash requires the following extensions to be present, even if it is not actually using them, before it will enable OpenGL mode: - - GL_ARB_multitexture (done) - - GL_EXT_framebuffer_object (FBO -> mem manager) - - GL_ARB_shader_objects - - GL_ARB_shading_language_100 (GLSL) - - GL_ARB_fragment_shader (done) So we need a memory manager for DRI, and also GLSL, before we can get HW-accelerated Flash. (Thank God they don't just check for OGL 2.0!) There was also a blocker bug with Mesa-based libGL on the Adobe side, but it's been handled. Oh, and finally, the only reason they're not using Xv is because only one DDX driver (nouveau) provides the RGB colorspace needed for Xv -- theoretically, all of the textured-video Xv implementations could support RGB, and this would be fairly easy (I've already got a half-baked patch sitting around for this on xf86-video-ati...) If we all got together and patched the Radeon and Intel drivers to support this, then Xv would suffice for all of the free drivers, which might make it "worth it" to Adobe. On the other hand, there's only one guy working on the Linux port, so he might just be porting the OpenGL code from Windows. (Insert speculation here.) ~ C. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiKEk8ACgkQeCCY8PC5utC89QCeO+sH50a5z/eKzou4CUue3ZeR 5gQAn2lGv3QY6bkRDq5w5aRQrkkuTyde =TgMb -END PGP SIGNATURE- -- Alexandre CONRAD - 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=100&url=/ ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
