text:
A Forest of X Server Changes
We've got about another month left in the X server merge window for 1.17 and I've written a small set of fixes which haven't been reviewed yet for merging. I thought I'd advertise them a bit and see if I couldn't encourage a few of you to take a look and see if they're useful, correct and complete.
All of these are in my personal X server repository:
Cleaning up the X Registry
Branch: registry-fixes
I'll bet most of you don't even know about this code. It serves as a database mapping various X enumerations to strings to aid in diagnostics. For the security extensions, SECURITY and XSELinux, it holds names for all of the request, event and errors in the core protocol and all registered extensions. For X-Resource, it has the names of the registered resource types.
The X registry gets the request, event and error data from a file, "protocol.txt", which is installed in /usr/lib/xorg/protocol.txt on my machine. It gets the resource names as a part of resource type allocation.
So, what's wrong with this? Three basic things:
A simple bug — protocol.txt is left open while the server runs. This consumes a file descriptor for no good reason.
protocol.txt is read and parsed even if the security extensions aren't available. This wastes time and memory.
The resource names are kept even if X-Resource isn't in use.
The fixes remove the configure options for including the registry code; these functions are only used by the above extensions, so we can tell whether to include the code based solely on whether the extensions are being built.
Getting rid of the TCP listener by default
Branch: listen-fixes
We've had the '-nolisten' option for a while now to disable inbound TCP connections. It's useful for security reasons, but we've never enabled this by default. This patch sequence provides configure options for each of the listen sockets (tcp, unix and local), leaves unix and local enabled by default and disables tcp by default.
A new option, '-listen', is added which allows the user to override the -nolisten defaults in case they actually want to use TCP connections to X.
Glamor bug fixes
branch: glamor-fixes
This branch fixes two bugs:
Scale a large pixmap down to a small pixmap. This happens when you display enormous images in a web page. Iceweasel sends the whole huge image to X and uses Render to scale it to the screen. If the image is larger than a single texture, the X server splits it up into tiles, but the code which tries to perform the merged scale is just broken. Five patches fix this.
Shader-based trapezoids. This code uses area coverage to compute trapezoids. That violates the Render spec, which requires point sampling. Further, the performance of these trapezoids is lower than software (by a lot). This one patch removes the code.
Present bug fixes
branch: present-fixes
A selection of small bug fixes:
Clear pending flips at CloseScreen. This removes a reference to any pending flip pixmap, allowing it to be freed. Otherwise, we'll leak memory across server reset.
Add support for PresentOptionCopy. This has been in the protocol spec for a while, and was completely trivial to implement. However, it never got done. One tiny little patch.
Expose the Present API to drivers via sdksyms.sh. Until now, the present extension APIs have only been available inside the X server. This exposes them to drivers. This took a few cleanup patches first.
Use Present for Glamor XV
branch: glamor-present-xv
Painting XV to the screen should be done at vblank time to avoid tearing. Present offers vblank synchronized operations. Hooking those two together required a few new present APIs to expose the vblank functionality outside of the present code, then a bit of glamor code to hook up that new API to the XV bits.
Switching Glamor to a GL core profile context
branch: glamor-core-profile
This patch set is still in progress, but demonstrates how close we are. We'll be requiring OpenGL 3.3 for this so that we get texture swizzling, which is required for our single channel objects.
The changes present on the branch are:
Switch single channel surfaces from GLALPHA to GLRED.
Use vertex array objects.
Switch ephyr over to using a core 3.3 profile.
Still left to do is
- Switch Render code to VBOs
The core code uses VBOs everywhere, but the Render code doesn't. This means that all Render drawing fails, which makes the resulting server not very useful.
My main objective for getting this done is to reduce memory usage by about 16MB, which is the space allocated for software rendering in Mesa in case someone does something which the hardware doesn't handle, and that can only with some legacy OpenGL APIs.
Please help out!
All of these friendly little patches are looking for a bit of review so that they can get merged before the 1.17 window closes.
AltOS 1.5 — EasyMega support, features and bug fixes
Bdale and I are pleased to announce the release of AltOS version 1.5.
AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.
This is a major release of AltOS, including support for our new EasyMega board and a host of new features and bug fixes
AltOS Firmware — EasyMega added, new features and fixes
Our new flight computer, EasyMega, is a TeleMega without any radios:
9 DoF IMU (3 axis accelerometer, 3 axis gyroscope, 3 axis compass).
Orientation tracking using the gyroscopes (and quaternions, which are lots of fun!)
Four fully-programmable pyro channels, in addition to the usual apogee and main channels.
AltOS Changes
We've made a few improvements in the firmware:
The APRS secondary station identifier (SSID) is now configurable by the user. By default, it is set to the last digit of the serial number.
Continuity of the four programmable pyro channels on EasyMega and TeleMega is now indicated via the beeper. Four tones are sent out after the continuity indication for the apogee and main channels with high tones indicating continuity and low tones indicating an open circuit.
Configurable telemetry data rates. You can now select among 38400 (the previous value, and still the default), 9600 or 2400 bps. To take advantage of this, you'll need to reflash your TeleDongle or TeleBT.
AltOS Bug Fixes
We also fixed a few bugs in the firmware:
TeleGPS had separate flight logs, one for each time the unit was turned on. Turning the unit on to test stuff and turning it back off would consume one of the flight log 'slots' on the board; once all of the slots were full, no further logging would take place. Now, TeleGPS appends new data to an existing single log.
Increase the maximum computed altitude from 32767m to 2147483647m. Back when TeleMetrum v1.0 was designed, we never dreamed we'd be flying to 100k' or more. Now that's surprisingly common, and so we've increased the size of the altitude data values to fit modern rocketry needs.
Continuously evaluate pyro firing condition during delay period. The previous firmware would evaluate the pyro firing requirements, and once met, would delay by the indicated amount and then fire the channel. If the conditions had changed state, the channel would still fire. Now, the conditions are continuously evaluated during the delay period and if they change state, the event is suppressed.
Allow negative values in the pyro configuration. Now you can select a negative speed to indicate a descent rate or a negative acceleration value to indicate acceleration towards the ground.
AltosUI and TeleGPS — EasyMega support, OS integration and more
The AltosUI and TeleGPS applications have a few changes for this release:
EasyMega support. That was a simple matter of adapting the existing TeleMega support.
Added icons for our file types, and hooked up the file manager so that AltosUI, TeleGPS and/or MicroPeak are used to view any of our data files.
Configuration support for APRS SSIDs, and telemetry data rates.
Reworking Intel Glamor
The original Intel driver Glamor support was based on the notion that it would be better to have the Intel driver capture any fall backs and try to make them faster than Glamor could do internally. Now that Glamor has reasonably complete acceleration, and its fall backs aren't terrible, this isn't as useful as it once was, and because this uses Glamor in a weird way, we're making the Glamor code harder to maintain.
Fixing the Intel driver to not use Glamor in this way took a bit of effort; the UXA support is all tied into the overall operation of the driver.
Separating out UXA functions
The first task was to just identify which functions were UXA-specific by adding "_uxa" to their names. A couple dozen sed runs and now a bunch of the driver is looking better.
Next, a pile of UXA-specific functions were actually inside the non-UXA parts of the code. Those got moved out, and a new 'intel_uxa.h" file was created to hold all of the definitions.
Finally, a few non UXA-specific functions were actually in the uxa files; those got moved over to the generic code.
Removing the Glamor paths in UXA
Each one of the UXA functions had a little piece of code at the top like:
if (uxa_screen->info->flags & UXA_USE_GLAMOR) {
int ok = 0;
if (uxa_prepare_access(pDrawable, UXA_GLAMOR_ACCESS_RW)) {
ok = glamor_fill_spans_nf(pDrawable,
pGC, n, ppt, pwidth, fSorted);
uxa_finish_access(pDrawable, UXA_GLAMOR_ACCESS_RW);
if (!ok)
goto fallback;
Pulling those out shrank the UXA code by quite a bit.
Selecting Acceleration (or not)
The intel driver only supported UXA before; Glamor was really just a slightly different mode for UXA. I switched the driver from using a bit in the UXA flags to having an 'accel' variable which could be one of three options:
I added ACCEL_NONE to give us a dumb frame buffer mode. That actually supports DRI3 so that we can bring up Mesa and run it under X before we have any acceleration code ready; avoiding a dependency loop when doing new hardware. All that it requires is a kernel that offers mode setting and buffer allocation.
Initializing Glamor
With UXA no longer supporting Glamor, it was time to plug the Glamor support into the top of the driver. That meant changing a bunch of the entry points to select appropriate Glamor or UXA functionality, instead of just calling into UXA. So, now we've got lots of places that look like:
switch (intel->accel) {
#if USE_GLAMOR
case ACCEL_GLAMOR:
if (!intel_glamor_create_screen_resources(screen))
return FALSE;
#if USE_UXA
case ACCEL_UXA:
if (!intel_uxa_create_screen_resources(screen))
return FALSE;
case ACCEL_NONE:
if (!intel_none_create_screen_resources(screen))
return FALSE;
Using a switch means that we can easily elide code that isn't wanted in a particular build. Of course 'accel' is an enum, so places which are missing one of the required paths will cause a compiler warning.
It's not all perfectly clean yet; there are piles of UXA-only paths still.
Making It Build Without UXA
The final trick was to make the driver build without UXA turned on; that took several iterations before I had the symbols sorted out appropriately.
I built the driver with various acceleration options and then tried to count the lines of source code. What I did was just list the source files named in the driver binary itself. This skips all of the header files and the render program source code, and ignores the fact that there are a bunch of #ifdef's in the uxa directory selecting between uxa, glamor and none.
Accel Lines Size(B)
----------- ------ -------
none 7143 73039
glamor 7397 76540
uxa 25979 283777
sna 118832 1303904
none legacy 14449 152480
glamor legacy 14703 156125
uxa legacy 33285 350685
sna legacy 126138 1395231
The 'legacy' addition supports i810-class hardware, which is needed for a complete driver.
Along The Way, Enable Tiling for the Front Buffer
While hacking the code, I discovered that the initial frame buffer allocated for the screen was created without tiling because a few parameters that depend on the GTT size were not initialized until after that frame buffer was allocated. I haven't analyzed what effect this has on performance.
Page Flipping and Resize
Page flipping (or just flipping) means switching the entire display from one frame buffer to another. It's generally the fastest way of updating the screen as you don't have to copy any bits.
The trick with flipping is that a client hands you a random pixmap and you need to stuff that into the KMS API. With UXA, that's pretty easy as all pixmaps are managed through the UXA API which knows which underlying kernel BO is tied with each pixmap. Using Glamor, only the underlying GL driver knows the mapping. Fortunately (?), we have the EGL Image extension, which lets us take a random GL texture and turn it into a file descriptor for a DMA-BUF kernel object. So, we have this cute little dance:
fd = glamor_fd_from_pixmap(screen,
bo = drm_intel_bo_gem_create_from_prime(intel->bufmgr, fd, size);
intel_glamor_get_pixmap(pixmap)->bo = bo;
That last bit remembers the bo in some local memory so we don't have to do this more than once for each pixmap. glamorfdfrompixmap ends up calling eglCreateImageKHR followed by gbmbo_import and then a kernel ioctl to convert a prime handle into an fd. It's all quite round-about, but it does seem to work just fine.
After I'd gotten Glamor mostly working, I tried a few OpenGL applications and discovered flipping wasn't working. That turned out to have an unexpected consequence — all full-screen applications would run flat-out, and not be limited to frame rate. Present 'recovers' from a failed flip queue operation by immediately performing a CopyArea; not waiting for vblank. This needs to get fixed in Present by having it re-queued the CopyArea for the right time. What I did in the intel driver was to add a bunch more checks for tiling mode, pixmap stride and other things to catch pixmaps that were going to fail before the operation was queued and forcing them to fall back to CopyArea at the right time.
The second adventure was with XRandR. Glamor has an API to fix up the screen pixmap for a new frame buffer, but that pulls the size of the frame buffer out of the pixmap instead of out of the screen. XRandR leaves the pixmap size set to the old screen size during this call; fixing that just meant getting the pixmap size set correctly before calling into glamor. I think glamor should get fixed to use the screen size rather than the pixmap size.
Painting Root before Mode set
The X server has generally done initialization in one order:
- Create root pixmap
- Set video modes
- Paint root window
Recently, we've added a '-background none' option to the X server which causes it to set the root window background to none and have the driver fill in that pixmap with whatever contents were on the screen before the X server started.
In a pre-Glamor world, that was done by hacking the video driver to copy the frame buffer console contents to the root pixmap as it was created. The trouble here is that the root pixmap is created long before the upper layers of the X server are ready for drawing, so you can't use the core rendering paths. Instead, UXA had kludges to call directly into the acceleration functions.
What we really want though is to change the order of operations:
- Create root pixmap
- Paint root window
- Set video mode
That way, the normal root window painting operation will take care of getting the image ready before that pixmap is ever used for scanout. I can use regular core X rendering to get the original frame buffer contents into the root window, and even if we're not using -background none and are instead painting the root with some other pattern (like the root weave), I get that presented without an intervening black flash.
That turned out to be really easy — just delay the call to I830EnterVT (which sets the modes) until the server is actually running. That required one additional kludge — I needed to tell the DIX level RandR functions about the new modes; the mode setting operation used during server init doesn't call up into RandR as RandR lists the current configuration after the screen has been initialized, which is when the modes used to be set.
Calling xf86RandR12CreateScreenResources does the trick nicely. Getting the root window bits from fbcon, setting video modes and updating the RandR/Xinerama DIX info is now all done from the BlockHandler the first time it is called.
I ran the current glamor version of the intel driver with the master branch of the X server and there were not any huge differences since my last Glamor performance evaluation aside from GetImage. The reason is that UXA/Glamor never called Glamor's image functions, and the UXA GetImage is pretty slow. Using Mesa's image download turns out to have a huge performance benefit:
1. UXA/Glamor from April
2. Glamor from today
1 2 Operation
------------ ------------------------- -------------------------
50700.0 56300.0 ( 1.110) ShmGetImage 10x10 square
12600.0 26200.0 ( 2.079) ShmGetImage 100x100 square
1840.0 4250.0 ( 2.310) ShmGetImage 500x500 square
3290.0 202.0 ( 0.061) ShmGetImage XY 10x10 square
36.5 170.0 ( 4.658) ShmGetImage XY 100x100 square
1.5 56.4 ( 37.600) ShmGetImage XY 500x500 square
49800.0 50200.0 ( 1.008) GetImage 10x10 square
5690.0 19300.0 ( 3.392) GetImage 100x100 square
609.0 1360.0 ( 2.233) GetImage 500x500 square
3100.0 206.0 ( 0.066) GetImage XY 10x10 square
36.4 183.0 ( 5.027) GetImage XY 100x100 square
1.5 55.4 ( 36.933) GetImage XY 500x500 square
Running UXA from today the situation is even more dire; I suspect that enabling tiling has made CPU reads through the GTT even worse than before?
1: UXA today
2: Glamor today
1 2 Operation
------------ ------------------------- -------------------------
43200.0 56300.0 ( 1.303) ShmGetImage 10x10 square
2600.0 26200.0 ( 10.077) ShmGetImage 100x100 square
130.0 4250.0 ( 32.692) ShmGetImage 500x500 square
3260.0 202.0 ( 0.062) ShmGetImage XY 10x10 square
36.7 170.0 ( 4.632) ShmGetImage XY 100x100 square
1.5 56.4 ( 37.600) ShmGetImage XY 500x500 square
41700.0 50200.0 ( 1.204) GetImage 10x10 square
2520.0 19300.0 ( 7.659) GetImage 100x100 square
125.0 1360.0 ( 10.880) GetImage 500x500 square
3150.0 206.0 ( 0.065) GetImage XY 10x10 square
36.1 183.0 ( 5.069) GetImage XY 100x100 square
1.5 55.4 ( 36.933) GetImage XY 500x500 square
Of course, this is all just x11perf, which doesn't represent real applications at all well. However, there are applications which end up doing more GetImage than would seem reasonable, and it's nice to have this kind of speed up.
I'm running this on my crash box to get some performance numbers and continue testing it. I'll switch my desktop over when I feel a bit more comfortable with how it's working. But, I think it's feature complete at this point.
Where's the Code
As usual, the code is in my personal repository. It's on the 'glamor' branch.
git://people.freedesktop.org/~keithp/xf86-video-intel glamor
AltOS 1.4.1 — Fix ups for 1.4
Bdale and I are pleased to announce the release of AltOS version 1.4.1.
AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.
This is a minor release of AltOS, incorporating a small handful of build and install issues. No new features have been added, and the only firmware change was to make sure that updated TeleMetrum v2.0 firmware is included in this release.
AltOS — TeleMetrum v2.0 firmware included
AltOS version 1.4 shipped without updated firmware for TeleMetrum v2.0. There are a couple of useful new features and bug fixes in that version, so if you have a TeleMetrum v2.0 board with older firmware, you should download this release and update it.
AltosUI and TeleGPS — Signed Windows Drivers, faster maps downloading
We finally figured out how to get our Windows drivers signed making it easier for Windows 7 and 8 users to install our software and use our devices.
Also for Windows users, we've fixed the Java version detection so that if you have Java 8 already installed, AltOS and TeleGPS won't try to download Java 7 and install that. We also fixed the Java download path so that if you have no Java installed, we'll download a working version of Java 6 instead of using an invalid Java 7 download URL.
Finally, for everyone, we fixed maps downloading to use the authorized Google API key method for getting map tiles. This makes map downloading faster and more reliable.
Thanks for flying with Altus Metrum!
TeleGPS Battery Life
I charged up one of the "160mAh" batteries that we sell. (The ones we've got now are labeled 200mAh; the 160mAh rating is something like a minimum that we expect to be able to ever get at that size.)
I connected the battery to a TeleGPS board, hooked up a telemetry monitoring setup on my laptop and set the device in the window of my office. This let me watch the battery voltage through the day without interrupting my other work. Of course, because the telemetry was logged to a file, I've now got a complete plot of the voltage data:
It looks like a pretty typical lithium polymer discharge graph; slightly faster drop from the 4.1V full charge voltage down to about 3.9V, then a gradual drop to 3.65 at which point it starts to dive as the battery is nearly discharged.
Because we run the electronics at 3.3V, and the LDO has a dropout of about 100mV, it's best if the battery stays above 3.4V. That occurred at around 21500 seconds of run time, or almost exactly six hours.
We also have an "850mAh" battery in the shop; I'd expect that to last a bit more than four times as long, or about a day. Maybe I'll get bored enough at some point to hook one up and verify that guess.
AltOS 1.4 — TeleGPS support, features and bug fixes
Bdale and I are pleased to announce the release of AltOS version 1.4.
AltOS is the core of the software for all of the Altus Metrum products. It consists of firmware for our cc1111, STM32L151, LPC11U14 and ATtiny85 based electronics and Java-based ground station software.
This is a major release of AltOS, including support for our new TeleGPS board and a host of new features and bug fixes
AltOS Firmware — TeleGPS added, new features and fixes
Our new tracker, TeleGPS, works quite differently than a flight computer
Starts tracking and logging at power-on
Disables RF and logging only when connected to USB
Doesn't log position when it isn't moving for a long time.
TeleGPS transmits our digital telemetry protocol, APRS and radio direction finding beacons.
For TeleMega, we've made the firing time for the additional pyro channels (A-D) configurable, in case the default (50ms) isn't long enough.
AltOS Beeping Changes
The three-beep startup tones have been replaced with a report of the current battery voltage. This is nice on all of the board, but particularly useful with EasyMini which doesn't have the benefit of telemetry reporting its state.
We also changed the other state tones to "Farnsworth" spacing. This makes them all faster, and easier to distinguish from the numeric reports of voltage and altitude.
Finally, we've added the ability to change the frequency of the beeper tones. This is nice when you have two Altus Metrum flight computers in the same ebay and want to be able to tell the beeps apart.
AltOS Bug Fixes
Fixed a bug which prevented you from using TeleMega's extra pyro channel 'Flight State After' configuration value.
AltOS 1.3.2 on TeleMetrum v2.0 and TeleMega would reset the flight number to 2 after erasing flights; that's been fixed.
AltosUI — New Maps, igniter tab and a few fixes
With TeleGPS tracks now potentially ranging over a much wider area than a typical rocket flight, the Maps interface has been updated to include zooming and multiple map styles. It also now uses less memory, which should make it work on a wider range of systems.
For TeleMega, we've added an 'Igniter' tab to the flight monitor interface so you can check voltages on the extra pyro channels before pushing the button.
We're hoping that the new Maps interface will load and run on machines with limited memory for Java applications; please let us know if this changes anything for you.
TeleGPS — All new application just for TeleGPS
While TeleGPS shares the same telemetry and data logging capabilities as all of the Altus Metrum flight computers, its use as a tracker is expected to be both broader and simpler than the rocketry-specific systems. We've build a custom TeleGPS application that incorporates the mapping and data visualization aspects of AltosUI, but eliminates all of the rocketry-specific flight state tracking.
Current Glamor Performance
I finally managed to get a Gigabyte Brix set up running Debian so that I could do some more reasonable performance characterization of Glamor in its current state. I wanted to use this particular machine because it has enough cooling to keep from thermally throttling the CPU/GPU package.
This is running my glamor-server branch of the X server, which completes the core operation rework and then has some core X server performance improvements as well for filled and outlined arcs.
Changes in X11perf
First off, I did some analysis of what x11perf was doing and found that it wasn't quite measuring what we thought. I'm not interested in competing on x11perf numbers absolutely, I'm only interested in doing relative measurements of useful operations, so fixing the tool to measure what I want seems reasonable to me.
When x11perf was first written, it drew 100x100 rectangles tight against one another without any gap. And, it filled the window with them, drawing a 6x6 grid of 100x100 rectangles in a 600x600 window. To better exercise the rectangle code and check edge conditions better, we added a one pixel gap between the rectangles. However, we didn't reduce the number of rectangles drawn, so we ended up drawing 11 of the 36 rectangles on top of the first set of 25. Simple region computations would allow the X server to draw only 25 most of the time, skipping the redundant rectangles.
The vertical and horizontal line tests were added a while after the first set of tests, and were done without regard to how an X server might optimize for them. x11perf draws these lines packed tightly together, creating a single square of pixels for the result.
EXA, UXA and SNA all take vertical and horizontal lines and convert them to rectangles, then take the rectangles and clip them against the window clip list by computing a region from them and intersecting that with the GC composite clip. It's a completely reasonable plan, however, when you take what x11perf was drawing and run it through this code, you end up with a single solid rectangle. Which is surprisingly fast, compared with drawing individual lines.
I "fixed" the overlapping rectangle case by reducing the number of boxes drawn from 36 to 25, and I fixed the vertical and horizontal line case by spacing the lines a pixel apart.
I've pushed out these changes to my x11perf repository on freedesktop.org.
What's Fast
Things that match GL's capabilities are fast, things which don't are slow. No surprises there. What's interesting is precisely what matches GL
Patterns For Free
Because GL makes it easy to program fill patterns into the GPU, there are essentially no performance differences between solid and patterned operations.
GL Lines
Glamor uses GL lines, which can be programmed to match X semantics, to quite good effect. The only trick required was to deal with cap styles. GL never draws the final pixel in a line, while X does unless the cap style is CapNotLast. The solution was to draw an extra line segment containing a single pixel at the end of every joined set of lines for this case.
The other implicit requirement is that all zero width lines look the same. Right now, I've solved that for fill styles and raster ops as they're all drawn with the same GL operations. However, for plane masks, we're currently falling back to software, which may draw something different. Fixing that isn't impossible, it's just tedious.
Pushing all of the work of drawing core text into glamor wasn't terribly difficult, and the results are pretty spectacular.
What's Slow
We've still got room for improvement in Glamor, but there aren't any obvious show-stoppers to getting great performance for reasonable X applications anymore.
Wide Lines and Arcs
One of the speed-ups I've made in my glamor branch is to merge all of drawing of multiple filled and zero-width arcs into a single giant GL request. That turned out to both improve performance and save a bit of code. Right now, drawing wide lines and wide arcs doesn't do this, and so we suffer from submitting many smaller requests to GL. It's hard to get excited about speeding any of this up as all of the wide primitives are essentially unused these days.
Filled Polygons
Because X only lets applications draw a single polygon in each request, Glamor can't really gain any efficiency from batching work unless we start looking ahead in the X protocol stream to see if the next request is another polygon. Alternatively, we could leave the span operation pending to see if more spans were coming before the X serve went idle. Neither of these is all that exciting though; X polygons just aren't that useful.
Render Operations
These are still not structured to best fit modern GL; some work here would help a bunch. We've got a gsoc student ready to go at this though, so I expect we'll have much better numbers in a few months.
Window Operations
You wouldn't think that moving and resizing windows would be so limited by drawing performance, but x11perf tests these with tiny little windows, and each operation draws or copies only a couple of little rectangles, which makes GL quite expensive. Working on speeding up GL for small numbers of operations would help a bunch here.
Unexpected Results
Solid rectangles are actually running slower than patterned rectangles, and I really have no idea why. The CPU is close to idle during the 500x500 solid rectangle test (as you'd expect, given the workload), the vertex and fragment shaders look correct out of the compiler, and yet solid rectangles run at only 0.80 of the performance of the patterned rectangles.
GL semantics for copying data essentially preclude overlapping blts of any form. There's the NVtexturebarrier extension which at least lets us do blts within the same object, but even that doesn't define how overlapping blts work. So, we have to create a temporary copy for this operation to make it work right. I was worried that this would slow things down, but the Iris Pro 3D engine is enough faster than the 2D engine that even with the extra copy, large scrolls and copies within the same object are actually faster.
Here's a giant image showing the ratio of Glamor to both UXA and SNA running on the same machine, with all of the same software; the only change between runs was to switch the configured acceleration architecture.
Java Sound on Linux
I'm often in the position of having my favorite Java program (AltosUI) unable to make any sounds. Here's a history of the various adventures I've had.
Java and PulseAudio ALSA support
When we started playing with Java a few years ago, we discovered that if PulseAudio were enabled, Java wouldn't make any sound. Presumably, that was because the ALSA emulation layer offered by PulseAudio wasn't capable of supporting Java.
The fix for that was to make sure pulseaudio would never run. That's harder than it seems; pulseaudio is like the living dead; rising from the grave every time you kill it. As it's nearly impossible to install any desktop applications without gaining a bogus dependency on pulseaudio, the solution that works best is to make sure dpkg never manages to actually install the program with dpkg-divert:
# dpkg-divert --rename /usr/bin/pulseaudio
With this in place, Java was a happy camper for a long time.
Java and PulseAudio Native support
More recently, Java has apparently gained some native PulseAudio support in some fashion. Of course, I couldn't actually get it to work, even after running the PulseAudio daemon but some kind Debian developer decided that sound should be broken by default for all Java applications and selected the PulseAudio back-end in the Java audio configuration file.
Fixing that involved learning about said Java audio configuration file and then applying patch to revert the Debian packaging damage.
$ cat /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/sound.properties
You can see the PulseAudio mistakes at the top of that listing, with the corrected native interface settings at the bottom.
Java and single-open ALSA drivers
It used to be that ALSA drivers could support multiple applications having the device open at the same time. Those with hardware mixing would use that to merge the streams together; those without hardware mixing might do that in the kernel itself. While the latter is probably not a great plan, it did make ALSA a lot more friendly to users.
My new laptop is not friendly, and returns EBUSY when you try to open the PCM device more than once.
After downloading the jdk and alsa library sources, I figured out that Java was trying to open the PCM device multiple times when using the standard Java sound API in the simplest possible way. I thought I was going to have to fix Java, when I figured out that ALSA provides user-space mixing with the 'dmix' plugin. I enabled that on my machine and now all was well.
$ cat /etc/asound.conf
pcm.!default {
type plug
slave.pcm "dmixer"
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm "hw:1,0"
period_time 0
period_size 1024
buffer_size 4096
rate 44100
bindings {
0 0
1 1
ctl.dmixer {
type hw
card 1
ctl.!default {
type hw
card 1
As you can see, my sound card is not number 0, it's number 1, so if your card is a different number, you'll have to adapt as necessary.
Core Rendering with Glamor
I've hacked up the intel driver to bypass all of the UXA paths when Glamor is enabled so I'm currently running an X server that uses only Glamor for all rendering. There are still too many fall backs, and performance for some operations is not what I'd like, but it's entirely usable. It supports DRI3, so I even have GL applications running.
Core Rendering Status
I've continued to focus on getting the core X protocol rendering operations complete and correct; those remain a critical part of many X applications and are a poor match for GL. At this point, I've got accelerated versions of the basic spans functions, filled rectangles, text and copies.
GL and Scrolling
OpenGL has been on a many-year vendetta against one of the most common 2D accelerated operations — copying data within the same object, even when that operation overlaps itself. This used to be the most performance-critical operation in X; it was used for scrolling your terminal windows and when moving windows around on the screen.
Reviewing the OpenGL 3.x spec, Eric and I both read the glCopyPixels specification as clearly requiring correct semantics for overlapping copy operations — it says that the operation must be equivalent to reading the pixels and then writing the pixels. My CopyArea acceleration thus uses this path for the self-copy case. However, the ARB decided that having a well defined blt operation was too nice to the users, so the current 4.4 specification adds explicit language to assert that this is not well defined anymore (even in the face of the existing language which is pretty darn unambiguous).
I suspect we'll end up creating an extension that offers what we need here; applications are unlikely to stop scrolling stuff around, and GPUs (at least Intel) will continue to do what we want. This is the kind of thing that makes GL maddening for 2D graphics — the GPU does what we want, and the GL doesn't let us get at it.
For implementations not capable of supporting the required semantic, someone will presumably need to write code that creates a temporary copy of the data.
PBOs for fall backs
For operations which Glamor can't manage, we need to fall back to using a software solution. Direct-to-hardware acceleration architectures do this by simply mapping the underlying GPU object to the CPU. GL doesn't provide this access, and it's probably a good thing as such access needs to be carefully synchronized with GPU access, and attempting to access tiled GPU objects with the CPU require either piles of CPU code to 'de-tile' accesses (ala wfb), or special hardware detilers (like the Intel GTT).
However, GL does provide a fairly nice abstraction called pixel buffer objects (PBOs) which work to speed access to GPU data from the CPU.
The fallback code allocates a PBO for each relevant X drawable, asks GL to copy pixels in, and then calls fb, with the drawable now referencing the temporary buffer. On the way back out, any potentially modified pixels are copied back through GL and the PBOs are freed.
This turns out to be dramatically faster than malloc'ing temporary buffers as it allows the GL to allocate memory that it likes, and for it to manage the data upload and buffer destruction asynchronously.
Because X pixmaps can contain many X windows (the root pixmap being the most obvious example), they are often significantly larger than the actual rendering target area. As an optimization, the code only copies data from the relevant area of the pixmap, saving considerable time as a result. There's even an interface which further restricts that to a subset of the target drawable which the Composite function uses.
Using Scissoring for Clipping
The GL scissor operation provides a single clipping rectangle. X provides a list of rectangles to clip to. There are two obvious ways to perform clipping here — either perform all clipping in software, or hand each X clipping rectangle in turn to GL and re-execute the entire rendering operation for each rectangle.
You'd think that the former plan would be the obvious choice; clearly re-executing the entire rendering operation potentially many times is going to take a lot of time in the GPU.
However, the reality is that most X drawing occurs under a single clipping rectangle. Accelerating this common case by using the hardware clipper provides enough benefit that we definitely want to use it when it works. We could duplicate all of the rendering paths and perform CPU-based clipping when the number of rectangles was above some threshold, but the additional code complexity isn't obviously worth the effort, given how infrequently it will be used. So I haven't bothered. Most operations look like this:
Allocate VBO space for data
Fill VBO with X primitives
loop over clip rects {
This obviously out-sources as much of the problem as possible to the GL library, reducing the CPU time spent in glamor to a minimum.
A Peek at Some Code
With all of these changes in place, drawing something like a list of rectangles becomes a fairly simple piece of code:
First, make sure the program we want to use is available and can be used with our GC configuration:
prog = glamor_use_program_fill(pixmap, gc,
if (!prog)
goto bail_ctx;
Next, allocate the VBO space and copy all of the X data into it. Note that the data transfer is simply 'memcpy' here — that's because we break the X objects apart in the vertex shader using instancing, avoiding the CPU overhead of computing four corner coordinates.
/* Set up the vertex buffers for the points */
v = glamor_get_vbo_space(drawable->pScreen, nrect * (4 * sizeof (GLshort)), &vbo_offset);
glVertexAttribDivisor(GLAMOR_VERTEX_POS, 1);
glVertexAttribPointer(GLAMOR_VERTEX_POS, 4, GL_SHORT, GL_FALSE,
4 * sizeof (GLshort), vbo_offset);
memcpy(v, prect, nrect * sizeof (xRectangle));
Finally, loop over the pixmap tile fragments, and then over the clip list, selecting the drawing target and painting the rectangles:
glamor_pixmap_loop(pixmap_priv, box_x, box_y) {
int nbox = RegionNumRects(gc->pCompositeClip);
BoxPtr box = RegionRects(gc->pCompositeClip);
glamor_set_destination_drawable(drawable, box_x, box_y, TRUE, FALSE, prog->matrix_uniform, &off_x, &off_y);
while (nbox--) {
glScissor(box->x1 + off_x,
box->y1 + off_y,
box->x2 - box->x1,
box->y2 - box->y1);
glDrawArraysInstanced(GL_TRIANGLE_STRIP, 0, 4, nrect);
GL texture size limits
X pixmaps use 16 bit dimensions for width and height, allowing them to be up to 65536 x 65536 pixels. Because the X coordinate space is signed, only a quarter of this space is actually useful, which makes the useful size of X pixmaps only 32767 x 32767. This is still larger than most GL implementations offer as a maximum texture size though, and while it would be nice to just say 'we don't allow pixmaps larger than GL textures', the reality is that many applications expect to be able to allocate such pixmaps today, largely to hold the ever increasing size of digital photographs.
Glamor has always supported large X pixmaps; it does this by splitting them up into tiles, each of which is no larger than the largest texture supported by the driver. What I've added to Glamor is some simple macros that walk over the array of tiles, making it easy for the rendering code to support large pixmaps without needing any special case code.
Glamor also had some simple testing support — you can compile the code to ignore the system-provided maximum texture size and supply your own value. This code had gone stale, and couldn't work as there were parts of the code for which tiling support just doesn't make sense, like the glyph cache, or the X scanout buffer. I fixed things so that you could leave those special cases as solitary large tiles while breaking up all other pixmaps into tiles no larger than 32 pixels square.
I hope to remove the single-tile case and leave the code supporting only the multiple-tile case; we have to have the latter code, and so having the single-tile code around simply increases our code size for not obvious benefit.
Getting accelerated copies between tiled pixmaps added a new coordinate system to the mix and took a few hours of fussing until it was working.
Rebasing Many (many) Times
I'm sure most of us remember the days before git; changes were often monolithic, and the notion of changing how the changes were made for the sake of clarity never occurred to anyone. It used to be that the final code was the only interesting artifact; how you got there didn't matter to anyone. Things are different today; I probably spend a third of my development time communicating how the code should change with other developers by changing the sequence of patches that are to be applied.
In the case of Glamor, I've now got a set of 28 patches. The first few are fixes outside of the glamor tree that make the rest of the server work better. Then there are a few general glamor infrastructure additions. After that, each core operation is replaced, one a at a time. Finally, a bit of stale code is removed. By sequencing things in a logical fashion, I hope to make review of the code easier, which should mean that people will spend less time trying to figure out what I did and be able to spend more time figuring out if what I did is reasonable and correct.
Supporting Older Versions of GL
All of the new code uses vertex instancing to move coordinate computation from the CPU to the GPU. I'm also pulling textures apart using integer operations. Right now, we should correctly fall back to software for older hardware, but it would probably be nicer to just fall back to simpler GL instead. Unless everyone decides to go buy hardware with new enough GL driver support, someone is going to need to write simplified code paths for glamor.
If you've got such hardware, and are interested in making it work well, please take this as an opportunity to help yourself and others.
Near-term Glamor Goals
I'm pretty sure we'll have the code in good enough shape to merge before the window closes for X server 1.16. Eric is in charge of the glamor tree, so it's up to him when stuff is pulled in. He and Markus Wick have also been generating code and reviewing stuff, but we could always use additional testing and review to make the code as good as possible before the merge window closes.
Markus has expressed an interest in working on Glamor as a part of the X.org summer of code this year; there's clearly plenty of work to do here, Eric and I haven't touched the render acceleration stuff at all, and that code could definitely use some updating to use more modern GL features.
If that works as well as the core rendering code changes, then we can look forward to a Glamor which offers GPU-limited performance for classic X applications, without requiring GPU-specific drivers for every generation of every chip.
Brief Glamor Hacks
Eric Anholt started writing Glamor a few years ago. The goal was to provide credible 2D acceleration based solely on the OpenGL API, in particular, to implement the X drawing primitives, both core and Render extension, without any GPU-specific code. When he started, the thinking was that fixed-function devices were still relevant, so that original code didn't insist upon "modern" OpenGL features like GLSL shaders. That made the code less efficient and hard to write.
Glamor used to be a side-project within the X world; seen as something that really wasn't very useful; something that any credible 2D driver would replace with custom highly-optimized GPU-specific code. Eric and I both hoped that Glamor would turn into something credible and that we'd be able to eliminate all of the horror-show GPU-specific code in every driver for drawing X text, rectangles and composited images. That hadn't happened though, until now.
Fast forward to the last six months. Eric has spent a bunch of time cleaning up Glamor internals, and in fact he's had it merged into the core X server for version 1.16 which will be coming up this July. Within the Glamor code base, he's been cleaning some internal structures up and making life more tolerable for Glamor developers.
Using libepoxy
A big part of the cleanup was a transition all of the extension function calls to use his other new project, libepoxy, which provides a sane, consistent and performant API to OpenGL extensions for Linux, Mac OS and Windows. That library is awesome, and you should use it for everything you do with OpenGL because not using it is like pounding nails into your head. Or eating non-tasty pie.
Using VBOs in Glamor
One thing he recently cleaned up was how to deal with VBOs during X operations. VBOs are absolutely essential to modern OpenGL applications; they're really the only way to efficiently pass vertex data from application to the GPU. And, every other mechanism is deprecated by the ARB as not a part of the blessed 'core context'.
Glamor provides a simple way of getting some VBO space, dumping data into it, and then using it through two wrapping calls which you use along with glVertexAttribPointer as follows:
pointer = glamor_get_vbo_space(screen, size, &offset);
glVertexAttribPointer(attribute_location, count, type,
GL_FALSE, stride, offset);
memcpy(pointer, data, size);
glamor_get_vbo_space allocates the specified amount of VBO space and returns a pointer to that along with an 'offset', which is suitable to pass to glVertexAttribPointer. You dump your data into the returned pointer, call glamor_put_vbo_space and you're all done.
Actually Drawing Stuff
At the same time, Eric has been optimizing some of the existing rendering code. But, all of it is still frankly terrible. Our dream of credible 2D graphics through OpenGL just wasn't being realized at all.
On Monday, I decided that I should go play in Glamor for a few days, both to hack up some simple rendering paths and to familiarize myself with the insides of Glamor as I'm getting asked to review piles of patches for it, and not understanding a code base is a great way to help introduce serious bugs during review.
I started with the core text operations. Not because they're particularly relevant these days as most applications draw text with the Render extension to provide better looking results, but instead because they're often one of the hardest things to do efficiently with a heavy weight GPU interface, and OpenGL can be amazingly heavy weight if you let it.
Eric spent a bunch of time optimizing the existing text code to try and make it faster, but at the bottom, it actually draws each lit pixel as a tiny GL_POINT object by sending a separate x/y vertex value to the GPU (using the above VBO interface). This code walks the array of bits in the font and checking each one to see if it is lit, then checking if the lit pixel is within the clip region and only then adding the coordinates of the lit pixel to the VBO. The amazing thing is that even with all of this CPU and GPU work, the venerable 6x13 font is drawn at an astonishing 3.2 million glyphs per second. Of course, pure software draws text at 9.3 million glyphs per second.
I suspected that a more efficient implementation might be able to draw text a bit faster, so I decided to just start from scratch with a new GL-based core X text drawing function. The plan was pretty simple:
Dump all glyphs in the font into a texture. Store them in 1bpp format to minimize memory consumption.
Place raw (integer) glyph coordinates into the VBO. Place four coordinates for each and draw a GL_QUAD for each glyph.
Transform the glyph coordinates into the usual GL range (-1..1) in the vertex shader.
Fetch a suitable byte from the glyph texture, extract a single bit and then either draw a solid color or discard the fragment.
This makes the X server code surprisingly simple; it computes integer coordinates for the glyph destination and glyph image source and writes those to the VBO. When all of the glyphs are in the VBO, it just calls glDrawArrays(GL_QUADS, 0, 4 * count). The results were "encouraging":
1: fb-text.perf
2: glamor-text.perf
3: keith-text.perf
1 2 3 Operation
------------ ------------------------- ------------------------- -------------------------
9300000.0 3160000.0 ( 0.340) 18000000.0 ( 1.935) Char in 80-char line (6x13)
8700000.0 2850000.0 ( 0.328) 16500000.0 ( 1.897) Char in 70-char line (8x13)
6560000.0 2380000.0 ( 0.363) 11900000.0 ( 1.814) Char in 60-char line (9x15)
2150000.0 700000.0 ( 0.326) 7710000.0 ( 3.586) Char16 in 40-char line (k14)
894000.0 283000.0 ( 0.317) 4500000.0 ( 5.034) Char16 in 23-char line (k24)
9170000.0 4400000.0 ( 0.480) 17300000.0 ( 1.887) Char in 80-char line (TR 10)
3080000.0 1090000.0 ( 0.354) 7810000.0 ( 2.536) Char in 30-char line (TR 24)
6690000.0 2640000.0 ( 0.395) 5180000.0 ( 0.774) Char in 20/40/20 line (6x13, TR 10)
1160000.0 351000.0 ( 0.303) 2080000.0 ( 1.793) Char16 in 7/14/7 line (k14, k24)
8310000.0 2880000.0 ( 0.347) 15600000.0 ( 1.877) Char in 80-char image line (6x13)
7510000.0 2550000.0 ( 0.340) 12900000.0 ( 1.718) Char in 70-char image line (8x13)
5650000.0 2090000.0 ( 0.370) 11400000.0 ( 2.018) Char in 60-char image line (9x15)
2000000.0 670000.0 ( 0.335) 7780000.0 ( 3.890) Char16 in 40-char image line (k14)
823000.0 270000.0 ( 0.328) 4470000.0 ( 5.431) Char16 in 23-char image line (k24)
8500000.0 3710000.0 ( 0.436) 8250000.0 ( 0.971) Char in 80-char image line (TR 10)
2620000.0 983000.0 ( 0.375) 3650000.0 ( 1.393) Char in 30-char image line (TR 24)
This is our old friend x11perfcomp, but slightly adjusted for a modern reality where you really do end up drawing billions of objects (hence the wider columns). This table lists the performance for drawing a range of different fonts in both poly text and image text variants. The first column is for Xephyr using software (fb) rendering, the second is for the existing Glamor GL_POINT based code and the third is the latest GL_QUAD based code.
As you can see, drawing points for every lit pixel in a glyph is surprisingly fast, but only about 1/3 the speed of software for essentially any size glyph. By minimizing the use of the CPU and pushing piles of work into the GPU, we manage to increase the speed of most of the operations, with larger glyphs improving significantly more than smaller glyphs.
Now, you ask how much code this involved. And, I can truthfully say that it was a very small amount to write:
Makefile.am | 2
glamor.c | 5
glamor_core.c | 8
glamor_font.c | 181 ++++++++++++++++++++
glamor_font.h | 50 +++++
glamor_priv.h | 26 ++
glamor_text.c | 472 +++++++++++++++++++++++++++++++++++++++++++++++++++++
glamor_transform.c | 2
8 files changed, 741 insertions(+), 5 deletions(-)
Let's Start At The Very Beginning
The results of optimizing text encouraged me to start at the top of x11perf and see what progress I could make. In particular, looking at the current Glamor code, I noticed that it did all of the vertex transformation with the CPU. That makes no sense at all for any GPU built in the last decade; they've got massive numbers of transistors dedicated to performing precisely this kind of operation. So, I decided to see what I could do with PolyPoint.
PolyPoint is absolutely brutal on any GPU; you have to pass it two coordinates for each pixel, and so the very best you can do is send it 32 bits, or precisely the same amount of data needed to actually draw a pixel on the frame buffer. With this in mind, one expects that about the best you can do compared with software is tie. Of course, the CPU version is actually computing an address and clipping, but those are all easily buried in the cost of actually storing a pixel.
In any case, the results of this little exercise are pretty close to a tie — the CPU draws 190,000,000 dots per second and the GPU draws 189,000,000 dots per second. Looking at the vertex and fragment shaders generated by the compiler, it's clear that there's room for improvement.
The fragment shader is simply pulling the constant pixel color from a uniform and assigning it to the fragment color in this the simplest of all possible shaders:
uniform vec4 color;
void main()
gl_FragColor = color;
This generates five instructions:
Native code for point fragment shader 7 (SIMD8 dispatch):
FB write target 0
0x00000000: mov(8) g113<1>F g2<0,1,0>F { align1 WE_normal 1Q };
0x00000010: mov(8) g114<1>F g2.1<0,1,0>F { align1 WE_normal 1Q };
0x00000020: mov(8) g115<1>F g2.2<0,1,0>F { align1 WE_normal 1Q };
0x00000030: mov(8) g116<1>F g2.3<0,1,0>F { align1 WE_normal 1Q };
0x00000040: sendc(8) null g113<8,8,1>F
render ( RT write, 0, 4, 12) mlen 4 rlen 0 { align1 WE_normal 1Q EOT };
As this pattern is actually pretty common, it turns out there's a single instruction that can replace all four of the moves. That should actually make a significant difference in the run time of this shader, and this shader runs once for every single pixel.
The vertex shader has some similar optimization opportunities, but it only runs once for every 8 pixels — with the SIMD format flipped around, the vertex shader can compute 8 vertices in parallel, so it ends up executing 8 times less often. It's got some redundant moves, which could be optimized by improving the copy propagation analysis code in the compiler.
Of course, improving the compiler to make these cases run faster will probably make a lot of other applications run faster too, so it's probably worth doing at some point.
Again, the amount of code necessary to add this path was tiny:
Makefile.am | 1
glamor.c | 2
glamor_polyops.c | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++--
glamor_priv.h | 8 +++
glamor_transform.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++++++++
glamor_transform.h | 51 ++++++++++++++++++++++
6 files changed, 292 insertions(+), 4 deletions(-)
Discussion of Results
These two cases, text and points, are probably the hardest operations to accelerate with a GPU and yet a small amount of OpenGL code was able to meet or beat software easily. The advantage of this work over traditional GPU 2D acceleration implementations should be pretty clear — this same code should work well on any GPU which offers a reasonable OpenGL implementation. That means everyone shares the benefits of this code, and everyone can contribute to making 2D operations faster.
All of these measurements were actually done using Xephyr, which offers a testing environment unlike any I've ever had — build and test hardware acceleration code within a nested X server, debugging it in a windowed environment on a single machine. Here's how I'm running it:
$ ./Xephyr -glamor :1 -schedMax 2000 -screen 1024x768 -retro
The one bit of magic here is the '-schedMax 2000' flag, which causes Xephyr to update the screen less often when applications are very busy and serves to reduce the overhead of screen updates while running x11perf.
Future Work
Having managed to accelerate 17 of the 392 operations in x11perf, it's pretty clear that I could spend a bunch of time just stepping through each of the remaining ones and working on them. Before doing that, we want to try and work out some general principles about how to handle core X fill styles. Moving all of the stipple and tile computation to the GPU will help reduce the amount of code necessary to fill rectangles and spans, along with improving performance, assuming the above exercise generalizes to other primitives.
Getting and Testing the Code
Most of the changes here are from Eric's glamor-server branch:
git://people.freedesktop.org/~anholt/xserver glamor-server
The two patches shown above, along with a pair of simple clean up patches that I've written this week are available here:
git://people.freedesktop.org/~keithp/xserver glamor-server
Of course, as this now uses libepoxy, you'll need to fetch, build and install that before trying to compile this X server.
Because you can try all of this out in Xephyr, it's easy to download and build this X server and then run it right on top of your current driver stack inside of X. I'd really like to hear from people with Radeon or nVidia hardware to know whether the code works, and how it compares with fb on the same machine, which you get when you elide the '-glamor' argument from the example Xephyr command line above.


text:
The intersection of Southern Ave. at Alma School Rd. will be closed from 8pm Friday 9/19 through 5am Monday 9/22 http://t.co/UUDrLQ2SS2
Sep 18
RT @Davidthe29th: 184 bowls thrown today at the bowl-a-thon for empty bowls #clayclub @DobsonHigh @mesacc http://t.co/BebRWCKD6x
Sep 17
The deadline to apply for Fall 2014 graduation is November 1. Apply today at mesacc.edu/graduation.
Posted on January 7, 2013 by Sally Mesarosh
Tips from MCC's Edward Callirgos.
Arizona Republic. December 12, 2012
mesacc.edu | 480-461-7000 | © 2014 Mesa Community College | A Maricopa Community College The Maricopa County Community College District is an EEO/AA institution and an equal opportunity employer of protected veterans and individuals with disabilities.

subset: commoncrawl


text:
This gallery of Pitchfork Festival denizens provides definitive proof that hipsters are now wearing old NBA jerseys at an even more obnoxious rate than previously imagined. But you probably haven't heard of these players, they're pretty obscure. [The Faster Times]
Hipsters Are Wearing Your Old NBA Jerseys
Pending approval David Matthews


text:
Research on Post-Evaluation of Oilfield Ground Engineering Project
Based on the research results of the scholars from domestic and overseas, we construct a evaluation index system for post- evaluation of oilfield ground engineering project focusing on the characteristics of the ground engineer project and combining the characteristics of the development of oilfield. The system includes 3 primary indicators, such as pre-project, 8 secondary indicators and 35 tertiary indicators. Multistage fuzzy evaluation with the combination of quantitative analysis qualitative analysis and degree of success method are used for Post-evaluation of oilfield ground engineering project which may lead to the reference of the decision-making of investment and management for oilfield ground engineering project.
Key words: Oilfield ground engineering; Postevaluation; Evaluation index; Multistage fuzzy evaluation
Full Text:PDF INDEXED/INCLUDED/ARCHIVED
WANG, Chunguang (2002). Post-Evaluation of Oil and Gas Fields Construction Project. Statistics and Decision, (1), 53-58.
WANG, Yue (2004). Post-Evaluation of Oil and Petrochemical Investment Projects and Case Analysis. Technology Economics, (10), 34-36.
JIANG, Zhihua (2006). Primary Study on Post-Project Analysis of Marine Oilfield Projects. Environmental Protection of Oil & Gas Fields, (3), 122-127.
Yu, Shuqing, & Liu, Chunyang (2007). Study on Comprehensive Assessment Method and Indexes System of Post-Evaluation for Pipeline Construction Projects. Petroleum Engineering Construction, (12), 558-602.
Gu, Xin, & Deng, Kelin (2008). Study on Post-Evaluation of Oilfield Construction Projects. Gansu Science and Technology, 8(15), 66-68.
Guo, Peng, & Li, Zhiyong (2010). Post-Evaluation Theories and Methods Research of International Cooperation in Oil and Gas Exploration and Development Projects. Project Management Technology, 5(5), 66-69.
Huang, Xunan (2010). Post-evaluation Index Systems and Quantified Evaluation of Oil and Gas Exploration Projects. International Petroleum Economics, 1(1), 56-58.
Liu, Hong, Wu, Tingting, & Fang, Guohua (2010). Application of Multi-Level Grey Evaluation Method in Post Evaluation of Urban Flood Control Projects. Journal of Economics of Water Resources, (3), 5-7.
DOI: http://dx.doi.org/10.3968%2Fj.mse.1913035X20120603.Z0137
- There are currently no refbacks.
If you have already registered in Journal A and plan to submit article(s) to Journal B, please click the CATEGORIES, or JOURNALS A-Z on the right side of the "HOME".
We only use three mailboxes as follows to deal with issues about paper acceptance, payment and submission of electronic versions of our journals to databases:
firstname.lastname@example.com; email@example.com; email@example.com
Copyright © 2010 Canadian Research & Development Centre of Sciences and Cultures
Address: 730, 77e AV, Laval, Quebec, H7V 4A8, Canada
Telephone: 1-514-558 6138
Http://www.cscanada.net Http://www.cscanada.org


text:
Sorry! The position you're looking for is no longer available. Check out other Non-profit internships in New Hampshire below.
Results 1 — 3
Sort By:
Public Relations & Marketing Internship
Lil' Iguana's Children's Safety Foundation — Nashua, NH
Lil Iguanas Childrens Safety Foundation is looking for an intern to assist as our organization expands. The Public Relations & Marketing intern in our Nashua office will be responsible for a variety o…
Application Deadline: Available Year-round
Marketing - Web Design Internship
The Town of Raymond — Raymond, NH
The Dudley-Tucker Library is probably the quaintest library in the region. We are proud of our constant changing collection and are programs that are available to the public. People find us and are no…
Application Deadline: Available Year-round
Marketing and Entreprenurial Small Business INternship
Project VetCare, Inc — Hanover, NH
Organization Description: Nonprofit Organization with its headquarters in downtown Hanover, New Hampshire. Helping Veterans Every Step of the Way ® is our Logo. We are doing community organizing with …
Application Deadline: Available Year-round


text:
Dundee ChannelInternet TV videos
Powered by Max Banner Ads
A taste of France for Dundee restaurantPosted onNovember 7, 2011
A taste of France for Dundee restaurant
A continental cultural event regularly held within French eateries is heading to Dundee as part of Dundee Science Festival.
Bon Appetit is holding Café Philosophie de Science on both Saturday 5 and 12 November 2011. Café Philosophie is a well-established social, gourmet and intellectual event in many French cities.
The cafe will be officially opened on 5 November by Dr Beth Lord, Philosophy Lecturer at the University of Dundee who will explore 'God and Science'.
The following Saturday, Professor Michael Wheeler from the University of Stirling will stimulate the neurons on a subject entitled "Human intelligence versus artificial intelligence – have the machines gone mad?"
John Batchelor, Owner commented, "We are delighted to be taking part in Dundee Science Festival as science is such a major part of the city's thriving economy and our modest contribution recognises this. Many Dundee scientists and their visitors from all around the world dine in Bon Appétit so we are doubly pleased to be participating and bringing a taste of the continent to our fabulous city."
Powered by Max Banner Ads


text:
55.84+0.06+0.10%Today's Close | 55.84 unch After hours
|NASDAQ national market
|VeriSign Inc
|Internet Content & Information
|VeriSign Inc is a Delaware Corporation, incorporated on April 12, 1995. The Company is a provider of internet infrastructure services for the networked world. The Company provides domain name registry services and infrastructure assurance services. The Company operates one reportable segment: Naming Services. It consists of Registry Services and Network Intelligence & Availability (NIA) Services. Registry Services operates the authoritative directory of all .com, .net, .cc, .tv, and .name domain names and the back-end systems for all .gov, .jobs and .edu domain names. NIA Services provides infrastructure assurance services to organizations and is comprised of Verisign iDefense Security Intelligence Services, Managed Domain Name System Services, and Distributed Denial of Service Protection Services. The Companys operations infrastructure consists of three main Company-operated secure data centers in Dulles, Virginia; New Castle, Delaware; and Fribourg, Switzerland as well as approximately 70 globally distributed resolution sites, which includes both regional resolution sites and supersites. These secure data centers operate 24-hours a day, supporting its business units and services. The Company offers promotional marketing programs for its registrars based upon market conditions and the business environment in which the registrars operate. The Company markets its NIA Services through multiple distribution channels, including direct sales and indirect channels. The Company competes with numerous companies in each of the Registry Services and NIA Services businesses. The Company faces competition in the domain name registry space from other gTLD and ccTLD registries that are competing for the business of entities and individuals that are seeking to establish a Web presence. The Company also faces competition from service providers that offer outsourced domain name registration, resolution and other DNS services to organizations that require a reliable and scalable infrastructure. Among the competitors are Neustar, Inc., Afilias Limited, ARI Registry Services. The Company is subject to income taxes in both the U.S. and numerous foreign jurisdictions. As a public company, it is subject to the rules and regulations of the SEC.
Copyright © 2014 Microsoft. All rights reserved.
Fundamental company data and historical chart data provided by Morningstar Inc. Real-time index quotes and delayed quotes supplied by Morningstar Inc. Quotes delayed by up to 15 minutes, except where indicated otherwise. Fund summary, fund performance and dividend data provided by Morningstar Inc. Analyst recommendations provided by Zacks Investment Research. StockScouter data provided by Verus Analytics. IPO data provided by Hoover's Inc. Index membership data provided by Morningstar Inc.
You're not signed in
You're not signed in to MSN Money, so you're seeing the Watchlist that is tied to your computer. For a more consistent Watchlist experience, sign in to MSN Money. Learn more
Sponsored by:
[BRIEFING.COM] The stock market finished an upbeat week on a mixed note. The S&P 500 shed less than a point, ending the week higher by 1.3%, while the Dow Jones Industrial Average (+0.1%) cemented a 1.7% advance for the week. High-beta names underper ... More
Sponsored by:


text:
から 15/04/2014 » へ 31/10/2014Fiesole Exhibition Fiesole and the Longobards pieces
This year, the Museo Civico Archeologico di Fiesole is 100 years old.
With an exhibition celebrating this important anniversary, exhibition, setting out the artifacts Longobardi found in Fiesole and in the excavations conducted by the[...]
から 01/08/2013 » へ 31/12/2014Florence city Card: museums+bus
The Firenze Card is valid for 72 hours and provides you the admission only once to all museums of the Circuit, located in Florence. It entitles you to visit permanent collections, exhibitions and other activities held in these museums. You will[...]
から 19/08/2014 » へ 04/12/2014Fabi, Silvestri, Gazzè Florence 2014
After the huge success of "Life is Sweet" - the first single from the supergroup which debuted at the top of the iTunes charts - will be released in September an album written, produced and performed by the three artists[...]
から 09/10/2014 » へ 19/10/2014Culture Week in Tuscany: events in Florence
The first edition of the Culture Week in Tuscany COOLT will be held in October from 9 to 19, will be organized a series of events scattered in Tuscany and Florence
Among the initiatives proposed there will be guided tours in museums,[...]


text:
SPOKANE, Wash. - Reporting a crime to authorities is the first step in helping catch criminals.
But how do you know what to report and to whom?
Authorities say they want you to report crime, but we've seen and heard different phone numbers when it comes to how to do that.
Call 911 in case of an emergency if you're in immediate danger or witnessing something happening where you need police right away call 911.
Here in Spokane there's also CrimeCheck. That number is 456-2233.
This is the number to call to make a police report if our car has been broken into, or you've been burglarized.
Now the Spokane police department has brought back it's tip line that's 242-TIPS.
This allows you to help police do their job.
Police officers say the bottom line is that they want to hear from you.
They say they can't do their job unless you call and tell them what's happening in your neighborhood.
Calling 911 will work no matter where you are. CrimeCheck works city and county wide, and the Spokane tip line are for crimes within the city of Spokane.


text:
Toni Braxton's foreclosed Atlanta home up for sale
Story | Nov 12, 2012 | 12:51 PM
Toni Braxton's foreclosed Atlanta home up for sale
Story | Nov 12, 2012 | 12:51 PM
Can Toni Braxton un-break her career?
Story | Apr 10, 2011 | 12:34 PM
'Dancing with the Stars' cast revealed
Blog | Aug 25, 2008 | 4:22 PM
ABC's hit show Dancing with the Stars is back in a couple weeks, and the new cast includes Maryland native Toni Braxton (left); daytime television's Susan Lucci, who is known for her portrayal of the character Erika Kane on All My...
'Dancing with the Stars': Low scores all around
Blog | Sep 23, 2008 | 4:22 PM
Unlike millions and millions of Americans, I'm not a huge Dancing with the Stars fan. In fact, I'm not a fan at all (unlike my dad). I've only watched a few minutes here and there. I can't believe another season...


text:
The next piece has fallen. The Miami Marlins have agreed to trade SS/3B Hanley Ramirez and RP Randy Choate to the Los Angeles Dodgers for SP Nathan Eovaldi and RP Scott McGough. This trade was finalized in the early hours Wednesday morning and came to a surprise to me, and many others.
The former face of the franchise has been showcasing another down year hitting wise, .248/14/48, which isn't much better than his 2011 numbers.
As a fan and Hanley Ramirez supporter, this is a tough trade to see. Players of Hanley's caliber shouldn't be hitting like he's hitting or be traded for what he has been traded for. Nathan Eovaldi is a quality young pitcher in my opinion, but to trade someone with all the credentials that Hanley has, it's a bummer. Sometimes things just don't work out and some moves may be necessary to rejuvenate or help restructure a ball club.
Lets talk about some positives in this trade, eh?
RHP Nathan Eovaldi, headline return in trade, is only 22 years old and has posted some quite impressive minor league numbers in his career showcasing a 3.28 ERA. His fastball sits in the mid 90′s and can occasionally reach the upper 90′s. He's been in the MLB for a few starts with the Dodgers and has a 1-6 record after 10 starts to go along with his 4.15 ERA. He should be in the Marlins rotation sometime soon if not placed there immediately.
Another positive in this trade is that the Dodgers WILL obtain the rest of Hanley Ramirez's salary for the next two seasons which is nearly $40 million in contract obligations. This trade allows the Marlins to clears about $20 million of the books for next seasons payroll.
Was this trade rushed? Did the Marlins feel pressured to trade Hanley Ramirez now? Should they have waited? I don't know. Part of me feels that the Marlins should have waited until the off season to gauge market and see if any other team would have been interested. Apparently the Marlins were more focused on getting Hanley's salary off the books instead of acquiring some top prospects.
The next big piece to be traded in my opinion is Josh Johnson. The Rangers need a SP and the Marlins need a 3B. I think it would be natural that the Marlins try to work out a trade for Rangers 3B/1B prospect Mike Olt along with others for Josh Johnson. It might even take more to acquire Johnson as I hear the asking price is extremely high.
Three Miami Marlins traded. When will the next one be?


text:
Been awhile since I actually came here and wrote anything so thought I'd ease into it today cause next week is gonna, well, be a bit busier.
I spend a lot of time with photoshop. Learning, playing and creating so I have over the last couple of years accumulated more than a few links to some pretty cool stuff.
Now, as a former commercial photgrapher, leaving the dark room behind, not having to actually load film into holders and camera backs it's been a bit strange. I like film. Though finding it is getting harder and harder and setting up a darkroom and sniffing all the developers and stop baths can't be that healthy.
I'm finally making the move to digital, though somewhat hesitantly. What I've found is it's pretty incredible what you can do with Photoshop. Not only retouching your photos but creating backgrounds, images etc for your websites as well as some cool effects that were only possible with spending hours in the darkroom and going through more than a few sheets of paper.
So what I thought I'd do is pop in some of my fav spots to get photoshop info tutorials, tips, and general cool stuff..
Here we go.
Creating a vibrant design with photoshop
This one is a step by step to making an image that is more than the photograph. Making it standout and well, be more vibrant. Simple.
Here's a vid from iceflowstudios on creating web 2.0 icons that will walk you through the steps to create your own.
Looking for help with making that cool background image for your site or maybe your profile page…. here's one on how to create your own paper type background
Cool Paper Background creation
Because brushes are also a large part of the design aspect of photoshop you might like some of these. Over 1300 different brushes to download and test out.
Or maybe you'd like to try your hand out in making your own to use or share . In that case this might be just the right thing for you. From www. bitbox.com
A handy tool for all is this site with a set of cheat sheets to help you get more done with less aggro.
14 Most Useful Web Design Cheat Sheets
That's it for now. I'll put some more up soon.


text:
An argument that began over a child's balloon could send two men to prison for a very long time. They're accused of opening fire on a house hunter as she was getting ready to show a property last year in Clarksville.
Following a previous guilty plea by the accused shooter to a charge of aggravated assault, the man believed to be his accomplice decided to try his fate with a jury trial.
On Wednesday, the jury found 22-year-old James Bagwell guilty of two counts of second-degree attempted murder as well as three other reckless endangerment charges.
Things turned violent after a 2-year-old got her hands on the balloon tied to a home that agent Tammy Earp planned to show to an interested couple in September 2012.
When Earp's boyfriend told the child to put it back, an argument ensued with some of the residents along Barkwood Drive.
A Ford Thunderbird with five men inside soon arrived and tried to block Earp's path. As the men exited the Thunderbird, officers said one of them started shooting.
Handgun rounds struck the door and hood of the woman's car as well as a nearby house.
Earlier this year, Detarius Curry, 20, pleaded guilty to a lesser charge of aggravated assault in the shooting and faces a sentence of eight to 12 years in prison.
Sentencing for Bagwell has not yet been set.
Copyright 2013 WSMV (Meredith Corporation). All rights reserved.
1960 Union Ave.
Memphis, TN 38104
(901) 726-0555
FCC Public File
EEO Report
Closed Captioning


text:
You are currently viewing the beta version of the new AMM site.
Click here
to return to the current site.
Nov 20, 2012 | 05:50 PM
Valmont Industries,
Earl Foust,
Katana Summit,
transmission towers,
wind towers,
Kevin Strudthoff,
acquisition of manufacturing assets
CHICAGO A Nebraska coil coater, tubing producer and manufacturer of metal-intensive utility structures and irrigation equipment Valmont Industries Inc. has acquired the manufacturing assets of Katana Summit LLC. Omaha-based Valmont said the purchase includes a 300,000-square-foot plant in Columbus, Neb., which the company will reconfigure from producing wind towers to producing steel transmission structures for the utility industry, Valmont said in a statement Monday. ....
To access AMM's full content, please log in below. If you do not have an AMM account, we invite you to take a free trial or subscribe below.
Access to amm.com editorial content is granted only to paid subscribers and trialists. If you do not have an active account in your own name, please either subscribe or take a trial and you will have instant access to amm.com content. Sharing your login credentials with individuals who are not subscribers represents a violation of AMM copyright.
Every morning, every minute no matter how often you follow the markets, there's an AMM subscription to fit your needs.
Not sure if you are ready to invest in a subscription right now? Take a free, no-obligation trial. Start your free trial today.
Are you stocking more inventory today than 18 months ago?
We recognize that it takes time to learn to make good, quality steel. And we're not underestimating the need to do that and do it right.
--Mark Bula, Big River Steel


text:
When I travel around the country, many of you say you'd like to know what the new health care law means for you — and for everyone over 50.
Get ready for some good news!
The Affordable Care Act (ACA) is already making it easier for people to get, keep and afford health care benefits. It helps protect consumers from discriminatory insurance practices, and it strengthens coverage for people who are on Medicare.
Subscribe to the AARP Health Newsletter
Many benefits are already in effect:
- A number of insurance plans, including Medicare, now cover more preventive services, such as colonoscopies and mammograms, with no out-of-pocket costs to you.
- The law has been gradually closing the Medicare Part D coverage gap, the "doughnut hole." In 2013, if you reach this gap, you receive a 52.5 percent discount on your brand-name prescriptions and a 21 percent discount on generics. Savings increase each year until the gap is closed in 2020.
- Insurers can't drop your coverage even if you become sick or disabled.
- Parents can keep their adult children on their health insurance until they reach age 26.
- Plans can't limit how much they pay for your lifetime medical costs. Beginning January 2014, the law also prohibits annual limits on the dollar amount of coverage for an individual.
- Plans can't deny coverage for children under age 19 who have preexisting conditions. The provision extends to people of all ages in 2014.
- Health insurance marketplaces, often called exchanges, will open in every state, making it easier for people without insurance, small businesses and self-employed workers to buy private health insurance. Coverage begins January 2014, but by this October, any American can compare plans and buy health insurance online.
- The ACA is also making Medicare more secure through cost savings that extend the program's financial life by several years. For the latest information on the ACA and for a personalized guide to how the law works for you, try the interactive tool on our aarp.org website.
AARP listened to you, our members, and fought to make your health care benefits — and Medicare — stronger. Now we're here to help make the new law easier to understand. You're not alone.
Robert Romasco is the president of AARP.
You May Also Like
- Visit AARP's HealthLawFacts.org for detailed information about the health care law
- What's the "Medicaid Expansion"?
- Join AARP: Savings, resources and news for your well-being
- More health information you can use


text:
Trim Fit Dress Shirt (Online Only)
|Item # 601461
(Available every day, from 7am to 1am Eastern.)
Details & Care
Rich coloring defines a modern dress shirt furnished with a wide spread collar and mitered, adjustable button cuffs.
- French placket.
- Back yoke.
- Curved hem.
- Cotton; machine wash.
- By 1901; imported.
- Men's Furnishings.


text:
Coping with end of semester stress
May 3,2012
By Dajana Gudic
As the semester is drawing to a close, many students are overwhelmed trying to study for exams, finish their assignments before due dates and complete their classes successfully.
Too much worrying leads to stress and anxiety, which may cause other health problems. Managing stress may be very challenging, but psychologists have some simple steps to follow to aid in calming down and decreasing one's stress level.
Darla Sedlacek, a psychologist from Lakewood, works with people of all ages providing them with several counseling services.
When it comes to managing stress, she suggested a couple of easy tips.
"Taking some deep breaths in a moment when you notice that you feel tight in your chest, such as right before an exam starts or while studying, may help students feel calm," said Sedlacek.
"For some, it helps to say cue words or phrases as they take a breath, something that is meaningful to them personally. An example might be, 'I'm doing my best,' or 'I am strong, I'm getting through this.' The more consistently these tools are used, the easier it gets and can become automatic. Practice makes improvement," she added.
Managing time may seem hard for students, but limiting one's involvement in too many activities and focusing primarily on school will give you more time for school work and studying and help reduce stress.
Jelena Jandric, a CSU social work major learned to manage her stress by being involved in only one or two student organizations. She also said, " Getting things done on time or earlier, rest and my belief in God helps me through everything. I give my worries and stress to Him and He gets me through everything smoothly," Jandric said.
To avoid stress, keep your life balanced and focus on one task at a time. Take a break during your hard studying and allow yourself to watch your favorite show, spend time with friends or take a nap.
Matthew Hernandez, a sophomore majoring in Dramatic Arts said he manages stress by finding time for other activities.
"During the week I set time aside to play video games, talk with my friends, and be with family," said Hernandez.
Eating a healthy diet and being active are known strategies of coping with stress.
"I work out, listen to music, do things to keep my mind at ease and things that just allow me to have a good time," said Cliff Phoenix, a CSU sophomore majoring in Education,
Exercising is a proven factor that releases stress. Working out relieves muscle tension and makes you feel good. After a hard workout, many feel accomplished and happy.
CSU senior Alex McKinley is one of them.
"During school I try to go to the gym every day and lift. I can clear my mind and take out my stress on the weights," McKinley said.
Barbara G. Feinberg, Life Coach & Psychotherapist, whose Ohio office is located in Cleveland Heights, offers many services to her clients. Among them is anxiety, panic attack, and stress counseling.
She also thinks that breathing exercises are very affective for releasing stress.
"I think breathing is the most important thing to remember. Now, of course, we all breathe. I'm talking, however, about nice easy deep breaths, especially when we feel our bodies tense up," said Feinberg.
She pointed out that remembering to take easy breaths throughout the day, not only when we are faced with a particularly stressful moment, is very important. That way, the students can reduce their overall level of tension, so the expected stressors are less intense.
"Think of a guitar string wound very very tightly - when it's plucked, it could break. If it's wound a little less tightly, the likelihood of breaking is less," she added.
To avoid anxiety and stressful thoughts the person first needs to think about the source where all the problems come from. "What may possibly help is for one to attempt to examine what one's anxiety is about, and what connections it has to previous examination situations in one's life," said Michael D. Colman a psychiatrist from Bloomfield Hills, Mich. who has been in practice for more than 30 years.
If you feel lost and need counseling, CSU counseling center is always there to help. They can be reached at 216-687-2277.


text:
The Taj Mahal Palace, Mumbai Magnificiently Restored and Joyfully Re-opened
The Taj Mahal Palace, Mumbai welcomes guests once again
When we open the heritage wing and do whatever it takes to get back its old glory; we will send a stronger message – a message that strongly resonates among all of us that we can be hurt, but we cannot be knocked down
Mr Ratan Tata, Chairman,
Indian Hotels Company Ltd, 21st December 2008
Mumbai, August 13th, 2010 /PRNewswire/ — As the country brings in India's 64th Independence Day, the iconic Taj Mahal Palace re-opens its doors to the magnificently restored Palace wing in Mumbai.
Mr. Ratan Tata's promise made to the world in 2008 has been a compelling force and a testament to the Taj Group's commitment to resurrecting India's original luxury hotel. And as promised the hotel will continue to benchmark the best in hospitality and service.
Speaking at a preview press conference, Mr. Raymond Bickson, Managing Director, Indian Hotels Company Limited, said, "Today, we have fulfilled our promise of rebuilding the Taj to its former glory. The Taj Mahal has always reinvented itself and its storied past which makes it the icon that it is. The palace wing has been lovingly and painstakingly restored, and we will now offer our guests an even more customized experience. It is a befitting tribute to the spirit and resilience that is The Taj Mahal Palace, Mumbai; and the beginning of a new chapter in the history of the hotel. As India celebrates its 64th year of independence, we warmly welcome our guests, old and new to the Taj Mahal Palace Hotel."
An extensive restoration by internationally acclaimed designers, Lissoni Associati, Milan, BAMO San Francisco, DesignWilkes, Malaysia and James Park Associates, Singapore was carried out. The Palace accommodations that is, the Taj Club rooms, Luxury Grande rooms, themed Grand Luxury Suites are graciously appointed spaces filled with precious art, redolent with luxury and state-of-the-art technology befitting the architectural magnificence of the building making it an unforgettable experience that encapsulates a slice of history, legend & romance.
The reinvigorated Palace wing comes with a warm arrival arrangement and stunning stay experiences. All our guests in the Palace wing will experience the highly attentive and personalized "Palace Butler Service" where the butler will discreetly and efficiently, guide guests to the pleasures that lie within and outside the walls. The Palace Lounge will be a private retreat; exclusively for residents of the Palace wing, for a cup of perfectly brewed tea or coffee; an evening cocktail or after hour chocolate and cognac. Guests can look forward to an indulgent customized bath experience, in the most luxuriously appointed bathrooms. High end technology and interactive multimedia systems at the touch of a button ensure that guest's experiences are wired for efficiency and comfort. Taj Club rooms and suites come with chauffeur-driven luxurious Jaguar transfers.
Even when the hotel was closed, renowned world leaders and prominent dignitaries continued to stay with us at the Tower wing of the hotel. With the reopening of the Palace wing, we look forward to receiving once again all those who have supported us and considered The Taj Mahal Palace as a home away from home. Through the last couple of years, the hotel has also been the quintessential venue for landmark events and celebrations. The restaurants and eateries which have been renovated, including Sea Lounge, Golden Dragon and the Taj Ballroom (design by LTW) and the Harbour Bar and Wasabi by Morimoto (design by the Rockwell Group) are accompanied by inspired cuisine from our team of acclaimed chefs.
The entire staff of the hotel shared a special moment with the Chairman Mr. Ratan Tata and the Vice Chairman, Mr. R K Krishnakumar and our Managing Director MR. Raymond Bickson.
The 15th of August is a day that India made her tryst with destiny. Echoing the same sentiments, the staff and management of The Taj Mahal Hotel, Mumbai, make their tryst with destiny and have pledged to reinvent the magic that made the Taj the institution it is.
The staff and management of The Taj Mahal Palace, joined hands with the Dabbawalas in a spirit of celebration and as a token of giving back to the city to share a meal with the less privileged in certain identified institutions... Dabbawalas are intrinsic to the city of Mumbai, and are indeed the nerve center and lifeline of the city, ensuring that in rain, hail, snow or storm – no one goes hungry. With their help, we will be able to share our happiness with our little friends.
On December 16, 1903, the Taj opened its doors to its first 17 guests. Over the years, the hotel has played perfect host to Maharajas and Princes, presidents & legends, performers and world figures offering them the ultimate in luxury, fine dining and impeccable service. It was all made possible by the love and support that all our guests wished upon us. A wish that finally finds freedom as the Taj welcomes you once more.
For access to press event images / videos and press documents, please visit us on - www.vccpl.in/taj
For more details on the Celebration Offer, please visit - www.tajhotels.com
To know more about the Press Conference please visit us on – www.tajhotels.com/Taj-Mahal-Palace/Press-Conference
You can now follow us on Twitter - twitter.com/TajMahalMumbai and Facebook - www.facebook.com/TajMahalMumbai
About Taj Hotels Resorts and Palaces
Established in 1903, Taj Hotels Resorts and Palaces is one of Asia's largest and finest group of hotels, comprising 67 hotels in 43 locations across India with an additional 16 international hotels in the Maldives, Malaysia, Australia, UK, USA, Bhutan, Sri Lanka, Africa and the Middle East. From world-renowned landmarks to modern business hotels, idyllic beach resorts to authentic Grand palaces, each Taj hotel offers an unrivalled fusion of warm Indian hospitality, world-class service and modern luxury. The Taj, a symbol of Indian hospitality, completed the centenary of its landmark hotel, The Taj Mahal Palace, Mumbai. Taj Hotels Resorts and Palaces is part of the Tata Group, India's premier business house.
For Further information please contact Vaishnavi Corporate Communications, Mumbai:
Tarini Mathur (firstname.lastname@example.com) / Swati Sundareswaran (email@example.com) / Deepika Sinha (email@example.com) or at 022-66568787


text:
Key Requirements Of GS-42 Certification
There are several requirements that must be met before an in-house or contract cleaning service can earn GS-42 certification.
A complete list is available at www.GreenSeal.org.
Some of the more general requirements include:
- Written operating procedures that are available to all cleaning personnel and clients
- A building-specific green cleaning plan
- A communication strategy for all cleaning personnel, building management and occupants, as well as a system for facilitating feedback from all stakeholders
- Cleaning schedules that carefully address all of the cleaning needs of a facility
- A detailed description of green cleaning implementation throughout the facility, including heavily used locations such as entryways and foodservice areas
- Easy-to-understand directions for cleaning professionals written in appropriate languages or utilizing graphic presentations that cover all of the facility's cleaning tools, machinery and products
- Tactics to address the special cleaning needs of vulnerable populations such as young children or the elderly
- Using only green-certified cleaning chemicals, as well as vacuum cleaners that meet the minimum requirements of the Carpet and Rug Institute's (CRI) Seal of Approval (SOA) program
- Using a chemical measuring and dilution system to limit human exposure to cleaning chemicals and facilitate proper dilution while eliminating waste.


text:
Whitney's Q & A
Favorite Sport/Team
basketball ORLANDO MAGIC
Go-to karaoke song
whitney i wanna dance
My first job
body shop clothing store
Piercings/Tattoos (How many? Where?)
none lol just ears...
Mac or PC?
Nintendo, Xbox 360, PS3, or don't game?
What fun fact, talent or superpower of yours should guys know about?
lol my boobs can dance.
What's the most memorable pick up line you've ever heard?
tell your mom thank you!!!why? for creating your mom that created you...
What's the most unusual place you've ever hooked up? How'd it go?
macy department store
What's in your purse or pocket right now?
lip gloss duh!!!
What do you feel most comfortable wearing?
t shirt and panties ...its the truth
Would you rather have boring sex all the time or an amazing romp once a year?
who wants boring sex EVER!!!!Definitely want that once a year romp....
If you could do a shot of Jose Cuervo with anyone -- dead or alive -- who would it be?
Michael Ealy all day!!!


text:
Access to Understanding Award Ceremony
Mon 11 Mar 2013, 18.30-20.30
Conference Centre, British Library
Free, booking essential
Access to Understanding is a new science-writing competition for PhD students and early career researchers with an interest in communicating science to the public. It aims to raise awareness of the importance of opening up the results of scientific research, so that they are accessible to everyone.
Winning entrants will be recognised at this award ceremony where a prestigious panel including: David Ardron (patient advocate), Tracey Brown (Sense about Science), Stephen Curry (Imperial College London), Simon Denegri (INVOLVE), Sharmila Nebhrajani (Association of Medical Research Charities) and Peter Rodgers (eLife Journal) will talk about why public engagement and communication of science are important. Award-winners will set a piece of cutting-edge research in context so that anyone can appreciate why the research was done and its potential importance to improving our understanding and/or human health. Refreshments will be provided.
Organised in association with Europe PubMed Central. For more information on the competition see http://EuropePMC.org/ScienceWritingCompetition


text:
Order Line 0330 123 4123
Order Line 0330 123 4123
Product Code: 199817
Practical and durable wood-effect toilet seat with robust soft-close chrome-effect hinges
Practical and durable wood-effect toilet seat with robust soft-close chrome-effect hinges
"I have tried a lot of toilet seats in my life and I can safely say, without fear of contradiction, that this one is just like any other. It works in the same way which I am sure you are familiar with. It looks like it's made of wood and arrived promptly. The hardest thing was ordering it through Wickes website (Sorry, I am not actually allowed to discuss anything other than the actual seat). I look forward to many more 'sessions' without issues (!) on my new seat."
"Always a risk buying online but here the product was better than expected, properly oak-looking, functional and the soft close lid really works. Very pleased with the item and would buy more from Wickes"
Our 'standard' products are available for next-day delivery (depending on your location and when you place your order).
Wickes delivers 'standard' (non-Big & Bulky) products to mainland UK (Great Britain) addresses, and to The Isle of Wight. We are unable to deliver to other remote and offshore locations.
Please refer to our Postcode Matrix to check whether we can deliver to your area, and if next-day delivery is available.
All products are delivered to the kerbside of the delivery address.
Where our next-day delivery service is available, it applies to 'standard' products that are ordered Monday – Thursday before 6pm.
For orders placed on a Friday before 6pm, we will try to deliver 'standard' products the following Monday.
For orders placed between 6pm on a Friday and 6pm on a Sunday, we will try to deliver 'standard' products the following Tuesday.
Next Day AM delivery is available for only £5 extra
Saturday delivery is available for only £5 extra.
Up to £50
Next Day Delivery: £5.95
Next Day AM Delivery: £10.95
Saturday Delivery: £10.95
£50 and over
Next Day Delivery: FREE
Next Day AM Delivery: £5
Saturday Delivery: £5
This delivery information applies to 'standard' products ordered online or by telephone. Go to our Delivery Information page for full delivery details of all our products and delivery methods.
Set out below is a summary of our Returns & Refunds policies, for full details see our Cancellations, Returns and Refunds policy
You can return any unused product to us in its original condition for a refund within 30 days of delivery to you. Please note that we may be unable to accept the return of made-to-measure products unless they are faulty or have been damaged in transit.
You can cancel any online order and receive a full refund (including standard delivery charges) at any time before the product is dispatched or within 14 days starting on the day after delivery.
Please note that if you cancel an order after the product has been delivered, you will be responsible for returning the Product to us at your cost within 14 days of the cancellation of your order. You can arrange for the product to be collected, by us or our nominated carrier, or return the product to your local Wickes store for free, with proof of purchase.
In the unlikely event that a delivered product is faulty or damaged, we will exchange it or provide you with a refund, as long as we are notified of the product's fault within 30 days of it being delivered to you.