| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Fixes the following GCC warning.
brw_screen.c: In function 'brw_get_shader_param':
brw_screen.c:241: warning: control reaches end of non-void function
|
|
Fixes the following GCC warning.
i915_screen.c: In function 'i915_get_shader_param':
i915_screen.c:184: warning: control reaches end of non-void function
|
|
Fixes the following GCC warning.
i915_screen.c: In function 'i915_get_shader_param':
i915_screen.c:147: warning: implicit declaration of function 'draw_get_shader_param'
|
|
This is a follow-up to commit a508d2dddcc67d0f92cc36b9ed6f36a9bbfc579d.
Fixes the following GCC warning.
id_screen.c: In function 'identity_screen_create':
id_screen.c:317: warning: assignment from incompatible pointer type
|
|
This is a follow-up to commit a508d2dddcc67d0f92cc36b9ed6f36a9bbfc579d.
Fixes the following GCC warning.
rbug_screen.c: In function 'rbug_screen_create':
rbug_screen.c:331: warning: assignment from incompatible pointer type
|
|
Changes in v3:
- Also change trace, which I forgot about
Changes in v2:
- No longer adds tessellation shaders
Currently each shader cap has FS and VS versions.
However, we want a version of them for geometry, tessellation control,
and tessellation evaluation shaders, and want to be able to easily
query a given cap type for a given shader stage.
Since having 5 duplicates of each shader cap is unmanageable, add
a new get_shader_param function that takes both a shader cap from a
new enum and a shader stage.
Drivers with non-unified shaders will first switch on the shader
and, within each case, switch on the cap.
Drivers with unified shaders instead first check whether the shader
is supported, and then switch on the cap.
MAX_CONST_BUFFERS is now per-stage.
The geometry shader cap is removed in favor of checking whether the
limit of geometry shader instructions is greater than 0, which is also
used for tessellation shaders.
WARNING: all drivers changed and compiled but only nvfx tested
|
|
Should fix fdo 30168.
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=29901
https://bugs.freedesktop.org/show_bug.cgi?id=30132
|
|
According to gcc documentation both are equivalent,
second are prefered as first can make conflict with existing symbols.
Signed-off-by: José Fonseca <jfonseca@vmware.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=29901
|
|
|
|
different yet compatible formats
|
|
evergreen is always the same as r700 here.
|
|
|
|
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=30145
|
|
|
|
radeon_cs_space_check flushes the pipe context on failure, retries
the validation, and returns -1 if it fails again. At that point, there is
nothing we can do, so let's skip draw operations instead of getting stuck
in an infinite loop.
This code path ideally should never be hit.
|
|
This a leftover probably and is unnecessary, since we flush u_upload_mgr
in r300_flush.
|
|
|
|
Fixes SCons build.
|
|
|
|
Doesn't require 16-alignment, so catch more cases.
|
|
Keep step array as a set of four m128i's and reuse throughout the
rasterization.
|
|
Fragment shader can extract the correct bits for each quad.
|
|
|
|
I really don't understand the mechanism behind this, but it
seems like the way data blocks for a scene are malloced, and in
particular whether we treat them as stack or a queue, and whether
we retain the most recently allocated or least recently allocated
has a real affect (~5%) on isosurf framerates...
This is probably specific to my distro or even just my machine,
but none the less, it's nicer not to see the framerates go in the
wrong direction.
|
|
Mesa doesn't respect it anyway, but this makes it assert rather
than threads access areas of l[] that don't belong to them.
|
|
|
|
|
|
|
|
If not opaque, then the color buffer will have to be read any way,
therefore the specialization is pointless.
|
|
If the buffer we are attempting to map is referenced by the unsubmitted
command stream for this context, we need to flush the command stream,
however to do that we need to be able to access the context at the lowest
level map function, currently we set the buffer in the toplevel map, but this
racy between context. (we probably have a lot more issues than that.)
I'll look into a proper solution as suggested by jrfonseca when I get some time.
|
|
|
|
|
|
As a by-product, remove the memory leak of nv_basic_blocks.
|
|
|
|
This reverts a part of e795ca8f3175fa6fd97b6b2ef2775e3f8803012a
that causes artefacts and a performance drop.
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
|
|
|
|
This is erroneously throwing non plain formats out of the faster
AoS sampling path.
Doing 8bit interpolation for single channels such as L8 should be no
worse than with floating point. But this may need more investigation.
|
|
|
|
Or any ordering.
|
