| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
The opcodes and strings were reversed. Quotient means division, and
modulus means remainder.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
| |
Follow a subset of changes in 7b1d94e5d1f53ac5f59000176aea1d02fc9a1181.
There are known issues, but it works to a certain degree. Non-working
demos also fail gracefully. More importantly, it fixes the build.
|
|
|
|
| |
Follow changes in c661ecce1089000c3fca9a543713f8264221be50.
|
|
|
|
| |
Follow the changes in 6602bda23ba6c4351eb7f04d34803103a68ac2db.
|
|
|
|
|
|
|
|
|
| |
In particular, S3TC compressed textures need align_h == 4.
Fixes skybox errors in Quake 4 and FEAR.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34628
Signed-off-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
The list of numbers in (constant type (<numbers>)) needs to contain
exactly type->components() numbers (16 for a mat4, 3 for a vec3, etc.)
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
| |
Throwing away the extra numbers ought to match the existing behavior.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Each of these vecN constants only provided one component, which is
illegal. The printed IR is meant to contain exactly as many components
as are necessary; the IR reader does not splat single values.
Signed-off-by: Kenneth Graunke <[email protected]>
Reviewed-by: Paul Berry <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
| |
I introduced a regression in here, I've just split the logic ot now, so
its easier to read/understand.
Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=40664
Signed-off-by: Dave Airlie <[email protected]>
|
|
|
|
| |
MSVC does not support inline keyword.
|
|
|
|
|
|
| |
Fixes glsl-vs-point-size.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
This is required to ensure ordering between reads and writes within a
thread.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
We were failing to relocate, so on the first draw run our scratch
would tend to get written to 0x0.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
We were passing an MRF as the source argument, instead of using the
implied move and putting the MRF number in the proper place in the
instruction encoding.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
The second vertex was getting a garbage index.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Fixes a giant pile of VS tests on gen4.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
On the old backend, we used scalar mode because Mesa IR math is
result.xyzw = math(op0.xxxx), which matched up well. However, in GLSL
IR we do things like result.xy = math(op0.xy), so we want vector mode.
For the common case of result.x = math(op0.x), performance will be the
same (no cost for un-executed channels), though result.xyzw =
math(op0.xxxx) would be worse.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Fixes vs-pow-float-float and friends.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
When we tried to retype a brw_null_reg() in CMP(), the retyping didn't
take effect because HW_REG just ignores the type field.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
If you get your total GRF count wrong, you write over some other
shader's g0, and the GPU fails shortly thereafter.
Reviewed-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
| |
Signed-off-by: Stuart Abercrombie <[email protected]>
Signed-off-by: Stéphane Marchesin <[email protected]>
|
|
|
|
|
|
|
| |
We need this for the upcoming fix for sw texture_from_pixmap.
Signed-off-by: Stuart Abercrombie <[email protected]>
Signed-off-by: Stéphane Marchesin <[email protected]>
|
|
|
|
|
|
| |
Signed-off-by: nobled <[email protected]>
Signed-off-by: Stuart Abercrombie <[email protected]>
Signed-off-by: Stéphane Marchesin <[email protected]>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Apparently the x11 driver had a hack for glide passthrough. Who knew?
Signed-off-by: Adam Jackson <[email protected]>
|
|
|
|
| |
Signed-off-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
| |
This belonged to the now-dead swrast-on-fbdev driver.
Signed-off-by: Adam Jackson <[email protected]>
|
|
|
|
| |
Signed-off-by: Adam Jackson <[email protected]>
|
|
|
|
|
|
| |
Causes crash and stack corruption.
Needs more investigation. Disable for now.
|
|
|
|
|
|
|
|
| |
Current just the items that have been removed from Mesa are mentioned
in the release notes.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Mesa hasn't supported color-index rendering for a long time.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
| |
GL_COLOR_INDEX produced the same result (because GL_BITMAP is always
used for stencil glDrawPixels), but it was confusing to read. I spent
about 15 minutes wondering, "WTF?"
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
| |
Mesa hasn't supported color-index rendering for a long time.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
_mesa_make_temp_float_image can't work on color-index textures, but
there is no such thing as a color-index texture anymore.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
These sampling functions don't work on color-index textures, but there
is no such thing as a color-index texture anymore.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
These enums were only valid with the paletted texture extensions.
This allows a couple other trivial clean-ups.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
::UpdateTexturePalette
There's nothing left that can call any of these functions. This also
removes the meta-ops code that implemented the first two.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EXT_shared_texture_palette
This was also discussed at XDS 2010. However, actually making the
change was delayed because several drivers still exposed these
extensions to significant benefit (e.g., tdfx). Now that those
drivers have been removed, this code can be removed as well.
v2: A lot of bits that were missed in the previous patch have been removed.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Since we now lay out the VUE the same way regardless of whether
two-sided color is enabled, brw_compute_vue_map() no longer needs to
know whether two-sided color is enabled. This allows the two-sided
color flag to be removed from the clip, GS, and VS keys, so that fewer
GPU programs need to be recompiled when turning two-sided color on and
off.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing two-sided color on GEN6+, we use the SF unit's
INPUTATTR_FACING mode to cause front colors to be used on front-facing
triangles, and back colors to be used on back-facing triangles. This
mode requires that the front and back colors be adjacent in the VUE.
Previously, we would only place front and back colors adjacent in the
VUE when two-sided color was enabled. Now we place them adjacent in
the VUE whether two-sided color is enabled or not. (We still only
swizzle the colors when two-sided color is enabled, so there should be
no user-visible change).
This simplifies the implementation of the VUE map and reduces the
amount of code that is dependent on two-sided color mode.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The previous computation had two bugs: (a) it used a formula based on
Gen5 for Gen6 and Gen7 as well. (b) it failed to account for the fact
that PSIZ is stored in the VUE header. Fortunately, both bugs caused
it to compute a URB size that was too large, which was benign. This
patch computes the URB size directly from the VUE map, so it gets the
result correct in all circumstances.
Reviewed-by: Eric Anholt <[email protected]>
|