[Mesa-dev] Anonymous unions (Was: [Bug 30789] mesa git fails to build)
What you guys feel about anonymous unions? I happened to committed some code with anonymous unions, but it caused gcc to choke when -std=c99 option is specified, which is only specified with automake but scons. After some search, it looks like anonymous unions are not part of C99, but are part of C++ and will reportedly be part of C1X [1]. I think all major compilers support it. I heard they are also often used together with bit fields to describe hardware registers. But for this to work to gcc we need to remove -std=c99, or replace with -std=gnu99, or pass -fms-extensions together with -std=c99. I don't care much either way. I'd just like to hear what's the general opinion on this to avoid ping-ponging on this matter. Jose [1] http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed-Fields ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30796] New: mesa builds drivers for r300 and Intel even when not asked to
https://bugs.freedesktop.org/show_bug.cgi?id=30796
Summary: mesa builds drivers for r300 and Intel even when not
asked to
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: hramr...@centrum.cz
./configure --disable-egl --disable-glu --disable-glut --enable-gallium-r600
--with-dri-drivers=r600 --with-state-trackers=dri,glx --enable-gallium-llvm
--enable-debug
prefix: /usr/local
exec_prefix: ${prefix}
libdir: ${exec_prefix}/lib
includedir: ${prefix}/include
Driver: dri
OSMesa: no
DRI drivers: r600
DRI driver dir: ${libdir}/dri
Use XCB: no
llvm:yes
llvm-config: /usr/bin/llvm-config
llvm-version:2.6
Gallium: yes
Gallium dirs:auxiliary drivers state_trackers
Target dirs: dri-r300 dri-r600 dri-swrast
Winsys dirs: sw sw/xlib sw/dri i915/sw radeon/drm r600/drm
Driver dirs: softpipe failover galahad trace rbug identity llvmpipe
svga i915 i965 r300 r600
Trackers dirs: dri glx
Shared libs: yes
Static libs: no
EGL: no
GLU: no
GLw: yes (Motif: no)
glut:no
CFLAGS: -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fvisibility=hidden -fno-strict-aliasing -g -fPIC
CXXFLAGS:-g -O2 -Wall -fvisibility=hidden -fno-strict-aliasing
-g -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING
-DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGALLIUM_LLVMPIPE
-D__STDC_CONSTANT_MACROS -DUSE_X86_64_ASM
--
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 30796] mesa builds drivers for r300 and Intel even when not asked to
https://bugs.freedesktop.org/show_bug.cgi?id=30796 --- Comment #1 from Michal Suchanek 2010-10-12 03:04:16 PDT --- Specifically I have no idea why I have some i915 and r300 drivers when I asked to build r600 only. -- 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 30796] mesa builds drivers for r300 and Intel even when not asked to
https://bugs.freedesktop.org/show_bug.cgi?id=30796 --- Comment #2 from Marek Olšák 2010-10-12 04:40:28 PDT --- Gallium/r300 is built by default. You can disable it with the parameter --disable-gallium-radeon. There are other drivers and libs built by default, like Gallium/swrast, egl, glu. Gallium/i915 is not actually built, only the source files are compiled for us to have everything compile-tested. -- 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 (7.9): st/xorg: Don't try to remove invalid fbs
On 12 okt 2010, at 15.09, Thomas Hellstrom wrote: Module: Mesa Branch: 7.9 Commit: 6730630804b6948dbb42340b1de1cf9ee04bf0fd URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=6730630804b6948dbb42340b1de1cf9ee04bf0fd Author: Thomas Hellstrom Date: Tue Oct 12 11:10:59 2010 +0200 st/xorg: Don't try to remove invalid fbs Signed-off-by: Thomas Hellstrom --- src/gallium/state_trackers/xorg/xorg_driver.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/gallium/state_trackers/xorg/xorg_driver.c b/src/ gallium/state_trackers/xorg/xorg_driver.c index f7b3ad3..ca74539 100644 --- a/src/gallium/state_trackers/xorg/xorg_driver.c +++ b/src/gallium/state_trackers/xorg/xorg_driver.c @@ -369,6 +369,7 @@ drv_pre_init(ScrnInfoPtr pScrn, int flags) ms = modesettingPTR(pScrn); ms->pEnt = pEnt; ms->cust = cust; +ms->fb_id = 1; Shouldn't this be -1? Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Anonymous unions (Was: [Bug 30789] mesa git fails to build)
José Fonseca wrote: > What you guys feel about anonymous unions? > > I happened to committed some code with anonymous unions, but it caused > gcc to choke when -std=c99 option is specified, which is only specified > with automake but scons. > > After some search, it looks like anonymous unions are not part of C99, > but are part of C++ and will reportedly be part of C1X [1]. I think all > major compilers support it. I don't think the Sun compilers support it, for the few of us who build with those, but Mesa is generally unbuildable on Solaris anyway when I'm too busy elsewhere to keep up with repairing it. (I know git master has been broken for a few months, but haven't gotten around to fixing, sorry.) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] What I'm working on
On Mon, 2010-10-11 at 14:49 -0700, Ian Romanick wrote: > As has been discussed numerous times, the > assembly-like IRs in Mesa (classic Mesa IR and TGSI) are completely > useless for generating code for GPUs. llvmpipe has shown that they are > also completely useless for generating code for CPUs. Ian, I don't fully understand the above. I'm not sure if there's actually an disagreement or just different terminology. TGSI is indeed inadequate for optimization (as in TGSI -> TGSI transformations), but it was never intended for that role: there was always the assumption it would be feed into an optimization compiler (ie. TGSI -> xxx -> GPU code). The role of TGSI was to be API agnostic (i.e., support xxx -> TGSI, yyy -> TGSI). I admit this is not advantage the only frontend is Mesa, but TGSI proved to be very useful when used in conjunction with other APIs beyond GL. It also makes hashing easy. FWIW, I'm fine with TGSI being replaced with something else (LLVM IR, mesa/src/glsl's), provided that IR is a superset of TGSI. Also, for the record, I don't think the problem is resemblance to assembly. Take LLVM IR for example: it is an assembly-like IR in SSA form, as every instruction consists of an opcode plus operands, and operands can't be complex expressions. What makes TGSI and Mesa IR inadequate for compilation is not their assembly resemblance, but the fact they lack any other auxiliary structure (a tree form or SSA form would be advisable, but they are merely an one directional list), and therefore are very difficult to walk, analyze, or rewrite. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): st/xorg: Add a customizer option to get rid of annoying cursor update flicker
On Die, 2010-10-12 at 06:09 -0700, Thomas Hellstrom wrote: > > st/xorg: Add a customizer option to get rid of annoying cursor update flicker Does this really need a customization knob? Is there any st/xorg user that needs the cursor to be disabled for updates? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Anonymous unions (Was: [Bug 30789] mesa git fails to build)
On 10/12/2010 02:06 AM, José Fonseca wrote: What you guys feel about anonymous unions? I happened to committed some code with anonymous unions, but it caused gcc to choke when -std=c99 option is specified, which is only specified with automake but scons. After some search, it looks like anonymous unions are not part of C99, but are part of C++ and will reportedly be part of C1X [1]. I think all major compilers support it. I heard they are also often used together with bit fields to describe hardware registers. But for this to work to gcc we need to remove -std=c99, or replace with -std=gnu99, or pass -fms-extensions together with -std=c99. I don't care much either way. I'd just like to hear what's the general opinion on this to avoid ping-ponging on this matter. Jose [1] http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed-Fields When I have a choice, I prefer to go with what is more portable. I think this is especially important for core Mesa/gallium to maximize portability to new compilers/platforms. You never know what's going to come along. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] What I'm working on
On 10/11/2010 03:49 PM, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just thought I'd give people a head-up of what I'm working on for the next few weeks and how this relates to what other Intel people are doing. We're trying to get 3D fully enabled on Sandybridge hardware for our Q4 release. Since there are quite a few subtle changes from Ironlake to Sandybridge, we don't want to re-work N different shader backends. Eric is trying to get his direct GLSL IR backend working solid on all GEN4-ish hardware, including Sandybridge. That will get GLSL working, but that leaves fixed-function and assembly shaders. To get the rest working, I'm implementing code to generate GLSL IR directly from assembly shaders and from fixed-function. To do this right, there is some additional infrastructure needed. This is why I recently implemented GL_ARB_explicit_attrib_location. Over the next week or two I will implement GL_EXT_separate_shader_objects. The plan is to then treat the assembly shaders like the compiled, par-linked programs that are used in EXT_sso. I'm only doing the EXT version because there is a lot less to do for it, and I believe that will supply enough infrastructure for the assembly shader rework. This will live in a (hopefully short lived) branch in my personal GIT repo called ext_sso. It's great you're implementing this extension. Once that is done, I'll start converting the shader assembler to generate GLSL IR. Fixed-function will get the same treatment shortly thereafter. It should be possible to move ir_to_mesa out of core Mesa and into a (lower) driver level. As has been discussed numerous times, the assembly-like IRs in Mesa (classic Mesa IR and TGSI) are completely useless for generating code for GPUs. I'm sorry, but that's an exageration. Mesa IR and TGSI are very similar to the original ARB vertex/fragment program languages which were clearly intended for GPU implementation. They may not be ideal in some ways, but certainly not completely useless. llvmpipe has shown that they are also completely useless for generating code for CPUs. The various proposed GLSL->LLVM and LLVM->GLSL translation layers will allow these relics to die. Someone will need to write a GLSL IR -> TGSI translator during the interim. I haven't had much spare time lately, but if I can find some I'll take a crack at it. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30783] Mesa git fails to build
https://bugs.freedesktop.org/show_bug.cgi?id=30783
atswa...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Comment #7 from atswa...@gmail.com 2010-10-12 08:37:12 PDT ---
(In reply to comment #6)
> Which commit is this copy of mesa? The copy of es_generator.py in comment #0
> is
> missing a comma in line 134.
>
>
> This is the current version in mesa master.
>
> mesa: c25fcf5aa5beccd7731706b8f85682170a2eca56 (master)
>
> src/mesa/main/es_generator.py
>132 try:
>133 optlist, args = getopt.getopt(sys.argv[1:], options)
>134 except getopt.GetoptError, message:
>135 sys.stderr.write("%s: %s. Use -h for help.\n" % (program,
> message))
Yeah, I was playing around with that comma to try to make it work and forgot to
change it back. I fixed it and had a problem with libxml2, I downgraded it to
the version that went with the downgraded python and it build successfully.
Thanks for your help
--
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 (7.9): st/xorg: Don't try to remove invalid fbs
On 10/12/2010 03:12 PM, Jakob Bornecrantz wrote: On 12 okt 2010, at 15.09, Thomas Hellstrom wrote: Module: Mesa Branch: 7.9 Commit: 6730630804b6948dbb42340b1de1cf9ee04bf0fd URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=6730630804b6948dbb42340b1de1cf9ee04bf0fd Author: Thomas Hellstrom Date: Tue Oct 12 11:10:59 2010 +0200 st/xorg: Don't try to remove invalid fbs Signed-off-by: Thomas Hellstrom --- src/gallium/state_trackers/xorg/xorg_driver.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/gallium/state_trackers/xorg/xorg_driver.c b/src/ gallium/state_trackers/xorg/xorg_driver.c index f7b3ad3..ca74539 100644 --- a/src/gallium/state_trackers/xorg/xorg_driver.c +++ b/src/gallium/state_trackers/xorg/xorg_driver.c @@ -369,6 +369,7 @@ drv_pre_init(ScrnInfoPtr pScrn, int flags) ms = modesettingPTR(pScrn); ms->pEnt = pEnt; ms->cust = cust; +ms->fb_id = 1; Shouldn't this be -1? Cheers Jakob. Ugh. You're right. I wonder what happened there /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] RFC: Whimsical renames and code motion
Hi, I wrote this patch series a while ago, but now that 7.9 is out I thought I'd float it on the list to see what people think. The first couple of patches kill off glcore.h, which is no longer used for any external interfaces, and pull the struct into mtypes.h. The next couple of patches massage it a bit to drop fields we don't use and rename it and it's many typedefs to just struct gl_config. The patch series finishes with two patches to drop the GLframebuffer and GLcontext typedefs and just use struct gl_framebuffer and struct gl_context instead. The last patch is 2MB, so I'll just point you to the branch in my repo: http://cgit.freedesktop.org/~krh/mesa/log/?h=whimsical-renames and this output: [...@hinata mesa]$ git log --oneline --shortstat origin/master..HEAD 8057432 Drop GLcontext typedef and use struct gl_context instead 789 files changed, 5696 insertions(+), 5699 deletions(-) 8dd8750 Drop GLframebuffer typedef and just use struct gl_framebuffer 54 files changed, 127 insertions(+), 128 deletions(-) e7158d3 Rename GLvisual and __GLcontextModes to struct gl_config 98 files changed, 176 insertions(+), 189 deletions(-) 4067d7a gl: Remove unused GLcontextModes fields 8 files changed, 7 insertions(+), 48 deletions(-) e63f0e4 Get rid of GL/internal/glcore.h 11 files changed, 314 insertions(+), 193 deletions(-) The last two renames are quite a mouthful, but I think they make a lot of sense and makes the mesa types more consistent; consistent with themselves (no other mesa structs have typedefs) and other code (gallium doesn't typedef structs and neither does most of the dri drivers (struct radeon_framebuffer, struct intel_context etc)). Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Anonymous unions (Was: [Bug 30789] mesa git fails to build)
José Fonseca writes: > What you guys feel about anonymous unions? > > I happened to committed some code with anonymous unions, but it > caused gcc to choke when -std=c99 option is specified, which is only > specified with automake but scons. > > After some search, it looks like anonymous unions are not part of > C99, but are part of C++ and will reportedly be part of C1X [1]. I > think all major compilers support it. I'd vote against it. I remember hitting an issue porting some of my own code that used anonymous unions. Further, a downstream app I work on needs to support AIX's native build environment; I haven't checked, but that toolchain always gives me grief && so I doubt it supports anonymous unions. -tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30805] New: Another mesa git build error ....
https://bugs.freedesktop.org/show_bug.cgi?id=30805 Summary: Another mesa git build error Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: rand...@mail.ru using mesa up to commit f1c1ee11d34f4aa5975641a615c7fd2edb32e1c0 Author: Brian Paul Date: Tue Oct 12 09:26:39 2010 -0600 ir_to_mesa: assorted clean-ups, const qualifiers, new comments I got this, after make distclean && autogen.sh with my usual switches: -- gcc -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I/usr/X11R7/include -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -g -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DHAVE_UDIS86 -DGALLIUM_LLVMPIPE -D__STDC_CONSTANT_MACROS -DHAVE_LLVM=0x0207 -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -I/usr/include -D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -O2 -fomit-frame-pointer -fPIC lp_rast_tri.c -o lp_rast_tri.o lp_rast_tri.c:284: warning: type defaults to 'int' in declaration of '__m128i' lp_rast_tri.c:284: error: expected ';', ',' or ')' before '*' token lp_rast_tri.c:322: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'mm_mullo_epi32' lp_rast_tri.c:350: error: redefinition of 'lp_rast_triangle_3_16' lp_rast_tri.c:116: note: previous definition of 'lp_rast_triangle_3_16' was here lp_rast_tri.c: In function 'lp_rast_triangle_3_16': lp_rast_tri.c:362: error: '__m128i' undeclared (first use in this function) lp_rast_tri.c:362: error: (Each undeclared identifier is reported only once lp_rast_tri.c:362: error: for each function it appears in.) lp_rast_tri.c:362: error: expected ';' before 'p0' lp_rast_tri.c:363: error: expected ';' before 'p1' lp_rast_tri.c:364: error: expected ';' before 'p2' lp_rast_tri.c:365: error: expected ';' before 'zero' lp_rast_tri.c:367: error: expected ';' before 'c' lp_rast_tri.c:368: error: expected ';' before 'dcdx' lp_rast_tri.c:369: error: expected ';' before 'dcdy' lp_rast_tri.c:370: error: expected ';' before 'rej4' lp_rast_tri.c:372: error: expected ';' before 'dcdx2' lp_rast_tri.c:373: error: expected ';' before 'dcdx3' lp_rast_tri.c:375: error: expected ';' before 'span_0' lp_rast_tri.c:376: error: expected ';' before 'span_1' lp_rast_tri.c:377: error: expected ';' before 'span_2' lp_rast_tri.c:378: error: expected ';' before 'unused' lp_rast_tri.c:380: warning: implicit declaration of function 'transpose4_epi32' lp_rast_tri.c:380: error: 'p0' undeclared (first use in this function) lp_rast_tri.c:380: error: 'p1' undeclared (first use in this function) lp_rast_tri.c:380: error: 'p2' undeclared (first use in this function) lp_rast_tri.c:380: error: 'zero' undeclared (first use in this function) lp_rast_tri.c:381: error: 'c' undeclared (first use in this function) lp_rast_tri.c:381: error: 'dcdx' undeclared (first use in this function) lp_rast_tri.c:381: error: 'dcdy' undeclared (first use in this function) lp_rast_tri.c:381: error: 'rej4' undeclared (first use in this function) lp_rast_tri.c:385: warning: implicit declaration of function '_mm_sub_epi32' lp_rast_tri.c:387: warning: implicit declaration of function '_mm_add_epi32' lp_rast_tri.c:387: warning: implicit declaration of function 'mm_mullo_epi32' lp_rast_tri.c:387: warning: implicit declaration of function '_mm_set1_epi32' lp_rast_tri.c:389: warning: implicit declaration of function '_mm_slli_epi32' lp_rast_tri.c:391: error: 'dcdx2' undeclared (first use in this function) lp_rast_tri.c:392: error: 'dcdx3' undeclared (first use in this function) lp_rast_tri.c:395: error: 'span_0' undeclared (first use in this function) lp_rast_tri.c:395: error: 'span_1' undeclared (first use in this function) lp_rast_tri.c:395: error: 'span_2' undeclared (first use in this function) lp_rast_tri.c:395: error: 'unused' undeclared (first use in this function) lp_rast_tri.c:398: error: expected ';' before 'cx' lp_rast_tri.c:401: error: expected ';' before 'c4rej' lp_rast_tri.c:402: error: expected ';' before 'rej_masks' lp_rast_tri.c:405: warning: implicit declaration of function '_mm_movemask_epi8' lp_rast_tri.c:405: error: 'rej_masks' undeclared (first use in this function) lp_rast_tri.c:406: error: expected ';' before 'c0_0' lp_rast_tri.c:407: error: expected ';' before 'c1_0' lp_rast_tri.c:408: error: expected ';' before 'c2_0' lp_rast_tri.c:410: error: expected ';' before 'c_0' lp_rast_tri.c:412: error: expected ';' before 'c0_1' lp_rast_tri.c:413: error: expected ';' before 'c1_1' lp_rast_tri.c:414: error: expected ';' before 'c2_
[Mesa-dev] [Bug 30805] Another mesa git build error ....
https://bugs.freedesktop.org/show_bug.cgi?id=30805 --- Comment #1 from Andrew Randrianasulu 2010-10-12 09:57:25 PDT --- Created an attachment (id=39386) --> (https://bugs.freedesktop.org/attachment.cgi?id=39386) config.log With my standard, Slackware's default gcc-4.4.4 -- 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] Anonymous unions (Was: [Bug 30789] mesa git fails to build)
On Tue, 2010-10-12 at 07:58 -0700, Brian Paul wrote: > On 10/12/2010 02:06 AM, José Fonseca wrote: > > What you guys feel about anonymous unions? > > > > I happened to committed some code with anonymous unions, but it caused > > gcc to choke when -std=c99 option is specified, which is only specified > > with automake but scons. > > > > After some search, it looks like anonymous unions are not part of C99, > > but are part of C++ and will reportedly be part of C1X [1]. I think all > > major compilers support it. > > > > I heard they are also often used together with bit fields to describe > > hardware registers. > > > > But for this to work to gcc we need to remove -std=c99, or replace with > > -std=gnu99, or pass -fms-extensions together with -std=c99. > > > > I don't care much either way. I'd just like to hear what's the general > > opinion on this to avoid ping-ponging on this matter. > > > > Jose > > > > [1] http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed-Fields > > When I have a choice, I prefer to go with what is more portable. I > think this is especially important for core Mesa/gallium to maximize > portability to new compilers/platforms. You never know what's going > to come along. On Tue, 2010-10-12 at 09:47 -0700, tom fogal wrote: > I'd vote against it. I remember hitting an issue porting some of my > own code that used anonymous unions. Further, a downstream app I work > on needs to support AIX's native build environment; I haven't checked, > but that toolchain always gives me grief && so I doubt it supports > anonymous unions. OK. It's gone now. Brian, Tom, thanks for the feedback. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30805] Another mesa git build error ....
https://bugs.freedesktop.org/show_bug.cgi?id=30805 José Fonseca changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|mesa-...@lists.freedesktop. |kei...@vmware.com |org | CC||jfons...@vmware.com --- Comment #2 from José Fonseca 2010-10-12 10:18:53 PDT --- Keith, it appears not all SSE intrinsic code is guarded by the PIPE_ARCH_SSE macro. -- 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] RFC: Whimsical renames and code motion
On 10/12/2010 10:43 AM, Kristian Høgsberg wrote: Hi, I wrote this patch series a while ago, but now that 7.9 is out I thought I'd float it on the list to see what people think. The first couple of patches kill off glcore.h, which is no longer used for any external interfaces, and pull the struct into mtypes.h. The next couple of patches massage it a bit to drop fields we don't use and rename it and it's many typedefs to just struct gl_config. The patch series finishes with two patches to drop the GLframebuffer and GLcontext typedefs and just use struct gl_framebuffer and struct gl_context instead. The last patch is 2MB, so I'll just point you to the branch in my repo: http://cgit.freedesktop.org/~krh/mesa/log/?h=whimsical-renames and this output: [...@hinata mesa]$ git log --oneline --shortstat origin/master..HEAD 8057432 Drop GLcontext typedef and use struct gl_context instead 789 files changed, 5696 insertions(+), 5699 deletions(-) 8dd8750 Drop GLframebuffer typedef and just use struct gl_framebuffer 54 files changed, 127 insertions(+), 128 deletions(-) e7158d3 Rename GLvisual and __GLcontextModes to struct gl_config 98 files changed, 176 insertions(+), 189 deletions(-) 4067d7a gl: Remove unused GLcontextModes fields 8 files changed, 7 insertions(+), 48 deletions(-) e63f0e4 Get rid of GL/internal/glcore.h 11 files changed, 314 insertions(+), 193 deletions(-) The last two renames are quite a mouthful, but I think they make a lot of sense and makes the mesa types more consistent; consistent with themselves (no other mesa structs have typedefs) and other code (gallium doesn't typedef structs and neither does most of the dri drivers (struct radeon_framebuffer, struct intel_context etc)). I'm OK with these changes. Some historical background. GLcontext goes back to the very first version of Mesa. The GLvisual and GLframebuffer types were added a bit later and were defined with typedefs to distinguish them as special types which percolate up to higher levels. Contexts, visuals and framebuffers/surfaces are internal entities which also exist in APIs such as GLX and WGL. But there's no concrete reasons for the typedefs. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] What I'm working on
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: > On 10/11/2010 03:49 PM, Ian Romanick wrote: >> It should be possible to move ir_to_mesa out of core Mesa and into a >> (lower) driver level. As has been discussed numerous times, the >> assembly-like IRs in Mesa (classic Mesa IR and TGSI) are completely >> useless for generating code for GPUs. > > I'm sorry, but that's an exageration. Mesa IR and TGSI are very similar > to the original ARB vertex/fragment program languages which were clearly > intended for GPU implementation. They may not be ideal in some ways, > but certainly not completely useless. I suppose I should have said "useless for generating high quality code for GPUs." The original ARB vertex/fragment program languages were clearly intended for *direct* GPU translation. That is, the intention was that there would be a nearly 1-to-1 translation from instructions in the source language to instructions on the hardware. For that generation of hardware that was a good assumption, but this hasn't been the case for many years. It certainly isn't true on i965 or r600. Look at what the r600 driver. It translates Mesa IR (r600g presumably does the same with TGSI) back up to some higher-level IR before doing register allocation, code generation, and scheduling. Every single credible DX driver also works this way, and driver writers *hate* it. The driver basically has to decompile one assembly back into a higher-level IR, attempting to infer the intention of the origin program along the way. When we have access to the original program already in a higher-level IR, this is just plain madness. The driver has to do more work. Since information is lost as the IR becomes lower and lower, the driver has less information to use to do that work. It's a lose/lose situation. Outside of DX and Mesa, no multi-target compiler works like this. LLVM doesn't[1]. GCC doesn't[2]. LCC doesn't[3]. Open64 (formerly MipsPro) doesn't[4]. Closed-source GLSL compilers don't. There is a reason. :) [1] http://llvm.org/docs/tutorial/LangImpl3.html [2] http://gcc.gnu.org/onlinedocs/gccint/GIMPLE.html [3] ftp://ftp.math.utah.edu/pub/lcc/interface4.pdf [4] http://www.open64.net/documentation/slides.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0m/kACgkQX1gOwKyEAw+ujQCfZUJ29g0novtNvKxqy54wZp9b ZSUAnj9TJjVlsH2R46NEjRjqPptg1Z3Q =oCfy -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Whimsical renames and code motion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kristian Høgsberg wrote: > Hi, > > I wrote this patch series a while ago, but now that 7.9 is out I > thought I'd float it on the list to see what people think. The first > couple of patches kill off glcore.h, which is no longer used for any > external interfaces, and pull the struct into mtypes.h. The next > couple of patches massage it a bit to drop fields we don't use and > rename it and it's many typedefs to just struct gl_config. The patch > series finishes with two patches to drop the GLframebuffer and > GLcontext typedefs and just use struct gl_framebuffer and struct > gl_context instead. The last patch is 2MB, so I'll just point you to Doesn't the GLX code in the xserver use some of the same config structures? I'm very much in favor of less typedefs. I'd much rather just use 'struct gl_context', etc. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0nfIACgkQX1gOwKyEAw/JzgCfYWuRxxw8AUuNP9a94fL3c2yu sZ8An0wZwZ6j53jc4bgPrNMk7c5fsuNK =zBjb -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): i915: Silence unused variable warning in non-debug builds.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kenneth Graunke wrote: > On Monday 11 October 2010 16:17:51 Ian Romanick wrote: > [snip] >>> diff --git a/src/mesa/drivers/dri/i915/i915_vtbl.c >>> b/src/mesa/drivers/dri/i915/i915_vtbl.c index d7828a2..8fa24e4 100644 >>> --- a/src/mesa/drivers/dri/i915/i915_vtbl.c >>> +++ b/src/mesa/drivers/dri/i915/i915_vtbl.c >>> @@ -669,6 +669,7 @@ i915_assert_not_dirty( struct intel_context *intel ) >>> >>> struct i915_context *i915 = i915_context(&intel->ctx); >>> GLuint dirty = get_dirty(&i915->state); >>> assert(!dirty); >>> >>> + (void) dirty; >> This should probably be changed to 'assert(!get_dirty(&i915->state))' >> instead. > > I don't think this is equivalent---get_dirty has side-effects. Moving the > call > inside the assert would mean these side effects would not occur in release > builds. Blarg. Maybe a comment to that effect would be good, then. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0nj4ACgkQX1gOwKyEAw8vrACfeHYCwv7x6ePrZReBbZ+qKVE8 UjkAnAv3stqa9Bu6gG5R6Tud4hz/GoYM =sgcw -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Strange performance cliff...
Using glxgears as a tool to exercise the GPU with some simple rendering, I have noted a strange cliff in the intel_gpu_top output when resizing the glxgears window: Below a certain size e.g.: -geometry 576x868+0+29 core clock: 400 Mhz render busy: 21%: ▎ render space: 10/126976 (0%) bitstream busy: 0%: bitstream space: 0/126976 (0%) task percent busy CS: 20%: vert fetch: 35071068 (137619/sec) RC Render cache: 17%: ███▌prim fetch: 15422476 (60993/sec) VF: 13%: ██▋ VS invocations: 31634160 (128160/sec) GS: 12%: ██▌ GS invocations: 11848000 (48000/sec) Windower IZ: 12%: ██▌ GS prims: 0 (0/sec) SF (strip / fan): 12%: ██▌ CL invocations: 0 (0/sec) Row 1, EU 3: 10%: ██CL prims: 28373497 (108993/sec) Row 0, EU 3: 10%: ██ PS invocations: 7810009 (600886/sec) Bypass FIFO: 10%: ██ PS depth pass: 17981565671 (73371256/sec) Pixel shader: 10%: ██ Windower / Masker: 9%: █▉ Filtering: 9%: █▉ Row 1, EU 2: 9%: █▉ Row 0, EU 2: 9%: █▉ Setup Engine: 8%: █▋ MASF: 8%: █▋ Row 1, EU 1: 8%: █▋ Row 0, EU 1: 7%: █▌ Row 1, EU 0: 7%: █▌ Map filter: 6%: █▎ DAP: 6%: █▎ Texture decompress: 6%: █▎ Sampler cache: 6%: █▎ Texture fetch: 5%: █ SVRW: 5%: █ SVRR: 4%: ▉ URB: 4%: ▉ Projection and LOD: 3%: ▋ Dependent address generator: 3%: ▋ Dispatcher: 2%: ▌ CL (clipper): 2%: ▌ SVDW: 2%: ▌ VS0: 2%: ▌ ISC: 1%: ▎ Message Arbiter row 1: 1%: ▎ MASM: 1%: ▎ SI (system instruction?): 0%: DM: 0%: SC: 0%: I get this trace. When I increase the window size just a fraction, to: -geometry 576x871+0+29 The CS (command streamer) unit jumps to 100% busy, along with the render busy graph. Does anyone have any ideas why? core clock: 400 Mhz render busy: 100%: render space: 61/126976 (0%) bitstream busy: 1%: ▎ bitstream space: 0/126976 (0%) task percent busy CS: 100%: vert fetch: 15165204 (133386/sec) RC Render cache: 18%: ███▋prim fetch: 6654764 (59078/sec) VF: 12%: ██▌ VS invocations: 13559328 (123888/sec) Windower IZ: 12%: ██▌ GS invocations: 5078400 (46400/sec) GS: 11%: ██▎ GS prims: 0 (0/sec) SF (strip / fan): 11%: ██▎ CL invocations: 0 (0/sec) Row 1, EU 3: 9%: █▉CL prims: 12836185 (105478/sec) Pixel shader: 9%: █▉ PS invocations: 6019756 (-1805377/sec) Bypass FIFO: 9%: █▉ PS depth pass: 7529067710 (71131031/sec) Row 0, EU 3: 9%: █▉ Windower / Masker: 9%: █▉ Row 1, EU 2: 8%: █▋ Filtering: 8%: █▋ Row 0, EU 2: 8%: █▋ MASF: 8%: █▋ Setup Engine: 7%: █▌ Row 1, EU 1: 7%: █▌ Row 0, EU
Re: [Mesa-dev] RFC: Whimsical renames and code motion
2010/10/12 Ian Romanick : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Kristian Høgsberg wrote: >> Hi, >> >> I wrote this patch series a while ago, but now that 7.9 is out I >> thought I'd float it on the list to see what people think. The first >> couple of patches kill off glcore.h, which is no longer used for any >> external interfaces, and pull the struct into mtypes.h. The next >> couple of patches massage it a bit to drop fields we don't use and >> rename it and it's many typedefs to just struct gl_config. The patch >> series finishes with two patches to drop the GLframebuffer and >> GLcontext typedefs and just use struct gl_framebuffer and struct >> gl_context instead. The last patch is 2MB, so I'll just point you to > > Doesn't the GLX code in the xserver use some of the same config structures? Not glx/, I copied the struct into the glx module. It's still used by dmx, Xephyr, xquarts and xwin32, but glproto installs a glcore.h too, so they can pick it up from there. Ideally these users would use a copy included in the Xserver, since it is just an imlpementation detail, but that's a patch for another day. > I'm very much in favor of less typedefs. I'd much rather just use > 'struct gl_context', etc. Yeah, me too. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30787] Invalid asm shader does not generate draw-time error when used with GLSL shader
https://bugs.freedesktop.org/show_bug.cgi?id=30787 Ian Romanick changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Ian Romanick 2010-10-12 10:56:35 PDT --- Fixed on master with the following commit. I'll close the bug once it's cherry picked to the 7.9 branch. commit b2b9b22c1013ebf02aa6f0d9c1c7b5267523d973 Author: Ian Romanick Date: Tue Oct 12 10:51:47 2010 -0700 mesa: Validate assembly shaders when GLSL shaders are used If an GLSL shader is used that does not provide all stages and assembly shaders are provided for the missing stages, validate the assembly shaders. Fixes bugzilla #30787 and piglit tests glsl-invalid-asm0[12]. NOTE: this is a candidate for the 7.9 branch. -- 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): mesa: Validate assembly shaders when GLSL shaders are used
On 10/12/2010 11:55 AM, Ian Romanick wrote: Module: Mesa Branch: master Commit: b2b9b22c1013ebf02aa6f0d9c1c7b5267523d973 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=b2b9b22c1013ebf02aa6f0d9c1c7b5267523d973 Author: Ian Romanick Date: Tue Oct 12 10:51:47 2010 -0700 mesa: Validate assembly shaders when GLSL shaders are used If an GLSL shader is used that does not provide all stages and assembly shaders are provided for the missing stages, validate the assembly shaders. Fixes bugzilla #30787 and piglit tests glsl-invalid-asm0[12]. NOTE: this is a candidate for the 7.9 branch. --- src/mesa/main/context.c | 52 -- 1 files changed, 40 insertions(+), 12 deletions(-) diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c index 0013251..284c8b1 100644 --- a/src/mesa/main/context.c +++ b/src/mesa/main/context.c @@ -137,7 +137,7 @@ #endif #include "glsl_parser_extras.h" - +#include Ian, could we stick with GLboolean/GL_TRUE/GL_FALSE in core Mesa to be consistent? It wouldn't surprise me if stdbool.h isn't present on one platform or another. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] Strange performance cliff...
On Tue, 2010-10-12 at 18:45 +0100, Peter Clifton wrote: > Using glxgears as a tool to exercise the GPU with some simple rendering, > I have noted a strange cliff in the intel_gpu_top output when resizing > the glxgears window: > > Below a certain size e.g.: > > -geometry 576x868+0+29 >render busy: 21%: ▎ > render space: 10/126976 (0%) > When I increase the window size just a fraction, to: > > -geometry 576x871+0+29 > The CS (command streamer) unit jumps to 100% busy, along with the render > busy graph. Does anyone have any ideas why? > >render busy: 100%: > render space: 61/126976 (0%) It would appear that this transition occurs at the point when glxgears executed with vblank_mode=0 set, gives approx 60Hz (vblank rate). I can only presume therefore, that the command stream shows as 100% when it is stalling the CPU.. is that right? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30355] compilation fails because sm4_defs.h is missing
https://bugs.freedesktop.org/show_bug.cgi?id=30355 Martin Stolpe changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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 30484] Mesa 7.9.2-rc2 and git fail to compile
https://bugs.freedesktop.org/show_bug.cgi?id=30484 --- Comment #3 from Witold Baryluk 2010-10-12 15:48:13 PDT --- Bug #30451 is very similar, but in ati driver. I mistakly send there some additional information releated to this mesa build error. -- 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] What I'm working on
On Wed, Oct 13, 2010 at 3:33 AM, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Brian Paul wrote: >> On 10/11/2010 03:49 PM, Ian Romanick wrote: >>> It should be possible to move ir_to_mesa out of core Mesa and into a >>> (lower) driver level. As has been discussed numerous times, the >>> assembly-like IRs in Mesa (classic Mesa IR and TGSI) are completely >>> useless for generating code for GPUs. >> >> I'm sorry, but that's an exageration. Mesa IR and TGSI are very similar >> to the original ARB vertex/fragment program languages which were clearly >> intended for GPU implementation. They may not be ideal in some ways, >> but certainly not completely useless. > > I suppose I should have said "useless for generating high quality code > for GPUs." > > The original ARB vertex/fragment program languages were clearly intended > for *direct* GPU translation. That is, the intention was that there > would be a nearly 1-to-1 translation from instructions in the source > language to instructions on the hardware. For that generation of > hardware that was a good assumption, but this hasn't been the case for > many years. It certainly isn't true on i965 or r600. > > Look at what the r600 driver. It translates Mesa IR (r600g presumably > does the same with TGSI) back up to some higher-level IR before doing > register allocation, code generation, and scheduling. Every single > credible DX driver also works this way, and driver writers *hate* it. > The driver basically has to decompile one assembly back into a > higher-level IR, attempting to infer the intention of the origin program > along the way. > > When we have access to the original program already in a higher-level > IR, this is just plain madness. The driver has to do more work. Since > information is lost as the IR becomes lower and lower, the driver has > less information to use to do that work. It's a lose/lose situation. > > Outside of DX and Mesa, no multi-target compiler works like this. LLVM > doesn't[1]. GCC doesn't[2]. LCC doesn't[3]. Open64 (formerly MipsPro) > doesn't[4]. Closed-source GLSL compilers don't. There is a reason. :) The AMD IR is findable with google, I think their GLSL compiler spits that out, it seems to my untrained eye to be more TGSI like than not, but you guys know more about what you are talking about than I. http://developer.amd.com/gpu/ATIStreamSDK/assets/ATI_Intermediate_Language_(IL)_Specification_v2d.pdf Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 30783] Mesa git fails to build
https://bugs.freedesktop.org/show_bug.cgi?id=30783 Vinson Lee changed: What|Removed |Added Resolution|FIXED |NOTOURBUG -- 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): mesa: Validate assembly shaders when GLSL shaders are used
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Paul wrote: >> - >> +#include > > Ian, could we stick with GLboolean/GL_TRUE/GL_FALSE in core Mesa to be > consistent? It wouldn't surprise me if stdbool.h isn't present on one > platform or another. If possible, I'd prefer not. All of the GL types are ugly anachronisms from the early 90's when there were no standard, cross-platform sized types. We've had those types for over a decade, and not using them makes the code more obtuse. To be perfectly honest, I'd love to see them removed from OpenGL altogether. We already have stdbool.h in the Mesa tree for platforms that lack it. Moreover, we're using bool/true/false in all of the C++ code. Even as a long time OpenGL programmer I find bool/true/false infinitely more natural than GLboolean/GL_TRUE/GL_FALSE. Either way, we should resolve this soon. All of the EXT_sso work I've been doing using stdbool.h, so I'd like to know if I need to go back and change all of that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky1EDAACgkQX1gOwKyEAw/eLwCdH89We8Shijfi3sSPCnmUtMK4 BT0An0chsS4e6uk08sGD3qYsztEzEL/V =cEmM -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] gallium: blitters and scissors
I've noticed that none of the blitters use scissor state, and wondered
if there was a reason for this.
It looks like drivers are expected to setup scissor state in the
framebuffer setup and in the set scissor state, but with r600g due to
the underlying state tracking it can end up doing the wrong thing.
The 3 patches add CSO cache + u_blit + u_blitter scissor usage.
Just wondering if I'm violating some rules of the gallium interface or not.
Dave.
From f2498533444c7e4ecde84681544face0da2a5616 Mon Sep 17 00:00:00 2001
From: Dave Airlie
Date: Wed, 13 Oct 2010 12:00:42 +1000
Subject: [PATCH 1/3] cso: add scissor support
---
src/gallium/auxiliary/cso_cache/cso_context.c | 49 +
src/gallium/auxiliary/cso_cache/cso_context.h | 11 ++
2 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c b/src/gallium/auxiliary/cso_cache/cso_context.c
index 58b022d..5e3dc41 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -96,6 +96,8 @@ struct cso_context {
struct pipe_clip_state clip;
struct pipe_clip_state clip_saved;
+ struct pipe_scissor_state scissor, scissor_saved;
+
struct pipe_framebuffer_state fb, fb_saved;
struct pipe_viewport_state vp, vp_saved;
struct pipe_blend_color blend_color;
@@ -1080,6 +1082,53 @@ cso_restore_clip(struct cso_context *ctx)
}
}
+/* scissor state */
+
+static INLINE void
+scissor_state_cpy(struct pipe_scissor_state *dst,
+ const struct pipe_scissor_state *src)
+{
+ dst->minx = src->minx;
+ dst->miny = src->miny;
+ dst->maxx = src->maxx;
+ dst->maxy = src->maxy;
+}
+
+static INLINE int
+scissor_state_cmp(const struct pipe_scissor_state *a,
+ const struct pipe_scissor_state *b)
+{
+ if ((a->minx != b->minx) || (a->miny != b->miny) || (a->maxx != b->maxx) || (a->maxy != b->maxy)) {
+ return 1;
+ }
+ return 0;
+}
+
+void
+cso_set_scissor(struct cso_context *ctx,
+ const struct pipe_scissor_state *scissor)
+{
+ if (scissor_state_cmp(&ctx->scissor, scissor)) {
+ scissor_state_cpy(&ctx->scissor, scissor);
+ ctx->pipe->set_scissor_state(ctx->pipe, scissor);
+ }
+}
+
+void
+cso_save_scissor(struct cso_context *ctx)
+{
+ scissor_state_cpy(&ctx->scissor_saved, &ctx->scissor);
+}
+
+void
+cso_restore_scissor(struct cso_context *ctx)
+{
+ if (scissor_state_cmp(&ctx->scissor, &ctx->scissor_saved)) {
+ scissor_state_cpy(&ctx->scissor, &ctx->scissor_saved);
+ ctx->pipe->set_scissor_state(ctx->pipe, &ctx->scissor_saved);
+ }
+}
+
enum pipe_error cso_set_vertex_elements(struct cso_context *ctx,
unsigned count,
const struct pipe_vertex_element *states)
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.h b/src/gallium/auxiliary/cso_cache/cso_context.h
index f0b07f7..5380b88 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.h
+++ b/src/gallium/auxiliary/cso_cache/cso_context.h
@@ -181,6 +181,17 @@ void
cso_restore_clip(struct cso_context *cso);
+/* scissor state */
+void
+cso_set_scissor(struct cso_context *cso,
+ const struct pipe_scissor_state *clip);
+
+void
+cso_save_scissor(struct cso_context *cso);
+
+void
+cso_restore_scissor(struct cso_context *cso);
+
/* fragment sampler view state */
void
--
1.7.2.3
From a15ed013fbd802d9771f06ce760957c318cd12c9 Mon Sep 17 00:00:00 2001
From: Dave Airlie
Date: Wed, 13 Oct 2010 12:01:00 +1000
Subject: [PATCH 2/3] u_blit: save/restore scissor state across blits.
---
src/gallium/auxiliary/util/u_blit.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_blit.c b/src/gallium/auxiliary/util/u_blit.c
index dfb142b..23e1b25 100644
--- a/src/gallium/auxiliary/util/u_blit.c
+++ b/src/gallium/auxiliary/util/u_blit.c
@@ -63,6 +63,7 @@ struct blit_state
struct pipe_sampler_state sampler;
struct pipe_viewport_state viewport;
struct pipe_clip_state clip;
+ struct pipe_scissor_state scissor;
struct pipe_vertex_element velem[2];
enum pipe_texture_target internal_target;
@@ -474,6 +475,7 @@ util_blit_pixels_writemask(struct blit_state *ctx,
cso_save_fragment_shader(ctx->cso);
cso_save_vertex_shader(ctx->cso);
cso_save_clip(ctx->cso);
+ cso_save_scissor(ctx->cso);
cso_save_vertex_elements(ctx->cso);
/* set misc state we care about */
@@ -485,6 +487,12 @@ util_blit_pixels_writemask(struct blit_state *ctx,
cso_set_clip(ctx->cso, &ctx->clip);
cso_set_vertex_elements(ctx->cso, 2, ctx->velem);
+ ctx->scissor.minx = 0;
+ ctx->scissor.miny = 0;
+ ctx->scissor.maxx = dst->width;
+ ctx->scissor.maxy = dst->height;
+ cso_set_scissor(ctx->cso, &ctx->scissor);
+
/* sampler */
ctx->sampler.normalized_coords = normalized;
ctx->sampler.min_img_filter = filter;
@@ -566,6 +574,
Re: [Mesa-dev] gallium: blitters and scissors
On Wed, Oct 13, 2010 at 12:07 PM, Dave Airlie wrote: > I've noticed that none of the blitters use scissor state, and wondered > if there was a reason for this. > > It looks like drivers are expected to setup scissor state in the > framebuffer setup and in the set scissor state, but with r600g due to > the underlying state tracking it can end up doing the wrong thing. > > The 3 patches add CSO cache + u_blit + u_blitter scissor usage. > > Just wondering if I'm violating some rules of the gallium interface or not. I realised this was a quite deep hole I started digging in mesa/st, any advice on whether cleaning it up is a good idea? Dave. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium: blitters and scissors
On Wed, Oct 13, 2010 at 1:07 PM, Dave Airlie wrote: > On Wed, Oct 13, 2010 at 12:07 PM, Dave Airlie wrote: >> I've noticed that none of the blitters use scissor state, and wondered >> if there was a reason for this. >> >> It looks like drivers are expected to setup scissor state in the >> framebuffer setup and in the set scissor state, but with r600g due to >> the underlying state tracking it can end up doing the wrong thing. >> >> The 3 patches add CSO cache + u_blit + u_blitter scissor usage. >> >> Just wondering if I'm violating some rules of the gallium interface or not. > > I realised this was a quite deep hole I started digging in mesa/st, > any advice on whether cleaning it up is a good idea? > Okay so it helps to read the docs, since it the scissor state enable relies on a bit in the rasterizer state. So it looks like we should always set scissor regs in the framebuffer state and only modify them if we notice the rasterizer bit is enabled. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium: blitters and scissors
Yes, that particular part of the spec is fairly Poulsboriffic. Does any open hardware have a scissor enable/disable bit? Sending from a mobile, pardon the brevity. ~ C. On Oct 12, 2010 8:47 PM, "Dave Airlie" wrote: > On Wed, Oct 13, 2010 at 1:07 PM, Dave Airlie wrote: >> On Wed, Oct 13, 2010 at 12:07 PM, Dave Airlie wrote: >>> I've noticed that none of the blitters use scissor state, and wondered >>> if there was a reason for this. >>> >>> It looks like drivers are expected to setup scissor state in the >>> framebuffer setup and in the set scissor state, but with r600g due to >>> the underlying state tracking it can end up doing the wrong thing. >>> >>> The 3 patches add CSO cache + u_blit + u_blitter scissor usage. >>> >>> Just wondering if I'm violating some rules of the gallium interface or not. >> >> I realised this was a quite deep hole I started digging in mesa/st, >> any advice on whether cleaning it up is a good idea? >> > > Okay so it helps to read the docs, since it the scissor state enable > relies on a bit in the rasterizer state. > > So it looks like we should always set scissor regs in the framebuffer > state and only modify them if we notice > the rasterizer bit is enabled. > > 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] gallium: blitters and scissors
On Tue, Oct 12, 2010 at 11:50 PM, Corbin Simpson wrote: > Yes, that particular part of the spec is fairly Poulsboriffic. Does any open > hardware have a scissor enable/disable bit? Most hardware can disable/enable cliprects, but not scissors. Alex > > Sending from a mobile, pardon the brevity. ~ C. > > On Oct 12, 2010 8:47 PM, "Dave Airlie" wrote: >> On Wed, Oct 13, 2010 at 1:07 PM, Dave Airlie wrote: >>> On Wed, Oct 13, 2010 at 12:07 PM, Dave Airlie wrote: I've noticed that none of the blitters use scissor state, and wondered if there was a reason for this. It looks like drivers are expected to setup scissor state in the framebuffer setup and in the set scissor state, but with r600g due to the underlying state tracking it can end up doing the wrong thing. The 3 patches add CSO cache + u_blit + u_blitter scissor usage. Just wondering if I'm violating some rules of the gallium interface or not. >>> >>> I realised this was a quite deep hole I started digging in mesa/st, >>> any advice on whether cleaning it up is a good idea? >>> >> >> Okay so it helps to read the docs, since it the scissor state enable >> relies on a bit in the rasterizer state. >> >> So it looks like we should always set scissor regs in the framebuffer >> state and only modify them if we notice >> the rasterizer bit is enabled. >> >> 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 > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gallium: blitters and scissors
On Wed, Oct 13, 2010 at 2:53 PM, Alex Deucher wrote: > On Tue, Oct 12, 2010 at 11:50 PM, Corbin Simpson > wrote: >> Yes, that particular part of the spec is fairly Poulsboriffic. Does any open >> hardware have a scissor enable/disable bit? > > Most hardware can disable/enable cliprects, but not scissors. > I ended up doing what r300g does and used cliprects to implement gallium scissors. seems to work okay here. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
