Skip to content

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 <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
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 <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
'c' is going away.  This is also a bit shorter.

Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
'c' is going away.  This is also a bit shorter.

Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
'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 <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
'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 <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
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 <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
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 <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
'c' is going away, but we still need a memory context that lives
for the duration of the compile.

Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
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 <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
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 <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Cc: "10.2" <[email protected]>
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" <[email protected]>
Signed-off-by: Topi Pohjolainen <[email protected]>
Reviewed-and-tested-by: Kenneth Graunke <[email protected]>
SCons is required for Windows.  Add links to flex/bison for Windows.
Reorder items and improve formatting.

Reviewed-by: Ian Romanick <[email protected]>
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 <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
Cc: "10.2" <[email protected]>
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 <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Courtney Goeltzenleuchter <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
Cc: "10.2" <[email protected]>
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 <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
Cc: "10.2" <[email protected]>
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 <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Chris Forbes <[email protected]>
Cc: "10.2" <[email protected]>
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 <[email protected]>
Signed-off-by: Jeremy Huddleston Sequoia <[email protected]>
Reviewed-by: Chia-I Wu <[email protected]>
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 <[email protected]>
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 <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Cc: Jamey Sharp <[email protected]>
Cc: Ian Romanick <[email protected]>
Cc: Stéphane Marchesin <[email protected]>
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 <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Cc: Jamey Sharp <[email protected]>
Cc: Ian Romanick <[email protected]>
Cc: Stéphane Marchesin <[email protected]>
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" <[email protected]>
Reviewed-by: Chad Versace <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Suggested by Ken as a way to cut down lines of code.

Reviewed-by: Kenneth Graunke <[email protected]>
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 <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Cc: "10.1 10.2" <[email protected]>
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 <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Cc: "10.1 10.2" <[email protected]>
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: [email protected]
Reviewed-by: Michel Dänzer <[email protected]>
It doesn't work and our docs say so too.

Cc: [email protected]
Reviewed-by: Michel Dänzer <[email protected]>
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 <[email protected]>
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.