Closed Bug 967300 Opened 10 years ago Closed 9 years ago

Use atomics with gcc in cairo

Categories

(Core :: Graphics, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla39
Tracking Status
firefox39 --- fixed

People

(Reporter: jrmuizel, Unassigned)

References

Details

Attachments

(1 file, 2 obsolete files)

Attached patch Use atomics with gcc in cairo (obsolete) — Splinter Review
This was an oversight.
Attachment #8369726 - Flags: review?(mshal)
Comment on attachment 8369726 [details] [diff] [review]
Use atomics with gcc in cairo

jmuizelaar and I chatted on IRC a few days ago - this patch fails to compile due to the fact that the HAVE_INTEL_ATOMIC_PRIMITIVES code patch relies on SIZEOF_VOID_P, SIZEOF_INT, etc, which normally would come from cairo's configure script.

One way to fix this would be to add the AC_CHECK_SIZEOF(void *) checks to the top-level configure.in, and then the defines would be picked up by cairo from mozilla-config.h. glandium: Is that an acceptible place for those? Or is there a better way to define them locally under the gfx/cairo tree?
Attachment #8369726 - Flags: review?(mshal) → review-
Flags: needinfo?(mh+mozilla)
There's probably nothing better to do at the moment.
Flags: needinfo?(mh+mozilla)
FWIW:
If we have
#define HAVE_STDINT_H 1
#define HAVE_UINT64_T 1
in cairo/src/cairoint.h and cairo/cairo/src/cairo.h, we will save the call of cairo_int32x32_64_mul(), etc.

It will improve performance a little bit.

Probably should file another bug, but maybe we will fix it together.
This is just Jeff's original patch + the modifications suggested by mshal and
reluctantly affirmed by glandium.  A local build seems to confirm everything works.
Attachment #8549862 - Flags: review?(mshal)
(In reply to Nathan Froyd [:froydnj] [:nfroyd] from comment #4)
> Created attachment 8549862 [details] [diff] [review]
> enable cairo's atomic support on gcc-esque compilers
> 
> This is just Jeff's original patch + the modifications suggested by mshal and
> reluctantly affirmed by glandium.  A local build seems to confirm everything
> works.

...well, it would have if tree-wide builds worked correctly.  Looks like some media/mtransport/ goop magically triggers things off our shiny new AC_CHECK_SIZEOF results.  Sigh.
Here's a better version of the patch that doesn't require running programs at
configure time to determine the sizes of fundamental datatypes.
Attachment #8369726 - Attachment is obsolete: true
Attachment #8549862 - Attachment is obsolete: true
Attachment #8549862 - Flags: review?(mshal)
Attachment #8549873 - Flags: review?(mshal)
Seems sort of busted that we'll have this enabled on Linux and Mac, but not Windows...or am I ignorant about how our gfx setup works?  Can we import a patch from upstream or write basic Windows-only atomic ops support?
Flags: needinfo?(jmuizelaar)
Blocks: 1111885
I'll write and upstream a windows implementation.
Flags: needinfo?(jmuizelaar)
Attachment #8549873 - Flags: review?(mshal) → review+
https://hg.mozilla.org/mozilla-central/rev/70aa258394bf
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
This has been backed out.
https://hg.mozilla.org/mozilla-central/rev/dc194ba77d7f
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Jeff, have you been able to look at why this causes performance regressions?
Flags: needinfo?(jmuizelaar)
Unfortunately, not yet. Let me do some sample try pushes to try to narrow things down.
Flags: needinfo?(jmuizelaar)
It looks like the performance regression wasn't actually a regression.

I've relanded:

https://hg.mozilla.org/integration/mozilla-inbound/rev/604003669a62
https://hg.mozilla.org/mozilla-central/rev/604003669a62
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: mozilla38 → mozilla39
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: