Skip to content

2014ww23.2 i965 lunar glass drop1#3

Open
courtney-lunarg wants to merge 2255 commits intoValveSoftware:alchemist-10.1from
LunarG:2014ww23.2_i965-LunarGlass_drop1
Open

2014ww23.2 i965 lunar glass drop1#3
courtney-lunarg wants to merge 2255 commits intoValveSoftware:alchemist-10.1from
LunarG:2014ww23.2_i965-LunarGlass_drop1

Conversation

@courtney-lunarg
Copy link
Contributor

Early prototype of LunarGlass front-end for Mesa Intel driver.

kaydenl and others added 30 commits May 18, 2014 23:35
This data is created by fs_visitor and only used when emitting code,
so keeping it in fs_visitor makes sense.  I decided it would be
reasonable to group these all together in a struct, since they're
highly related.

v2: s/nr_payload_regs/payload.num_regs/ in some comments (chrisf).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
runtime_check_aads_emit isn't actually used currently, but I believe
we should be using it on Gen4-5, so I haven't eliminated it.
See https://bugs.freedesktop.org/show_bug.cgi?id=78679 for details.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
'c' is going away.  This is also a bit shorter.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
'c' is going away.  This is also a bit shorter.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
'c' is going away.  This is also shorter.

Marking the key pointer as const will also deter people from changing
it in fs_visitor, as it's absolutely not OK to modify it there.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
'c' is going away.  This is also a bit shorter.

Marking the key pointer as const will also deter people from changing
it in these classes, as that's absolutely not OK.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
We throw away the data generated during compilation on the success path,
so we really ought to on the failure path as well.  The caller has no
access to it anyway, so it's purely leaked.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Previously, the memory context situation was a bit of a mess:

fs_visitor allocated its own memory context, and freed it in the
destructor.  However, some data produced by fs_visitor (such as the list
of instructions) needs to live beyond when fs_visitor is "done", so the
caller can pass it to fs_generator.

Everything worked out because brw_wm_fs_emit's fs_visitor variables
happen to not go out of scope until the end of the function.  But that
meant that moving the declaration of, say, the SIMD16 fs_visitor
instance, could cause everything to explode.

Using a memory context that exists for the duration of the compile is
clearer, and should be equivalent.

Ultimately, we don't want to use 'c', but this matches the behavior of
fs_generator and gen8_fs_generator, so it'll be simple to change later.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
'c' is going away, but we still need a memory context that lives
for the duration of the compile.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Instead, just pass the key and prog_data as separate parameters.

This moves it up a level - one step further toward getting rid of it.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
We already have a perfectly good copy of the program key, and nobody is
going to modify it.  The only reason we copied it was because the
brw_wm_compile structure embedded the key rather than pointing to it.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Fixes build error introduced with commit
4b04152.

  CC       test_eu_compact.o
test_eu_compact.c: In function ‘test_compact_instruction’:
test_eu_compact.c:54:3: error: implicit declaration of function ‘brw_disasm’ [-Werror=implicit-function-declaration]
   brw_disasm(stderr, &src, brw->gen, false);
   ^

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78888
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
2ea923c had the side effect of IR counting
now being done after IR optimization instead of before. Some quick analysis
shows that there's roughly 1.5 times more IR instructions before optimization
than after, hence the effective shader cache size got quite a bit smaller.
Could counter this with an increase of the instruction limit but it probably
makes more sense to count them after optimizations, so move that code.

Reviewed-by: Brian Paul <brianp@vmware.com>
It's not properly implemented in the meta code, and we don't have time
to fix it for 10.2.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
I don't have an ILK at hand but the fix should be trivial.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78872
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-and-tested-by: Kenneth Graunke <kenneth@whitecape.org>
SCons is required for Windows.  Add links to flex/bison for Windows.
Reorder items and improve formatting.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
This reverts commit bd44ac8.

Fixes:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78842
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78843

Re-breaks:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77705
but that will be fixed properly in a few commits.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
These aren't necessary - all of the following code is predicated on mask
being non-zero, so no code will get executed anyway.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Courtney Goeltzenleuchter <courtney@lunarg.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Separating the software fallbacks from the rest of the meta path (which
is usually hardware accelerated) gives callers better control over their
blitting options.

