Re: [fedora-arm] ARM summit at Plumbers 2011
On Tue, 23 Aug 2011 17:11:34 +0100, Steve McIntyre wrote: On Tue, Aug 09, 2011 at 07:15:34PM +0100, Steve McIntyre wrote: Hi folks, Following on from the founding of the cross-distro ARM mailing list, I'd like to propose an ARM summit at this year's Linux Plumbers conference [1]. I'm hoping for a slot on Thursday evening, but this remains to be confirmed at this point. We had some lively discussion about the state of ARM Linux distros at the Linaro Connect [2] event in Cambridge last week. It rapidly became clear that some of the topics we discussed deserve a wider audience, so we're suggesting a meetup at Plumbers for that bigger discussion. The initial proposed agenda is: * ARM hard-float + What is it and why does it matter? + How can distributions keep compatible (i.e. gcc triplet to describe the port)? * Adding support for ARM as an architecture to the Linux Standard Base (LSB) + Does it matter? + What's needed? * FHS - multi-arch coming soon, how do we proceed? * 3D support on ARM platforms + Open GL vs. GLES - which is appropriate? but I'm sure that other people will think of more issues they'd like to discuss. :-) If you wish to attend, please reply to the cross-distro list and let us know to expect you. Make sure you're registered to attend Plumbers Conf, and get your travel and accommodation organised ASAP. [1] http://www.linuxplumbersconf.org/2011/ [2] http://connect.linaro.org/ UPDATE: we've not had many people confirm interest in this event yet, which is a shame. If you would like to join us for this session, please reply and let me know. If we don't get enough interest by the end of Sunday (28th August), then we'll have to cancel the meeting. Unfortunately there is no way I could make it, but on the subject of 3D support on ARM, Luke recently mentioned something that initially seemed outlandish but upon closer examination doesn't seem like a bad idea. As we all know, the state of openness of specifications of commonly used ARM 3D GPUs is at best dire. What has been proposed is a bit radical, but it doesn't actually seem that implausible. Specifically, combining Open Graphics Project (http://wiki.opengraphics.org/tiki-index.php) and the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The idea is to have an OGP GPU in firmware in FPGA. In terms of the power budget, it seems to work relatively sanely considering what it is, and it is as ideal as it gets as far as openness and flexibility goes. I just thought it's worthy of a mention. Gordan
Re: ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011
On 08/23/2011 07:01 PM, omall...@msu.edu wrote: Quoting Gordan Bobic : Unfortunately there is no way I could make it, but on the subject of 3D support on ARM, Luke recently mentioned something that initially seemed outlandish but upon closer examination doesn't seem like a bad idea. As we all know, the state of openness of specifications of commonly used ARM 3D GPUs is at best dire. What has been proposed is a bit radical, but it doesn't actually seem that implausible. Specifically, combining Open Graphics Project (http://wiki.opengraphics.org/tiki-index.php) and the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The idea is to have an OGP GPU in firmware in FPGA. In terms of the power budget, it seems to work relatively sanely considering what it is, and it is as ideal as it gets as far as openness and flexibility goes. I just thought it's worthy of a mention. It does seem outlandish, but it is kind of cool. Is it going to give enough 3d speed? The next gen tegra is supposed to have a 24 core GPU. If you can quantify what "enough 3D speed" means, then perhaps that can be assessed. There really aren't many applications around at the moment to make this an issue. I'd be more interested in it's ability to decode 1080p. Then again - it's FPGA! You can load a different "firmware" depending on whether you need 1080p decoding or 3D rendering, or some other kind of specialized DSP offload with only bare minimal VGA. :) Personally, I think OGP would be worth it even if just for the fact that we would no longer have to beg (in vain) the vendors for decent drivers or published specs. The added flexibility on top is just a "free extra". :) Gordan
Implementing VMX128 AltiVec Variant
Hi, For those of you who don't know, VMX128 is a slightly modified version of VMX (AltiVec) in the Xenon processor (i.e. XBox 360). I'm trying to implement support for this in GCC. The principal difference that makes -maltivec not work is that some VMX instructions are missing. Namely, the following: vmuloub, vmulouh, vmulosb, vmulosh, vmuleub, vmuleuh, vmulesb, vmulesh, vsum4ubs, vsum4shs, vsum2sws, vsum4sbs, vsumsws, vmhaddshs, vmhraddshs, vmladduhm, vmsumubm, vmsummbm, vmsumuhm, vmsumuhs, vmsumshm, vmsumshs As a firs pass at this, I removed all references to these instructions from: gcc/config/rs6000/rs6000.c gcc/config/rs6000/altivec.h gcc/config/rs6000/altivec.md These are the only place I found references to them, apart from the files in the gcc/ada directory: gcc/ada/g-alveop.adb gcc/ada/g-alveop.ads gcc/ada/g-alleve.adb gcc/ada/g-alleve.ads I ignored these - I am making a rash assumption here that these are not too important for a C/C++ only build, but I'd like some confirmation on that. What are the above ada files for? With the modifications I made, GCC still compiled fine. However, libgcc and libstdc++ DO still get build with the missing instructions (according to objdump -D). Why is that? Is that a consequence of the ADA files? Or something else? Where should I look? Is the it ada files that are the cause of the problem I'm seeing? When I compile a test program with -maltivec and a loop that vectorizes, my .o files don't contain any of the non-existant instructions (listed above). However, once it is linked, the resulting binary does (including if it is a dynamically linked executable). Can anyone hazard a guess as to what is actually going on? Eventually, I would like to implement this as an option independent of -maltivec. Binutils already have a -mvmx128 flag, and I was planning to use the same flag. Other VMX128 changes include an addition of an extra 96 vector registers (for a total of 128), and possibly some extra functions, I'm not sure off the top of my head. But for a first pass, I'm hoping that just removing the non-existent instructions should work. I'm very new to GCC code (been using it for years, just never looked at the source). If somebody would be kind enough to help me out by pointing me in the right direction, it would be very much appreciated. Thanks in advance. Gordan
Re: Implementing VMX128 AltiVec Variant
Ian Lance Taylor wrote: Gordan Bobic <[EMAIL PROTECTED]> writes: These are the only place I found references to them, apart from the files in the gcc/ada directory: gcc/ada/g-alveop.adb gcc/ada/g-alveop.ads gcc/ada/g-alleve.adb gcc/ada/g-alleve.ads I ignored these - I am making a rash assumption here that these are not too important for a C/C++ only build, but I'd like some confirmation on that. What are the above ada files for? I don't know what they are for, but I can confirm that they are irrelevant for a C/C++ build. Just out of interest, I only downloaded the core, gcc and g++ tar balls of the source. Why are the above ada files in there if they are irrelevant for a C/C++ only build? With the modifications I made, GCC still compiled fine. However, libgcc and libstdc++ DO still get build with the missing instructions (according to objdump -D). Why is that? Is that a consequence of the ADA files? Or something else? Where should I look? Is the it ada files that are the cause of the problem I'm seeing? It must be something else. I'm not sure what, though. It might be something as simple as an instruction built from substrings. For example, search for altivec_vmsumum in altivec.md. Hmm, fair point. I'll have a re-check for this. I thought I weeded all those out, but I might have missed some. Thanks. Gordan
Re: Implementing VMX128 AltiVec Variant
On Tue, 21 Aug 2007, Ian Lance Taylor wrote:
With the modifications I made, GCC still compiled fine. However,
libgcc and libstdc++ DO still get build with the missing instructions
(according to objdump -D). Why is that? Is that a consequence of the
ADA files? Or something else? Where should I look? Is the it ada files
that are the cause of the problem I'm seeing?
It must be something else. I'm not sure what, though. It might be
something as simple as an instruction built from substrings. For
example, search for altivec_vmsumum in altivec.md.
I just re-checked for that and I can't find any. I have attached a diff
for my modified altivec.h, altivec.md and rs6000.c files. Patch in
gcc/config/rs6000 subtree with -p1.
Can anyone think of anywhere else I should be looking? Where else could
these instructions be coming from?
Thanks.
Gordandiff -uN altivec/altivec.h vmx128/altivec.h
--- altivec/altivec.h 2007-08-22 09:31:46.0 +0100
+++ vmx128/altivec.h2007-08-22 09:31:21.0 +0100
@@ -71,9 +71,6 @@
#define vec_lvxl vec_ldl
#define vec_vlogefp vec_loge
#define vec_vmaddfp vec_madd
-#define vec_vmhaddshs vec_madds
-#define vec_vmladduhm vec_mladd
-#define vec_vmhraddshs vec_mradds
#define vec_vnmsubfp vec_nmsub
#define vec_vnor vec_nor
#define vec_vor vec_or
@@ -94,8 +91,6 @@
#define vec_stvx vec_st
#define vec_stvxl vec_stl
#define vec_vsubcuw vec_subc
-#define vec_vsum2sws vec_sum2s
-#define vec_vsumsws vec_sums
#define vec_vrfiz vec_trunc
#define vec_vxor vec_xor
@@ -142,20 +137,6 @@
#define vec_vminsh __builtin_vec_vminsh
#define vec_vminsb __builtin_vec_vminsb
#define vec_mradds __builtin_vec_mradds
-#define vec_vmsumshm __builtin_vec_vmsumshm
-#define vec_vmsumuhm __builtin_vec_vmsumuhm
-#define vec_vmsummbm __builtin_vec_vmsummbm
-#define vec_vmsumubm __builtin_vec_vmsumubm
-#define vec_vmsumshs __builtin_vec_vmsumshs
-#define vec_vmsumuhs __builtin_vec_vmsumuhs
-#define vec_vmulesb __builtin_vec_vmulesb
-#define vec_vmulesh __builtin_vec_vmulesh
-#define vec_vmuleuh __builtin_vec_vmuleuh
-#define vec_vmuleub __builtin_vec_vmuleub
-#define vec_vmulosh __builtin_vec_vmulosh
-#define vec_vmulouh __builtin_vec_vmulouh
-#define vec_vmulosb __builtin_vec_vmulosb
-#define vec_vmuloub __builtin_vec_vmuloub
#define vec_nmsub __builtin_vec_nmsub
#define vec_packpx __builtin_vec_packpx
#define vec_vpkswss __builtin_vec_vpkswss
@@ -173,9 +154,6 @@
#define vec_vsubshs __builtin_vec_vsubshs
#define vec_vsubsbs __builtin_vec_vsubsbs
#define vec_sum4s __builtin_vec_sum4s
-#define vec_vsum4shs __builtin_vec_vsum4shs
-#define vec_vsum4sbs __builtin_vec_vsum4sbs
-#define vec_vsum4ubs __builtin_vec_vsum4ubs
#define vec_sum2s __builtin_vec_sum2s
#define vec_sums __builtin_vec_sums
#define vec_trunc __builtin_vec_trunc
diff -uN altivec/altivec.md vmx128/altivec.md
--- altivec/altivec.md 2007-08-22 09:31:46.0 +0100
+++ vmx128/altivec.md 2007-08-22 09:31:21.0 +0100
@@ -566,53 +566,6 @@
;; [(set (match_operand:V4SI 0 "register_operand" "=v")
;; (mult:V4SI (match_operand:V4SI 1 "register_operand" "v")
;;(match_operand:V4SI 2 "register_operand" "v")))]
-(define_expand "mulv4si3"
- [(use (match_operand:V4SI 0 "register_operand" ""))
- (use (match_operand:V4SI 1 "register_operand" ""))
- (use (match_operand:V4SI 2 "register_operand" ""))]
- "TARGET_ALTIVEC"
- "
- {
- rtx zero;
- rtx swap;
- rtx small_swap;
- rtx sixteen;
- rtx one;
- rtx two;
- rtx low_product;
- rtx high_product;
-
- zero = gen_reg_rtx (V4SImode);
- emit_insn (gen_altivec_vspltisw (zero, const0_rtx));
-
- sixteen = gen_reg_rtx (V4SImode);
- emit_insn (gen_altivec_vspltisw (sixteen, gen_rtx_CONST_INT (V4SImode,
-16)));
-
- swap = gen_reg_rtx (V4SImode);
- emit_insn (gen_altivec_vrlw (swap, operands[2], sixteen));
-
- one = gen_reg_rtx (V8HImode);
- convert_move (one, operands[1], 0);
-
- two = gen_reg_rtx (V8HImode);
- convert_move (two, operands[2], 0);
-
- small_swap = gen_reg_rtx (V8HImode);
- convert_move (small_swap, swap, 0);
-
- low_product = gen_reg_rtx (V4SImode);
- emit_insn (gen_altivec_vmulouh (low_product, one, two));
-
- high_product = gen_reg_rtx (V4SImode);
- emit_insn (gen_altivec_vmsumuhm (high_product, one, small_swap, zero));
-
- emit_insn (gen_altivec_vslw (high_product, high_product, sixteen));
-
- emit_insn (gen_addv4si3 (operands[0], high_product, low_product));
-
- DONE;
- }")
-
;; Fused multiply subtract
(define_insn "altivec_vnmsubfp"
@@ -644,38 +597,6 @@
"vmsummm %0,%1,%2,%3"
[(set_attr "type" "veccomplex")])
-(define_insn "altivec_vmsumshm"
- [(set (match_operand:V4SI 0 "register_operand" "=v")
-(unspec:V4SI [(match_operand:V8HI 1 "register_operand" "v")
- (match_operand:V8HI 2 "register_operand" "v")
- (match_operand:V4SI 3 "register_operand" "v")]
-UNSPEC_VMS
Re: Implementing VMX128 AltiVec Variant
On Wed, 22 Aug 2007, Paolo Bonzini wrote: > > With the modifications I made, GCC still compiled fine. However, > > libgcc and libstdc++ DO still get build with the missing instructions > > (according to objdump -D). Why is that? Is that a consequence of the > > ADA files? Or something else? Where should I look? Is the it ada files > > that are the cause of the problem I'm seeing? > > It must be something else. I'm not sure what, though. It might be > something as simple as an instruction built from substrings. For > example, search for altivec_vmsumum in altivec.md. I just re-checked for that and I can't find any. I have attached a diff for my modified altivec.h, altivec.md and rs6000.c files. Patch in gcc/config/rs6000 subtree with -p1. Can anyone think of anywhere else I should be looking? Where else could these instructions be coming from? This is really not relevant to the posted patch; however, I'll still post it here. The proper way to disable Altivec instructions is to leave altivec.h and rs6000.c aside, and just change the "TARGET_ALTIVEC" to something like "(TARGET_ALTIVEC && 0)". The remaining code will automagically be disabled. Later, you can add your option and the corresponding TARGET_VMX128 mask, and go back replacing the "TARGET_ALTIVEC && 0" with "TARGET_ALTIVEC && !TARGET_VMX128". Thanks for that. This is the sort of thing I was hoping to eventually implement (rather than re-implementing vmx128.h and vmx128.md from scratch with 90% overlap with altivec.h and altivec.md). But I'd really like to go with a quick and dirty proof of concept first, which is to just cut out the offending instructions from altivec support, just to make sure that it would work. Gordan
Re: Is Sun putting much effort into supporting the gcc/binutils toolchain on sparc64 ?
On Wed, 12 Sep 2007, Andrew Walrond wrote: David Miller wrote: So no, Sun really isn't helping with any actual development. I don't know what to say. Incredible work David, but quite frankly, I'm speechless. I'm sure I can't be the only hardware purchaser asking these questions. I really like the Niagra and the successors sound even better, but I can't recommend buying into the platform without solid support for the OS and toolchain from Sun. Sun have their own, compiler, though. I'm trying to conceive a valid business reason for Sun to be so dismissive of the (surely massive?) gnu/linux hardware market, (even if they would rather we used Solaris), but it eludes me completely. Because given the price of their hardware, the only people who can afford it are enterprise customers, and Solaris is a more "enterprisey" solution. If I had to guess, that is... Gordan
Re: Is Sun putting much effort into supporting the gcc/binutils toolchain on sparc64 ?
Joe Buck wrote: I have a full rack of Niagara systems that proves that Sun cares to some extent. I get early hardware access and documentation access, plus engineers to talk to and ask questions of. With all due respect to your incredible efforts, this amounts to crumbs from their table. It doesn't serve us to bash contributors for not doing more. As some have pointed out, it can backfire; I wouldn't be surprised if Sun's own compiler group sees gcc as competition and would like for Sun to support it *less*. Sure - if it was good. But from what I've seen, SunCC on x86 gets beaten by GCC, performance-wise. And ICC utterly annihilates GCC in turn, on x86. :-( I sincerely hope, for Sun's sake, that the situation on SPARC platform is different, performance-wise. (I don't own any Sun hardware more recent than SuperSPARC, so wouldn't want to base any conclusions on what I have.) Gordan
