[Mesa-dev] [Bug 32666] etqw triggers an assert in st_texture.c
https://bugs.freedesktop.org/show_bug.cgi?id=32666 Álmos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Álmos 2011-03-03 02:46:19 PST --- With latest mesa master it works perfectly. Closing. -- 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] Mesa 7.8.2 DRI2 configuration mismatch
Dear All,
Sorry for such a big mail, i just want to put in detailed.
I am trying for hardware acceleration on Mesa 7.8.2 on RHEL6 which has kernel
version 2.6.32.
I compiled mesa with below configurations.
./configure --enable-gles2 --enable-egl --with-egl-platforms=drm
--with-dri-drivers=i965 --disable-glw --with-state-trackers=egl,dri,es
--enable-gallium-intel
it generated the below list of libraries
[srini@RHEL2 ~]$ ls -l /usr/local/lib/dri/
total 25636
-rwxr-xr-x 1 root root 12435719 Mar 2 17:31 i915_dri.so
-rwxr-xr-x 1 root root 13808225 Mar 3 15:35 i965_dri.so
[srini@RHEL2 ~]$ ls -l /usr/local/lib/egl/
total 7896
-rwxr-xr-x 1 root root 65323 Mar 3 11:06 egl_dri2.so
-rwxr-xr-x 1 root root 41347 Mar 2 17:31 egl_glx.so
-rwxr-xr-x 1 root root 3223726 Mar 2 17:31 egl_x11_i915.so
-rwxr-xr-x 1 root root 4744002 Mar 2 21:24 egl_x11_i965.so
srini@RHEL2 ~]$ ls -l /usr/local/lib/
total 22804
drwxr-xr-x 2 root root4096 Mar 3 15:35 dri
drwxr-xr-x 2 root root4096 Mar 3 11:06 egl
lrwxrwxrwx 1 root root 11 Mar 3 15:35 libEGL.so -> libEGL.so.1
lrwxrwxrwx 1 root root 13 Mar 3 15:35 libEGL.so.1 -> libEGL.so.1.0
-rwxr-xr-x 1 root root 240824 Mar 3 15:35 libEGL.so.1.0
lrwxrwxrwx 1 root root 17 Mar 3 15:35 libGLESv1_CM.so -> libGLESv1_CM.so.1
lrwxrwxrwx 1 root root 21 Mar 3 15:35 libGLESv1_CM.so.1 ->
libGLESv1_CM.so.1.1.0
-rwxr-xr-x 1 root root 9914669 Mar 2 17:31 libGLESv1_CM.so.1.1.0
lrwxrwxrwx 1 root root 14 Mar 3 15:35 libGLESv2.so -> libGLESv2.so.2
lrwxrwxrwx 1 root root 18 Mar 3 15:35 libGLESv2.so.2 -> libGLESv2.so.2.0.0
-rwxr-xr-x 1 root root 9721044 Mar 2 17:31 libGLESv2.so.2.0.0
lrwxrwxrwx 1 root root 10 Mar 3 15:35 libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root 12 Mar 3 15:35 libGL.so.1 -> libGL.so.1.2
-rwxr-xr-x 1 root root 1799639 Mar 2 17:31 libGL.so.1.2
lrwxrwxrwx 1 root root 11 Mar 3 15:35 libGLU.so -> libGLU.so.1
lrwxrwxrwx 1 root root 20 Mar 3 15:35 libGLU.so.1 -> libGLU.so.1.3.070802
-rwxr-xr-x 1 root root 1653469 Mar 2 17:31 libGLU.so.1.3.070802
drwxr-xr-x 2 root root4096 Mar 3 15:35 pkgconfig
Runing my test application, i got below error
[srini@RHEL2 check_GLES]$ ./sphere
libEGL fatal: DRI2: did not find extension DRI_IMAGE version 1
then i changed few stuff in the file egl_dri2.c. the changes are this.
static struct dri2_extension_match dri2_core_extensions[] = {
{ __DRI2_FLUSH, 1, offsetof(struct dri2_egl_display, flush) },
{ __DRI_TEX_BUFFER, 2, offsetof(struct dri2_egl_display, tex_buffer) },
{ NULL },
{ __DRI_IMAGE, 1, offsetof(struct dri2_egl_display, image) }
};
originally it was like this.
static struct dri2_extension_match dri2_core_extensions[] = {
{ __DRI2_FLUSH, 1, offsetof(struct dri2_egl_display, flush) },
{ __DRI_TEX_BUFFER, 2, offsetof(struct dri2_egl_display, tex_buffer) },
{ __DRI_IMAGE, 1, offsetof(struct dri2_egl_display, image) },
{ NULL }
};
I changed this after seeing the below structure in the file dri_screen.c
static const __DRIextension *dri_screen_extensions[] = {
&driReadDrawableExtension,
&driCopySubBufferExtension.base,
&driSwapControlExtension.base,
&driFrameTrackingExtension.base,
&driMediaStreamCounterExtension.base,
&dri2TexBufferExtension.base,
&dri2FlushExtension.base,
NULL
};
which actually loads the dri_extension, doesn't have entry for image_extension.
with this change build,eglInitilization is successfull. which actually create
the screen, configurations everything.
but the application when comming to eglChooseConfig(), it could not find the
matching EGL attributes. below is my attribute list my application is quering
for.
static const EGLint attribs[] = {
EGL_RED_SIZE, 1,
EGL_GREEN_SIZE, 1,
EGL_BLUE_SIZE, 1,
EGL_DEPTH_SIZE, 1,
EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
EGL_NONE
};
and i am endup with the error.
-
[srini@RHEL2 check_GLES]$ ./sphere
libEGL debug: dlopen(/usr/local/lib/egl/egl_dri2.so)
libEGL debug: DRI2: dlopen(/usr/local/lib/dri/i965_dri.so)
libEGL debug: DRI2: found extension `DRI_Core'
libEGL info: DRI2: found extension DRI_Core version 1
libEGL debug: DRI2: found extension `DRI_Legacy'
libEGL debug: DRI2: found extension `DRI_DRI2'
libEGL info: DRI2: found extension DRI_DRI2 version 1
libEGL debug: DRI2: found exten
Re: [Mesa-dev] build fails with current git
Andy Furniss wrote: I am getting a build fail today - mklib: Making Linux static library: libglapi.a ar: creating libglapi.a make[2]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/mapi/glapi' make[2]: Entering directory `/home/andy/Src/Mesa-git/mesa/src/glsl' flex --nounistd -oglcpp/glcpp-lex.c glcpp/glcpp-lex.l bison -v -o "glcpp/glcpp-parse.c" --defines=glcpp/glcpp-parse.h glcpp/glcpp-parse.y flex --nounistd -oglsl_lexer.cpp glsl_lexer.ll bison -v -o "glsl_parser.cpp" -p "_mesa_glsl_" --defines=glsl_parser.h glsl_parser.yy glcpp/glcpp-lex.l:55: unrecognized %option: extra-type glsl_lexer.ll:86: unrecognized %option: extra-type glsl_parser.yy: conflicts: 1 shift/reduce make[2]: *** No rule to make target `depend', needed by `default'. Stop. make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/glsl' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src' make: *** [default] Error 1 Updating flex fixed it - though I also had to re-clone as make distclean wasn't enough to get rid of a link error. r600_dri.so.tmp: undefined reference to `yylex_init_extra' ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 31159] shadow problem in 0ad game
https://bugs.freedesktop.org/show_bug.cgi?id=31159 --- Comment #1 from Marek Olšák 2011-03-03 05:22:11 PST --- I was looking into this issue and I wasn't able to find the cause. I guess there is a bug in the texenv program code, because both swrast and gallium fail, and because the only shaders which generate 2DSHADOW texture fetch instructions are texenv programs. Would it be possible to make a simple test case? -- 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 8640] Driver does not support GLX_SGI_make_current_read
https://bugs.freedesktop.org/show_bug.cgi?id=8640 Marek Olšák changed: What|Removed |Added Summary|[810] Driver does not |Driver does not support |support |GLX_SGI_make_current_read |GLX_SGI_make_current_read | Status|NEW |RESOLVED Resolution||FIXED Component|Drivers/DRI/i810|GLX AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org --- Comment #4 from Marek Olšák 2011-03-03 05:40:43 PST --- The extension is available on swrast and the hardware drivers I have here, so I guess it's also available on i810. This issue doesn't seem to be driver-specific at all. Closing. -- 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 32006] KMS/R100 - [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=32006 Marek Olšák changed: What|Removed |Added Component|Other |Drivers/DRI/Radeon AssignedTo|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.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] [Bug 4704] Modify glxgears to not output FPS by default.
https://bugs.freedesktop.org/show_bug.cgi?id=4704 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #9 from Marek Olšák 2011-03-03 06:08:42 PST --- (In reply to comment #3) > Actually gears *is* a benchmark -- primarily a benchmark of swapbuffers. The > fact that swapbuffers has gotten a lot slower recently isn't a justification > for turning off the output. > > I can't really think of any reason to run gears except to get the fps number > -- > what other purpose does that application have? I agree. Anyway, no matter if we print fps or not, some people will always consider it a benchmark of something else than swapbuffers. That's their problem, not ours. Closing. -- 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 29029] mesa-demos scons build fails
https://bugs.freedesktop.org/show_bug.cgi?id=29029 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Marek Olšák 2011-03-03 06:13:14 PST --- Demos are now in a separate repository and there are no scons build scripts. Closing. -- 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 12365] Vegastrike not useable under Archlinux.
https://bugs.freedesktop.org/show_bug.cgi?id=12365 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Version|XOrg CVS|unspecified Component|libGL |Mesa core AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|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] [Bug 14134] Crash when context is shared among 2 processes.
https://bugs.freedesktop.org/show_bug.cgi?id=14134 Marek Olšák changed: What|Removed |Added Product|DRI |Mesa Component|libglx |GLX AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|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
Re: [Mesa-dev] build fails with current git
On Thu, Mar 3, 2011 at 3:44 AM, Andy Furniss wrote: > Andy Furniss wrote: >> >> I am getting a build fail today - >> >> mklib: Making Linux static library: libglapi.a >> ar: creating libglapi.a >> make[2]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/mapi/glapi' >> make[2]: Entering directory `/home/andy/Src/Mesa-git/mesa/src/glsl' >> flex --nounistd -oglcpp/glcpp-lex.c glcpp/glcpp-lex.l >> bison -v -o "glcpp/glcpp-parse.c" --defines=glcpp/glcpp-parse.h >> glcpp/glcpp-parse.y >> flex --nounistd -oglsl_lexer.cpp glsl_lexer.ll >> bison -v -o "glsl_parser.cpp" -p "_mesa_glsl_" --defines=glsl_parser.h >> glsl_parser.yy >> glcpp/glcpp-lex.l:55: unrecognized %option: extra-type >> glsl_lexer.ll:86: unrecognized %option: extra-type >> glsl_parser.yy: conflicts: 1 shift/reduce >> make[2]: *** No rule to make target `depend', needed by `default'. Stop. >> make[2]: *** Waiting for unfinished jobs >> make[2]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/glsl' >> make[1]: *** [subdirs] Error 1 >> make[1]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src' >> make: *** [default] Error 1 > > Updating flex fixed it - Just curious, what was the old version and the new version? though I also had to re-clone as make distclean > wasn't enough to get rid of a link error. > > r600_dri.so.tmp: undefined reference to `yylex_init_extra' -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] build fails with current git
Brian Paul wrote: On Thu, Mar 3, 2011 at 3:44 AM, Andy Furniss wrote: Andy Furniss wrote: I am getting a build fail today - mklib: Making Linux static library: libglapi.a ar: creating libglapi.a make[2]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/mapi/glapi' make[2]: Entering directory `/home/andy/Src/Mesa-git/mesa/src/glsl' flex --nounistd -oglcpp/glcpp-lex.c glcpp/glcpp-lex.l bison -v -o "glcpp/glcpp-parse.c" --defines=glcpp/glcpp-parse.h glcpp/glcpp-parse.y flex --nounistd -oglsl_lexer.cpp glsl_lexer.ll bison -v -o "glsl_parser.cpp" -p "_mesa_glsl_" --defines=glsl_parser.h glsl_parser.yy glcpp/glcpp-lex.l:55: unrecognized %option: extra-type glsl_lexer.ll:86: unrecognized %option: extra-type glsl_parser.yy: conflicts: 1 shift/reduce make[2]: *** No rule to make target `depend', needed by `default'. Stop. make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src/glsl' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/home/andy/Src/Mesa-git/mesa/src' make: *** [default] Error 1 Updating flex fixed it - Just curious, what was the old version and the new version? Old was 2.5.33 new is 2.5.35 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa-demos] Fix texwrap removal
Commit 92b0a9425d0f1b32e5568a9efaadc5641c56d24a removes texwrap.c but doesn't remove texwrap from the list of programs build by Makefile.am Signed-off-by: Jon TURNEY --- src/tests/Makefile.am |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/tests/Makefile.am b/src/tests/Makefile.am index e650b62..c1301fc 100644 --- a/src/tests/Makefile.am +++ b/src/tests/Makefile.am @@ -143,7 +143,6 @@ noinst_PROGRAMS = \ texobj \ texobjshare \ texrect \ - texwrap \ unfilledclip \ vparray \ vpeval \ -- 1.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa-demos] Fix texwrap removal
Pushed, thanks. Marek On Thu, Mar 3, 2011 at 9:25 PM, Jon TURNEY wrote: > Commit 92b0a9425d0f1b32e5568a9efaadc5641c56d24a removes texwrap.c > but doesn't remove texwrap from the list of programs build by Makefile.am > > Signed-off-by: Jon TURNEY > --- > src/tests/Makefile.am |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/src/tests/Makefile.am b/src/tests/Makefile.am > index e650b62..c1301fc 100644 > --- a/src/tests/Makefile.am > +++ b/src/tests/Makefile.am > @@ -143,7 +143,6 @@ noinst_PROGRAMS = \ >texobj \ >texobjshare \ >texrect \ > - texwrap \ >unfilledclip \ >vparray \ >vpeval \ > -- > 1.7.4 > > ___ > 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] [Bug 27268] GLSL: using step function in vec4 constructor is not completely correct
https://bugs.freedesktop.org/show_bug.cgi?id=27268 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Ian Romanick 2011-03-03 13:37:35 PST --- This test passes here on swrast and the i965 driver. Closing. -- 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] rgtc signed format and u_format: some open questions
About a), one day we should have this in a library shared by mesa/gallium, but until then anywhere is fine by me. About b) please provide unorm8 support for all formats. It's useful for debugging/displaying, e.g., writing to BMP files, or visualizing on a window. There is already a helper function called util_format_fits_rgba8unorm (or something like that) to determine whether a format can be faithfully represented in unorm8 or not. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Dave Airlie [airl...@gmail.com] Sent: Wednesday, March 02, 2011 5:29 To: mesa-dev@lists.freedesktop.org Subject: [Mesa-dev] rgtc signed format and u_format: some open questions Hi guys, Two open questions with the RGTC support in gallium: a) I'd like to share texcompress_rgtc_tmp.h between gallium and mesa, at the moment gallium has an extended ../../../mesa/main/texcompress_rgtc_tmp.h in it, do we have a better place to put this file? any suggestions on where things like this could live? b) mipmap generation in the state tracker was done with r8g8b8a8 unorm types, however I need snorm handling to generate mipmaps for the snorm types, however u_format only has two set of hooks unorm or float, so I added float support to generate mipmaps. That leaves me with some blank functions in the u_format_rgtc.c file, should I fix u_format generation to not generate unorm support for snorm types? also in u_format.csv nothing specifies that rgtc types are signed/unsigned except for the format name, any ideas on where I could stash this without breaking other assumptions? Dave. ___ 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] rgtc signed format and u_format: some open questions
On Fri, Mar 4, 2011 at 8:17 AM, Jose Fonseca wrote: > About a), one day we should have this in a library shared by mesa/gallium, > but until then anywhere is fine by me. > > About b) please provide unorm8 support for all formats. It's useful for > debugging/displaying, e.g., writing to BMP files, or visualizing on a window. > There is already a helper function called util_format_fits_rgba8unorm (or > something like that) to determine whether a format can be faithfully > represented in unorm8 or not. > I don't understand how it can be useful though, if I have an image internally represented at -128..127, and I dump it as unorm 0.255 it is going to actually me less useful I would guess as I'd try and interpret it. Though I've no idea what negative color looks like, the hooks are pretty easy to add in, but I'd like to add something to warn if they ever get used. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rgtc signed format and u_format: some open questions
On 03/03/2011 02:40 PM, Dave Airlie wrote: On Fri, Mar 4, 2011 at 8:17 AM, Jose Fonseca wrote: About a), one day we should have this in a library shared by mesa/gallium, but until then anywhere is fine by me. About b) please provide unorm8 support for all formats. It's useful for debugging/displaying, e.g., writing to BMP files, or visualizing on a window. There is already a helper function called util_format_fits_rgba8unorm (or something like that) to determine whether a format can be faithfully represented in unorm8 or not. I don't understand how it can be useful though, if I have an image internally represented at -128..127, and I dump it as unorm 0.255 it is going to actually me less useful I would guess as I'd try and interpret it. Though I've no idea what negative color looks like, the hooks are pretty easy to add in, but I'd like to add something to warn if they ever get used. You could either clamp the signed values to [0,127] or bias them by 128 I guess. It's not a huge deal. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 34974] Mesa demos regression since - tgsi: defer allocation of huge inputs/outputs until we have a gs
https://bugs.freedesktop.org/show_bug.cgi?id=34974 Rafael Monica changed: What|Removed |Added Component|Drivers/Gallium/r600|Mesa core AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org CC||monr...@gmail.com --- Comment #1 from Rafael Monica 2011-03-03 16:34:20 PST --- Seeing this also happening wit a bunch of piglit tests, both on r600g and softpipe. e.g: stencil-drawpixels scissor-copypixels scissor-bitmap -- 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 34974] Mesa demos regression since - tgsi: defer allocation of huge inputs/outputs until we have a gs
https://bugs.freedesktop.org/show_bug.cgi?id=34974 --- Comment #2 from Brian Paul 2011-03-03 16:51:32 PST --- What happens if you set GALLIUM_NOSSE=1? I bet the tgsi->sse2 translator needs to be updated. -- 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 34974] Mesa demos regression since - tgsi: defer allocation of huge inputs/outputs until we have a gs
https://bugs.freedesktop.org/show_bug.cgi?id=34974 --- Comment #3 from Rafael Monica 2011-03-03 17:18:59 PST --- Yeah, just did some quick tests and setting GALLIUM_NOSSE=1 does indeed seem to fix it. -- 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] auto generated glx code in X server
Hi guys, I know this used to work, but it seems to be well busted now. If you made glx changes in mesa you could just set XORG_BASE and run make and it would regenerate all the files in the X server which really are cryptic as all hell. Now when I do that stuff breaks all over the place, missing include, glx code in X won't build anymore etc. Is this still supposed to work? Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33886] fix gallium sampler view first_level usage
https://bugs.freedesktop.org/show_bug.cgi?id=33886 Marek Olšák changed: What|Removed |Added Attachment #42911|0 |1 is obsolete|| --- Comment #5 from Marek Olšák 2011-03-03 19:23:28 PST --- Created an attachment (id=44101) View: https://bugs.freedesktop.org/attachment.cgi?id=44101 Review: https://bugs.freedesktop.org/review?bug=33886&attachment=44101 patch for r300 rebased Is there any reason not to commit the patches? They work fine on r300g and softpipe. -- 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 33886] fix gallium sampler view first_level usage
https://bugs.freedesktop.org/show_bug.cgi?id=33886 --- Comment #6 from Brian Paul 2011-03-03 20:52:45 PST --- I'd like to get this resolved for llvmpipe too. I just haven't had the time. -- 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] [PATCH] st/mesa: set PIPE_BIND_RENDER_TARGET for sRGB formats if UNORM is supported
Because the format can be changed to UNORM in a sampler view.
This fixes:
state_tracker/st_atom_framebuffer.c:163:update_framebuffer_state:
Assertion `framebuffer->cbufs[i]->texture->bind & (1 << 1)' failed.
---
src/mesa/state_tracker/st_cb_texture.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index c3c4246..1e793dc 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -227,8 +227,17 @@ default_bindings(struct st_context *st, enum pipe_format
format)
if (screen->is_format_supported(screen, format, target, 0, bindings, geom))
return bindings;
- else
- return PIPE_BIND_SAMPLER_VIEW;
+ else {
+ /* Try non-sRGB. */
+ const gl_format linearFormat =
+ _mesa_get_srgb_format_linear(st_pipe_format_to_mesa_format(format));
+ format = st_mesa_format_to_pipe_format(linearFormat);
+
+ if (screen->is_format_supported(screen, format, target, 0, bindings,
geom))
+ return bindings;
+ else
+ return PIPE_BIND_SAMPLER_VIEW;
+ }
}
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: set PIPE_BIND_RENDER_TARGET for sRGB formats if UNORM is supported
On Thu, Mar 3, 2011 at 10:41 PM, Marek Olšák wrote:
> Because the format can be changed to UNORM in a sampler view.
>
> This fixes:
> state_tracker/st_atom_framebuffer.c:163:update_framebuffer_state:
> Assertion `framebuffer->cbufs[i]->texture->bind & (1 << 1)' failed.
> ---
> src/mesa/state_tracker/st_cb_texture.c | 13 +++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_texture.c
> b/src/mesa/state_tracker/st_cb_texture.c
> index c3c4246..1e793dc 100644
> --- a/src/mesa/state_tracker/st_cb_texture.c
> +++ b/src/mesa/state_tracker/st_cb_texture.c
> @@ -227,8 +227,17 @@ default_bindings(struct st_context *st, enum pipe_format
> format)
>
> if (screen->is_format_supported(screen, format, target, 0, bindings, geom))
> return bindings;
> - else
> - return PIPE_BIND_SAMPLER_VIEW;
> + else {
> + /* Try non-sRGB. */
> + const gl_format linearFormat =
> + _mesa_get_srgb_format_linear(st_pipe_format_to_mesa_format(format));
> + format = st_mesa_format_to_pipe_format(linearFormat);
How about:
format = util_format_linear(format);
> +
> + if (screen->is_format_supported(screen, format, target, 0, bindings,
> geom))
> + return bindings;
> + else
> + return PIPE_BIND_SAMPLER_VIEW;
> + }
> }
>
>
> --
> 1.7.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: set PIPE_BIND_RENDER_TARGET for sRGB formats if UNORM is supported
On Fri, Mar 4, 2011 at 7:35 AM, Brian Paul wrote:
> How about:
>
> format = util_format_linear(format);
>
Yeah, that's nicer, thanks. :) I am going to push this later today if there
are no objections.
Marek
diff --git a/src/mesa/state_tracker/st_cb_texture.c
b/src/mesa/state_tracker/st_cb_texture.c
index c3c4246..3f98ffd 100644
--- a/src/mesa/state_tracker/st_cb_texture.c
+++ b/src/mesa/state_tracker/st_cb_texture.c
@@ -227,8 +227,15 @@ default_bindings(struct st_context *st, enum
pipe_format format)
if (screen->is_format_supported(screen, format, target, 0, bindings,
geom))
return bindings;
- else
- return PIPE_BIND_SAMPLER_VIEW;
+ else {
+ /* Try non-sRGB. */
+ format = util_format_linear(format);
+
+ if (screen->is_format_supported(screen, format, target, 0, bindings,
geom))
+ return bindings;
+ else
+ return PIPE_BIND_SAMPLER_VIEW;
+ }
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rgtc signed format and u_format: some open questions
If we implement, we should follow the normal conversion rules. Imagine that user is doing a screen aligned textured quad blit from a snorm texture to a bgra_unorm8 rendertarget. And imagine inside llvmpipe/softpipe we detect blits and optimize this case by calling util_format_translate. It's far fetched, but it should still work as expected. There may be other more useful examples, or actual use cases. Point being that (un)pack_rgba_8unorm that it should do what's specified, not what looks better. It's perfectly fine if (un)pack_rgba_8unorm is not optimized -- one could just call internally rgtc's (un)pack_float_8norm if that helps. Thinking more about this, I agree it makes sense to make (un)pack_rgba_8unorm optional for formats that don't fit in there, and always use the (un)pack_rgba_float in those cases. It will be a bit of work to change the places that expect (un)pack_rgba_8unorm to be always there, but it will save code in the long term. Jose From: Brian Paul [bri...@vmware.com] Sent: Thursday, March 03, 2011 23:58 To: Dave Airlie Cc: Jose Fonseca; mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] rgtc signed format and u_format: some open questions On 03/03/2011 02:40 PM, Dave Airlie wrote: > On Fri, Mar 4, 2011 at 8:17 AM, Jose Fonseca wrote: >> About a), one day we should have this in a library shared by mesa/gallium, >> but until then anywhere is fine by me. >> >> About b) please provide unorm8 support for all formats. It's useful for >> debugging/displaying, e.g., writing to BMP files, or visualizing on a >> window. There is already a helper function called >> util_format_fits_rgba8unorm (or something like that) to determine whether a >> format can be faithfully represented in unorm8 or not. >> > > I don't understand how it can be useful though, if I have an image > internally represented at -128..127, and I dump it as unorm 0.255 it > is going to actually me less useful I would guess as I'd try and > interpret it. Though I've no idea what negative color looks like, the > hooks are pretty easy to add in, but I'd like to add something to warn > if they ever get used. You could either clamp the signed values to [0,127] or bias them by 128 I guess. It's not a huge deal. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
