| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
| |
The only caller is _mesa_update_state_locked() which already
checks if _NEW_PIXEL is set before calling _mesa_update_pixel().
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GLSL ES spec includes the following:
"It is an error to undefine or to redefine a built-in
(pre-defined) macro name."
But desktop GLSL doesn't. This has sparked some discussion
in Khronos, and the final conclusion was to update the
GLSL 4.50 spec to include the following:
"By convention, all macro names containing two consecutive
underscores ( __ ) are reserved for use by underlying
software layers. Defining or undefining such a name in a
shader does not itself result in an error, but may result
in unintended behaviors that stem from having multiple
definitions of the same name. All macro names prefixed
with “GL_” (“GL” followed by a single underscore) are also
reserved, and defining or undefining such a name results in
a compile-time error."
In other words, undefining GL_* names should be an error, but
undefining other names with a double underscore in them is
not strictly prohibited in desktop GLSL.
This patch fixes the preprocessor to apply these rules,
following exactly the implementation already present
in GLSLang. This fixes some tests in CTS.
Khronos bug:
https://cvs.khronos.org/bugzilla/show_bug.cgi?id=16003
Fixes:
KHR-GL45.shaders.preprocessor.definitions.undefine_core_profile_vertex
KHR-GL45.shaders.preprocessor.definitions.undefine_core_profile_fragment
Reviewed-by: Samuel Pitoiset <[email protected]>
|
|
|
|
|
|
|
| |
This just moves this code in here to it's cleaner.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Instead of having the fragile code to do a second pass, just
give the pointers you want params in to the initial code,
then call a later pass to assign them.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
Just pass a pointer and increment inside the function,
makes the code less error prone.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The other user of print_sync_dispatch() was ending up with code that
looked like:
_mesa_glthread_finish(ctx);
_mesa_glthread_restore_dispatch(ctx);
_mesa_glthread_finish(ctx);
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is undoing the changes to way size computation
in broxton 2x6, made by below commit:
Commit: 0d576fbfbe912cf3fb9ab594bb31eb58bccf2138
Author: Anuj Phogat <[email protected]>
i965: Simplify l3 way size computations
By making use of l3_banks field in gen_device_info struct
l3_way_size for gen7+ = 2 * l3_banks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101306
Signed-off-by: Anuj Phogat <[email protected]>
Tested-by: Mark Janes <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
This seems to matter here in a profile, without this we spend a lot
more time exiting this function with no flush bits.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
This just moves lots of stuff to the bind stage rather than
dealing with it in the draw stage.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
There is no need to calculate this at draw time.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
I want to use these in the pipeline setup stage.
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Simple search for a backslash followed by two newlines.
If one of the newlines were to be removed, this would cause issues, so
let's just remove these trailing backslashes.
Signed-off-by: Eric Engestrom <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
| |
Thanks to Marek for pointing this out.
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
radeonsi doesn't have it anymore either.
Signed-off-by: Bas Nieuwenhuizen <[email protected]>
Fixes: f4e499ec791 "radv: add initial non-conformant radv vulkan driver"
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
Simple refactor.
Signed-off-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
No functional changes.
Signed-off-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
No sense checking each bit separately in the common case of none
being set.
Signed-off-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
Redundant.
Signed-off-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
| |
Divides are pretty slow, and this is in the hot path of a draw.
Signed-off-by: Bas Nieuwenhuizen <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The manual detiling paths are not prepared to handle Gen4-G45 with
swizzling enabled, so explicitly disable them. (They're already
disabled because these platforms don't have LLC but a future patch could
enable this path).
Reviewed-by: Matt Turner <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Call brw_bo_map() directly.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Now that unsynchronized maps actually work, we can use them, like we do
on LLC platforms.
On Broxton, the performance of Unigine Valley 1.1-rc1 is improved by
37.6656% +/- 0.401389% (n=20) at 1280x720/QUALITY_LOW, and by
20.862% +/- 2.20901% (n=3) at 1920x1080/QUALITY_LOW.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
On Broxton, the performance of Unigine Valley 1.0 is improved by
13.3067% +/- 0.144322% (n=40) at 1280x720/QUALITY_LOW, and by
1.68478% +/- 0.484226% (n=3) at 1920x1080/QUALITY_LOW.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This way we can let brw_bo_map() choose the best mapping type.
Part of the patch inlines map_gtt() into brw_bo_map_gtt() (and removes
map_gtt()). brw_bo_map_gtt() just wrapped map_gtt() with locking and a
call to set_domain(). map_gtt() is called by brw_bo_map_unsynchronized()
to avoid the call to set_domain(). With the MAP_ASYNC flag, we now have
the same behavior previously provided by brw_bo_map_unsynchronized().
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
No functional change (no callers currently pass MAP_ASYNC)
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can encapsulate the logic for choosing the mapping type. This will
also help when we add WC mappings.
A few functional changes are made in this patch. On non-LLC, what were
previously WB mappings are now GTT mappings (in the prefilling debug
code in brw_performance_query.c; the shader_time code in brw_program.c;
and in the case of an RW mapping in intel_buffer_objects.c).
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
brw_bo_map_cpu() took a write_enable arg, but it wasn't always clear
whether we were also planning to read from the buffer. I kept everything
semantically identical by passing only MAP_READ or MAP_READ | MAP_WRITE
depending on the write_enable argument.
The other flags are not used yet, but MAP_ASYNC for instance, will be
used in a later patch to remove the need for a separate
brw_bo_map_unsynchronized() function.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
I'm going to make a new function named brw_bo_map() in a later patch
that is responsible for choosing the mapping type, so this patch clears
the way.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
I think these are better names, and it reduces the delta between
upstream and Chris Wilson's brw-batch branch.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Since we can distinguish when mapping between READ and WRITE, we can
pass along the map mode to avoid stalls and flushes where possible.
Reviewed-by: Kenneth Graunke <[email protected]>
Reviewed-by: Matt Turner <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Missing in the resource streamer removal of commit 951f56cd43bc.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Just return the map from brw_map_bo_*
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
| |
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on discussions with Jason, Ivy Bridge and Bay Trail only actually
support 16 samplers, while newer hardware can support more than the
current limit of 64. Therefore set the lower limit where needed, and
bump up to 128 for everything else. There is also a limit on the total
number of other resources of around 250.
This allows Dawn of War III to render correctly on ANV.
Signed-off-by: Alex Smith <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
As already done by RADV.
v2: Move version calculation function to src/vulkan/util to share with
RADV.
Signed-off-by: Alex Smith <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This means it can be reused for other Vulkan drivers. Also fix up a
typo, need to search for '.' in the version string rather than ','.
v2: Remove unneeded temporary version variable (Emil, Eric)
Signed-off-by: Alex Smith <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have Vulkan utilities in both src/util and src/vulkan/util. The
latter seems a more appropriate place for Vulkan-specific things, so
move them there.
v2: Android build system changes (from Tapani Pälli)
Signed-off-by: Alex Smith <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Acked-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current way of handling groups doesn't seem to be able to handle
MI_LOAD_REGISTER_* with more than one register. This change reworks
the way we handle groups by building a traversal list on loading the
GENXML files.
Let's say you have
Instruction {
Field0
Field1
Field2
Group0 (count=2) {
Field0-0
Field0-1
}
Group1 (count=4) {
Field1-0
Field1-1
}
}
We build of linked on load that goes :
Instruction -> Group0 -> Group1
All of those are gen_group structures, making the traversal trivial.
We just need to iterate groups for the right number of timers (count
field in genxml).
The more fancy case is when you have only a single group of unknown
size (count=0). In that case we keep on reading that group for as long
as we're within the DWordLength of that instruction.
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Rafael Antognolli <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Only harvested Stoney has 2 CUs. Tested on 2-CU Stoney and Fiji forced
to 2 CUs.
Cc: 17.0 17.1 <[email protected]>
Tested-by: Edmondo Tommasina <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
|
| |
Now, st_update_window_rectangles() won't be called when the
scissor is going to be updated.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new driver flag will replace _NEW_SCISSOR which is
emitted when setting new window rectangles but it actually
triggers useless changes in the state tracker (like scissor
and rasterizer).
EXT_window_rectangles is currently only supported by Nouveau.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
|
| |
This is actually useless because this driver call is only used
by the classic DRI drivers which don't support that extension
and probably won't never support it.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
We usually check that given parameters are different before
updating the state.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
We usually check that given parameters are different before
updating the state.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
|
|
| |
We usually check that given parameters are different before
updating the state.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>
|