| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: [email protected]
(cherry picked from commit a778831735ea45f789c247c40677cd26adc78e3e)
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hardware only generates vertexid when vertices come from a VBO. This
fixes:
vertexid-drawelements
vertexid-drawarrays
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: "11.0" <[email protected]>
(cherry picked from commit c830d193db5c90cf0af57ff73606e2aa12aed9a8)
|
|
|
|
|
|
|
|
|
| |
The index buffer is fed in inline over a pushbuf. It's not related to
vertices or any caching that might be done on them.
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: [email protected]
(cherry picked from commit 4a025c6bc835387a31007fdf30a130e612e54e19)
|
|
|
|
|
|
|
|
|
| |
There is nothing to be done on a dirty idxbuf, but the bo may have
changed, so we have to rebind it to the bufctx.
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: [email protected]
(cherry picked from commit 1f62d36ae21043c472fc182fd4b738ec1d54a2d2)
|
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: [email protected]
(cherry picked from commit 114cc18b98b6e016ab1986577aa3df12acc22cca)
|
|
|
|
|
|
|
|
|
|
|
|
| |
The stride was being set to 0, which is illegal (and also non-sensical).
Also we must wait for the buffer to become available for reading as
otherwise a wrong value may be prefetched. Since we must wait for the
buffer anyways, and it's mapped and in GART, we may as well avoid the
annoyance of the indirect pushbuf submit.
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: [email protected]
(cherry picked from commit 75e34d1df8b0ab56e5e658b8ef90ff6057ec954e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
round(val*dscale) produces a double result, as val and dscale are double.
However, LLVMConstInt receives unsigned long long, so there is an
implicit conversion from double to unsigned long long.
This is an undefined behavior. Therefore, we need to first explicitly
convert the round result to long long, and then let the compiler handle
conversion from that to unsigned long long.
This bug manifests itself in POWER, where all IMM values of -1 are being
converted to 0 implicitly, causing a wrong LLVM IR output.
Signed-off-by: Oded Gabbay <[email protected]>
CC: "10.6 11.0" <[email protected]>
Reviewed-by: Tom Stellard <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
(cherry picked from commit 4f2290d1612569686284609059d29a85c9de67cf)
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note this is not ideal. Since the sifm can only do source sizes upto
1024x1024 we end up using the blitter on nv4x, which is not that fast.
And on nv3x we end up using the cpu which is really slow.
Cc: "10.6 11.0" <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
(cherry picked from commit 3c6c4d4f298ec81fe57992790a68aaab2e573519)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scanout buffers on nv30 must always be non-swizzled and have special
width alignment constraints.
These constrains have been taken from the xf86-video-nouveau
src/nv_accel_common.c: nouveau_allocate_surface() function.
nouveau_allocate_surface() applies these width constraints only when a
tiled attribute is set, which it sets for all surfaces allocated via
dri, and this "tiling" is not the same as swizzling, scanout surfaces
must be linear / have a uniform_pitch or only complete garbage is shown.
This commit fixes dri3 on nv30 showing a garbled display, with dri3 the
scanout buffers are allocated by mesa, rather then by the ddx, and the
wrong stride of these buffers was causing the garbled display.
Cc: "10.6 11.0" <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Ilia Mirkin <[email protected]>
(cherry picked from commit 3329703eb116a7ad73bc694356b43e014532240b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids generation of undefined packing in qir and qpu instructions,
fixing a lot of rendering errors.
Fixes 8b36d107fdd (vc4: Pack the unorm-packing bits into a src MUL
instruction when possible.)
Cc: [email protected]
Signed-off-by: Boyan Ding <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
(cherry picked from commit 48de40ce9c45de154965490843f9e50407970c26)
|
|
|
|
|
|
| |
Cc: 11.0 <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
(cherry picked from commit efea7c3a3f91219db6e2fa3588388b6be4ecfa40)
|
|
|
|
|
|
| |
Cc: 11.0 <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
(cherry picked from commit 54964c77510b060806615c842692c0f393e807e6)
|
|
|
|
|
|
|
|
|
| |
This must be done before exporting a buffer as dmabuf fds, because
we lose track of who is using it and can't trust the reference counter.
Cc: 11.0 <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
(cherry picked from commit 35d0f12797237cdd38e7fd2c39d3c19e875875ca)
|
|
|
|
|
|
|
| |
Cc: 11.0 <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Acked-by: Christian König <[email protected]>
(cherry picked from commit 05af645a951fd985d0dbe3c22614e1dee8dfb3f0)
|
|
|
|
|
|
|
| |
Cc: 11.0 <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Acked-by: Christian König <[email protected]>
(cherry picked from commit 08775a219628611989ab87c621255ac3c841dcda)
|
|
|
|
|
|
|
| |
Cc: 10.6 11.0 <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Acked-by: Christian König <[email protected]>
(cherry picked from commit 9b510a9652297a63677f1d55b2bf444694fd94e1)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been chasing a geom shader hang on rv635 since I wrote
r600 geom code, and finally I hacked some values from fglrx
in and I could run texelfetch without failures.
This is totally my fault as well, maths fail 101.
This makes geom shaders on r600 not fail heavily.
Cc: "10.6" "11.0" <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Reviewed-by: Edward O'Callaghan <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
(cherry picked from commit 0de53ccc8cbee0f63ba25c9e72664b3cbd31be54)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Glenn did for finalize_loop we need to update_cf when we
add a POP at the end of a shader.
I think this fixes one of the earlier shader going off end
of memory problems we've stopped.
Reviewed-by: Glenn Kennard <[email protected]>
Cc: "10.6" "11.0" <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
(cherry picked from commit 3063913f77cd2db1a263cb824a5c8c3dcc1a51a0)
|
|
|
|
|
|
|
| |
Fixes glamor, which wants to use R8 integer textures.
Signed-off-by: Rob Clark <[email protected]>
(cherry picked from commit 000e225360c020e8b3de142c4c898baad321d242)
|
|
|
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
(cherry picked from commit afb6c24a207fe7b9917644b940e4c5d1870c5c92)
|
|
|
|
|
|
|
|
|
|
| |
This should avoid C++ fail including this header.
Reviewed-by: Marek Olšák <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
(cherry picked from commit 03b7ec877843cd622717b01c1047e08baf34facf)
Fixes: 69418831756 (r600: port si_conv_prim_to_gs_out from radeonsi)
Nominated-by: Marek Olšák <[email protected]>
|
|
|
|
|
|
| |
Cc: [email protected]
Reviewed-by: Alex Deucher <[email protected]>
(cherry picked from commit 437cb1e3f482570447501526927df4d80c845bf5)
|
|
|
|
|
|
|
|
|
|
| |
The hardware is capable of dealing with GL1-style user clip planes.
No clip vertex, no clip distances. Fixes a number of ucp tests, as well
as neverball.
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: "11.0" <[email protected]>
(cherry picked from commit 58e24b4761ec8c348bf6825c2355a6e047599306)
|
|
|
|
|
|
|
|
|
|
| |
This code was broken by the tess merge, and I totally missed it
until now. I'm not sure this fixes anything but it stops the assert.
Cc: "11.0" <[email protected]>
Reviewed-by: Glenn Kennard <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
(cherry picked from commit 6941883175612ae602a8745945153ba064f53a7a)
|
|
|
|
|
|
|
|
|
|
| |
On 32-bit we need to use PRIu64 flags for printfs,
otherwise this segfaults in R600_DEBUG=help otherwise.
Reviewed-by: Marek Olšák <[email protected]>
Cc: "11.0" <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
(cherry picked from commit 8d6d0cc17d945317f44328a7761801e6781dc3fc)
|
|
|
|
|
|
|
| |
Signed-off-by: Glenn Kennard <[email protected]>
Cc: <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
(cherry picked from commit 608c7b4a63d5818f7ae0b3d48496b02cf8458d9b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Shaders that contain instruction data after an instruction with EOP could end
up parsing that as an instruction, leading to various crashes and asserts in
SB as it gets very confused if it sees for instance a loop start instruction
jumping off to some random point.
Add a couple of asserts, and print EOP bit if set in old asm printer.
Signed-off-by: Glenn Kennard <[email protected]>
Cc: <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
(cherry picked from commit a830225adbb77073272961df409885cca6b861ee)
|
|
|
|
|
|
|
|
|
|
| |
e8e443 missed adding check for undef values also in
unreserve function, leading to an assert triggering.
Signed-off-by: Glenn Kennard <[email protected]>
Cc: <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
(cherry picked from commit 36f1999a87258603b6720d55e6020d5d24c215c9)
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 567394112d904096abff1d994ab952f475dfb444.
It regressed performance. It looks like smaller IBs are better, because
the GPU goes idle quicker and there is less waiting for buffers and fences.
Cc: 11.0 <[email protected]>
(cherry picked from commit a83c36b5c0c64c717ced76db89bab900006648aa)
|
|
|
|
|
|
|
|
| |
This fixes bin/ext_framebuffer_multisample-formats all_samples
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: "11.0" <[email protected]>
(cherry picked from commit e18c29b03105567cf20bc235ce23cf08986cc537)
|
|
|
|
|
|
|
|
|
| |
Same as commit 1af0641db but for nvc0. If an integer texture is
bound to RT0, don't do alpha-to-one or alpha-to-coverage.
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: "11.0" <[email protected]>
(cherry picked from commit a6ad49cbbd599aec054d0a3163fff5ad724f2b18)
|
|
|
|
|
|
| |
Signed-off-by: Ilia Mirkin <[email protected]>
Cc: "11.0" <[email protected]>
(cherry picked from commit abbf05cfc2bea0787bcf710ef984d73ee8ba8f9e)
|
|
|
|
|
|
|
|
|
| |
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=91726
Signed-off-by: Glenn Kennard <[email protected]>
Cc: "11.0" <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
(cherry picked from commit 50932268aad0cc21511f370793e77c76e038bd06)
|
|
|
|
| |
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
| |
The build/file was removed with an earlier commit while the EXTRA_DIST
was forgotten.
Fixes: 66d77cd71c6 (scons: don't build the kms-dri winsys)
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
| |
The files are not referenced in any other place in whole of
mesa. They are likely remnants of the early development stage.
Signed-off-by: Emil Velikov <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Edward O'Callaghan <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Edward O'Callaghan <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
I switched us to tracking whether the results *could* go to r4, but then
didn't make a separate register class for the class bits that included r4.
Switch the "any" class to actually be "any", and name the "any but r4"
class more appropriately.
total instructions in shared programs: 96798 -> 94680 (-2.19%)
instructions in affected programs: 62736 -> 60618 (-3.38%)
|
|
|
|
|
| |
total instructions in shared programs: 97580 -> 96798 (-0.80%)
instructions in affected programs: 52826 -> 52044 (-1.48%)
|
| |
|
| |
|
|
|
|
|
| |
I thought I'd converted this over previously. It was copy propagating
MOVs badly with the new destination packing flags.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had several reports of users hitting bugs
with the other path to upload constants,
and switching to the user constant buffer
path solves the bugs.
User constant buffers are expected to be slower
for Nvidia cards, so ideally this patch should be
reverted when the path is fixed.
Reviewed-by: Axel Davy <[email protected]>
Signed-off-by: Krzysztof Sobiecki <[email protected]>
|
|
|
|
|
|
| |
release build was complaining
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
| |
release build was complaining
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
| |
The compiler was complaining the value may be uninitialised
when it is used (which is wrong). Initialize to NULL to silent
the warning.
|
|
|
|
| |
There was an unused variable
|
|
|
|
|
|
|
|
| |
This is quite rare that an app does set again
the same shaders, but it isn't an expensive check
either.
Signed-off-by: Axel Davy <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
It is very common for d3d9 apps to set again the constants
they need before every draw call, even if nothing changed.
Since we are mostly gpu bound, it is better to check
for change, and upload constants again (and thus use
gpu bandwith) only if the constants changed.
Signed-off-by: Axel Davy <[email protected]>
|