NV20 seems to be very different to NV10. In vertex array, pos is first,
not last. There are maximum 16 attributes and only few are currently
known.
This makes trivial/tri work on NV20.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
VIEWPORT_SCALE0 seems to do with translation and the sane
value for x and y is zero.
VIEWPORT_SCALE1 is still a mystery.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Someone changed the st_get_framebuffer_surface() signature, and did not
update the users in Nouveau winsys. Surface is returned via a pointer
now instead of returning it from the function. No semantic changes.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Fixes:
In file included from nouveau_context_dri.c:6:
../../../../../../src/mesa/state_tracker/st_public.h:87: warning:
'struct pipe_texture' declared inside parameter list
../../../../../../src/mesa/state_tracker/st_public.h:87: warning: its
scope is only this definition or declaration, which is probably not what
you want
../../../../../../src/mesa/state_tracker/st_public.h:104: warning:
'struct pipe_texture' declared inside parameter list
Signed-off-by: Pekka Paalanen <pq@iki.fi>
There were several bugs in the infrastructure for these two routines.
1. GLX_ALIAS was incorrectly used. The function and its alias must be
identical! glXMakeContextCurrent / glXMakeCurrentReadSGI and
MakeContextCurrent had different parameters. This caused the last
parameter of MakeContextCurrent to get random values.
2. We based the implementation of glXMakeContextCurrent on the manual
page instead of the GLX spec. The GLX spec says that
glXMakeContextCurrent can be passed a Window as a drawable. When this
happens, it will behave just like glXMakeCurrentReadSGI or
glXMakeCurrent.
3. If there was a problem finding or creating the DRI drawable,
MakeContextCurrent would crash instead of returning an error.
This commit fixes all three issues, and fixes bug #18367 and bug #19625.
The upstream linux kernel headers and libdrm kernel headers disagree on the
tag name for the sarea struct: _drm_i915_sarea vs drm_i915_sarea. They
both typedef it to drm_i915_sarea_t though, so just use that.
It's been broken and deprecated for a while, so it's time to die. This has the
wonderful benefit of cleaning up the code a fair amount; making it marginally
less twisty.
I'm unsure if the for loops in IntelWindowMoved are still needed.
This commit is mostly just a cosmetic change that cleans-up the interfaces,
replacing pipe_winsys::surface_* calls by
/**
* Allocate storage for a display target surface.
*
* Often surfaces which are meant to be blitted to the front screen (i.e.,
* display targets) must be allocated with special characteristics, memory
* pools, or obtained directly from the windowing system.
*
* This callback is invoked by the pipe_screenwhen creating a texture marked
* with the PIPE_TEXTURE_USAGE_DISPLAY_TARGET flag to get the underlying
* buffer storage.
*/
struct pipe_buffer *(*surface_buffer_create)(struct pipe_winsys *ws,
unsigned width, unsigned height,
enum pipe_format format,
unsigned usage,
unsigned *stride);
Most drivers were updated but not all were tested. Use the softpipe pipe
driver and the xlib winsys changes as a reference when fixing other drivers.
This utility is useful for hardware that doesn't support HW index buffers.
It's a bit inefficient but appears to give a substantial performance gain,
as we can emit tri strips that would otherwise be split into triangles.
Dri drivers often may validate first a write drawable and then a read
drawable ("readable"). However, the hardware lock may be unlocked when
validating the readable, causing the write drawable status to be stale.
Drivers should use this macro instead when validating two drawables.
