-
Notifications
You must be signed in to change notification settings - Fork 26
2014ww23.2 i965 lunar glass drop1 #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
courtney-lunarg
wants to merge
2,255
commits into
ValveSoftware:alchemist-10.1
Choose a base branch
from
LunarG:2014ww23.2_i965-LunarGlass_drop1
base: alchemist-10.1
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
2014ww23.2 i965 lunar glass drop1 #3
courtney-lunarg
wants to merge
2,255
commits into
ValveSoftware:alchemist-10.1
from
LunarG:2014ww23.2_i965-LunarGlass_drop1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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]>
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]>
Signed-off-by: Rob Clark <[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: 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]>
Signed-off-by: Jeremy Huddleston Sequoia <[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]>
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]>
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
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]>
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Early prototype of LunarGlass front-end for Mesa Intel driver.