Re: [Mesa-dev] Should we need one release function for DRI's GLX_EXT_texture_from_pixmap?
On Thu, Jan 6, 2011 at 9:01 PM, Zhao, Juan J wrote: > On Thu, 2011-01-06 at 08:36 -0500, Kristian Høgsberg wrote: >> On Thu, Jan 6, 2011 at 4:33 AM, Zhao, Juan J wrote: >> > On Wed, 2011-01-05 at 08:28 -0500, Kristian Høgsberg wrote: >> >> On Tue, Jan 4, 2011 at 11:10 PM, Zhao, Juan J >> >> wrote: >> >> > Hi all, >> >> > >> >> > In the structure “__DRItexBufferExtensionRec”, we don’t >> >> > have >> >> > one release interface now. But in our platform, we need to release some >> >> > resources. >> >> > >> >> > Why we don’t need the release interface? Or should we >> >> > add >> >> > one? >> >> >> >> In the open source drivers, glXBindTexImageEXT is pretty much the same >> >> as glBindTexture. The pixmaps stays bound until you bind another >> >> texture or pixmap, at which point all the resources are released. >> >> There is nothing for the open source drivers to do in release, so the >> >> DRI extension never had a release function. If you need a release >> >> function, just send a patch and we can add it. You'll need to bump >> >> the extension version number and then add the call to release in the >> >> dri loaders (libGL, AIGLX, egl_dri2) conditional on the extension >> >> version. >> >> >> > Thanks a lot! :) >> > I add this interface. Would you please help to check it? >> >> Kristian >> >> Looks good, just a few commets: I don't think we need the format >> argument in release do we? I'd like to drop that to make it a little >> easier to call the release function. > Thank your for your comments.:) > Yes, we don't need this. I just removed this parameter. > >> Also, in files in the mesa repo, >> and in particular dri_interface.h, we don't need to check for >> __DRI_TEX_BUFFER_VERSION >=3, since we know exactly what versions are >> available. Only the AIGLX code in X (and potentially other >> out-of-tree users of the DRI driver interface) need this. > OK. And I updated this. > >> And please >> keep the commit message under 80 characters wide: use a short >> description in the header, then provide more detail in the following >> lines, if necessary. > Thanks a lot. I corrected the commit message. > >> Finally, why do you need the invalidate call in >> dri2_release_tex_image()? > I think the invalidate call is used to flush and bump the stamp > sequence. When the stamp is changed, we will update render buffers and > finally update frame-buffer size. Now we are releasing the texture > image, so we need this call. But we're binding a pixmap - they never change size and never need to be invalidated. Does it not work without the invalidate call there? As it is, it introduces a roundtrip on every bind/release cycle. Aside from the invalidate call, the patch is good to go. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa-demos 1/6] es1_info: convert indentString into a literal string
Thanks, I've applied the patch series.
-Brian
On 01/06/2011 09:09 AM, Paulo Zanoni wrote:
This fixes compilation with "-Wformat -Werror=format-security". Some
distros like Mandriva enable this flag by default. Its purpose is to
improve security.
Another option for this patch would be to do
"printf("%s", indentString)", but converting indentString into a literal
also gives the compiler some hints to improve performance.
Signed-off-by: Paulo Zanoni
---
By the way, combining this patch with a "printf("%s", indentString)" would
make the code even safer. The last patch of this series does this change, so
you can choose to apply it or not.
Using "printf(string);" is dangerous, might lead to bugs and even
security issues. If the string being printed contains the "%" character
one can do really dangerous things. Even if you think the string in
question might not be dangerous, future code changes might lead that
piece of code to bugs or security holes.
Some references:
http://wiki.mandriva.com/en/Development/Packaging/Problems#format_not_a_string_literal_and_no_format_arguments
http://wiki.debian.org/Hardening#DEBBUILDHARDENINGFORMAT.28gcc.2BAC8-g.2B-.2B--Wformat-Wformat-security.29
http://en.wikipedia.org/wiki/Format_string_attack
See also "How To Write Shared Libraries" Section 2.4.1, written by Ulrich
Drepper for more information on the difference between 'char *foo = "bar"'
and 'char foo[] = "bar"'
src/egl/opengles1/es1_info.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/egl/opengles1/es1_info.c b/src/egl/opengles1/es1_info.c
index 93816b5..38becc5 100644
--- a/src/egl/opengles1/es1_info.c
+++ b/src/egl/opengles1/es1_info.c
@@ -29,7 +29,7 @@
static void
print_extension_list(const char *ext)
{
- const char *indentString = "";
+ const char indentString[] = "";
const int indent = 4;
const int max = 79;
int width, i, j;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32879] egl_glx driver segfaults with NULL config
https://bugs.freedesktop.org/show_bug.cgi?id=32879 --- Comment #1 from Chia-I Wu 2011-01-06 21:07:56 PST --- There is a bug in 7.9 that makes NULL config to slip. I've cherry-picked the fix to it. Do you see this on all versions? When is config NULL? -- 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] Upcoming Mesa 7.9.1 and 7.10 releases
On 2011.01.06 13:56:25 +0800, Zhenyu Wang wrote: > Ian, I propose to pick up Eric's below commit on master, which is required to > fix fbo issue within ogles conformance suite on sandybridge. > > https://bugs.freedesktop.org/show_bug.cgi?id=32286 > > commit be72efb4f29180fdaf0935f8739f230fe5ea6317 > Author: Eric Anholt > Date: Thu Dec 9 17:15:26 2010 -0800 > > intel: Just use ChooseTextureFormat for renderbuffer format choice. > > One less place to forget to put your new MESA_FORMAT support in. > Although this change looks cosmetic, but old intelChooseTextureFormat() does have different format setting for RGBA4/RGB555A1/DEPTH_16,etc. to better comply with hw format, which is exactly the formats used in failed ogles fbo tests in above bug. So hope this could be included in 7.10 for more stable sandybridge support. I've done several piglit tests with above commit onto 7.10 on 965/G45/945, and no regression has been found. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: Digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 32825] egl_glx driver completely broken in 7.9 branch [fix in master]
https://bugs.freedesktop.org/show_bug.cgi?id=32825 --- Comment #7 from Chia-I Wu 2011-01-06 21:16:10 PST --- This fix is a WORKSFORME. I am not sure, but it may be a compatibility issue with your libGL. Could you set a breakpoint at _eglSetConfigKey and see when is 0x3034 set and to which value? -- 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] Uploading PIPE_FORMAT_B8G8R8A8_UNORM to pixmap texture in PIPE_FORMAT_B8G8R8X8_UNORM
On Fri, Jan 7, 2011 at 2:57 AM, Fredrik Höglund wrote: > On Thursday 16 December 2010, Michel Dänzer wrote: >> The bigger issue here is that no blit should be necessary in the first >> place. According to Dave on IRC he implemented this using sampler views >> at some point, I guess that was probably broken during some EGL rework. > > Actually this is a regression from the changes to st_finalize_texture > in cae2bb76. > > The attached patch fixes the issue for me, and the piglit test still passes. > I don't know if it's correct in all cases though. > > If the patch looks good to you I'd like to see it in the 7.10 release. Looks good to me. Reviewed-by: Alex Deucher Alex > > Regards, > Fredrik > > > ___ > 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
