| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Batch dumping is now handled by shared code in libdrm.
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
I noticed these while building the fork-i915 branch.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
We've already computed what the dimensions of the miptree are, and stored
it in the miptree.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The polygon offset math used for triangles by the WM is "OffsetUnits * 2 *
MRD + OffsetFactor * m" where 'MRD' is the minimum resolvable difference
for the depth buffer (~1/(1<<16) or ~1/(1<<24)), 'm' is the approximated
slope from the GL spec, and '2' is this magic number from the original
i965 code dump that we deviate from the GL spec by because "it makes glean
work" (except that it doesn't, because of some hilarity with 0.5 *
approximately 2.0 != 1.0. go glean!).
This clipper code for unfilled polygons, on the other hand, was doing
"OffsetUnits * garbage + OffsetFactor * m", where garbage was MRD in the
case of 16-bit depth visual (regardless the FBO's depth resolution), or
128 * MRD for 24-bit depth visual.
This change just makes the unfilled polygons behavior match the WM's
filled polygons behavior.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
There's no reason to care about the window system visual's depth for
handling polygon offset in an FBO, and it could only lead to pain.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The separate function for the fallback checks wasn't particularly
clarifying things, so I put the improved checks in the caller. (Note that
the dropped _mesa_update_state() had already happened once at the start of
the caller)
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think we've all added instrumentation at one point or another to see
what's being called in blorp. Now you can quickly get output like:
Testing glCopyPixels(depth).
intel_hiz_exec depth clear to mt 0x16d9160 level 0 layer 0
intel_hiz_exec depth resolve to mt 0x16d9160 level 0 layer 0
intel_hiz_exec hiz ambiguate to mt 0x16d9160 level 0 layer 0
intel_hiz_exec depth resolve to mt 0x16d9160 level 0 layer 0
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 551c991606e543c3a264a762026f11348b37947e tried to avoid spilling
registers that were trivially colorable. But since we do optimistic
coloring, the top of the stack also contains nodes that are not trivially
colorable, so we need to consider them for spilling (since they are some
of our best candidates).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58384
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63674
NOTE: This is a candidate for the 9.1 branch.
|
|
|
|
|
|
| |
It should never happen, but it does, and at this point, you're going to
_mesa_problem() and abort() (unless it's just in precompile). Give the
developer something to look at.
|
|
|
|
|
|
|
|
|
|
| |
Some shells does not set variables sequentially in a statement i.e. "a=X
b=${a}" won't set "b" to "X" but empty value.
This patch introduce ";" to make sure "mo" is set properly before "lang"
assignment.
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=471302
|
|
|
|
|
|
|
|
|
|
|
| |
The last piece of code with an effect was flagging _NEW_BUFFERS. Only,
that is already flagged from everything that calls this function: Mesa GL
state updates flag it before even calling down into the driver, and the
calls from the DRI2 window system framebuffer update path end up flagging
it as part of the ResizeBuffers() hook.
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
The computed fields are updated appropriately as part of the normal draw
call path due to _NEW_BUFFERS being set.
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
For winsys FBOs, the bounds are appropriately updated immediately upon
_mesa_resize_framebuffer(). For user FBOs, they're updated as part of the
normal draw path state update due to _NEW_BUFFERS having been flagged.
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Of the places noting a _NEW_DEPTH dependency, all were already checking
for _NEW_BUFFERS if appropriate.
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
2/3 packets depending on Stencil._Enabled already checked for
_NEW_BUFFERS, so just add _NEW_BUFFERS to the remaining one.
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The viewport (ctx->Viewport._WindowMap) doesn't change with drawable size
changes, and we update scissor (ctx->DrawBuffer->_Xmin and friends) on
_NEW_BUFFERS in things like brw_sf_state.c.
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Things like brw_sf.c that need to know about orientation are already
recomputing on _NEW_BUFFERS.
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
_mesa_resize_framebuffer(), the default value of the ResizeBuffers hook,
already checks for a window system framebuffer and walks the renderbuffers
calling AllocStorage().
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
_mesa_resize_framebuffer(), the default value of the ResizeBuffers hook,
already checks for a window system framebuffer and walks the renderbuffers
calling AllocStorage().
Reviewed-by: Anuj Phogat <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This existed to tell the core not to call GetBufferSize, except that even
if you didn't set it nothing happened because nobody had a GetBufferSize.
v2: Remove two more instances of setting the field (from Brian)
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Only the GDI driver set it to non-NULL any more, and that driver has a
Viewport hook that should keep it limping along as well as it ever has.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 26d86d26f9f972b19c7040bdb1b1daf48537ef3e added
gl_shader_program::UniformLocationBaseScale. According to the code
comments in that commit, UniformLocationBaseScale "must be >=1".
UniformLocationBaseScale is of type unsigned. Coverity reported a "Macro
compares unsigned to 0" defect as well.
Signed-off-by: Vinson Lee <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
| |
To get array bounds checking.
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
| |
Reviewed-by: Jose Fonseca <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The function does array bounds checking. Note, this exposes a
bug in the svga_mark_surface_dirty() function: we're calling
svga_age_texture_view() with a texture slice instead of mipmap
level. This can lead to a failed assertion. That'll be fixed next.
Reviewed-by: Jose Fonseca <[email protected]>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- use mgwhelp -- the successor for bfdhelp which does not have a hard
dependency on BFD, and works on 64bits.
- use a macro instead of hand-typing to dispatch DbgHelp functions
- dump line numbers
- dump module names when symbols are not available
- support 64bits.
- add comments
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
Rely on Windows' CaptureStackBackTrace to do the grunt work.
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because our code couldn't handle it we were skipping rendering
if we detected overflows. According to the spec we should
still render but with all 0 vertices, which is what the llvm
code already does. So for the llvm paths lets enable processing
even if an overflow condition has been detected.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Before we could easily overflow if start+count>max integer. To
avoid it we can just iterate over the count. This makes sure
that we never crash, since most of the overflow conditions
is already handled.
Signed-off-by: Zack Rusin <[email protected]>
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
| |
Signed-off-by: Maarten Lankhorst <[email protected]>
|
|
|
|
|
|
| |
Make pass_render_condition() available for blitter, and check for render
condition in (and only in) clear(), clear_render_target(), and
clear_depth_stencil().
|
|
|
|
| |
Replace direct shader accesses with ilo_shader_get_kernel_param() and etc.
|
|
|
|
| |
Replace direct shader accesses with ilo_shader_get_kernel_param() and etc.
|
|
|
|
|
| |
Remember the order of the source attributes and avoid recomputation when it
does not change.
|
|
|
|
|
|
|
|
|
| |
Add ilo_shader_select_kernel_routing() to construct 3DSTATE_SBE. It is called
in ilo_finalize_states(), rather than in create_fs_state(), as it depends on
VS/GS and rasterizer states.
With this change, ilo_shader_internal.h is no longer needed for
ilo_gpe_gen6.c.
|
|
|
|
|
|
| |
This allows us to remove ilo_shader_internal.h from ilo_gpe_gen7.c. The
unfinished code in 3DSTATE_DS, 3DSTATE_HS, and INTERFACE_DESCRIPTOR_DATA are
partly or entirely removed.
|
|
|
|
|
|
|
| |
The unmodified pipe_stream_output_info describes its outputs as if they are in
TGSI_FILE_OUTPUT. Remap the register indices to where they appear in the VUE.
TGSI_SEMANTIC_PSIZE needs a little care because it is at the W channel.
|
|
|
|
|
| |
Add ilo_gpe_init_fs_cso() to construct 3DSTATE_PS and shader part of
3DSTATE_WM once and early for fragment shaders.
|
|
|
|
|
| |
Replace pipe_rasterizer_state by ilo_rasterizer_state for the remaining GPE
functions for consistency.
|
|
|
|
|
| |
Add ilo_gpe_init_rasterizer_wm() to construct fixed-function part of
3DSTATE_WM once in create_rasterizer_state().
|
|
|
|
|
| |
Add ilo_gpe_init_gs_cso() to construct 3DSTATE_GS once and early for geometry
shaders.
|
|
|
|
|
|
|
| |
When a new VS kernel is generated, a newly added function,
ilo_gpe_init_vs_cso(), is called to construct 3DSTATE_VS command in
ilo_shader_cso. When the command needs to be emitted later, we copy the
command from the CSO instead of constructing it dynamically.
|
|
|
|
|
|
| |
Add ilo_shader_get_type() to query the type (PIPE_SHADER_x) of the shader.
Add ilo_shader_get_kernel_offset() and ilo_shader_get_kernel_param() to query
the cache offset and various kernel parameters of the selected kernel.
|
|
|
|
|
|
|
|
| |
Add ilo_shader_select_kernel() to replace the dependency table,
ilo_shader_variant_init(), and ilo_shader_state_use_variant().
With the changes, we no longer need to include ilo_shader_internal.h in
ilo_state.c.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace ilo_shader_state_create() by
ilo_shader_create_vs()
ilo_shader_create_gs()
ilo_shader_create_fs()
ilo_shader_create_cs()
Rename ilo_shader_state_destroy() to ilo_shader_destroy(). The old
ilo_shader_destroy() is renamed to ilo_shader_destroy_kernel().
|
|
|
|
|
| |
Move it to ilo_shader_internal.h. The goal is to make files not part of the
compiler include only ilo_shader.h eventually.
|