For example, i965 might want to try meta blit, hardware blits, then
swrast as a last resort.  Splitting it makes that possible.

This updates all callers to maintain the existing behavior (even in the
few cases where it isn't desirable behavior - later patches can change
that).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
This is a replacement for bd44ac8
that should actually work.

Fixes Piglit's copyteximage-border on swrast, as well as one of
es3conform's packed_pixels_pixelstore test.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78546
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77705
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Split it up into some smaller fxns so it doesn't grow into a huge
monster as we add things.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Chia-I Wu <olv@lunarg.com>
I think a3xx and later should support (it is part of GLES3), but this
isn't needed for the time being and still needs to be reversed.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
In order to support the (currently unregistered) Chromium-specific EGL
extension eglGetSyncValuesCHROMIUM on Intel systems, we need to import
the Chromium header that defines it.  The file was downloaded from

https://chromium.googlesource.com/chromium/chromium/+/trunk/ui/gl/EGL/eglextchromium.h

It is subject to the license found at

https://chromium.googlesource.com/chromium/chromium/+/trunk/LICENSE

I have imported the header file and added the license text to the top.
The only change was to fix the include guard on the Chromium header to
change the last line from a #define to a #endif, which makes the header
actually compile.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Cc: Jamey Sharp <jamey@minilop.net>
Cc: Ian Romanick <idr@freedesktop.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Chromium defined a new GL extension (that isn't registered with Khronos).
We need to add an EGL extension for it, so we can migrate ChromeOS on
Intel systems to use EGL instead of GLX.

http://git.chromium.org/gitweb/?p=chromium/src/third_party/khronos.git;a=commitdiff;h=27cbfdab35c601f70aa150581ad1448d0401f447

The EGL_CHROMIUM_sync_control extension is similar to the GLX extension
OML_sync_control, but only defines one function,
eglGetSyncValuesCHROMIUM, which is equivalent to glXGetSyncValuesOML.

http://www.opengl.org/registry/specs/OML/glx_sync_control.txt

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: Jamey Sharp <jamey@minilop.net>
Cc: Ian Romanick <idr@freedesktop.org>
Cc: Stéphane Marchesin <stephane.marchesin@gmail.com>
Marek Olšák and others added 29 commits June 2, 2014 12:58
The sample positions are read from a constant buffer.
EGL 1.4 Specification says that
eglMakeCurrent(display, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT)
can be used to release the current thread's ownership on the surfaces
and context.

MESA's egl implementation was only accepting the parameters when the
KHR_surfaceless_context extension is supported.

[chadv] Add quote from the EGL 1.4 spec.
Cc: "10,1, 10.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
In all cases, we set both dst and src0 to brw_ip_reg().  This is no
accident: according to the ISA reference, both are required to be the IP
register.  So, we may as well drop the parameters.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
We use both predicated and unconditional JMPI instructions.  But in each
case, it's clear which we want.  It's simpler to just specify it as a
parameter, rather than relying on default state.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Often times, we want to emit an instruction, then set one field on it,
such as predication or a conditional modifier.  Normally, we'd have to
declare "struct brw_instruction *inst;" and then use "inst =
brw_FOO(...)" to emit the instruction, which can hurt readability.

The new "brw_last_inst" macro refers to the most recently emitted
instruction, so you can just do:

    brw_ADD(...)
    brw_last_inst->header.predicate_control = BRW_PREDICATE_NORMAL;

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
It wasn't too bad before, but the macro is going to be nicer once I
start modifying a lot more instructions in this pattern.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
brw_CMP already takes a conditional modifier as a parameter, and sets it
accordingly.  brw_set_conditionalmod() also makes everything after the
next instruction predicated, but we don't need that: we always emit an
IF instruction after load_clip_distance(), and that's already
predicated.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
brw_set_conditionalmod has traditionally been complex: it causes
conditionalmod to be set for the next instruction, and then predication
to be set on all future instructions after that.

We may want to generate a flag condition and not use it immediately,
due to instruction scheduling or the like.  Even if not, it's easy
to set things explicitly, and that's clearer.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
brw_set_conditionalmod and brw_next_insn work together to set the
conditional modifier for the next instruction, then turn it off.
The Gen8+ generators don't implement this: we just set it for all future
instructions, and whack it for each fs_inst/vec4_instruction.

Both approaches work out because we only set conditional_mod on
IR instructions like CMP, AND, and so on, which correspond to exactly
one assembly instruction.  The Gen8 generators would break if we had
an IR instruction that generated multiple instructions, and the Gen4-7
EU emit layer would do...something.

To safeguard against this, assert that we only generated one instruction
if conditional_mod is set, and just set the flag directly on that
instruction rather than altering default state.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
With the predication changes eliminated, all this does is set the
conditional modifier on a single instruction.  Doing that directly is
easy, and avoids mucking about with default state.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This removes the ability to set the default conditional modifier on all
future instructions.  Nothing uses it, and it's not really a sensible
thing to do anyway.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Eventually we're going to use functions to set bits on an instruction.
Putting 'default' in the name of functions that alter default state will
help distinguins them.

This patch was generated entirely mechanically, by the following:

for file in brw*.{cpp,c,h}; do
   sed -i \
   -e 's/brw_set_mask_control/brw_set_default_mask_control/g' \
   -e 's/brw_set_saturate/brw_set_default_saturate/g' \
   -e 's/brw_set_access_mode/brw_set_default_access_mode/g' \
   -e 's/brw_set_compression_control/brw_set_default_compression_control/g' \
   -e 's/brw_set_predicate_control/brw_set_default_predicate_control/g' \
   -e 's/brw_set_predicate_inverse/brw_set_default_predicate_inverse/g' \
   -e 's/brw_set_flag_reg/brw_set_default_flag_reg/g' \
   -e 's/brw_set_acc_write_control/brw_set_default_acc_write_control/g' \
   $file;
done

No manual changes were done after running that command.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Suggested by Ken as a way to cut down lines of code.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
These were missed in commit e374809.

Fixes 'make check'.

  CC       test_eu_compact.o
test_eu_compact.c: In function ‘gen_f0_0_MOV_GRF_GRF’:
test_eu_compact.c:222:4: error: implicit declaration of function ‘brw_set_predicate_control’ [-Werror=implicit-function-declaration]
    brw_set_predicate_control(p, true);
    ^
test_eu_compact.c: In function ‘run_tests’:
test_eu_compact.c:270:6: error: implicit declaration of function ‘brw_set_access_mode’ [-Werror=implicit-function-declaration]
      brw_set_access_mode(p, BRW_ALIGN_16);
      ^

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
Same as b026b6b, but
COLOR_ARRAY_SIZE/SECONDARY_COLOR_ARRAY_SIZE.

Ideally we wouldn't munge the incoming state, so that we wouldn't need
to unmunge it back on glGet*.  But the array size state is copied and
referred in many places, many of which couldn't take an GLenum like
GL_BGRA instead of a plain integer.  So just hack around on glGet*,
to ensure there is no risk of introducing regressions elsewhere.

This bug causes problems to Apitrace, resulting in wrong traces.  See
apitrace/apitrace#261 for details.

Tested with piglit arb_vertex_array_bgra-get, which was created for this
purpose.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>
For some reason, CP DMA doesn't follow the predicate bit if I enable it,
so this is the only option.

This fixes piglit: spec/NV_conditional_render/clear

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
It doesn't work and our docs say so too.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Plagman pushed a commit that referenced this pull request Jun 4, 2014
With the recent SRGB changes all my automated OpenGL llvmpipe tests
(piglit, conform, glretrace) start asserting with the backtrace below.

I'm hoping this change will fix it.  I'm not entirely sure, as this
doesn't happen in my development machine (the bug probably depends on
the exact X visual).

