Skip to content
  1. Mar 04, 2019
  3. Mar 02, 2019
    • Erico Nunes's avatar
      ppir: regalloc: debug option for register spilling · df79b36a
      Erico Nunes authored 
      

This commit adds an option to force register spilling usage, for
debugging and testing purposes.
The option is picked from an environment variable which will cause the
register allocation to trigger the register spilling routine for a
specified number of times, even if the register allocator originally
succeeded.

Signed-off-by: default avatarErico Nunes <nunes.erico@gmail.com>
      df79b36a
    • Erico Nunes's avatar
      ppir: regalloc: register spilling · 8144e107
      Erico Nunes authored 
      

This implements register spilling for ppir. That is, storing some values
in memory as temporaries for when the number of available pp registers
is not enough.

The strategy for spilling is to find the most long lived register during
the program and spill it, hoping that the number of iterations spilling
registers is kept to a minimum. Then, for each use of the chosen
register, the register allocator will insert instructions to load the
value from memory before using, and in case of a write operation, insert
another instruction to store it afterwards.
To account for operations partially updating vector registers, a load
operation is also inserted before write operations.
Many of these operations might not be absolutely necessary in all cases,
but instructions are inserted anyway in order to keep the spilling
algorithm simpler.
Registers are always stored as vec4 in memory even if their use is not 4
components, again to keep the algorithm for spilling simpler.

This implementation for spilling is not the most optional possible, but
it is a working implementation. Hopefully, spilling should be left as a
last resource and effort is best spent optimizing other parts of ppir
rather than in optimizing the use of temporaries.

This code has been tested with a debug patch that forces spilling
regardless of whether the mesa register allocator succeeded or not.
It was possible to test multiple spilling iterations and it seems to
work. Also, the fragment shader shipped in the gbm-surface-render-two
gfx example requires spilling to be implemented with ppir, and it
renders successfully with this patch.

Signed-off-by: default avatarErico Nunes <nunes.erico@gmail.com>
      8144e107
    • Erico Nunes's avatar
      lima: prepare pp stack registers configuration · 940611b2
      Erico Nunes authored 
      

This commit prepares the pp command stream to set the fragment shader
stack address and size registers.
These registers are part of the pp frame register.
The address set has to be different per pp, and the value is expected to
be sent to the kernel in a separate variable than the pp frame register
structure.
The size register is also set per pp, all pp get the same value as the
value in the pp frame register structure. The size register is composed
by the "stack size" and "stack offset" values.

The lima ppir still does not implement the actual use of temporaries as
of this commit, this implementation is to be done in an upcoming patch.

Signed-off-by: default avatarErico Nunes <nunes.erico@gmail.com>
      940611b2
    • Erico Nunes's avatar
      ppir: support load temporaries · 2a99b2ae
      Erico Nunes authored 
      

Signed-off-by: default avatarErico Nunes <nunes.erico@gmail.com>
      2a99b2ae
    • Erico Nunes's avatar
      ppir: support store temporaries · 70c8896f
      Erico Nunes authored 
      

Signed-off-by: default avatarErico Nunes <nunes.erico@gmail.com>
      70c8896f
    • Qiang Yu's avatar
      lima: adopt kernel context interface change · 5fd8d345
      Qiang Yu authored 
      

Signed-off-by: default avatarQiang Yu <yuq825@gmail.com>
      5fd8d345
    • Qiang Yu's avatar
      lima: adopt kernel get param interface change · a32dcbb5
      Qiang Yu authored 
      

Signed-off-by: default avatarQiang Yu <yuq825@gmail.com>
      a32dcbb5
  5. Feb 18, 2019
    • marmeladema's avatar
      lima: fix NULL pointer dereference on error path in lima_context_destroy · 0dd3dee3
      marmeladema authored 
      When the following code path happens:
lima_context_create
|-> lima_submit_create
    |-> drmSyncobjCreate: can fail here
    |Thus ctx->pp_submit and ctx->gp_submit are NULL
    |-> lima_context_destroy
        |-> lima_submit_free: will access submit->in_sync_fd

It triggers a segfault in mesa because we are trying to derefence
both ctx->pp_submit and ctx->gp_submit which are NULL.
      0dd3dee3
  7. Feb 17, 2019
  9. Feb 16, 2019
  11. Feb 13, 2019
  13. Feb 12, 2019
  15. Jan 27, 2019
  17. Jan 08, 2019
  19. Jan 01, 2019
  21. Dec 30, 2018
  23. Dec 29, 2018
  25. Dec 23, 2018
  27. Dec 20, 2018
  29. Dec 14, 2018
  31. Dec 12, 2018
  33. Dec 11, 2018
  35. Dec 10, 2018
  37. Dec 08, 2018