On 2/21/08, Eric Anholt <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-02-20 at 09:56 +0900, José Fonseca wrote: > > On 2/20/08, Eric Anholt <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, 2008-02-20 at 03:25 +0900, José Fonseca wrote: > > > > On 2/20/08, Ian Romanick <[EMAIL PROTECTED]> wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > Hash: SHA1 > > > > > > > > > > Keith Whitwell wrote: > > > > > | Ian Romanick wrote: > > > > > |> José Fonseca wrote: > > > > > |> | Microsoft compilers don't support C99 syntax. The only native > windows > > > > > |> | compilers that support C99 syntax are mingw32-gcc and Intel > C/C++ > > > > > |> | compiler, but we can't seriously support windows platform by > targeting > > > > > |> | these compilers alone and leave msvc out. > > > > > |> > > > > > |> In a word, NO. Frankly, I don't care to be restricted to 20 year > old C > > > > > |> syntax just because Microsoft doesn't care to support the 10 year > old C > > > > > |> syntax. > > > > > | > > > > > | Well, in the core parts of gallium this will hold. For the Cell > driver > > > > > | it doesn't matter so much... > > > > > | > > > > > | It's hardly ideal but we're basically grownups here and can > probably > > > > > | take it in our stride, especially given that the same restrictions > have > > > > > | been historically enforced in core Mesa. > > > > > > > > > > But this has not been the case in the hardware driver code. Isn't > this > > > > > code being folded into gallium (i.e., i965simple)? In that code we > > > > > routinely use variadic macros, C99 array initializers, and C99 > structure > > > > > initializers...and it makes the code better. > > > > > > > > It actually was when I tried to compile this code with msvc and saw > > > > all the compile errors and all the necessary effort to fix it that I > > > > decided to write this thread. Basically, using -stc=c99 with gallium > > > > code hides this problem until it is quite big. > > > > > > Wait, are you saying that you're going to be enforcing msvc > > > compatibility in the drivers as well? I would strongly object to that. > > > > On the drivers we care about, e.g., i965simple, I'm afraid it will > > have to be so... Drivers that third-parties create, or drivers we > > maintain but are clearly Linux only (e.g., cell), there is no point to > > enforce anything. Also the winsys drivers are platform specific, so > > they can use whatever features the platform they target have. > > > > C99 syntax is useful, and I admit that enforcing C89 even for the sake > > of portability is retrograde, nevertheless the C99 syntax is mostly > > syntactic sugar: > > - you can replace variadic macros with inline functions is most common uses > > - named strucuture initializers help reading, but you can achieve the > > same thing using a simple comment on each member. > > - you can easily avoid middle-of-scope variables declarations > > > > IMO, the best C99 feature has are library things like stdint.h types. > > But for those we can and we do provide equivalent definitions in the > > platforms that lack it. > > > > Also, if people care so deeply for C99, it might be worth considering > > C++, as it is supported. Even though for Windows Kernel mode, almost > > every single C++ feature is not advisable > > (http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx). So, at the > > of the day, you can only use pretty much what C99 gives you. > > > > Another suggestion given on IRC yesterday is compiling C99 code as C++ > > on MSVC. I have strong suspicion that it will bring a world of pain > > when linking to code outside gallium, but it is worth to check it. > > > > But for the meanwhile, please refrain of using C99 syntax on: > > - src/mesa/state_tracker/*.h > > - src/gallium/include > > - src/gallium/auxiliary > > - src/gallium/drivers/i915simple > > - src/gallium/drivers/i965simple > > It is OK to use C99 in > > - src/mesa > > - src/gallium/winsys > > - src/gallium/drivers/cell > > - etc. > > > > I'll soon disable -std=c99 and enable -pedantic inside src/gallium so > > that people get warnings when using c99 features. > > > > Again, I'm sorry to have to play the role of bad guy here. However, > > Windows support on gallium was an objective from the very beginning, > > and cross-platform portability implies sacrifices. Of course that, for > > those who don't care about windows portability, you're basically being > > asked to give up something without receiving nothing extra in > > return... But don't forget that the gallium source code was almost > > entirely coded by TG so far, so you *did* actually receive something > > already. Code doesn't come out of thin air -- it costs money. So I > > think it's not unfair to ask you in name of cooperation to do such > > sacrifice. > > > I guess I had been unclear on the gallium plan. If existing DRI drivers > get to continue living side-by-side with gallium stuff, then until > gallium proves to be a significant win for our chipsets we can go ahead > and ignore it, it sounds like.
Yes, that's correct. For existing drivers, the win that gallium can already give is the use of LLVM for shaders, that Zack has been working, which is faster than the hand written sse code path, and supports more processors for which there was no assembly code path. In the future, the ability of accelerating graphic APIs other than OpenGL will be also a win. But at the moment, there is only the mesa state tracker available. For new drivers, there is also the advantage that the amount of necessary code being smaller. Jose ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