Anyway, it seems the sensible thing to do here.

   Program terminated with signal 5, Trace/breakpoint trap.
   #0  _debug_assert_fail (expr=expr@entry=0x7fa324df2ed7 "0", file=file@entry=0x7fa324e3fc30 "src/mesa/state_tracker/st_format.c", line=line@entry=758, function=function@entry=0x7fa324e40160 <__func__.34798> "st_pipe_format_to_mesa_format") at src/gallium/auxiliary/util/u_debug.c:281
   #0  _debug_assert_fail (expr=expr@entry=0x7fa324df2ed7 "0", file=file@entry=0x7fa324e3fc30 "src/mesa/state_tracker/st_format.c", line=line@entry=758, function=function@entry=0x7fa324e40160 <__func__.34798> "st_pipe_format_to_mesa_format") at src/gallium/auxiliary/util/u_debug.c:281
   No locals.
   #1  0x00007fa3241d22b3 in st_pipe_format_to_mesa_format (format=format@entry=PIPE_FORMAT_R8G8B8A8_SRGB) at src/mesa/state_tracker/st_format.c:758
           __func__ = "st_pipe_format_to_mesa_format"
   #2  0x00007fa3241c8ec5 in st_new_renderbuffer_fb (format=format@entry=PIPE_FORMAT_R8G8B8A8_SRGB, samples=0, sw=<optimised out>) at src/mesa/state_tracker/st_cb_fbo.c:295
           strb = 0x19e8420
   #3  0x00007fa32409d355 in st_framebuffer_add_renderbuffer (stfb=stfb@entry=0x19e7fa0, idx=<optimised out>) at src/mesa/state_tracker/st_manager.c:314
           rb = <optimised out>
           format = PIPE_FORMAT_R8G8B8A8_SRGB
           sw = <optimised out>
   #4  0x00007fa32409e635 in st_framebuffer_create (st=0x19e7fa0, st=0x19e7fa0, stfbi=0x19e7a30) at src/mesa/state_tracker/st_manager.c:458
           stfb = 0x19e7fa0
           mode = {rgbMode = 1 '\001', floatMode = 0 '\000', colorIndexMode = 0 '\000', doubleBufferMode = 0, stereoMode = 0, haveAccumBuffer = 0 '\000', haveDepthBuffer = 1 '\001', haveStencilBuffer = 1 '\001', redBits = 8, greenBits = 8, blueBits = 8, alphaBits = 8, redMask = 0, greenMask = 0, blueMask = 0, alphaMask = 0, rgbBits = 32, indexBits = 0, accumRedBits = 0, accumGreenBits = 0, accumBlueBits = 0, accumAlphaBits = 0, depthBits = 24, stencilBits = 8, numAuxBuffers = 0, level = 0, visualRating = 0, transparentPixel = 0, transparentRed = 0, transparentGreen = 0, transparentBlue = 0, transparentAlpha = 0, transparentIndex = 0, sampleBuffers = 0, samples = 0, maxPbufferWidth = 0, maxPbufferHeight = 0, maxPbufferPixels = 0, optimalPbufferWidth = 0, optimalPbufferHeight = 0, swapMethod = 0, bindToTextureRgb = 0, bindToTextureRgba = 0, bindToMipmapTexture = 0, bindToTextureTargets = 0, yInverted = 0, sRGBCapable = 1}
           idx = <optimised out>
   #5  st_framebuffer_reuse_or_create (st=st@entry=0x19dfce0, fb=<optimised out>, stfbi=stfbi@entry=0x19e7a30) at src/mesa/state_tracker/st_manager.c:728
   No locals.
   #6  0x00007fa32409e8cc in st_api_make_current (stapi=<optimised out>, stctxi=0x19dfce0, stdrawi=0x19e7a30, streadi=0x19e7a30) at src/mesa/state_tracker/st_manager.c:747
           st = 0x19dfce0
           stdraw = 0x640064
           stread = 0x1300000006
           ret = <optimised out>
   #7  0x00007fa324074a20 in XMesaMakeCurrent2 (c=c@entry=0x195bb00, drawBuffer=0x19e7e90, readBuffer=0x19e7e90) at src/gallium/state_trackers/glx/xlib/xm_api.c:1194
   No locals.
   #8  0x00007fa3240783c8 in glXMakeContextCurrent (dpy=0x194e900, draw=8388610, read=8388610, ctx=0x195bac0) at src/gallium/state_trackers/glx/xlib/glx_api.c:1177
           drawBuffer = <optimised out>
           readBuffer = <optimised out>
           xmctx = 0x195bb00
           glxCtx = 0x195bac0
           firsttime = 0 '\000'
           no_rast = 0 '\000'
   #9  0x00007fa32407852f in glXMakeCurrent (dpy=<optimised out>, drawable=<optimised out>, ctx=<optimised out>) at src/gallium/state_trackers/glx/xlib/glx_api.c:1211
   No locals.

Acked-by: Brian Paul <brianp@vmware.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.