[Mesa-dev] [PATCH] gallium/dri: Support DRI Image extension version 6 (v3)
From: Christopher James Halse Rogers
v2: Pick out the correct gl_context pointer
v3: Don't leak pipe_resources on error path
Set img->dri_format correctly
---
src/gallium/state_trackers/dri/drm/dri2.c | 72 ++-
1 file changed, 71 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index 868cd25..27f2147 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -33,6 +33,9 @@
#include "util/u_format.h"
#include "util/u_debug.h"
#include "state_tracker/drm_driver.h"
+#include "state_tracker/st_texture.h"
+#include "state_tracker/st_context.h"
+#include "main/texobj.h"
#include "dri_screen.h"
#include "dri_context.h"
@@ -825,6 +828,72 @@ dri2_from_planar(__DRIimage *image, int plane, void
*loaderPrivate)
return img;
}
+static __DRIimage *
+dri2_create_from_texture(__DRIcontext *context, int target, unsigned texture,
+ int depth, int level, unsigned *error,
+ void *loaderPrivate)
+{
+ __DRIimage *img;
+ struct gl_context *ctx = ((struct st_context
*)dri_context(context)->st)->ctx;
+ struct gl_texture_object *obj;
+ struct pipe_resource *tex;
+ GLuint face = 0;
+
+ obj = _mesa_lookup_texture(ctx, texture);
+ if (!obj || obj->Target != target) {
+ *error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
+ return NULL;
+ }
+
+ tex = st_get_texobj_resource(obj);
+ if (!tex) {
+ *error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
+ return NULL;
+ }
+
+ if (target == GL_TEXTURE_CUBE_MAP)
+ face = depth;
+
+ _mesa_test_texobj_completeness(ctx, obj);
+ if (!obj->_BaseComplete || (level > 0 && !obj->_MipmapComplete)) {
+ *error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
+ return NULL;
+ }
+
+ if (level < obj->BaseLevel || level > obj->_MaxLevel) {
+ *error = __DRI_IMAGE_ERROR_BAD_MATCH;
+ return NULL;
+ }
+
+ if (target == GL_TEXTURE_3D && obj->Image[face][level]->Depth < depth) {
+ *error = __DRI_IMAGE_ERROR_BAD_MATCH;
+ return NULL;
+ }
+
+ img = CALLOC_STRUCT(__DRIimageRec);
+ if (!img) {
+ *error = __DRI_IMAGE_ERROR_BAD_ALLOC;
+ return NULL;
+ }
+
+ img->level = level;
+ img->layer = depth;
+ img->dri_format =
driGLFormatToImageFormat(obj->Image[face][level]->TexFormat);
+
+ img->loader_private = loaderPrivate;
+
+ if (img->dri_format == __DRI_IMAGE_FORMAT_NONE) {
+ *error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
+ free(img);
+ return NULL;
+ }
+
+ pipe_resource_reference(&img->texture, tex);
+
+ *error = __DRI_IMAGE_ERROR_SUCCESS;
+ return img;
+}
+
static void
dri2_destroy_image(__DRIimage *img)
{
@@ -833,7 +902,7 @@ dri2_destroy_image(__DRIimage *img)
}
static struct __DRIimageExtensionRec dri2ImageExtension = {
-{ __DRI_IMAGE, 5 },
+{ __DRI_IMAGE, 6 },
dri2_create_image_from_name,
dri2_create_image_from_renderbuffer,
dri2_destroy_image,
@@ -843,6 +912,7 @@ static struct __DRIimageExtensionRec dri2ImageExtension = {
dri2_validate_usage,
dri2_from_names,
dri2_from_planar,
+dri2_create_from_texture,
};
/*
--
1.8.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/17] Modified _mesa_buffer_data to use _mesa_align_malloc.
Yes I think you are right, I guess *_mesa_align_realloc* is the correct function which should be used here. What do you think Ian? Best regards, Siavash Eliasi. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/4] dri3: Fix dri3_wait_for_sbc to wait for completion of requested SBC
Eric figured out that glXWaitForSbcOML wanted to block until the requested SBC
had been completed, which means to wait until the PresentCompleteNotify event
for that SBC had been received.
This replaces the simple sleep(1) loop (which was bogus) with a loop that just
checks to see if we've seen the specified SBC value come back in a
PresentCompleteNotify event yet.
The change is a bit larger than that as I've broken out a piece of common code
to wait for and process a single Present event for the target drawable.
Signed-off-by: Keith Packard
---
src/glx/dri3_glx.c | 55 ++
1 file changed, 39 insertions(+), 16 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index c0915f2..da3f08b 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -397,14 +397,33 @@ dri3_handle_present_event(struct dri3_drawable *priv,
xcb_present_generic_event_
free(ge);
}
+static bool
+dri3_wait_for_event(__GLXDRIdrawable *pdraw)
+{
+ xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
+ struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
+ xcb_generic_event_t *ev;
+ xcb_present_generic_event_t *ge;
+
+ ev = xcb_wait_for_special_event(c, priv->special_event);
+ if (!ev)
+ return false;
+ ge = (void *) ev;
+ dri3_handle_present_event(priv, ge);
+ return true;
+}
+
+/** dri3_wait_for_msc
+ *
+ * Get the X server to send an event when the target msc/divisor/remainder is
+ * reached.
+ */
static int
dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
int64_t remainder, int64_t *ust, int64_t *msc, int64_t *sbc)
{
xcb_connection_t *c = XGetXCBConnection(pdraw->psc->dpy);
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
- xcb_generic_event_t *ev;
- xcb_present_generic_event_t *ge;
uint32_t msc_serial;
/* Ask for the an event for the target MSC */
@@ -421,11 +440,8 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t
target_msc, int64_t divisor,
/* Wait for the event */
if (priv->special_event) {
while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) {
- ev = xcb_wait_for_special_event(c, priv->special_event);
- if (!ev)
-break;
- ge = (void *) ev;
- dri3_handle_present_event(priv, ge);
+ if (!dri3_wait_for_event(pdraw))
+return 0;
}
}
@@ -436,6 +452,11 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t
target_msc, int64_t divisor,
return 1;
}
+/** dri3_drawable_get_msc
+ *
+ * Return the current UST/MSC/SBC triplet by asking the server
+ * for an event
+ */
static int
dri3_drawable_get_msc(struct glx_screen *psc, __GLXDRIdrawable *pdraw,
int64_t *ust, int64_t *msc, int64_t *sbc)
@@ -445,12 +466,9 @@ dri3_drawable_get_msc(struct glx_screen *psc,
__GLXDRIdrawable *pdraw,
/** dri3_wait_for_sbc
*
- * Wait for the swap buffer count to increase. The only way this
- * can happen is if some other thread is doing swap buffers as
- * we no longer share swap buffer counts with other processes.
- *
- * I'm not sure this is actually useful as such, and so this
- * implementation is a kludge that just polls once a second
+ * Wait for the completed swap buffer count to reach the specified
+ * target. Presumably the application knows that this will be reached with
+ * outstanding complete events, or we're going to be here awhile.
*/
static int
dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t target_sbc, int64_t *ust,
@@ -458,10 +476,15 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t
target_sbc, int64_t *ust,
{
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
- while (priv->send_sbc < target_sbc) {
- sleep(1);
+ while (priv->recv_sbc < target_sbc) {
+ if (!dri3_wait_for_event(pdraw))
+ return 0;
}
- return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
+
+ *ust = priv->ust;
+ *msc = priv->msc;
+ *sbc = priv->recv_sbc;
+ return 1;
}
/**
--
1.8.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/4] Clean up dri3 SBC handling, enable GLX_INTEL_swap_event
I've split the GLX_INTEL_swap_event enabling patch into four bits -- the first three just fix the existing code to track SBC values correctly and to fix wait_for_sbc. The fourth is the trivial patch to actually turn on the new extension; all of the hard work for that is actually dealt with in the X server. [PATCH 1/4] dri3: Clean up struct dri3_drawable Trivial struct member cleanup -- a couple of unused fields, and one oddly placed field. [PATCH 2/4] dri3: Track full 64-bit SBC numbers, instead of just This switches all of the internal SBC tracking to use 64-bit values. I use uint64_t because I don't trust compilers with signed integer comparisons that may wrap any more. [PATCH 3/4] dri3: Fix dri3_wait_for_sbc to wait for completion of This one makes wait_for_sbc actually wait for the completion of the specified swap, rather than the queuing of that value. Makes *far* more sense this way. [PATCH 4/4] dri3: Enable GLX_INTEL_swap_event The trivial patch that just adds the extension to the list. -keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/4] dri3: Clean up struct dri3_drawable
Move the depth field up with width and height.
Remove unused previous_time and frames fields.
Signed-off-by: Keith Packard
---
src/glx/dri3_priv.h | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 05f66cf..34c67a6 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -177,7 +177,7 @@ dri3_pixmap_buf_id(enum dri3_buffer_type buffer_type)
struct dri3_drawable {
__GLXDRIdrawable base;
__DRIdrawable *driDrawable;
- int width, height;
+ int width, height, depth;
int swap_interval;
uint8_t have_back;
uint8_t have_fake_front;
@@ -193,13 +193,9 @@ struct dri3_drawable {
/* For WaitMSC */
uint32_t present_msc_request_serial;
uint32_t present_msc_event_serial;
-
- uint64_t previous_time;
- unsigned frames;
struct dri3_buffer *buffers[DRI3_NUM_BUFFERS];
int cur_back;
- int depth;
uint32_t *stamp;
--
1.8.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/4] dri3: Track full 64-bit SBC numbers, instead of just 32-bits
Tracking the full 64-bit SBC values makes it clearer how those values are
being used, and simplifies the wait_msc code. The only trick is in
re-constructing the full 64-bit value from Present's 32-bit serial number that
we use to pass the SBC value from request to event.
Signed-off-by: Keith Packard
---
src/glx/dri3_glx.c | 34 +-
src/glx/dri3_priv.h | 16 +---
2 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index 669f0bb..c0915f2 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -364,10 +364,17 @@ dri3_handle_present_event(struct dri3_drawable *priv,
xcb_present_generic_event_
case XCB_PRESENT_COMPLETE_NOTIFY: {
xcb_present_complete_notify_event_t *ce = (void *) ge;
- if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP)
- priv->present_event_serial = ce->serial;
- else
- priv->present_msc_event_serial = ce->serial;
+ /* Compute the processed SBC number from the received 32-bit serial
number merged
+ * with the upper 32-bits of the sent 64-bit serial number while
checking for
+ * wrap
+ */
+ if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) {
+ priv->recv_sbc = (priv->send_sbc & 0xLL) | ce->serial;
+ if (priv->recv_sbc > priv->send_sbc)
+priv->recv_sbc -= 0x1;
+ } else {
+ priv->recv_msc_serial = ce->serial;
+ }
priv->ust = ce->ust;
priv->msc = ce->msc;
break;
@@ -398,12 +405,13 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t
target_msc, int64_t divisor,
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
xcb_generic_event_t *ev;
xcb_present_generic_event_t *ge;
+ uint32_t msc_serial;
/* Ask for the an event for the target MSC */
- ++priv->present_msc_request_serial;
+ msc_serial = ++priv->send_msc_serial;
xcb_present_notify_msc(c,
priv->base.xDrawable,
- priv->present_msc_request_serial,
+ msc_serial,
target_msc,
divisor,
remainder);
@@ -412,7 +420,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t
target_msc, int64_t divisor,
/* Wait for the event */
if (priv->special_event) {
- while (priv->present_msc_request_serial !=
priv->present_msc_event_serial) {
+ while ((int32_t) (msc_serial - priv->recv_msc_serial) > 0) {
ev = xcb_wait_for_special_event(c, priv->special_event);
if (!ev)
break;
@@ -423,7 +431,7 @@ dri3_wait_for_msc(__GLXDRIdrawable *pdraw, int64_t
target_msc, int64_t divisor,
*ust = priv->ust;
*msc = priv->msc;
- *sbc = priv->sbc;
+ *sbc = priv->recv_sbc;
return 1;
}
@@ -450,7 +458,7 @@ dri3_wait_for_sbc(__GLXDRIdrawable *pdraw, int64_t
target_sbc, int64_t *ust,
{
struct dri3_drawable *priv = (struct dri3_drawable *) pdraw;
- while (priv->sbc < target_sbc) {
+ while (priv->send_sbc < target_sbc) {
sleep(1);
}
return dri3_wait_for_msc(pdraw, 0, 0, 0, ust, msc, sbc);
@@ -1282,15 +1290,15 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t
target_msc, int64_t divisor,
/* Compute when we want the frame shown by taking the last known
successful
* MSC and adding in a swap interval for each outstanding swap request
*/
- ++priv->present_request_serial;
+ ++priv->send_sbc;
if (target_msc == 0)
- target_msc = priv->msc + priv->swap_interval *
(priv->present_request_serial - priv->present_event_serial);
+ target_msc = priv->msc + priv->swap_interval * (priv->send_sbc -
priv->recv_sbc);
priv->buffers[buf_id]->busy = 1;
xcb_present_pixmap(c,
priv->base.xDrawable,
priv->buffers[buf_id]->pixmap,
- priv->present_request_serial,
+ (uint32_t) priv->send_sbc,
0,/* valid */
0,/* update */
0,/* x_off */
@@ -1302,7 +1310,7 @@ dri3_swap_buffers(__GLXDRIdrawable *pdraw, int64_t
target_msc, int64_t divisor,
target_msc,
divisor,
remainder, 0, NULL);
- ret = ++priv->sbc;
+ ret = (int64_t) priv->send_sbc;
/* If there's a fake front, then copy the source back buffer
* to the fake front to keep it up to date. This needs
diff --git a/src/glx/dri3_priv.h b/src/glx/dri3_priv.h
index 34c67a6..f1fec3c 100644
--- a/src/glx/dri3_priv.h
+++ b/src/glx/dri3_priv.h
@@ -183,16 +183,18 @@ struct dri3_drawable {
uint8_t have_fake_front;
uint8_t is_pixmap;
- uint32_t present_request_serial;
-
[Mesa-dev] [PATCH 4/4] dri3: Enable GLX_INTEL_swap_event
Now that we're tracking SBC values correctly, and the X server has the ability
to send the GLX swap events from a PresentPixmap request, enable this extension.
Signed-off-by: Keith Packard
---
src/glx/dri3_glx.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/src/glx/dri3_glx.c b/src/glx/dri3_glx.c
index da3f08b..aa5dd21 100644
--- a/src/glx/dri3_glx.c
+++ b/src/glx/dri3_glx.c
@@ -1525,23 +1525,7 @@ dri3_bind_extensions(struct dri3_screen *psc, struct
glx_display * priv,
__glXEnableDirectExtension(&psc->base, "GLX_SGI_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_MESA_swap_control");
__glXEnableDirectExtension(&psc->base, "GLX_SGI_make_current_read");
-
- /*
-* GLX_INTEL_swap_event is broken on the server side, where it's
-* currently unconditionally enabled. This completely breaks
-* systems running on drivers which don't support that extension.
-* There's no way to test for its presence on this side, so instead
-* of disabling it unconditionally, just disable it for drivers
-* which are known to not support it, or for DDX drivers supporting
-* only an older (pre-ScheduleSwap) version of DRI2.
-*
-* This is a hack which is required until:
-* http://lists.x.org/archives/xorg-devel/2013-February/035449.html
-* is merged and updated xserver makes it's way into distros:
-*/
-// if (pdp->swapAvailable && strcmp(driverName, "vmwgfx") != 0) {
-// __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
-// }
+ __glXEnableDirectExtension(&psc->base, "GLX_INTEL_swap_event");
mask = psc->image_driver->getAPIMask(psc->driScreen);
--
1.8.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] gallium/cso: fix sampler / sampler_view counts
The entire series looks good to me. > Now that it is possible to query drivers for the max sampler view it should > be safe to increase this without crashing. > Not entirely convinced this really works correctly though if state trackers > using non-linked sampler / sampler_views use this. I'm not sure if I get this. What would be the problem in that case? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] Picks to 10.0 release branch
On Sat, Nov 23, 2013 at 03:30:30PM -0800, Ian Romanick wrote: > I believe that I have picked over all of the patches marked for the 10.0 > release branch. I have included the full list far below. There are a > few patches that were sent to the mesa-stable mailing list that do not > appear to have landed on master yet. I have not picked these over. > These are: > > radeon/compute: Unconditionally inline all functions I just pushed this patch to master, so it should show up on your pick list now. -Tom > docs: update 10.0 relnotes for GL_NV_vdpau_interop > docs: Add Haiku mention to the release notes > glsl: Fix lowering of direct assignment in lower_clip_distance. > > In addition, v1 of the following patch was NAKed for stable, but I > didn't see any mention of the NAK being revoked in v2. I'm just waiting > to hear back from the patch author. > > meta: fix meta clear of layered framebuffers > > If a patch that you believe should be on the release branch is not on > one of these two lists, please send (or resend) it to mesa-stable... or > at least send me links to the archive because I accidentally deleted the > message. :( > > I am currently planning to do Mesa 10.0-rc2 later today. > > 1efe2ef620ba592d25d127d64d435fbf2db0bbda i965: Fix streamed state > dumping/annotation after the blorp-flush change. > 47ff55fa86f9bf74cf05944f4420bb6f2208790a mesa: Implement > GL_FRAMEBUFFER_ATTACHMENT_LAYERED query. > 8f4d95d41c0e84766279d7220adec959f86ed081 mesa: Fix texture target validation > for glFramebufferTexture() > 79d727e06302e500c5dcb0e766f959a77510eb08 i965: Fix fast clear of depth > buffers. > 7f99ae72c402869b76f297f87e8ef5b236f5c113 i965: Fix blorp clear of layered > framebuffers. > e934782b2a87cab79fde9e9c45bd796863dcaf7f i965: refactor blorp clear code in > preparation for layered clears. > ffa073ec72fe33f2155871fc511edbdb43152220 mesa: Track number of layers in > layered framebuffers. > 620d11aed40088a33011eb62dee911ac5b5a6985 radeonsi/compute: Fix LDS size > calculation > c8cf5dc401a964cacf88d6bd347f07f31221fc85 r600g/compute: Add a work-around for > flushing issues on Cayman > a645df01340d758b79905696a7ae41e196ba57f5 glsl: Fix interstage uniform > interface block link error detection. > 3470916d6af016254fe938324d67d58307384920 glsl: Fix cross-version linking > between VS and GS. > 320f2fa45daa27009137a52bee79267482a0bf96 glsl: Prohibit illegal mixing of > redeclarations inside/outside gl_PerVertex. > 2747e720362869c0a3ff7724745d4b9c11c86f9a mesa: enable GL_TEXTURE_LOD_BIAS > set/get > d4b7ff7fe00b8ff9734c2cd7cb6561c5d3653ec9 glx: don't fail out when no configs > if we have visuals > 63b02533f04226d391c62a7c67cdbf2ca927b5bd mesa/swrast: fix inverted front > buffer rendering with old-school swrast > 19f05b26ba638c51d4fe75107b7902906cc2b106 i965: Link -ldl after libmesa.la > 11da04e1bbc283fd7fb322bcc632641afe2dc6d7 st/mesa: fix GL_FEEDBACK mode > inverted Y coordinate bug > 989d65009018d25b54496060a9ab5bf707849577 i965/vec4: Fix broken IR annotation > in debug output. > 9495fb4fff15c7f0e8b07bc101dd7a8ccfc6421c r600g/compute: Fix handling of > global buffers in r600_resource_copy_region() > 521c59f1327e8902e4bb9dc4f926a54a1cb26bd3 gallium: Pass version scripts to > linker using --version-script= > eafb9f675611ba40ca7ed8da95d90e3f87cc13c1 clover: Optionally return context's > devices from clGetProgramInfo() > 5af1fb532451f41d7cd920497d468582711bac00 i965/gen7: Emit workaround flush > when changing GS enable state. > 0040edcf9dd401b1b49d487c0ab15ad6aae8d4df docs: indicate > GLX_MESA_query_renderer's completion > defff44e1cb1f7524842ac69a876d290da588b9f docs: add a note about removed state > tracker/targets > 8f78b06dca4367be4dfbc4d8b984f260c344b2b5 r600g/sb: work around hw issues with > stack on eg/cm > 367241ec64c8140b0f1f5f6b452dc315684e4343 i965: Add missing break in > SHADER_OPCODE_GEN7_SCRATCH_READ case. > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] R600/SI: Implement spilling of SGPRs v4
From: Tom Stellard
SGPRs are spilled into VGPRs using the {READ,WRITE}LANE_B32 instructions.
v2:
- Fix encoding of Lane Mask
- Use correct register flags, so we don't overwrite the low dword
when restoring multi-dword registers.
v3:
- Register spilling seems to hang the GPU, so replace all shaders
that need spilling with a dummy shader.
v4:
- Fix *LANE definitions
- Change destination reg class for 32-bit SMRD instructions
https://bugs.freedesktop.org/show_bug.cgi?id=71285
NOTE: This is a candidate for the 3.4 branch.
---
lib/Target/R600/AMDGPUInstrInfo.h | 20 -
lib/Target/R600/SIInstrInfo.cpp | 75 +++
lib/Target/R600/SIInstrInfo.h | 12 +
lib/Target/R600/SIInstructions.td | 24 --
lib/Target/R600/SIMachineFunctionInfo.cpp | 35 ++-
lib/Target/R600/SIMachineFunctionInfo.h | 28
lib/Target/R600/SIRegisterInfo.cpp| 19
lib/Target/R600/SIRegisterInfo.h | 1 +
8 files changed, 199 insertions(+), 15 deletions(-)
diff --git a/lib/Target/R600/AMDGPUInstrInfo.h
b/lib/Target/R600/AMDGPUInstrInfo.h
index ce5b58c..426910c 100644
--- a/lib/Target/R600/AMDGPUInstrInfo.h
+++ b/lib/Target/R600/AMDGPUInstrInfo.h
@@ -78,18 +78,18 @@ public:
unsigned DestReg, unsigned SrcReg,
bool KillSrc) const = 0;
- void storeRegToStackSlot(MachineBasicBlock &MBB,
- MachineBasicBlock::iterator MI,
- unsigned SrcReg, bool isKill, int FrameIndex,
- const TargetRegisterClass *RC,
- const TargetRegisterInfo *TRI) const;
- void loadRegFromStackSlot(MachineBasicBlock &MBB,
-MachineBasicBlock::iterator MI,
-unsigned DestReg, int FrameIndex,
-const TargetRegisterClass *RC,
-const TargetRegisterInfo *TRI) const;
virtual bool expandPostRAPseudo(MachineBasicBlock::iterator MI) const;
+ virtual void storeRegToStackSlot(MachineBasicBlock &MBB,
+ MachineBasicBlock::iterator MI,
+ unsigned SrcReg, bool isKill, int
FrameIndex,
+ const TargetRegisterClass *RC,
+ const TargetRegisterInfo *TRI) const;
+ virtual void loadRegFromStackSlot(MachineBasicBlock &MBB,
+MachineBasicBlock::iterator MI,
+unsigned DestReg, int FrameIndex,
+const TargetRegisterClass *RC,
+const TargetRegisterInfo *TRI) const;
protected:
MachineInstr *foldMemoryOperandImpl(MachineFunction &MF,
diff --git a/lib/Target/R600/SIInstrInfo.cpp b/lib/Target/R600/SIInstrInfo.cpp
index c05d278..b3df0d6 100644
--- a/lib/Target/R600/SIInstrInfo.cpp
+++ b/lib/Target/R600/SIInstrInfo.cpp
@@ -16,6 +16,7 @@
#include "SIInstrInfo.h"
#include "AMDGPUTargetMachine.h"
#include "SIDefines.h"
+#include "SIMachineFunctionInfo.h"
#include "llvm/CodeGen/MachineInstrBuilder.h"
#include "llvm/CodeGen/MachineRegisterInfo.h"
#include "llvm/MC/MCInstrDesc.h"
@@ -185,6 +186,80 @@ unsigned SIInstrInfo::commuteOpcode(unsigned Opcode) const
{
return Opcode;
}
+void SIInstrInfo::storeRegToStackSlot(MachineBasicBlock &MBB,
+ MachineBasicBlock::iterator MI,
+ unsigned SrcReg, bool isKill,
+ int FrameIndex,
+ const TargetRegisterClass *RC,
+ const TargetRegisterInfo *TRI) const {
+ MachineRegisterInfo &MRI = MBB.getParent()->getRegInfo();
+ SIMachineFunctionInfo *MFI =
MBB.getParent()->getInfo();
+ DebugLoc DL = MBB.findDebugLoc(MI);
+ unsigned KillFlag = isKill ? RegState::Kill : 0;
+
+ if (TRI->getCommonSubClass(RC, &AMDGPU::SGPR_32RegClass)) {
+if (RI.allUsesCanBeCopiedToVGPR(MRI, MI->getOperand(0).getReg())) {
+ unsigned VReg = MRI.createVirtualRegister(&AMDGPU::VReg_32RegClass);
+ BuildMI(MBB, MI, DL, get(AMDGPU::COPY), VReg)
+ .addReg(SrcReg, KillFlag);
+ MFI->SpillTracker.addSpilledReg(FrameIndex, VReg);
+} else {
+ unsigned Lane = MFI->SpillTracker.getNextLane(MRI);
+ BuildMI(MBB, MI, DL, get(AMDGPU::V_WRITELANE_B32),
+ MFI->SpillTracker.LaneVGPR)
+ .addReg(SrcReg, KillFlag)
+ .addImm(Lane);
+ MFI->SpillTracker.addSpilledReg(FrameIndex, MFI->SpillTracker.LaneVGPR,
+ Lane);
+}
+ } else {
+for (unsigned i = 0, e = RC->getSize() / 4; i != e; ++i) {
+ unsigned SubReg = MRI.createVirtualRegister(&AMDGPU::SReg_32RegClass);
+ BuildMI(MBB, MI, MBB.findDeb
Re: [Mesa-dev] [PATCH 02/17] Modified softpipe to return 64 in case of PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT.
Hello, thanks for reviewing these patches! There is a patch to address these issues: http://lists.freedesktop.org/archives/mesa-dev/2013-November/049057.html Best Regards, Siavash Eliasi. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/8] radeonsi: add driver support for layered rendering and AMD_vertex_shader_layer
On Son, 2013-11-24 at 11:55 +0100, Marek Olšák wrote: > From: Marek Olšák The radeonsi patches in this series are Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
On Sat, Nov 23, 2013 at 2:10 AM, Ville Syrjälä
wrote:
> On Fri, Nov 22, 2013 at 03:43:13PM -0800, Keith Packard wrote:
>> Ville Syrjälä writes:
>>
>> > What is this format anyway? -ENODOCS
>>
>> Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)
>>
>> > If its just an srgb version of ARGB, then I wouldn't really want it
>> > in drm_fourcc.h. I expect colorspacy stuff will be handled by various
>> > crtc/plane properties in the kernel so we don't need to encode that
>> > stuff into the fb format.
>>
>> It's not any different from splitting YUV codes from RGB codes;
>
> Not really. Saying something is YUV (or rather Y'CbCr) doesn't
> actually tell you the color space. It just tells you whether the
> information is encoded as R+G+B or Y+Cb+Cr. How you convert between
> them is another matter. You need to know the gamma, color primaries,
> chroma siting for sub-sampled YCbCr formats, etc.
Yep. Fbdev has a separation of type (how pixel values are laid out in memory),
fb_bitfield structs (how tuples are formed into pixels), and visual (how to
interprete the tuples).
The fb_bitfield structs do have RGB-centric names, but you could use them
for e.g. Y, Cb, Cr, and alpha, giving a proper visual. Unfortunately the
YCbCr visuals haven't made it into mainline.
FOURCC unifies all of that in (not so) unique 32-bit IDs.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/17] Modified llvmpipe to return 64 in case of PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT.
Am 25.11.2013 06:36 schrieb "Siavash Eliasi" : > > --- > src/gallium/drivers/llvmpipe/lp_screen.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c > index f61df98..8be1779 100644 > --- a/src/gallium/drivers/llvmpipe/lp_screen.c > +++ b/src/gallium/drivers/llvmpipe/lp_screen.c > @@ -220,6 +220,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) > case PIPE_CAP_START_INSTANCE: > case PIPE_CAP_TEXTURE_MULTISAMPLE: > case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: > + return 64; Same issue here as with the other patch. > case PIPE_CAP_CUBE_MAP_ARRAY: >return 0; > case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: > -- > 1.8.4.2 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/17] Modified softpipe to return 64 in case of PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT.
Am 25.11.2013 06:36 schrieb "Siavash Eliasi" : > > --- > src/gallium/drivers/softpipe/sp_screen.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/softpipe/sp_screen.c b/src/gallium/drivers/softpipe/sp_screen.c > index 47ef20e..022b5bf 100644 > --- a/src/gallium/drivers/softpipe/sp_screen.c > +++ b/src/gallium/drivers/softpipe/sp_screen.c > @@ -169,7 +169,7 @@ softpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) > case PIPE_CAP_START_INSTANCE: > case PIPE_CAP_TEXTURE_MULTISAMPLE: > case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: > - return 0; > + return 64; This would return 64 for PIPE_CAP_START_INSTANCE, PIPE_CAP_TEXTURE_MULTISAMPLE, etc. as well, which likely is wrong. > case PIPE_CAP_QUERY_TIMESTAMP: > case PIPE_CAP_CUBE_MAP_ARRAY: >return 1; > -- > 1.8.4.2 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] gallium/drivers: support more sampler views than samplers for more drivers
From: Roland Scheidegger
This adds support for this to more drivers, in particular for all the "special"
ones useful for debugging.
HW drivers are left alone, some should be able to support it if they want but
they may not be interested at this point.
---
src/gallium/drivers/galahad/glhd_context.c |2 +-
src/gallium/drivers/identity/id_context.c |2 +-
src/gallium/drivers/rbug/rbug_context.c|2 +-
src/gallium/drivers/rbug/rbug_context.h|4 ++--
src/gallium/drivers/rbug/rbug_core.c |2 +-
src/gallium/drivers/trace/tr_context.c |2 +-
6 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/galahad/glhd_context.c
b/src/gallium/drivers/galahad/glhd_context.c
index 0bb7abd..fa743bd 100644
--- a/src/gallium/drivers/galahad/glhd_context.c
+++ b/src/gallium/drivers/galahad/glhd_context.c
@@ -518,7 +518,7 @@ galahad_context_set_sampler_views(struct pipe_context
*_pipe,
{
struct galahad_context *glhd_pipe = galahad_context(_pipe);
struct pipe_context *pipe = glhd_pipe->pipe;
- struct pipe_sampler_view *unwrapped_views[PIPE_MAX_SAMPLERS];
+ struct pipe_sampler_view *unwrapped_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
unsigned i;
for (i = 0; i < num; i++)
diff --git a/src/gallium/drivers/identity/id_context.c
b/src/gallium/drivers/identity/id_context.c
index 60e8860..00414b8 100644
--- a/src/gallium/drivers/identity/id_context.c
+++ b/src/gallium/drivers/identity/id_context.c
@@ -485,7 +485,7 @@ identity_set_sampler_views(struct pipe_context *_pipe,
{
struct identity_context *id_pipe = identity_context(_pipe);
struct pipe_context *pipe = id_pipe->pipe;
- struct pipe_sampler_view *unwrapped_views[PIPE_MAX_SAMPLERS];
+ struct pipe_sampler_view *unwrapped_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
unsigned i;
for (i = 0; i < num; i++)
diff --git a/src/gallium/drivers/rbug/rbug_context.c
b/src/gallium/drivers/rbug/rbug_context.c
index be3e964..0e7badb 100644
--- a/src/gallium/drivers/rbug/rbug_context.c
+++ b/src/gallium/drivers/rbug/rbug_context.c
@@ -712,7 +712,7 @@ rbug_set_sampler_views(struct pipe_context *_pipe,
{
struct rbug_context *rb_pipe = rbug_context(_pipe);
struct pipe_context *pipe = rb_pipe->pipe;
- struct pipe_sampler_view *unwrapped_views[PIPE_MAX_SAMPLERS];
+ struct pipe_sampler_view *unwrapped_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
struct pipe_sampler_view **views = NULL;
unsigned i;
diff --git a/src/gallium/drivers/rbug/rbug_context.h
b/src/gallium/drivers/rbug/rbug_context.h
index 6b44da0..5e7b9d4 100644
--- a/src/gallium/drivers/rbug/rbug_context.h
+++ b/src/gallium/drivers/rbug/rbug_context.h
@@ -48,8 +48,8 @@ struct rbug_context {
struct {
struct rbug_shader *shader[PIPE_SHADER_TYPES];
- struct rbug_sampler_view *views[PIPE_SHADER_TYPES][PIPE_MAX_SAMPLERS];
- struct rbug_resource *texs[PIPE_SHADER_TYPES][PIPE_MAX_SAMPLERS];
+ struct rbug_sampler_view
*views[PIPE_SHADER_TYPES][PIPE_MAX_SHADER_SAMPLER_VIEWS];
+ struct rbug_resource
*texs[PIPE_SHADER_TYPES][PIPE_MAX_SHADER_SAMPLER_VIEWS];
unsigned num_views[PIPE_SHADER_TYPES];
unsigned nr_cbufs;
diff --git a/src/gallium/drivers/rbug/rbug_core.c
b/src/gallium/drivers/rbug/rbug_core.c
index b957261..8f9388a 100644
--- a/src/gallium/drivers/rbug/rbug_core.c
+++ b/src/gallium/drivers/rbug/rbug_core.c
@@ -320,7 +320,7 @@ rbug_context_info(struct rbug_rbug *tr_rbug, struct
rbug_header *header, uint32_
struct rbug_screen *rb_screen = tr_rbug->rb_screen;
struct rbug_context *rb_context = NULL;
rbug_texture_t cbufs[PIPE_MAX_COLOR_BUFS];
- rbug_texture_t texs[PIPE_MAX_SAMPLERS];
+ rbug_texture_t texs[PIPE_MAX_SHADER_SAMPLER_VIEWS];
unsigned i;
pipe_mutex_lock(rb_screen->list_mutex);
diff --git a/src/gallium/drivers/trace/tr_context.c
b/src/gallium/drivers/trace/tr_context.c
index 78911aa..6a98657 100644
--- a/src/gallium/drivers/trace/tr_context.c
+++ b/src/gallium/drivers/trace/tr_context.c
@@ -891,7 +891,7 @@ trace_context_set_sampler_views(struct pipe_context *_pipe,
struct trace_context *tr_ctx = trace_context(_pipe);
struct trace_sampler_view *tr_view;
struct pipe_context *pipe = tr_ctx->pipe;
- struct pipe_sampler_view *unwrapped_views[PIPE_MAX_SAMPLERS];
+ struct pipe_sampler_view *unwrapped_views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
unsigned i;
/* remove this when we have pipe->set_sampler_views(..., start, ...) */
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] gallium/cso: fix sampler / sampler_view counts
From: Roland Scheidegger
Now that it is possible to query drivers for the max sampler view it should
be safe to increase this without crashing.
Not entirely convinced this really works correctly though if state trackers
using non-linked sampler / sampler_views use this.
---
src/gallium/auxiliary/cso_cache/cso_context.c | 27 +++--
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/src/gallium/auxiliary/cso_cache/cso_context.c
b/src/gallium/auxiliary/cso_cache/cso_context.c
index 23d3245..33adee8 100644
--- a/src/gallium/auxiliary/cso_cache/cso_context.c
+++ b/src/gallium/auxiliary/cso_cache/cso_context.c
@@ -67,10 +67,10 @@ struct sampler_info
void *samplers_saved[PIPE_MAX_SAMPLERS];
unsigned nr_samplers_saved;
- struct pipe_sampler_view *views[PIPE_MAX_SAMPLERS];
+ struct pipe_sampler_view *views[PIPE_MAX_SHADER_SAMPLER_VIEWS];
unsigned nr_views;
- struct pipe_sampler_view *views_saved[PIPE_MAX_SAMPLERS];
+ struct pipe_sampler_view *views_saved[PIPE_MAX_SHADER_SAMPLER_VIEWS];
unsigned nr_views_saved;
};
@@ -306,17 +306,22 @@ void cso_release_all( struct cso_context *ctx )
ctx->pipe->bind_rasterizer_state( ctx->pipe, NULL );
{
- static struct pipe_sampler_view *views[PIPE_MAX_SAMPLERS] = { NULL };
+ static struct pipe_sampler_view *views[PIPE_MAX_SHADER_SAMPLER_VIEWS]
= { NULL };
static void *zeros[PIPE_MAX_SAMPLERS] = { NULL };
struct pipe_screen *scr = ctx->pipe->screen;
unsigned sh;
for (sh = 0; sh < PIPE_SHADER_TYPES; sh++) {
-int max = scr->get_shader_param(scr, sh,
- PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS);
-assert(max <= PIPE_MAX_SAMPLERS);
-if (max > 0) {
- ctx->pipe->bind_sampler_states(ctx->pipe, sh, 0, max, zeros);
- ctx->pipe->set_sampler_views(ctx->pipe, sh, 0, max, views);
+int maxsam = scr->get_shader_param(scr, sh,
+
PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS);
+int maxview = scr->get_shader_param(scr, sh,
+
PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS);
+assert(maxsam <= PIPE_MAX_SAMPLERS);
+assert(maxview <= PIPE_MAX_SHADER_SAMPLER_VIEWS);
+if (maxsam > 0) {
+ ctx->pipe->bind_sampler_states(ctx->pipe, sh, 0, maxsam, zeros);
+}
+if (maxview > 0) {
+ ctx->pipe->set_sampler_views(ctx->pipe, sh, 0, maxview, views);
}
}
}
@@ -330,10 +335,10 @@ void cso_release_all( struct cso_context *ctx )
ctx->pipe->set_stream_output_targets(ctx->pipe, 0, NULL, 0);
}
- /* free fragment samplers, views */
+ /* free fragment sampler views */
for (shader = 0; shader < Elements(ctx->samplers); shader++) {
struct sampler_info *info = &ctx->samplers[shader];
- for (i = 0; i < PIPE_MAX_SAMPLERS; i++) {
+ for (i = 0; i < PIPE_MAX_SHADER_SAMPLER_VIEWS; i++) {
pipe_sampler_view_reference(&info->views[i], NULL);
pipe_sampler_view_reference(&info->views_saved[i], NULL);
}
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] gallium: new shader cap bit for the amount of sampler views
From: Roland Scheidegger
Ever since introducing separate sampler and sampler view max this was really
missing.
Every driver but llvmpipe reports the same number as number of samplers for
now, so nothing should break.
---
src/gallium/auxiliary/gallivm/lp_bld_limits.h|2 ++
src/gallium/docs/source/screen.rst |4 +++-
src/gallium/drivers/freedreno/freedreno_screen.c |1 +
src/gallium/drivers/i915/i915_screen.c |2 ++
src/gallium/drivers/ilo/ilo_screen.c |2 ++
src/gallium/drivers/llvmpipe/lp_screen.c |5 +
src/gallium/drivers/nouveau/nv30/nv30_screen.c |2 ++
src/gallium/drivers/nouveau/nv50/nv50_screen.c |2 ++
src/gallium/drivers/nouveau/nvc0/nvc0_screen.c |6 ++
src/gallium/drivers/r300/r300_screen.c |3 +++
src/gallium/drivers/r600/r600_pipe.c |1 +
src/gallium/drivers/radeonsi/radeonsi_pipe.c |1 +
src/gallium/drivers/softpipe/sp_screen.c |5 +++--
src/gallium/drivers/svga/svga_screen.c |2 ++
src/gallium/include/pipe/p_defines.h |3 ++-
15 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
index 5675e36..521b45b 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_limits.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_limits.h
@@ -112,6 +112,8 @@ gallivm_get_shader_param(enum pipe_shader_cap param)
return 1;
case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
return PIPE_MAX_SAMPLERS;
+ case PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS:
+ return PIPE_MAX_SHADER_SAMPLER_VIEWS;
case PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED:
return 1;
default:
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index a01f548..035309d 100644
--- a/src/gallium/docs/source/screen.rst
+++ b/src/gallium/docs/source/screen.rst
@@ -247,10 +247,12 @@ to be 0.
BGNSUB, ENDSUB, CAL, and RET, including RET in the main block.
* ``PIPE_SHADER_CAP_INTEGERS``: Whether integer opcodes are supported.
If unsupported, only float opcodes are supported.
-* ``PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS``: THe maximum number of texture
+* ``PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS``: The maximum number of texture
samplers.
* ``PIPE_SHADER_CAP_PREFERRED_IR``: Preferred representation of the
program. It should be one of the ``pipe_shader_ir`` enum values.
+* ``PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS``: The maximum number of texture
+ sampler views. Must not be lower than PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS.
.. _pipe_compute_cap:
diff --git a/src/gallium/drivers/freedreno/freedreno_screen.c
b/src/gallium/drivers/freedreno/freedreno_screen.c
index 20adf21..5dafa92 100644
--- a/src/gallium/drivers/freedreno/freedreno_screen.c
+++ b/src/gallium/drivers/freedreno/freedreno_screen.c
@@ -323,6 +323,7 @@ fd_screen_get_shader_param(struct pipe_screen *pscreen,
unsigned shader,
*/
return 0;
case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
+ case PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS:
return 16;
case PIPE_SHADER_CAP_PREFERRED_IR:
return PIPE_SHADER_IR_TGSI;
diff --git a/src/gallium/drivers/i915/i915_screen.c
b/src/gallium/drivers/i915/i915_screen.c
index 77607d0..5e1e18d 100644
--- a/src/gallium/drivers/i915/i915_screen.c
+++ b/src/gallium/drivers/i915/i915_screen.c
@@ -106,6 +106,7 @@ i915_get_shader_param(struct pipe_screen *screen, unsigned
shader, enum pipe_sha
case PIPE_SHADER_VERTEX:
switch (cap) {
case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
+ case PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS:
if (debug_get_bool_option("DRAW_USE_LLVM", TRUE))
return PIPE_MAX_SAMPLERS;
else
@@ -151,6 +152,7 @@ i915_get_shader_param(struct pipe_screen *screen, unsigned
shader, enum pipe_sha
case PIPE_SHADER_CAP_INTEGERS:
return 0;
case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
+ case PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS:
return I915_TEX_UNITS;
default:
debug_printf("%s: Unknown cap %u.\n", __FUNCTION__, cap);
diff --git a/src/gallium/drivers/ilo/ilo_screen.c
b/src/gallium/drivers/ilo/ilo_screen.c
index a345b70..d6e3f94 100644
--- a/src/gallium/drivers/ilo/ilo_screen.c
+++ b/src/gallium/drivers/ilo/ilo_screen.c
@@ -141,6 +141,8 @@ ilo_get_shader_param(struct pipe_screen *screen, unsigned
shader,
return 1;
case PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS:
return ILO_MAX_SAMPLERS;
+ case PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS:
+ return ILO_MAX_SAMPLER_VIEWS;
case PIPE_SHADER_CAP_PREFERRED_IR:
return PIPE_SHADER_IR_TGSI;
case PIPE_SHADER_CAP_TGSI_SQRT_SUPPORTED:
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index f61df98..81ebc69 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/ga
Re: [Mesa-dev] [PATCH] present: Send GLX_BufferSwapComplete events from present extension
Eric Anholt writes: > There's a minor behavior change that the event now gets sent to the > drawable owner rather than the caller of DRI2SwapBuffers. Yeah, probably not ideal, especially when the GLX drawable is created using the window XID (as is the case for some older GLX clients). I don't have the original client at the time the event is generated, but I think I can go back and stick it in; will require tracking when the client exits, of course. > I don't expect it to matter in practice (I expect that the > swap-requesting client using this GLX extension is also the > drawable-creating one), and either choice seems wrong compared to "send > the event to everyone listening for the event on this drawable". That > would be a separate change, anyway. I think the original behaviour, sending the event to the client who sent the PresentPixmap request is the only sane plan, and only a bit more complicated than sending it to the drawable owner. I'll cook up an alternate patch and send that along; we can then compare the two approaches at least. -- keith.pack...@intel.com pgphrF2sBXa1F.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
While incorporating Brian's comments I did some refactoring to consolidate multiple uses of next_mimap_level_size into one shared helper function. That adds another commit to the stream. I thought it was big enough now that I should post the branch to make it easier to use. I've posted the updated stream, including the next_mipmap_level_size refactoring on github here: https://github.com/courtney-lunarg/mesa/tree/texture_view-rc5 Courtney -- Courtney Goeltzenleuchter LunarG ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/9] mesa: Fill out ARB_texture_view entry points
Add Mesa TextureView logic.
Incorporate feedback on ARB_texture_view:
- Add S3TC VIEW_CLASSes to compatibility table
- Use existing _mesa_get_tex_image
- Clean up error strings
- Use bool instead of GLboolean for internal functions
- Split compound level & layer test into individual tests
Signed-off-by: Courtney Goeltzenleuchter
---
src/mesa/main/textureview.c | 540 +++-
1 file changed, 539 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
index 4a6bd62..1bfc86b 100644
--- a/src/mesa/main/textureview.c
+++ b/src/mesa/main/textureview.c
@@ -38,10 +38,318 @@
#include "macros.h"
#include "teximage.h"
#include "texobj.h"
+#include "mipmap.h"
#include "texstorage.h"
#include "textureview.h"
+#include "stdbool.h"
#include "mtypes.h"
+/* Table 3.X.2 (Compatible internal formats for TextureView)
+---
+| Class | Internal formats|
+---
+| VIEW_CLASS_128_BITS | RGBA32F, RGBA32UI, RGBA32I |
+---
+| VIEW_CLASS_96_BITS| RGB32F, RGB32UI, RGB32I |
+---
+| VIEW_CLASS_64_BITS| RGBA16F, RG32F, RGBA16UI, RG32UI, RGBA16I, |
+| | RG32I, RGBA16, RGBA16_SNORM |
+---
+| VIEW_CLASS_48_BITS| RGB16, RGB16_SNORM, RGB16F, RGB16UI, RGB16I |
+---
+| VIEW_CLASS_32_BITS| RG16F, R11F_G11F_B10F, R32F,|
+| | RGB10_A2UI, RGBA8UI, RG16UI, R32UI, |
+| | RGBA8I, RG16I, R32I, RGB10_A2, RGBA8, RG16, |
+| | RGBA8_SNORM, RG16_SNORM, SRGB8_ALPHA8, RGB9_E5 |
+---
+| VIEW_CLASS_24_BITS| RGB8, RGB8_SNORM, SRGB8, RGB8UI, RGB8I |
+---
+| VIEW_CLASS_16_BITS| R16F, RG8UI, R16UI, RG8I, R16I, RG8, R16, |
+| | RG8_SNORM, R16_SNORM|
+---
+| VIEW_CLASS_8_BITS | R8UI, R8I, R8, R8_SNORM |
+---
+| VIEW_CLASS_RGTC1_RED | COMPRESSED_RED_RGTC1, |
+| | COMPRESSED_SIGNED_RED_RGTC1 |
+---
+| VIEW_CLASS_RGTC2_RG | COMPRESSED_RG_RGTC2,|
+| | COMPRESSED_SIGNED_RG_RGTC2 |
+---
+| VIEW_CLASS_BPTC_UNORM | COMPRESSED_RGBA_BPTC_UNORM, |
+| | COMPRESSED_SRGB_ALPHA_BPTC_UNORM|
+---
+| VIEW_CLASS_BPTC_FLOAT | COMPRESSED_RGB_BPTC_SIGNED_FLOAT, |
+| | COMPRESSED_RGB_BPTC_UNSIGNED_FLOAT |
+---
+ */
+struct internal_format_class_info {
+ GLenum view_class;
+ GLenum internal_format;
+};
+#define INFO(c,f) {GL_##c, GL_##f}
+static const struct internal_format_class_info compatible_internal_formats[] =
{
+ INFO(VIEW_CLASS_128_BITS, RGBA32F),
+ INFO(VIEW_CLASS_128_BITS, RGBA32UI),
+ INFO(VIEW_CLASS_128_BITS, RGBA32I),
+ INFO(VIEW_CLASS_96_BITS, RGB32F),
+ INFO(VIEW_CLASS_96_BITS, RGB32UI),
+ INFO(VIEW_CLASS_96_BITS, RGB32I),
+ INFO(VIEW_CLASS_64_BITS, RGBA16F),
+ INFO(VIEW_CLASS_64_BITS, RG32F),
+ INFO(VIEW_CLASS_64_BITS, RGBA16UI),
+ INFO(VIEW_CLASS_64_BITS, RG32UI),
+ INFO(VIEW_CLASS_64_BITS, RGBA16I),
+ INFO(VIEW_CLASS_64_BITS, RG32I),
+ INFO(VIEW_CLASS_64_BITS, RGBA16),
+ INFO(VIEW_CLASS_64_BITS, RGBA16_SNORM),
+ INFO(VIEW_CLASS_48_BITS, RGB16),
+ INFO(VIEW_CLASS_48_BITS, RGB16_SNORM),
+ INFO(VIEW_CLASS_48_BITS, RGB16F),
+ INFO(VIEW_CLASS_48_BITS, RGB16UI),
+ INFO(VIEW_CLASS_48_BITS, RGB16I),
+ INFO(VIEW_CLASS_32_BITS, RG16F),
+ INFO(VIEW_CLASS_32_BITS, R11F_G11F_B10F),
+ INFO(VIEW_CLASS_32_BITS, R32F),
+ INFO(VIEW_CLASS_32_BITS, RGB10_A2UI),
+ INFO(VIEW_CLASS_32_BITS, RGBA8UI),
+ INFO(VIEW_CLASS_32
[Mesa-dev] [PATCH 6/9] mesa: consolidate multiple next_mipmap_level_size
Refactor to make next_mipmap_level_size defined in mipmap.c a
_mesa_ helper function that can then be used by texture_view
Signed-off-by: Courtney Goeltzenleuchter
---
src/mesa/main/mipmap.c | 8
src/mesa/main/mipmap.h | 4
src/mesa/main/texstorage.c | 25 +++--
3 files changed, 11 insertions(+), 26 deletions(-)
diff --git a/src/mesa/main/mipmap.c b/src/mesa/main/mipmap.c
index 180f891..0330157 100644
--- a/src/mesa/main/mipmap.c
+++ b/src/mesa/main/mipmap.c
@@ -1767,8 +1767,8 @@ _mesa_generate_mipmap_level(GLenum target,
* compute next (level+1) image size
* \return GL_FALSE if no smaller size can be generated (eg. src is 1x1x1 size)
*/
-static GLboolean
-next_mipmap_level_size(GLenum target, GLint border,
+GLboolean
+_mesa_next_mipmap_level_size(GLenum target, GLint border,
GLint srcWidth, GLint srcHeight, GLint srcDepth,
GLint *dstWidth, GLint *dstHeight, GLint *dstDepth)
{
@@ -1911,7 +1911,7 @@ generate_mipmap_uncompressed(struct gl_context *ctx,
GLenum target,
srcDepth = srcImage->Depth;
border = srcImage->Border;
- nextLevel = next_mipmap_level_size(target, border,
+ nextLevel = _mesa_next_mipmap_level_size(target, border,
srcWidth, srcHeight, srcDepth,
&dstWidth, &dstHeight, &dstDepth);
if (!nextLevel)
@@ -2102,7 +2102,7 @@ generate_mipmap_compressed(struct gl_context *ctx, GLenum
target,
srcDepth = srcImage->Depth;
border = srcImage->Border;
- nextLevel = next_mipmap_level_size(target, border,
+ nextLevel = _mesa_next_mipmap_level_size(target, border,
srcWidth, srcHeight, srcDepth,
&dstWidth, &dstHeight, &dstDepth);
if (!nextLevel)
diff --git a/src/mesa/main/mipmap.h b/src/mesa/main/mipmap.h
index d5bd1d8..ee91df0 100644
--- a/src/mesa/main/mipmap.h
+++ b/src/mesa/main/mipmap.h
@@ -51,5 +51,9 @@ extern void
_mesa_generate_mipmap(struct gl_context *ctx, GLenum target,
struct gl_texture_object *texObj);
+extern GLboolean
+_mesa_next_mipmap_level_size(GLenum target, GLint border,
+ GLint srcWidth, GLint srcHeight, GLint srcDepth,
+ GLint *dstWidth, GLint *dstHeight, GLint *dstDepth);
#endif /* MIPMAP_H */
diff --git a/src/mesa/main/texstorage.c b/src/mesa/main/texstorage.c
index 84b8f82..8d472a2 100644
--- a/src/mesa/main/texstorage.c
+++ b/src/mesa/main/texstorage.c
@@ -37,6 +37,7 @@
#include "macros.h"
#include "teximage.h"
#include "texobj.h"
+#include "mipmap.h"
#include "texstorage.h"
#include "mtypes.h"
@@ -100,27 +101,6 @@ legal_texobj_target(struct gl_context *ctx, GLuint dims,
GLenum target)
}
-/**
- * Compute the size of the next mipmap level.
- */
-static void
-next_mipmap_level_size(GLenum target,
- GLint *width, GLint *height, GLint *depth)
-{
- if (*width > 1) {
- *width /= 2;
- }
-
- if ((*height > 1) && (target != GL_TEXTURE_1D_ARRAY)) {
- *height /= 2;
- }
-
- if ((*depth > 1) && (target != GL_TEXTURE_2D_ARRAY)) {
- *depth /= 2;
- }
-}
-
-
/** Helper to get a particular texture image in a texture object */
static struct gl_texture_image *
get_tex_image(struct gl_context *ctx,
@@ -164,7 +144,8 @@ initialize_texture_fields(struct gl_context *ctx,
0, internalFormat, texFormat);
}
- next_mipmap_level_size(target, &levelWidth, &levelHeight, &levelDepth);
+ _mesa_next_mipmap_level_size(target, 0, levelWidth, levelHeight,
levelDepth,
+ &levelWidth, &levelHeight, &levelDepth);
}
return GL_TRUE;
}
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [v3 5/8] mesa: Add driver entry point for ARB_texture_view
On Thu, Nov 21, 2013 at 5:56 PM, Brian Paul wrote:
> On 11/19/2013 04:16 PM, Courtney Goeltzenleuchter wrote:
>
>>
>> Signed-off-by: Courtney Goeltzenleuchter
>> ---
>> src/mesa/drivers/common/driverfuncs.c | 3 +++
>> src/mesa/main/dd.h| 5 +
>> 2 files changed, 8 insertions(+)
>>
>> diff --git a/src/mesa/drivers/common/driverfuncs.c
>> b/src/mesa/drivers/common/driverfuncs.c
>> index 5faa98a..f185688 100644
>> --- a/src/mesa/drivers/common/driverfuncs.c
>> +++ b/src/mesa/drivers/common/driverfuncs.c
>> @@ -211,6 +211,9 @@ _mesa_init_driver_functions(struct dd_function_table
>> *driver)
>> /* GL_ARB_texture_storage */
>> driver->AllocTextureStorage = _mesa_alloc_texture_storage;
>>
>> + /* GL_ARB_texture_view */
>> + driver->TextureView = NULL;
>> +
>> /* GL_ARB_texture_multisample */
>> driver->GetSamplePosition = NULL;
>> }
>> diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
>> index b5b874f..3e263f4 100644
>> --- a/src/mesa/main/dd.h
>> +++ b/src/mesa/main/dd.h
>> @@ -375,6 +375,11 @@ struct dd_function_table {
>> GLsizei levels, GLsizei width,
>> GLsizei height, GLsizei depth);
>>
>> + /** Called as part of glTextureView to add views to origTexObj */
>> + GLboolean (*TextureView)(struct gl_context *ctx,
>> +struct gl_texture_object *texObj,
>> +struct gl_texture_object *origTexObj);
>>
>
> Either the comment on this function, or the place where it's called from
> should probably be beefed up with more info about what's expected of the
> driver. Is it possible to return FALSE for any reason beyond out-of-memory?
>
>
When the driver side is done I'll have more details. Ideally this should
never fail as we are simply creating a different way to look at a texture
that already exists.
>
>
>
> +
>> /**
>> * Map a renderbuffer into user space.
>> * \param mode bitmask of GL_MAP_READ_BIT, GL_MAP_WRITE_BIT and
>>
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
Courtney Goeltzenleuchter
LunarG
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Replace OUT_RELOC_FENCED with OUT_RELOC.
Kenneth Graunke writes: > On Gen4+, OUT_RELOC_FENCED is equivalent to OUT_RELOC; libdrm silently > ignores the fenced flag: > > /* We never use HW fences for rendering on 965+ */ > if (bufmgr_gem->gen >= 4) > need_fence = false; > > Thanks to Eric for noticing this. Reviewed-by: Eric Anholt pgpkTZb15EZEb.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glsl: Fix lowering of direct assignment in lower_clip_distance.
On 25 November 2013 15:02, Eric Anholt wrote: > Paul Berry writes: > > > In commit 065da16 (glsl: Convert lower_clip_distance_visitor to be an > > ir_rvalue_visitor), we failed to notice that since > > lower_clip_distance_visitor overrides visit_leave(ir_assignment *), > > ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called. > > As a result, clip distance dereferences appearing directly on the > > right hand side of an assignment (not in a subexpression) weren't > > getting properly lowered. This caused an ir_dereference_variable node > > to be left in the IR that referred to the old gl_ClipDistance > > variable. However, since the lowering pass replaces gl_ClipDistance > > with gl_ClipDistanceMESA, this turned into a dangling pointer when the > > IR got reparented. > > > > Prior to the introduction of geometry shaders, this bug was unlikely > > to arise, because (a) reading from gl_ClipDistance[i] in the fragment > > shader was rare, and (b) when it happened, it was likely that it would > > either appear in a subexpression, or be hoisted into a subexpression > > by tree grafting. > > > > However, in a geometry shader, we're likely to see a statement like > > this, which would trigger the bug: > > > > gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i]; > > These two are: > > Reviewed-by: Eric Anholt > > I didn't follow how gl_in[j].gl_ClipDistance[i] is a bare struct deref > of the thing needing to be lowered, since it reads to me like there's an > array and struct dereference first. But I assume that's just me not > understanding how gl_in[] works. > Yeah, it's complicated by the fact that by the time we get to this code, lower_named_interface_blocks.cpp has munged gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i] into: gl_ClipDistance[i] = gl_ClipDistance[j][i] (note that the "gl_ClipDistance" appearing on the LHS refers to the GS output var, and the "gl_ClipDistance" appearing on the RHS refers to the GS input var). Also, I oversimplified a bit when I said "clip distance dereferences appearing directly on the right hand side of an assignment"; what I really meant was "either an array_deref of gl_ClipDistance out, or an array_deref of an array_deref of gl_ClipDistance in". But I figured that going into that level of detail would create more confusion than it solved. Anyway, thanks for hte review :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] glsl: Fix lowering of direct assignment in lower_clip_distance.
Paul Berry writes: > In commit 065da16 (glsl: Convert lower_clip_distance_visitor to be an > ir_rvalue_visitor), we failed to notice that since > lower_clip_distance_visitor overrides visit_leave(ir_assignment *), > ir_rvalue_visitor::visit_leave(ir_assignment *) wasn't getting called. > As a result, clip distance dereferences appearing directly on the > right hand side of an assignment (not in a subexpression) weren't > getting properly lowered. This caused an ir_dereference_variable node > to be left in the IR that referred to the old gl_ClipDistance > variable. However, since the lowering pass replaces gl_ClipDistance > with gl_ClipDistanceMESA, this turned into a dangling pointer when the > IR got reparented. > > Prior to the introduction of geometry shaders, this bug was unlikely > to arise, because (a) reading from gl_ClipDistance[i] in the fragment > shader was rare, and (b) when it happened, it was likely that it would > either appear in a subexpression, or be hoisted into a subexpression > by tree grafting. > > However, in a geometry shader, we're likely to see a statement like > this, which would trigger the bug: > > gl_ClipDistance[i] = gl_in[j].gl_ClipDistance[i]; These two are: Reviewed-by: Eric Anholt I didn't follow how gl_in[j].gl_ClipDistance[i] is a bare struct deref of the thing needing to be lowered, since it reads to me like there's an array and struct dereference first. But I assume that's just me not understanding how gl_in[] works. pgpNolMERjthi.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] present: Send GLX_BufferSwapComplete events from present extension
Keith Packard writes: > This allows GL to support the GLX_INTEL_swap_event extension > > Signed-off-by: Keith Packard There's a minor behavior change that the event now gets sent to the drawable owner rather than the caller of DRI2SwapBuffers. I don't expect it to matter in practice (I expect that the swap-requesting client using this GLX extension is also the drawable-creating one), and either choice seems wrong compared to "send the event to everyone listening for the event on this drawable". That would be a separate change, anyway. Reviewed-by: Eric Anholt pgpmiPzHkmfMQ.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri3: Support GLX_INTEL_swap_event
Eric Anholt writes: > I'd prefer to see sbc stay with its current name, since that's its name > in the specs we're trying to implement (GLX_OML_sync_control, > GLX_INTEL_swap_event). If you drop the rename from the patch, > > Reviewed-by: Eric Anholt Sounds good. > I read that as "SBC is incremented when the PresentComplete comes in" > not "SBC is incremented when we generate the Present request". > Otherwise glXWaitForSbcOML doesn't make much sense. (in the "e.g." I'm > assuming they're talking a hardware register for pageflipping that > immediately starts scanning out the new stuff, not our fancy new > automatically double buffered ones that you have to push hard on to get > an immediate pageflip mode) Oh, that's almost sensible. And nicely eliminates the silly sleep(1) loop. New patches coming shortly. -- keith.pack...@intel.com pgppjA6dKRi9F.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Anonymous structure in uniform question
Hello Grigori, indeed the patch cures the error, but when I was testing the newly compiled Mesa with XPlane10, it turns out there is something wrong - there are no shadows (without shadows I can't really tell if the patch didn't visibly break anything). I'm going to try and find out where exactly the problem happened and will report back. Thank you, Michal "On 21.11.2013 21:50, f.jo...@email.cz wrote: > The problem is, that each anonymous structure gets its own unique type, > without checking if such type already exists. It seems to me, that such > code is somewhat in the gray area - the rest of OpenGL implementations > doesn't seem to have a problem with this code (Intel on Win, OSX, Nvidia > and AMD drivers in Win, OSX and Linux), which of course doesn't mean > such a behavior is correct. > This should be allowed, according to GLSL (3.3) spec and grammar. It's just a bug/oversight in the linker, I guess. The GLSL linker already includes some special handling to match array types between stages. I added something similar for structs, see the attached patch. It's probably not the nicest approach (it duplicates some code from glsl_types.cpp), but seems to work fine. I don't really know the GLSL compiler/linker code, so YMMV. :) Best regards Grigori"___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
Keith Packard writes: > The __DRIimage createImageFromFds function takes a fourcc code, but there was > no fourcc code that match __DRI_IMAGE_FORMAT_SARGB8. This adds a define for > that format, adds a translation in DRI3 from __DRI_IMAGE_FORMAT_SARGB8 to > __DRI_IMAGE_FOURCC_SARGB and then adds translations *back* to > __IMAGE_FORMAT_SARGB8 in both the i915 and i965 drivers. > > I'll refrain from comments on whether I think having two separate sets of > format defines in dri_interface.h is a good idea or not... > > Signed-off-by: Keith Packard Reviewed-by: Eric Anholt I'd love to see some debug information in whatever path it was that was silently failing, if we can. It's so easy to miss places to add format support. (I see gallium doesn't use sargb images currently, but might want this in the future, plus we're still missing an equivalent change for 2101010 though I don't know if anybody's made it really work anywhere on dri2 either) pgptFrIzDGi1W.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Replace OUT_RELOC_FENCED with OUT_RELOC.
On Gen4+, OUT_RELOC_FENCED is equivalent to OUT_RELOC; libdrm silently
ignores the fenced flag:
/* We never use HW fences for rendering on 965+ */
if (bufmgr_gem->gen >= 4)
need_fence = false;
Thanks to Eric for noticing this.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 4
src/mesa/drivers/dri/i965/intel_blit.c| 22 ++
2 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
index ac8eb7d..54b5f25 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.h
@@ -173,10 +173,6 @@ void intel_batchbuffer_cached_advance(struct brw_context
*brw);
intel_batchbuffer_emit_reloc(brw, buf, \
read_domains, write_domain, delta); \
} while (0)
-#define OUT_RELOC_FENCED(buf, read_domains, write_domain, delta) do { \
- intel_batchbuffer_emit_reloc_fenced(brw, buf, \
- read_domains, write_domain, delta); \
-} while (0)
#define ADVANCE_BATCH() intel_batchbuffer_advance(brw);
#define CACHED_BATCH() intel_batchbuffer_cached_advance(brw);
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
b/src/mesa/drivers/dri/i965/intel_blit.c
index a47d02e..8c354f6 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -378,14 +378,12 @@ intelEmitCopyBlit(struct brw_context *brw,
OUT_BATCH(BR13 | (uint16_t)dst_pitch);
OUT_BATCH((dst_y << 16) | dst_x);
OUT_BATCH((dst_y2 << 16) | dst_x2);
- OUT_RELOC_FENCED(dst_buffer,
- I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
- dst_offset);
+ OUT_RELOC(dst_buffer,
+ I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
+ dst_offset);
OUT_BATCH((src_y << 16) | src_x);
OUT_BATCH((uint16_t)src_pitch);
- OUT_RELOC_FENCED(src_buffer,
- I915_GEM_DOMAIN_RENDER, 0,
- src_offset);
+ OUT_RELOC(src_buffer, I915_GEM_DOMAIN_RENDER, 0, src_offset);
ADVANCE_BATCH_TILED(dst_y_tiled, src_y_tiled);
@@ -449,9 +447,9 @@ intelEmitImmediateColorExpandBlit(struct brw_context *brw,
OUT_BATCH(br13);
OUT_BATCH((0 << 16) | 0); /* clip x1, y1 */
OUT_BATCH((100 << 16) | 100); /* clip x2, y2 */
- OUT_RELOC_FENCED(dst_buffer,
- I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
- dst_offset);
+ OUT_RELOC(dst_buffer,
+ I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
+ dst_offset);
OUT_BATCH(0); /* bg */
OUT_BATCH(fg_color); /* fg */
OUT_BATCH(0); /* pattern base addr */
@@ -568,9 +566,9 @@ intel_miptree_set_alpha_to_one(struct brw_context *brw,
OUT_BATCH(BR13);
OUT_BATCH((y << 16) | x);
OUT_BATCH(((y + height) << 16) | (x + width));
- OUT_RELOC_FENCED(region->bo,
- I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
- 0);
+ OUT_RELOC(region->bo,
+ I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
+ 0);
OUT_BATCH(0x); /* white, but only alpha gets written */
ADVANCE_BATCH_TILED(dst_y_tiled, false);
--
1.8.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri3: Support GLX_INTEL_swap_event
Keith Packard writes: > The easy part is turning on the extension, now that the X server has a patch > to send the events. > > The only trick was making sure the Present extension reliably provided the > right 'sbc' count back in the event, and that's done by making sure the sbc > count is always the same as the sequence number that we send in the > PresentPixmap requests, and that's done by using the same variable for both > roles. I'd prefer to see sbc stay with its current name, since that's its name in the specs we're trying to implement (GLX_OML_sync_control, GLX_INTEL_swap_event). If you drop the rename from the patch, Reviewed-by: Eric Anholt I think our handling of SBC for glXWaitForSbcOML() is wrong. From the OML_sync_control spec: The SBC value is incremented by the graphics driver at the completion of each buffer swap (e.g., the pixel copy has been completed or the hardware register that swaps memory banks has been written). For pixel formats that do not contain a back buffer, the SBC will always be returned as 0. I read that as "SBC is incremented when the PresentComplete comes in" not "SBC is incremented when we generate the Present request". Otherwise glXWaitForSbcOML doesn't make much sense. (in the "e.g." I'm assuming they're talking a hardware register for pageflipping that immediately starts scanning out the new stuff, not our fancy new automatically double buffered ones that you have to push hard on to get an immediate pageflip mode) pgpBlfDo8h8fx.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/17] Modified _mesa_buffer_data to use _mesa_align_malloc.
On Sun, Nov 24, 2013 at 11:36 PM, Siavash Eliasi
wrote:
> ---
> src/mesa/main/bufferobj.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index b27f592..5581a5d 100644
> --- a/src/mesa/main/bufferobj.c
> +++ b/src/mesa/main/bufferobj.c
> @@ -416,9 +416,9 @@ _mesa_buffer_data( struct gl_context *ctx, GLenum target,
> GLsizeiptrARB size,
> {
> void * new_data;
>
> - (void) ctx; (void) target;
> + (void) target;
>
> - new_data = _mesa_realloc( bufObj->Data, bufObj->Size, size );
> + new_data = _mesa_align_malloc( size, ctx->Const.MinMapBufferAlignment );
realloc can be used to either allocate a new buffer or re-allocate an
existing buffer (which may or may not return a different pointer).
Given that, I think that this will leak the old buffer (if one has
already been allocated). From looking at the rest of the surrounding
code in the patch, we don't preserve the existing buffer contents, so
I guess I'd just FREE(bufObj->Data) within the following if block
before assigning bufObj->Data = newdata;
--Aaron
> if (new_data) {
>bufObj->Data = (GLubyte *) new_data;
>bufObj->Size = size;
> --
> 1.8.4.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] intel: Track known prime buffers for re-use
If the application sends us a file descriptor pointing at a prime
buffer that we've already got, we have to re-use the same bo_gem
structure or chaos will result.
Track the set of all known prime objects and look to see if the kernel
has returned one of those for a new file descriptor.
Also checks for prime buffers in the flink case.
Signed-off-by: Keith Packard
---
intel/intel_bufmgr_gem.c | 50 +---
1 file changed, 43 insertions(+), 7 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index df6fcec..2b7fe07 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -149,6 +149,8 @@ struct _drm_intel_bo_gem {
/**
* Kenel-assigned global name for this object
+ *
+ * List contains both flink named and prime fd'd objects
*/
unsigned int global_name;
drmMMListHead name_list;
@@ -862,10 +864,6 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr *bufmgr,
}
}
- bo_gem = calloc(1, sizeof(*bo_gem));
- if (!bo_gem)
- return NULL;
-
VG_CLEAR(open_arg);
open_arg.name = handle;
ret = drmIoctl(bufmgr_gem->fd,
@@ -874,9 +872,26 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr *bufmgr,
if (ret != 0) {
DBG("Couldn't reference %s handle 0x%08x: %s\n",
name, handle, strerror(errno));
- free(bo_gem);
return NULL;
}
+/* Now see if someone has used a prime handle to get this
+ * object from the kernel before by looking through the list
+ * again for a matching gem_handle
+ */
+ for (list = bufmgr_gem->named.next;
+list != &bufmgr_gem->named;
+list = list->next) {
+ bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
+ if (bo_gem->gem_handle == open_arg.handle) {
+ drm_intel_gem_bo_reference(&bo_gem->bo);
+ return &bo_gem->bo;
+ }
+ }
+
+ bo_gem = calloc(1, sizeof(*bo_gem));
+ if (!bo_gem)
+ return NULL;
+
bo_gem->bo.size = open_arg.size;
bo_gem->bo.offset = 0;
bo_gem->bo.virtual = NULL;
@@ -2451,8 +2466,25 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr
*bufmgr, int prime_fd, int s
uint32_t handle;
drm_intel_bo_gem *bo_gem;
struct drm_i915_gem_get_tiling get_tiling;
+ drmMMListHead *list;
ret = drmPrimeFDToHandle(bufmgr_gem->fd, prime_fd, &handle);
+
+ /*
+* See if the kernel has already returned this buffer to us. Just as
+* for named buffers, we must not create two bo's pointing at the same
+* kernel object
+*/
+ for (list = bufmgr_gem->named.next;
+list != &bufmgr_gem->named;
+list = list->next) {
+ bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
+ if (bo_gem->gem_handle == handle) {
+ drm_intel_gem_bo_reference(&bo_gem->bo);
+ return &bo_gem->bo;
+ }
+ }
+
if (ret) {
fprintf(stderr,"ret is %d %d\n", ret, errno);
return NULL;
@@ -2487,8 +2519,8 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr
*bufmgr, int prime_fd, int s
bo_gem->has_error = false;
bo_gem->reusable = false;
- DRMINITLISTHEAD(&bo_gem->name_list);
DRMINITLISTHEAD(&bo_gem->vma_list);
+ DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named);
VG_CLEAR(get_tiling);
get_tiling.handle = bo_gem->gem_handle;
@@ -2513,6 +2545,9 @@ drm_intel_bo_gem_export_to_prime(drm_intel_bo *bo, int
*prime_fd)
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *) bo->bufmgr;
drm_intel_bo_gem *bo_gem = (drm_intel_bo_gem *) bo;
+if (DRMLISTEMPTY(&bo_gem->name_list))
+DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named);
+
if (drmPrimeHandleToFD(bufmgr_gem->fd, bo_gem->gem_handle,
DRM_CLOEXEC, prime_fd) != 0)
return -errno;
@@ -2542,7 +2577,8 @@ drm_intel_gem_bo_flink(drm_intel_bo *bo, uint32_t * name)
bo_gem->global_name = flink.name;
bo_gem->reusable = false;
- DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named);
+if (DRMLISTEMPTY(&bo_gem->name_list))
+DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->named);
}
*name = bo_gem->global_name;
--
1.8.4.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Track known prime buffers for re-use
Daniel Vetter writes: > Yeah, it unfortunately took a few rounds of kernel fixes and other > haggling to get the semantics right on this one. The kernel atm promises > to userspace (minus one big in a racy corner case no one should care > about, still need to fix that one) that it'll return the same gem handle > if userspace already has one for the underlying object. That's definitely something we want it to do -- returning different handles to the same object would result in madness. We just need to deal with the userspace consequences. > We need that to make sure userspace doesn't submit the same bo in execbuf > multiple times and then upsets the kernel - we'll reject such batches as > userspace bugs. Oh, I'm well aware of that; you can imagine the adventures I had trying to debug this... >> -DRMINITLISTHEAD(&bo_gem->name_list); >> DRMINITLISTHEAD(&bo_gem->vma_list); >> +DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->prime); > > Won't this result in us having fun when a buffer is both imported from a > prime buffer and then also used with legacy flink? Or is this something > the X server won't support? Well, the whole point of prime-based FD buffer passing is to *not* use flink, of course. However, you could use both DRI2 and DRI3 on the same pixmap (presumably through different APIs). Ok, I just tried to create a completely separate prime list for this, and I think that's wrong. If the question is whether the kernel might return the same object from two calls, then we'd best actually keep a single list and look things up for both APIs there. *and*, I think we need to do the flink->gem handle conversion and then look in the list again to see if that gem handle was already returned from another flink or prime fd. > The second one is about exporting: With flink names we also add the name > to the lookup list in drm_intel_gem_bo_flink. I think we should do the > same for exported prime buffers just as a precaution - the kernel will > return the (existing) gem name also for a prime buffer that has been > exported by yourself. I guess that would imply insane userspace, but > better safe than sorry. yeah, that would seem like crazy user-space behaviour, but user space often seems insane. Thanks for your review; replacement patch to follow shortly. -- keith.pack...@intel.com pgpfCvqKcIVq9.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [v3 7/8] mesa: add texture_view helper function for TexStorage
On Thu, Nov 21, 2013 at 5:56 PM, Brian Paul wrote:
> On 11/19/2013 04:16 PM, Courtney Goeltzenleuchter wrote:
>
>> Add helper function to set texture_view state from TexStorage calls.
>>
>> Signed-off-by: Courtney Goeltzenleuchter
>> ---
>> src/mesa/main/textureview.c | 59 ++
>> +++
>> src/mesa/main/textureview.h | 4 +++
>> 2 files changed, 63 insertions(+)
>>
>> diff --git a/src/mesa/main/textureview.c b/src/mesa/main/textureview.c
>> index 1858465..a25b928 100644
>> --- a/src/mesa/main/textureview.c
>> +++ b/src/mesa/main/textureview.c
>> @@ -379,6 +379,65 @@ compatible_format(struct gl_context *ctx, struct
>> gl_texture_object *origTexObj,
>> _mesa_lookup_enum_by_nr(origInternalFormat));
>> return GL_FALSE;
>> }
>> +/**
>> + * Helper function for TexStorage to set TextureView state
>> + */
>>
>
> Could you put a bit more info into that comment?
How about:
/**
* Helper function for TexStorage and teximagemultisample to set immutable
* texture state needed by ARB_texture_view.
*/
void
_mesa_set_texture_view_state(struct gl_context *ctx, struct
gl_texture_object *texObj,
GLenum target, GLuint levels)
...
>
>
> +void
>> +set_texture_view_state(struct gl_context *ctx, struct gl_texture_object
>> *texObj,
>> + GLenum target, GLuint levels)
>>
>
> non-static functions should be prefixed with "_mesa_".
See above.
>
>
>
> +{
>> + struct gl_texture_image *texImage;
>> +
>> + /* Get a reference to what will become this View's base level */
>> + texImage = _mesa_select_tex_image(ctx, texObj, target, 0);
>>
>
> Early return if texImage is NULL (out of memory, etc?)?
Immutable textures have all their image levels allocated when they are
created, so teximage should never be null at this point. At least as I
understand things.
>
>
>
> +
>> + /* If the command is successful,
>>
>
> If what command is successful? glTexStorage()?
That is a copy & paste from the ARB_texture_view spec, meaning that if the
glTexStorage command is successful...
Modify subsection 3.9.16 (Immutable-Format Texture Images)
Modify the second to last bullet on p. 258:
If the command is successful, TEXTURE_IMMUTABLE_FORMAT becomes
TRUE,TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become
.
I can change that to something like: When an immutable texture is created
via glTexStorage or glTexImageMultisample,
>
>
>
> +* TEXTURE_IMMUTABLE_FORMAT becomes TRUE.
>> +* TEXTURE_IMMUTABLE_LEVELS and TEXTURE_VIEW_NUM_LEVELS become levels.
>> +* If the texture target is TEXTURE_1D_ARRAY then
>> +* TEXTURE_VIEW_NUM_LAYERS becomes height.
>> +* If the texture target is TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY,
>> +* or TEXTURE_2D_MULTISAMPLE_ARRAY then TEXTURE_VIEW_NUM_LAYERS
>> becomes depth.
>> +* If the texture target is TEXTURE_CUBE_MAP, then
>> +* TEXTURE_VIEW_NUM_LAYERS becomes 6.
>> +* For any other texture target, TEXTURE_VIEW_NUM_LAYERS becomes 1.
>> +*
>> +* ARB_texture_multisample: Multisample textures do
>> +* not have multiple image levels.
>> +*/
>> +
>> + texObj->Immutable = GL_TRUE;
>> + texObj->ImmutableLevels = levels;
>> + texObj->MinLevel = 0;
>> + texObj->NumLevels = levels;
>> + texObj->MinLayer = 0;
>> + texObj->NumLayers = 1;
>> + switch (target) {
>> + case GL_TEXTURE_1D_ARRAY:
>> + texObj->NumLayers = texImage->Height;
>> + break;
>> +
>> + case GL_TEXTURE_2D_MULTISAMPLE:
>> + texObj->NumLevels = 1;
>> + texObj->ImmutableLevels = 1;
>> + break;
>> +
>> + case GL_TEXTURE_2D_MULTISAMPLE_ARRAY:
>> + texObj->NumLevels = 1;
>> + texObj->ImmutableLevels = 1;
>> + /* fall through to set NumLayers */
>> +
>> + case GL_TEXTURE_2D_ARRAY:
>> + case GL_TEXTURE_CUBE_MAP_ARRAY:
>> + texObj->NumLayers = texImage->Depth;
>> + break;
>> +
>> + case GL_TEXTURE_CUBE_MAP:
>> + texObj->NumLayers = 6;
>> + break;
>> +
>> + }
>> +}
>>
>> /**
>>* glTextureView (ARB_texture_view)
>> diff --git a/src/mesa/main/textureview.h b/src/mesa/main/textureview.h
>> index c2f0f32..36a8ed3 100644
>> --- a/src/mesa/main/textureview.h
>> +++ b/src/mesa/main/textureview.h
>> @@ -36,4 +36,8 @@ _mesa_TextureView(GLuint texture, GLenum target, GLuint
>> origtexture,
>> GLuint minlevel, GLuint numlevels,
>> GLuint minlayer, GLuint numlayers);
>>
>> +extern void
>> +set_texture_view_state(struct gl_context *ctx, struct gl_texture_object
>> *texObj,
>> + GLenum target, GLuint levels);
>> +
>> #endif /* TEXTUREVIEW_H */
>>
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
--
Courtney Goeltzenleuchter
LunarG
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.
Re: [Mesa-dev] [PATCH 2/2] i965: Set fast color clear mcs_state on newly allocated image miptrees
Keith Packard writes: > Just copying code from the dri2 path to set up the fast color clear state. > > This also removes a couple of bogus intel_region_reference calls. These two are: Reviewed-by: Eric Anholt pgpWbpIEouoko.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 15/18] mesa: Add ARB_viewport_array plumbing
I've added a viewport_array-rc2 branch to my github repository with updates from the feedback so far. Also includes a commit from Ian to Add varying slot for viewport index. Courtney On Fri, Nov 22, 2013 at 3:51 PM, Courtney Goeltzenleuchter < court...@lunarg.com> wrote: > Got it. > > > On Fri, Nov 22, 2013 at 2:55 PM, Chris Forbes wrote: > >> It's just that last block that were messed up -- rest was context. >> >> Sorry for any confusion. >> >> >> On Sat, Nov 23, 2013 at 10:06 AM, Courtney Goeltzenleuchter < >> court...@lunarg.com> wrote: >> >>> Hi Chris, >>> >>> I'm using this version of the spec: >>> http://www.opengl.org/registry/specs/ARB/viewport_array.txt >>> >>> On Thu, Nov 21, 2013 at 4:41 PM, Chris Forbes wrote: >>> I was just comparing to the list in the ARB_viewport_array spec. On Fri, Nov 22, 2013 at 11:33 AM, Courtney Goeltzenleuchter < court...@lunarg.com> wrote: > Hi Chris, > > Where are you getting your defines? > I copied them from include/GL/gl.h > #define GL_VIEWPORT 0x0BA2 > /* Scissor box */ > #define GL_SCISSOR_BOX 0x0C10 > #define GL_SCISSOR_TEST 0x0C11 > #define GL_SCISSOR_TEST 0x0C11 > #define GL_DEPTH_RANGE 0x0B70 > > Ah, FIRST_VERTEX looks different. > #define GL_FIRST_VERTEX_CONVENTION0x8E4D > > I'll add PROVOKING_VERTEX > > Looks like UNDEFINED_VERTEX was wrong as well. > (include/GL/glext.h) #define GL_UNDEFINED_VERTEX 0x8260 > > I was modelling one of the other extension xml files and they had > similar defines, though I could see no effect including or excluding them. > > Should I just get rid of the definitions for values that already exist > in gl.h or glext.h? > > Courtney > > > On Thu, Nov 21, 2013 at 1:00 PM, Chris Forbes wrote: > >> I'm surprised the build system accepts the conflicting second >> definition of SCISSOR_BOX at all, actually -- that's weird. >> >> >> On Fri, Nov 22, 2013 at 8:55 AM, Chris Forbes wrote: >> >>> I mean some of the values don't match the spec :) >>> >>> >>> On Fri, Nov 22, 2013 at 7:52 AM, Courtney Goeltzenleuchter < >>> court...@lunarg.com> wrote: >>> On Wed, Nov 20, 2013 at 7:28 PM, Chris Forbes wrote: > Oops -- the 8E4E is obviously correct. Artifact of me switching > how I > was commenting halfway through. > > On Thu, Nov 21, 2013 at 3:25 PM, Chris Forbes > wrote: > > These are bogus: > > > > + > > + > > + > > + > > + > >>> In the spec I'm using I see: >>> >>> New Tokens >>> >>> Accepted by the parameter of GetBooleanv, GetIntegerv, >>> GetFloatv, >>> GetDoublev and GetInteger64v: >>> >>> MAX_VIEWPORTS 0x825B >>> VIEWPORT_SUBPIXEL_BITS 0x825C >>> VIEWPORT_BOUNDS_RANGE 0x825D >>> LAYER_PROVOKING_VERTEX 0x825E >>> VIEWPORT_INDEX_PROVOKING_VERTEX 0x825F >>> >>> Accepted by the parameter of GetIntegeri_v: >>> >>> *SCISSOR_BOX 0x0C10* >>> >>> Accepted by the parameter of GetFloati_v: >>> >>> *VIEWPORT0x0BA2* >>> >>> Accepted by the parameter of GetDoublei_v: >>> >>> *DEPTH_RANGE 0x0B70* >>> >>> Accepted by the parameter of Enablei, Disablei, and IsEnabledi: >>> >>> *SCISSOR_TEST0x0C11* >>> >>> Thus my confusion regarding "bogus" values. >>> >>> Returned in the parameter from a Get query with a of >>> LAYER_PROVOKING_VERTEX or VIEWPORT_INDEX_PROVOKING_VERTEX: >>> >>> FIRST_VERTEX_CONVENTION 0x8E4D >>> LAST_VERTEX_CONVENTION 0x8E4E >>> PROVOKING_VERTEX0x8E4F >>> UNDEFINED_VERTEX0x8260 >>> >>> >>> >>> What do you mean by "bogus"? I was emulating other extension xml files. Are these not needed because they are already defined in gl_ext.h? > > > > 0x8E4D > > > > + > > > > 0x8E4E > > > > add: > > > > + > > > > 0x8260 > -- Courtney Goeltzenleuchter LunarG >>> >> > > > -- > Courtney Goeltzenleuchter > LunarG > > >>> >>> >>> -- >>> Courtney Goeltzenleuchter >>> LunarG >>> >>> >> > > > -- > Courtney Goeltzenleuchter > LunarG > > -- Courtney Goeltzenleuchter Lun
Re: [Mesa-dev] [PATCH] gallium/dri: Support DRI Image extension version 6 (v2)
Hi,
+ pipe_resource_reference(&img->texture, tex);
You shouldn't reference the texture before we manage to get a correct
dri_format,
in case we fail.
+ img->level = level;
+ img->layer = depth;
+ img->dri_format = driGLFormatToImageFormat(obj->_BufferObjectFormat);
This doesn't give me a correct dri_format.
I think a better way to get the dri_format is to
use tex->format (of type enum pipe_format).
in dri_image_allocate_textures, there is code to convert
such a type in a dri_format.
+
+ img->loader_private = loaderPrivate;
+
+ if (img->dri_format == MESA_FORMAT_NONE) {
I assume you meant __DRI_IMAGE_FORMAT_NONE
+ *error = __DRI_IMAGE_ERROR_BAD_PARAMETER;
+ free(img);
+ return NULL;
+ }
+
+ *error = __DRI_IMAGE_ERROR_SUCCESS;
+ return img;
+}
+
Axel Davy
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/gs: Properly skip GS binding table upload when no GS active.
On 11/25/2013 08:23 AM, Paul Berry wrote:
> Previously, in brw_gs_upload_binding_table(), we checked whether
> brw->gs.prog_data was NULL in order to determine whether a geometry
> shader was active. This didn't work: brw->gs.prog_data starts off as
> NULL, but it is set to non-NULL when a geometry shader program is
> built, and then never set to NULL again. As a result, if we called
> brw_gs_upload_binding_table() while there was no geometry shader
> active, but a geometry shader had previously been active, it would
> refer to a stale (and possibly freed) prog_data structure.
>
> This patch fixes the problem by modifying
> brw_gs_upload_binding_table() to use the proper technique to determine
> whether a geometry shader is active: by checking whether
> brw->geometry_program is NULL.
>
> I suspect this may address the crash reported in comment 2 of bug
> 71870.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/mesa/drivers/dri/i965/brw_binding_tables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_binding_tables.c
> b/src/mesa/drivers/dri/i965/brw_binding_tables.c
> index 0a322dc..b39bd10 100644
> --- a/src/mesa/drivers/dri/i965/brw_binding_tables.c
> +++ b/src/mesa/drivers/dri/i965/brw_binding_tables.c
> @@ -128,7 +128,7 @@ static void
> brw_gs_upload_binding_table(struct brw_context *brw)
> {
> /* If there's no GS, skip changing anything. */
> - if (!brw->gs.prog_data)
> + if (brw->geometry_program == NULL)
>return;
>
> brw_upload_binding_table(brw, BRW_NEW_GS_BINDING_TABLE, &brw->gs.base);
>
Both are:
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/gs: Properly skip GS binding table upload when no GS active.
Ouch.
Reviewed-by: Chris Forbes
On Tue, Nov 26, 2013 at 5:23 AM, Paul Berry wrote:
> Previously, in brw_gs_upload_binding_table(), we checked whether
> brw->gs.prog_data was NULL in order to determine whether a geometry
> shader was active. This didn't work: brw->gs.prog_data starts off as
> NULL, but it is set to non-NULL when a geometry shader program is
> built, and then never set to NULL again. As a result, if we called
> brw_gs_upload_binding_table() while there was no geometry shader
> active, but a geometry shader had previously been active, it would
> refer to a stale (and possibly freed) prog_data structure.
>
> This patch fixes the problem by modifying
> brw_gs_upload_binding_table() to use the proper technique to determine
> whether a geometry shader is active: by checking whether
> brw->geometry_program is NULL.
>
> I suspect this may address the crash reported in comment 2 of bug
> 71870.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
>
> Cc: mesa-sta...@lists.freedesktop.org
> ---
> src/mesa/drivers/dri/i965/brw_binding_tables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_binding_tables.c
> b/src/mesa/drivers/dri/i965/brw_binding_tables.c
> index 0a322dc..b39bd10 100644
> --- a/src/mesa/drivers/dri/i965/brw_binding_tables.c
> +++ b/src/mesa/drivers/dri/i965/brw_binding_tables.c
> @@ -128,7 +128,7 @@ static void
> brw_gs_upload_binding_table(struct brw_context *brw)
> {
> /* If there's no GS, skip changing anything. */
> - if (!brw->gs.prog_data)
> + if (brw->geometry_program == NULL)
>return;
>
> brw_upload_binding_table(brw, BRW_NEW_GS_BINDING_TABLE, &brw->gs.base);
> --
> 1.8.4.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Use __attribute__((flatten)) on fast tiled teximage code.
On 11/23/2013 01:41 PM, Kenneth Graunke wrote:
The fast tiled texture upload code does not compile with GCC 4.8's -Og
optimization flag.
memcpy() has the always_inline attribute set. This poses a problem,
since {x,y}tile_copy_faster calls it indirectly via {x,y}tile_copy,
and {x,y}tile_copy normally aren't inlined at -Og.
Using __attribute__((flatten)) tells GCC to inline every function call
inside the function, which I believe was the author's intent.
Fix suggested by Alexander Monakov.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_tex_subimage.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
Reviewed-by: Chad Versace
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/gs: Set GS prog_data to NULL if there is no GS program.
Paul Berry writes: > The previous commit fixes a bug wherein we would incorrectly refer to > stale geometry shader prog_data when no geometry shader was active. > > This patch reduces the likelihood of that sort of bug occurring in the > future by setting prog_data to NULL whenever there is no GS program. These two are: Reviewed-by: Eric Anholt pgpMT2JxSfKh3.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Spec interpretation question: layered framebuffers with mismatched layer counts
On 11/22/2013 03:08 PM, Paul Berry wrote:
> The ARB_geometry_shader4 spec says, in the list of conditions necessary
> for framebuffer completeness:
>
> * If any framebuffer attachment is layered, all attachments must have
> the same layer count. For three-dimensional textures, the layer
> count
> is the depth of the attached volume. For cube map textures, the
> layer
> count is always six. For one- and two-dimensional array
> textures, the
> layer count is simply the number of layers in the array texture.
> { FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB }
>
>
> When geometry shaders were adopted into desktop GL, this condition was
> dropped. The constant FRAMEBUFFER_INCOMPLETE_LAYER_COUNT doesn't appear
> at all in the desktop GL spec. Instead, GL 3.2 says (in section 4.4.7
> (Layered Framebuffers)):
>
> When fragments are written to a layered framebuffer, the fragment’s
> layer number selects an image from the array of images at each
> attachment point to use for the stencil test (see section 4.1.5), depth
> buffer test (see section 4.1.6), and for blending and color buffer
> writes (see section 4.1.8). If the fragment’s layer number is negative,
> or greater than the minimum number of layers of any attachment, the
> effects of the fragment on the framebuffer contents are undefined.
>
> (note: presumably where the spec says "greater", "greater than equal" is
> actually intended).
>
> In other words, a framebuffer is allowed to have layers with mismatched
> layer counts, but if so then the client may only reliably render to
> layer numbers that are present in all attachments.
>
> Mesa currently implements the rule in ARB_geometry_shader4.
> Technically, this is a bug, since Mesa is trying to implement geometry
> shaders as specified in GL 3.2, not as specified in ARB_geometry_shader4.
>
> However, there are two mitigating factors:
>
> 1. If we follow the GL 3.2 spec, then it's not clear what should happen
> if the client calls glClear() on a framebuffer with mismatched layer
> counts. For example, if I have a color attachment with 4 layers and a
> color attachment with 2 layers, should all 4 layers of the color
> attachment with 4 layers be cleared, or just the first 2? Or is it
> undefined? If we're required to clear all 4 layers, that's going to
> make the Meta implementation of glClear() a lot more clumsy.
Principle of least surprise suggests that we should do whatever we
already do for mismatches in other dimensions. I seem to recall there
being a fairly recent Khronos bug about that very issue. I'll try to
track down the resoultion.
> 2. The Nvidia proprietary drivers for Linux (version 313.18) follows the
> ARB_geometry_shader4 rule (returning
> FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB from glCheckFramebufferStatus()),
> even when an OpenGL 3.2+ context is used.
That is surprising. If you have a test case, maybe Ken could try it on AMD.
> Currently, I'm inclined to leave Mesa as is, and file a spec bug with
> Khronos encouraging them to adopt the ARB_geometry_shader4 text into
> OpenGL. I'm curious to hear other people's opinions.
Looking at the spec, I think the change was intentional, but I don't
recall why. I'd have to do some archaeology to find the reason. If we
poke at some other implementations and they all generate
FRAMEBUFFER_INCOMPLETE_LAYER_COUNT_ARB, then we should try to get the
spec changed. If some implementations don't generate the error, then
the next step is not as clear to me.
As for what to do now (i.e., for 10.0), I think we're safe generating
the error. Since another major implementation incorrectly generates the
erorr, the probably that any application depends on mis-matched layer
counts is very low. This means that our spec deviation is unlikely to
break anything or cause developers to create more buggy apps (since this
is more strict rather than more lax).
> Thanks,
>
> Paul
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Enable ARB_map_buffer_alignment in all drivers - first try
Hi, today I read an article on phoronix (http://www.phoronix.com/scan.php?page=news_item&px=MTUyNDY) which linked to a wiki page (http://wiki.freedesktop.org/dri/NewbieProjects/) where easy projects to start with were listed. I gave it a shot and tried to implement the ARB_map_buffer_alignment extensions for all drivers. Long story short, here is the patch I've created. I'm not completely sure whether everything I did was what the creator of the wiki page had in mind. I am especially unsure about the last item. Ofc it would be very great iff one of you guys can provide some feedback :) -Thomas >From 34ef41b9755366d99610997b223a2a6aada163b1 Mon Sep 17 00:00:00 2001 From: Thomas Prescher Date: Tue, 26 Nov 2013 19:45:15 + Subject: [PATCH] Enable ARB_map_buffer_alignment in all drivers --- src/gallium/drivers/i915/i915_resource_buffer.c| 2 +- src/gallium/drivers/i915/i915_screen.c | 1 + src/gallium/drivers/ilo/ilo_screen.c | 2 +- src/gallium/drivers/llvmpipe/lp_screen.c | 1 + src/gallium/drivers/llvmpipe/lp_texture.c | 6 +++--- src/gallium/drivers/softpipe/sp_screen.c | 2 +- src/gallium/drivers/softpipe/sp_texture.c | 4 ++-- src/gallium/drivers/svga/svga_screen.c | 1 + src/mesa/drivers/dri/i915/intel_buffer_objects.c | 2 +- src/mesa/drivers/dri/i965/brw_context.c| 2 ++ src/mesa/drivers/dri/nouveau/nouveau_bufferobj.c | 2 +- .../drivers/dri/radeon/radeon_buffer_objects.c | 2 +- src/mesa/main/bufferobj.c | 24 ++ src/mesa/main/context.c| 3 +++ src/mesa/main/extensions.c | 2 +- src/mesa/state_tracker/st_extensions.c | 1 + 16 files changed, 32 insertions(+), 25 deletions(-) diff --git a/src/gallium/drivers/i915/i915_resource_buffer.c b/src/gallium/drivers/i915/i915_resource_buffer.c index 80ec43a..fd29524 100644 --- a/src/gallium/drivers/i915/i915_resource_buffer.c +++ b/src/gallium/drivers/i915/i915_resource_buffer.c @@ -135,7 +135,7 @@ i915_buffer_create(struct pipe_screen *screen, buf->b.vtbl = &i915_buffer_vtbl; pipe_reference_init(&buf->b.b.reference, 1); buf->b.b.screen = screen; - buf->data = align_malloc(template->width0, 16); + buf->data = align_malloc(template->width0, 64); buf->free_on_destroy = TRUE; if (!buf->data) diff --git a/src/gallium/drivers/i915/i915_screen.c b/src/gallium/drivers/i915/i915_screen.c index 77607d0..3bc6ecf 100644 --- a/src/gallium/drivers/i915/i915_screen.c +++ b/src/gallium/drivers/i915/i915_screen.c @@ -213,6 +213,7 @@ i915_get_param(struct pipe_screen *screen, enum pipe_cap cap) case PIPE_CAP_QUERY_PIPELINE_STATISTICS: case PIPE_CAP_TEXTURE_MULTISAMPLE: case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: + return 64; case PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK: return 0; case PIPE_CAP_MAX_DUAL_SOURCE_RENDER_TARGETS: diff --git a/src/gallium/drivers/ilo/ilo_screen.c b/src/gallium/drivers/ilo/ilo_screen.c index a345b70..466b21c 100644 --- a/src/gallium/drivers/ilo/ilo_screen.c +++ b/src/gallium/drivers/ilo/ilo_screen.c @@ -406,7 +406,7 @@ ilo_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_TEXTURE_MULTISAMPLE: return false; /* TODO */ case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: - return 0; + return 4096; case PIPE_CAP_CUBE_MAP_ARRAY: case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: return true; diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c b/src/gallium/drivers/llvmpipe/lp_screen.c index f61df98..8be1779 100644 --- a/src/gallium/drivers/llvmpipe/lp_screen.c +++ b/src/gallium/drivers/llvmpipe/lp_screen.c @@ -220,6 +220,7 @@ llvmpipe_get_param(struct pipe_screen *screen, enum pipe_cap param) case PIPE_CAP_START_INSTANCE: case PIPE_CAP_TEXTURE_MULTISAMPLE: case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT: + return 64; case PIPE_CAP_CUBE_MAP_ARRAY: return 0; case PIPE_CAP_TEXTURE_BUFFER_OBJECTS: diff --git a/src/gallium/drivers/llvmpipe/lp_texture.c b/src/gallium/drivers/llvmpipe/lp_texture.c index 0088b6a..fa75df8 100644 --- a/src/gallium/drivers/llvmpipe/lp_texture.c +++ b/src/gallium/drivers/llvmpipe/lp_texture.c @@ -200,7 +200,7 @@ llvmpipe_displaytarget_layout(struct llvmpipe_screen *screen, lpr->base.bind, lpr->base.format, width, height, - 16, + 64, &lpr->row_stride[0] ); if (lpr->dt == NULL) @@ -261,7 +261,7 @@ llvmpipe_resource_create(struct pipe_screen *_screen, * read/write always LP_RASTER_BLOCK_SIZE pixels, but the element * offset doesn't need to be aligned to LP_RASTER_BLOCK_SIZE. */ - lpr->data = align_malloc(bytes
Re: [Mesa-dev] [PATCH] glx: Extra gc null check for glXMakeCurrent
On Mon, Nov 25, 2013 at 7:12 PM, Ian Romanick wrote: > On 11/25/2013 07:23 AM, Juha-Pekka Heikkila wrote: > > Extra null check before accessing user given context pointer. > > oldGC can never be NULL. If there is no current context, it will point > to dummyContext. > Ah, ok. I was just going through list what Klocwork says about Mesa and did not see what prevented null here. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 14/17] Modified i915 intel_bufferobj_data to use _mesa_align_malloc instead of malloc.
On 11/24/2013 11:17 PM, Chris Forbes wrote:
> I'm not convinced that just using _mesa_align_malloc() is sufficient
> here. Issue 2 from the ARB_map_buffer_alignment spec says:
>
> 2) What alignment should be used for MapBufferRange when is
> non-zero?
>
> RESOLVED: The pointer returned should be consistent with the base of the
> buffer being aligned. For example, if a buffer was mapped with an
> of 24 bytes on an implementation with a
> MIN_MAP_BUFFER_ALIGNMENT of 64, the value of the pointer returned
> would have a value of the form 64*+24 for some integer .
>
> Cc'ing Ian, since I assume this is based on his instructions.
Yeah... Ken told me that Eric mentioned this issue when Ken sent out
some patches to enable this extension just for i965. There are a couple
ways to solve this, I think.
One way would be to modify MapBuffer and friends to only request aligned
offsets from the driver and do some pointer fidgeting. For drivers that
advertise small alignments, that should be fine... for drivers that
advertise large alignments this could be a problem.
Another way would be some similar sorts of fudging in each driver. The
MapBufferRange handler in the driver would have to do an aligned
allocation but only copy the necessary bits.
I don't have a strong opinion either way about the implementation...
though I would like to see some tests that could tickle this bug, if it
existed. AFAIK, we tend to return a direct mapping, so an obvious test
of glMapBufferRange(target, 7, size, access) probably won't hit it.
> -- Chris
>
>
> On Mon, Nov 25, 2013 at 6:36 PM, Siavash Eliasi
> wrote:
>> ---
>> src/mesa/drivers/dri/i915/intel_buffer_objects.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i915/intel_buffer_objects.c
>> b/src/mesa/drivers/dri/i915/intel_buffer_objects.c
>> index bc58c70..4fbf954 100644
>> --- a/src/mesa/drivers/dri/i915/intel_buffer_objects.c
>> +++ b/src/mesa/drivers/dri/i915/intel_buffer_objects.c
>> @@ -137,7 +137,7 @@ intel_bufferobj_data(struct gl_context * ctx,
>> * contents anyway.
>> */
>>if (target == GL_ARRAY_BUFFER || target == GL_ELEMENT_ARRAY_BUFFER) {
>> -intel_obj->sys_buffer = malloc(size);
>> +intel_obj->sys_buffer = _mesa_align_malloc(size,
>> ctx->Const.MinMapBufferAlignment);
>> if (intel_obj->sys_buffer != NULL) {
>> if (data != NULL)
>>memcpy(intel_obj->sys_buffer, data, size);
>> @@ -337,7 +337,7 @@ intel_bufferobj_map_range(struct gl_context * ctx,
>> if ((access & GL_MAP_INVALIDATE_RANGE_BIT) &&
>> drm_intel_bo_busy(intel_obj->buffer)) {
>>if (access & GL_MAP_FLUSH_EXPLICIT_BIT) {
>> -intel_obj->range_map_buffer = malloc(length);
>> +intel_obj->range_map_buffer = _mesa_align_malloc(length,
>> ctx->Const.MinMapBufferAlignment);
>> obj->Pointer = intel_obj->range_map_buffer;
>>} else {
>> intel_obj->range_map_bo = drm_intel_bo_alloc(intel->bufmgr,
>> --
>> 1.8.4.2
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/11] mesa: Validate image units when the texture state changes.
Ah, of course; so it's not a factor for driver which don't expose the
extension at all.
The `unused` side still stands as a vague concern, I think -- we
currently pay for lots of things that most apps don't use.
On Tue, Nov 26, 2013 at 6:43 AM, Francisco Jerez wrote:
> Chris Forbes writes:
>
>> It would be nice not to have to touch this memory when the extension
>> is unused|unsupported, but that might be a problem for another
>> patch...
>>
> How do you mean? If the driver doesn't know about this extension
> ctx->Const.MaxImageUnits will be zero and no memory will be touched.
>
>> -- Chris
>>
>> On Mon, Nov 25, 2013 at 6:00 PM, Francisco Jerez
>> wrote:
>>> ---
>>> src/mesa/main/shaderimage.c | 11 +++
>>> src/mesa/main/shaderimage.h | 9 +
>>> src/mesa/main/texstate.c| 3 +++
>>> 3 files changed, 23 insertions(+)
>>>
>>> diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
>>> index 627366b..3a59409 100644
>>> --- a/src/mesa/main/shaderimage.c
>>> +++ b/src/mesa/main/shaderimage.c
>>> @@ -368,6 +368,17 @@ validate_image_unit(struct gl_context *ctx, struct
>>> gl_image_unit *u)
>>> return GL_TRUE;
>>> }
>>>
>>> +void
>>> +_mesa_validate_image_units(struct gl_context *ctx)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; i < ctx->Const.MaxImageUnits; ++i) {
>>> + struct gl_image_unit *u = &ctx->ImageUnits[i];
>>> + u->_Valid = validate_image_unit(ctx, u);
>>> + }
>>> +}
>>> +
>>> static GLboolean
>>> validate_bind_image_texture(struct gl_context *ctx, GLuint unit,
>>> GLuint texture, GLint level, GLboolean layered,
>>> diff --git a/src/mesa/main/shaderimage.h b/src/mesa/main/shaderimage.h
>>> index f9d550b..aaecc5d 100644
>>> --- a/src/mesa/main/shaderimage.h
>>> +++ b/src/mesa/main/shaderimage.h
>>> @@ -31,6 +31,15 @@
>>>
>>> struct gl_context;
>>>
>>> +/**
>>> + * Recalculate the \c _Valid flag of a context's shader image units.
>>> + *
>>> + * To be called when the state of any texture bound to an image unit
>>> + * changes.
>>> + */
>>> +void
>>> +_mesa_validate_image_units(struct gl_context *ctx);
>>> +
>>> void GLAPIENTRY
>>> _mesa_BindImageTexture(GLuint unit, GLuint texture, GLint level,
>>> GLboolean layered, GLint layer, GLenum access,
>>> diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
>>> index ad80dcf..7720965 100644
>>> --- a/src/mesa/main/texstate.c
>>> +++ b/src/mesa/main/texstate.c
>>> @@ -35,6 +35,7 @@
>>> #include "context.h"
>>> #include "enums.h"
>>> #include "macros.h"
>>> +#include "shaderimage.h"
>>> #include "texobj.h"
>>> #include "teximage.h"
>>> #include "texstate.h"
>>> @@ -674,6 +675,8 @@ update_texture_state( struct gl_context *ctx )
>>>
>>> if (!fprog || !vprog)
>>>update_texgen(ctx);
>>> +
>>> + _mesa_validate_image_units(ctx);
>>> }
>>>
>>>
>>> --
>>> 1.8.3.4
>>>
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/11] mesa: Add state data structures requried for ARB_shader_image_load_store.
That makes good sense.
On Tue, Nov 26, 2013 at 6:45 AM, Francisco Jerez wrote:
> Chris Forbes writes:
>
>> In the commit message, s/requried/required/
>>
>> Does holding onto the whole texture object make things easier? I had
>> assumed you could get by just referencing the right gl_texture_image,
>> but maybe that doesn't work out.
>>
>
> Yes, it does for many reasons: First, if we only kept a reference to the
> teximage we would still need to reference the texture object to prevent
> it from being deleted. Second, it would be hard to deal with cases like
> the binding of an incomplete mipmap to an image unit that is only
> completed afterwards -- that would make the teximage reference go stale.
> Third, in array and cubemap textures, there is no "right" teximage, we
> may want to bind all images present in some specific level.
>
> Thanks for the quick response. :)
>
>> On Mon, Nov 25, 2013 at 6:00 PM, Francisco Jerez
>> wrote:
>>> ---
>>> src/mesa/main/config.h | 1 +
>>> src/mesa/main/dd.h | 1 +
>>> src/mesa/main/mtypes.h | 100
>>> +
>>> src/mesa/main/texobj.c | 1 +
>>> 4 files changed, 103 insertions(+)
>>>
>>> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
>>> index 22bbfa0..8bd9765 100644
>>> --- a/src/mesa/main/config.h
>>> +++ b/src/mesa/main/config.h
>>> @@ -175,6 +175,7 @@
>>> #define MAX_COMBINED_ATOMIC_BUFFERS(MAX_UNIFORM_BUFFERS * 6)
>>> /* Size of an atomic counter in bytes according to
>>> ARB_shader_atomic_counters */
>>> #define ATOMIC_COUNTER_SIZE4
>>> +#define MAX_IMAGE_UNITS32
>>> /*@}*/
>>>
>>> /**
>>> diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
>>> index b5b874f..648062f 100644
>>> --- a/src/mesa/main/dd.h
>>> +++ b/src/mesa/main/dd.h
>>> @@ -39,6 +39,7 @@ struct gl_buffer_object;
>>> struct gl_context;
>>> struct gl_display_list;
>>> struct gl_framebuffer;
>>> +struct gl_image_unit;
>>> struct gl_pixelstore_attrib;
>>> struct gl_program;
>>> struct gl_renderbuffer;
>>> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
>>> index e9750f4..7be0664 100644
>>> --- a/src/mesa/main/mtypes.h
>>> +++ b/src/mesa/main/mtypes.h
>>> @@ -1207,6 +1207,9 @@ struct gl_texture_object
>>>
>>> /** GL_OES_EGL_image_external */
>>> GLint RequiredTextureImageUnits;
>>> +
>>> + /** GL_ARB_shader_image_load_store */
>>> + GLenum ImageFormatCompatibility;
>>> };
>>>
>>>
>>> @@ -2373,6 +2376,29 @@ struct gl_shader
>>> */
>>>GLenum OutputType;
>>> } Geom;
>>> +
>>> + /**
>>> +* Map from image uniform index to image unit (set by glUniform1i())
>>> +*
>>> +* An image uniform index is associated with each image uniform by
>>> +* the linker. The image index associated with each uniform is
>>> +* stored in the \c gl_uniform_storage::image field.
>>> +*/
>>> + GLubyte ImageUnits[MAX_IMAGE_UNITS];
>>> +
>>> + /**
>>> +* Access qualifier specified in the shader for each image uniform.
>>> +* Either \c GL_READ_ONLY, \c GL_WRITE_ONLY or \c GL_READ_WRITE.
>>> +*
>>> +* It may be different, though only more strict than the value of
>>> +* \c gl_image_unit::Access for the corresponding image unit.
>>> +*/
>>> + GLenum ImageAccess[MAX_IMAGE_UNITS];
>>> +
>>> + /**
>>> +* Number of image uniforms defined in the shader.
>>> +*/
>>> + GLuint NumImages;
>>> };
>>>
>>>
>>> @@ -3077,9 +3103,13 @@ struct gl_program_constants
>>> GLuint MaxUniformBlocks;
>>> GLuint MaxCombinedUniformComponents;
>>> GLuint MaxTextureImageUnits;
>>> +
>>> /* GL_ARB_shader_atomic_counters */
>>> GLuint MaxAtomicBuffers;
>>> GLuint MaxAtomicCounters;
>>> +
>>> + /* GL_ARB_shader_image_load_store */
>>> + GLuint MaxImageUniforms;
>>> };
>>>
>>>
>>> @@ -3302,6 +3332,12 @@ struct gl_constants
>>> /** GL_ARB_vertex_attrib_binding */
>>> GLint MaxVertexAttribRelativeOffset;
>>> GLint MaxVertexAttribBindings;
>>> +
>>> + /* GL_ARB_shader_image_load_store */
>>> + GLuint MaxImageUnits;
>>> + GLuint MaxCombinedImageUnitsAndFragmentOutputs;
>>> + GLuint MaxImageSamples;
>>> + GLuint MaxCombinedImageUniforms;
>>> };
>>>
>>>
>>> @@ -3727,6 +3763,11 @@ struct gl_driver_flags
>>> * gl_context::AtomicBufferBindings
>>> */
>>> GLbitfield NewAtomicBuffer;
>>> +
>>> + /**
>>> +* gl_context::ImageUnits
>>> +*/
>>> + GLbitfield NewImageUnits;
>>> };
>>>
>>> struct gl_uniform_buffer_binding
>>> @@ -3744,6 +3785,60 @@ struct gl_uniform_buffer_binding
>>> };
>>>
>>> /**
>>> + * ARB_shader_image_load_store image unit.
>>> + */
>>> +struct gl_image_unit
>>> +{
>>> + /**
>>> +* Texture object bound to this unit.
>>> +*/
>>> + struct gl_texture_object *TexObj;
>>> +
>>> + /**
>>> +* Level of the texture object bound to this unit.
>>> +*/
>>> + GLuint Level;
>>> +
>>> + /**
>>> +* \c GL_TRUE if the whole level is bound as
Re: [Mesa-dev] [PATCH 1/2] i965: Allocate vec4_visitor's uniform_size and uniform_vector_size arrays dynamically.
Petri Latvala writes:
> On 11/22/2013 08:05 PM, Francisco Jerez wrote:
>> Petri Latvala writes:
>>
>>> [...]
>>> @@ -325,8 +326,9 @@ public:
>>> */
>>> dst_reg output_reg[BRW_VARYING_SLOT_COUNT];
>>> const char *output_reg_annotation[BRW_VARYING_SLOT_COUNT];
>>> - int uniform_size[MAX_UNIFORMS];
>>> - int uniform_vector_size[MAX_UNIFORMS];
>>> + unsigned uniform_param_count;
>>> + int* uniform_size;
>>> + int* uniform_vector_size;
>>> int uniforms;
>>>
>> All the code around you uses the 'type *identifier' convention, please
>> keep it consistent.
>
> *slap on forehead* note to self, disable muscle memory. Fixing that.
>
>>> src_reg shader_start_time;
>>> [...]
>>> @@ -556,7 +558,7 @@ brw_gs_emit(struct brw_context *brw,
>>> if (likely(!(INTEL_DEBUG& DEBUG_NO_DUAL_OBJECT_GS))) {
>>> c->prog_data.dual_instanced_dispatch = false;
>>>
>>> - vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, true /* no_spills
>>> */);
>>> + vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, true /* no_spills
>>> */, param_count);
>> Another possibility would be to set 'c.prog_data.base.nr_params =
>> param_count' here and in brw_vs_emit(), so you'd have the same value
>> available from the constructor of vec4_visitor without all the parameter
>> changes.
>
> When trying this change, I began to wonder if I'm using the right values
> at all. What is that nr_params supposed to be for code elsewhere?
> vec4_visitor::setup_uniforms() sets it to this->uniforms * 4, but
> param_count that I passed from do_vs_prog() to brw_vs_emit() is
> num_uniform_components * 4, yielding (close to) this->uniforms * 4 * 4.
Oh... Apparently do_vs_prog() is overallocating memory. And so is
do_gs_prog()... That seems like a bug.
> Close to means that my test program gives param_count being 92, and
> this->uniforms * 4 in setup_uniforms() is 24.
>
> Is vec4_visitor::setup_uniforms() supposed to be the authoritative
> source of the uniform counts or is that nr_params assignment just for
> the pre-gen6 hack in the same function? Is nr_params supposed to be the
> number of uniform components or uniforms?
It should be the number of uniform components (in units of 32-bit
floats).
> To my understanding param_count in do_vs_prog() is the number of
> uniform components required to hold all uniforms with a vec4 for each
> one (float or otherwise), are the floats packed to vec4s anywhere?
>
Yes, see vec4_visitor::pack_uniform_registers().
>
> --
> Petri Latvala
pgpH9bUzFzmPZ.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/11] mesa: Add state data structures requried for ARB_shader_image_load_store.
Chris Forbes writes:
> In the commit message, s/requried/required/
>
> Does holding onto the whole texture object make things easier? I had
> assumed you could get by just referencing the right gl_texture_image,
> but maybe that doesn't work out.
>
Yes, it does for many reasons: First, if we only kept a reference to the
teximage we would still need to reference the texture object to prevent
it from being deleted. Second, it would be hard to deal with cases like
the binding of an incomplete mipmap to an image unit that is only
completed afterwards -- that would make the teximage reference go stale.
Third, in array and cubemap textures, there is no "right" teximage, we
may want to bind all images present in some specific level.
Thanks for the quick response. :)
> On Mon, Nov 25, 2013 at 6:00 PM, Francisco Jerez
> wrote:
>> ---
>> src/mesa/main/config.h | 1 +
>> src/mesa/main/dd.h | 1 +
>> src/mesa/main/mtypes.h | 100
>> +
>> src/mesa/main/texobj.c | 1 +
>> 4 files changed, 103 insertions(+)
>>
>> diff --git a/src/mesa/main/config.h b/src/mesa/main/config.h
>> index 22bbfa0..8bd9765 100644
>> --- a/src/mesa/main/config.h
>> +++ b/src/mesa/main/config.h
>> @@ -175,6 +175,7 @@
>> #define MAX_COMBINED_ATOMIC_BUFFERS(MAX_UNIFORM_BUFFERS * 6)
>> /* Size of an atomic counter in bytes according to
>> ARB_shader_atomic_counters */
>> #define ATOMIC_COUNTER_SIZE4
>> +#define MAX_IMAGE_UNITS32
>> /*@}*/
>>
>> /**
>> diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
>> index b5b874f..648062f 100644
>> --- a/src/mesa/main/dd.h
>> +++ b/src/mesa/main/dd.h
>> @@ -39,6 +39,7 @@ struct gl_buffer_object;
>> struct gl_context;
>> struct gl_display_list;
>> struct gl_framebuffer;
>> +struct gl_image_unit;
>> struct gl_pixelstore_attrib;
>> struct gl_program;
>> struct gl_renderbuffer;
>> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
>> index e9750f4..7be0664 100644
>> --- a/src/mesa/main/mtypes.h
>> +++ b/src/mesa/main/mtypes.h
>> @@ -1207,6 +1207,9 @@ struct gl_texture_object
>>
>> /** GL_OES_EGL_image_external */
>> GLint RequiredTextureImageUnits;
>> +
>> + /** GL_ARB_shader_image_load_store */
>> + GLenum ImageFormatCompatibility;
>> };
>>
>>
>> @@ -2373,6 +2376,29 @@ struct gl_shader
>> */
>>GLenum OutputType;
>> } Geom;
>> +
>> + /**
>> +* Map from image uniform index to image unit (set by glUniform1i())
>> +*
>> +* An image uniform index is associated with each image uniform by
>> +* the linker. The image index associated with each uniform is
>> +* stored in the \c gl_uniform_storage::image field.
>> +*/
>> + GLubyte ImageUnits[MAX_IMAGE_UNITS];
>> +
>> + /**
>> +* Access qualifier specified in the shader for each image uniform.
>> +* Either \c GL_READ_ONLY, \c GL_WRITE_ONLY or \c GL_READ_WRITE.
>> +*
>> +* It may be different, though only more strict than the value of
>> +* \c gl_image_unit::Access for the corresponding image unit.
>> +*/
>> + GLenum ImageAccess[MAX_IMAGE_UNITS];
>> +
>> + /**
>> +* Number of image uniforms defined in the shader.
>> +*/
>> + GLuint NumImages;
>> };
>>
>>
>> @@ -3077,9 +3103,13 @@ struct gl_program_constants
>> GLuint MaxUniformBlocks;
>> GLuint MaxCombinedUniformComponents;
>> GLuint MaxTextureImageUnits;
>> +
>> /* GL_ARB_shader_atomic_counters */
>> GLuint MaxAtomicBuffers;
>> GLuint MaxAtomicCounters;
>> +
>> + /* GL_ARB_shader_image_load_store */
>> + GLuint MaxImageUniforms;
>> };
>>
>>
>> @@ -3302,6 +3332,12 @@ struct gl_constants
>> /** GL_ARB_vertex_attrib_binding */
>> GLint MaxVertexAttribRelativeOffset;
>> GLint MaxVertexAttribBindings;
>> +
>> + /* GL_ARB_shader_image_load_store */
>> + GLuint MaxImageUnits;
>> + GLuint MaxCombinedImageUnitsAndFragmentOutputs;
>> + GLuint MaxImageSamples;
>> + GLuint MaxCombinedImageUniforms;
>> };
>>
>>
>> @@ -3727,6 +3763,11 @@ struct gl_driver_flags
>> * gl_context::AtomicBufferBindings
>> */
>> GLbitfield NewAtomicBuffer;
>> +
>> + /**
>> +* gl_context::ImageUnits
>> +*/
>> + GLbitfield NewImageUnits;
>> };
>>
>> struct gl_uniform_buffer_binding
>> @@ -3744,6 +3785,60 @@ struct gl_uniform_buffer_binding
>> };
>>
>> /**
>> + * ARB_shader_image_load_store image unit.
>> + */
>> +struct gl_image_unit
>> +{
>> + /**
>> +* Texture object bound to this unit.
>> +*/
>> + struct gl_texture_object *TexObj;
>> +
>> + /**
>> +* Level of the texture object bound to this unit.
>> +*/
>> + GLuint Level;
>> +
>> + /**
>> +* \c GL_TRUE if the whole level is bound as an array of layers, \c
>> +* GL_FALSE if only some specific layer of the texture is bound.
>> +* \sa Layer
>> +*/
>> + GLboolean Layered;
>> +
>> + /**
>> +* Layer of the texture object bound to this unit, or zero if \c
>> +
Re: [Mesa-dev] [PATCH 2/2] llvmpipe: start faking multisample support
Am 25.11.2013 11:41, schrieb Dave Airlie:
> From: Dave Airlie
>
> We've talked in the past about just faking multisample support
> in the sw drivers as much as we possibly can, this just adds enough
> to llvmpipe to do that.
>
> It produces some valid fails in piglit, like the accuracy tests
> and the texelFetch tests fail due to lack of second texel,
>
> Some fails we might be able to mitigate but not sure what we'd gain,
> like alpha-to-one.
>
> Some of the format tests fail so could do with more investigation.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 7 ++-
> src/gallium/drivers/llvmpipe/lp_screen.c| 4 ++--
> src/gallium/drivers/llvmpipe/lp_surface.c | 8
> 3 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> index 6d8dc8c..b732b72 100644
> --- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> +++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
> @@ -1920,11 +1920,13 @@ emit_sample(struct lp_build_tgsi_soa_context *bld,
>num_derivs = 1;
>break;
> case TGSI_TEXTURE_2D:
> + case TGSI_TEXTURE_2D_MSAA:
> case TGSI_TEXTURE_RECT:
>num_offsets = 2;
>num_derivs = 2;
>break;
> case TGSI_TEXTURE_2D_ARRAY:
> + case TGSI_TEXTURE_2D_ARRAY_MSAA:
>layer_coord = 2;
>num_offsets = 2;
>num_derivs = 2;
> @@ -2088,10 +2090,12 @@ emit_fetch_texels( struct lp_build_tgsi_soa_context
> *bld,
>dims = 1;
>break;
> case TGSI_TEXTURE_2D:
> + case TGSI_TEXTURE_2D_MSAA:
> case TGSI_TEXTURE_RECT:
>dims = 2;
>break;
> case TGSI_TEXTURE_2D_ARRAY:
> + case TGSI_TEXTURE_2D_ARRAY_MSAA:
>layer_coord = 2;
>dims = 2;
>break;
> @@ -2104,7 +2108,8 @@ emit_fetch_texels( struct lp_build_tgsi_soa_context
> *bld,
> }
>
> /* always have lod except for buffers ? */
> - if (target != TGSI_TEXTURE_BUFFER) {
> + if (target != TGSI_TEXTURE_BUFFER && target != TGSI_TEXTURE_2D_MSAA &&
> + target != TGSI_TEXTURE_2D_ARRAY_MSAA) {
>explicit_lod = lp_build_emit_fetch(&bld->bld_base, inst, 0, 3);
>lod_property = lp_build_lod_property(&bld->bld_base, inst, 0);
> }
> diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
> b/src/gallium/drivers/llvmpipe/lp_screen.c
> index f61df98..34d536b 100644
> --- a/src/gallium/drivers/llvmpipe/lp_screen.c
> +++ b/src/gallium/drivers/llvmpipe/lp_screen.c
> @@ -218,11 +218,11 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
> pipe_cap param)
> case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
>return 16;
> case PIPE_CAP_START_INSTANCE:
> - case PIPE_CAP_TEXTURE_MULTISAMPLE:
> case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT:
> case PIPE_CAP_CUBE_MAP_ARRAY:
>return 0;
> case PIPE_CAP_TEXTURE_BUFFER_OBJECTS:
> + case PIPE_CAP_TEXTURE_MULTISAMPLE:
>return 1;
> case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
>return 65536;
> @@ -327,7 +327,7 @@ llvmpipe_is_format_supported( struct pipe_screen *_screen,
>target == PIPE_TEXTURE_3D ||
>target == PIPE_TEXTURE_CUBE);
>
> - if (sample_count > 1)
> + if (sample_count > 4)
>return FALSE;
>
> if (bind & PIPE_BIND_RENDER_TARGET) {
> diff --git a/src/gallium/drivers/llvmpipe/lp_surface.c
> b/src/gallium/drivers/llvmpipe/lp_surface.c
> index f033c46..5c059d7 100644
> --- a/src/gallium/drivers/llvmpipe/lp_surface.c
> +++ b/src/gallium/drivers/llvmpipe/lp_surface.c
> @@ -180,14 +180,6 @@ static void lp_blit(struct pipe_context *pipe,
> struct llvmpipe_context *lp = llvmpipe_context(pipe);
> struct pipe_blit_info info = *blit_info;
>
> - if (info.src.resource->nr_samples > 1 &&
> - info.dst.resource->nr_samples <= 1 &&
> - !util_format_is_depth_or_stencil(info.src.resource->format) &&
> - !util_format_is_pure_integer(info.src.resource->format)) {
> - debug_printf("llvmpipe: color resolve unimplemented\n");
> - return;
> - }
> -
> if (util_try_blit_via_copy_region(pipe, &info)) {
>return; /* done */
> }
>
I think some switch statements inside the sampling code would need
updates too, I don't think the two new cases are handled appropriately
everywhere.
Though actually I was thinking more about wrongly advertizing GL 3.0 (or
3.1 or whatever) and still just sample count of 1 rather than faking 4
samples support. Seemed like a neater hack.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/11] mesa: Validate image units when the texture state changes.
Chris Forbes writes:
> It would be nice not to have to touch this memory when the extension
> is unused|unsupported, but that might be a problem for another
> patch...
>
How do you mean? If the driver doesn't know about this extension
ctx->Const.MaxImageUnits will be zero and no memory will be touched.
> -- Chris
>
> On Mon, Nov 25, 2013 at 6:00 PM, Francisco Jerez
> wrote:
>> ---
>> src/mesa/main/shaderimage.c | 11 +++
>> src/mesa/main/shaderimage.h | 9 +
>> src/mesa/main/texstate.c| 3 +++
>> 3 files changed, 23 insertions(+)
>>
>> diff --git a/src/mesa/main/shaderimage.c b/src/mesa/main/shaderimage.c
>> index 627366b..3a59409 100644
>> --- a/src/mesa/main/shaderimage.c
>> +++ b/src/mesa/main/shaderimage.c
>> @@ -368,6 +368,17 @@ validate_image_unit(struct gl_context *ctx, struct
>> gl_image_unit *u)
>> return GL_TRUE;
>> }
>>
>> +void
>> +_mesa_validate_image_units(struct gl_context *ctx)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < ctx->Const.MaxImageUnits; ++i) {
>> + struct gl_image_unit *u = &ctx->ImageUnits[i];
>> + u->_Valid = validate_image_unit(ctx, u);
>> + }
>> +}
>> +
>> static GLboolean
>> validate_bind_image_texture(struct gl_context *ctx, GLuint unit,
>> GLuint texture, GLint level, GLboolean layered,
>> diff --git a/src/mesa/main/shaderimage.h b/src/mesa/main/shaderimage.h
>> index f9d550b..aaecc5d 100644
>> --- a/src/mesa/main/shaderimage.h
>> +++ b/src/mesa/main/shaderimage.h
>> @@ -31,6 +31,15 @@
>>
>> struct gl_context;
>>
>> +/**
>> + * Recalculate the \c _Valid flag of a context's shader image units.
>> + *
>> + * To be called when the state of any texture bound to an image unit
>> + * changes.
>> + */
>> +void
>> +_mesa_validate_image_units(struct gl_context *ctx);
>> +
>> void GLAPIENTRY
>> _mesa_BindImageTexture(GLuint unit, GLuint texture, GLint level,
>> GLboolean layered, GLint layer, GLenum access,
>> diff --git a/src/mesa/main/texstate.c b/src/mesa/main/texstate.c
>> index ad80dcf..7720965 100644
>> --- a/src/mesa/main/texstate.c
>> +++ b/src/mesa/main/texstate.c
>> @@ -35,6 +35,7 @@
>> #include "context.h"
>> #include "enums.h"
>> #include "macros.h"
>> +#include "shaderimage.h"
>> #include "texobj.h"
>> #include "teximage.h"
>> #include "texstate.h"
>> @@ -674,6 +675,8 @@ update_texture_state( struct gl_context *ctx )
>>
>> if (!fprog || !vprog)
>>update_texgen(ctx);
>> +
>> + _mesa_validate_image_units(ctx);
>> }
>>
>>
>> --
>> 1.8.3.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgpHh9NyhClPU.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/11] mesa: Add image parameter queries for ARB_shader_image_load_store.
Chris Forbes writes:
> + if (index > ctx->Const.MaxImageUnits)
> + goto invalid_value;
>
> Image unit indices are zero-based, so I think you want >= in all these cases.
>
Ouch... Good catch. I'll fix that.
Thanks.
> -- Chris
>
> On Mon, Nov 25, 2013 at 6:00 PM, Francisco Jerez
> wrote:
>> ---
>> src/mesa/main/get.c | 70
>>
>> src/mesa/main/get_hash_params.py | 9 ++
>> src/mesa/main/texparam.c | 6
>> 3 files changed, 85 insertions(+)
>>
>> diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
>> index eee8550..db77a65 100644
>> --- a/src/mesa/main/get.c
>> +++ b/src/mesa/main/get.c
>> @@ -145,6 +145,7 @@ enum value_extra {
>> EXTRA_GLSL_130,
>> EXTRA_EXT_UBO_GS4,
>> EXTRA_EXT_ATOMICS_GS4,
>> + EXTRA_EXT_SHADER_IMAGE_GS4,
>> };
>>
>> #define NO_EXTRA NULL
>> @@ -338,6 +339,11 @@ static const int
>> extra_ARB_shader_atomic_counters_and_geometry_shader[] = {
>> EXTRA_END
>> };
>>
>> +static const int extra_ARB_shader_image_load_store_and_geometry_shader[] = {
>> + EXTRA_EXT_SHADER_IMAGE_GS4,
>> + EXTRA_END
>> +};
>> +
>> EXTRA_EXT(ARB_texture_cube_map);
>> EXTRA_EXT(MESA_texture_array);
>> EXTRA_EXT(NV_fog_distance);
>> @@ -375,6 +381,7 @@ EXTRA_EXT(ARB_texture_buffer_range);
>> EXTRA_EXT(ARB_texture_multisample);
>> EXTRA_EXT(ARB_texture_gather);
>> EXTRA_EXT(ARB_shader_atomic_counters);
>> +EXTRA_EXT(ARB_shader_image_load_store);
>>
>> static const int
>> extra_ARB_color_buffer_float_or_glcore[] = {
>> @@ -1023,6 +1030,11 @@ check_extra(struct gl_context *ctx, const char *func,
>> const struct value_desc *d
>> api_found = (ctx->Extensions.ARB_shader_atomic_counters &&
>>_mesa_has_geometry_shaders(ctx));
>> break;
>> + case EXTRA_EXT_SHADER_IMAGE_GS4:
>> + api_check = GL_TRUE;
>> + api_found = (ctx->Extensions.ARB_shader_image_load_store &&
>> + _mesa_has_geometry_shaders(ctx));
>> + break;
>>case EXTRA_END:
>> break;
>>default: /* *e is a offset into the extension struct */
>> @@ -1763,6 +1775,64 @@ find_value_indexed(const char *func, GLenum pname,
>> GLuint index, union value *v)
>>if (index >= ctx->Const.VertexProgram.MaxAttribs)
>>goto invalid_value;
>>v->value_int =
>> ctx->Array.ArrayObj->VertexBinding[VERT_ATTRIB_GENERIC(index)].Stride;
>> +
>> + /* ARB_shader_image_load_store */
>> + case GL_IMAGE_BINDING_NAME: {
>> + struct gl_texture_object *t;
>> +
>> + if (!ctx->Extensions.ARB_shader_image_load_store)
>> + goto invalid_enum;
>> + if (index > ctx->Const.MaxImageUnits)
>> + goto invalid_value;
>> +
>> + t = ctx->ImageUnits[index].TexObj;
>> + v->value_int = (t ? t->Name : 0);
>> + return TYPE_INT;
>> + }
>> +
>> + case GL_IMAGE_BINDING_LEVEL:
>> + if (!ctx->Extensions.ARB_shader_image_load_store)
>> + goto invalid_enum;
>> + if (index > ctx->Const.MaxImageUnits)
>> + goto invalid_value;
>> +
>> + v->value_int = ctx->ImageUnits[index].Level;
>> + return TYPE_INT;
>> +
>> + case GL_IMAGE_BINDING_LAYERED:
>> + if (!ctx->Extensions.ARB_shader_image_load_store)
>> + goto invalid_enum;
>> + if (index > ctx->Const.MaxImageUnits)
>> + goto invalid_value;
>> +
>> + v->value_int = ctx->ImageUnits[index].Layered;
>> + return TYPE_INT;
>> +
>> + case GL_IMAGE_BINDING_LAYER:
>> + if (!ctx->Extensions.ARB_shader_image_load_store)
>> + goto invalid_enum;
>> + if (index > ctx->Const.MaxImageUnits)
>> + goto invalid_value;
>> +
>> + v->value_int = ctx->ImageUnits[index].Layer;
>> + return TYPE_INT;
>> +
>> + case GL_IMAGE_BINDING_ACCESS:
>> + if (!ctx->Extensions.ARB_shader_image_load_store)
>> + goto invalid_enum;
>> + if (index > ctx->Const.MaxImageUnits)
>> + goto invalid_value;
>> +
>> + v->value_int = ctx->ImageUnits[index].Access;
>> + return TYPE_INT;
>> +
>> + case GL_IMAGE_BINDING_FORMAT:
>> + if (!ctx->Extensions.ARB_shader_image_load_store)
>> + goto invalid_enum;
>> + if (index > ctx->Const.MaxImageUnits)
>> + goto invalid_value;
>> +
>> + v->value_int = ctx->ImageUnits[index].Format;
>>return TYPE_INT;
>> }
>>
>> diff --git a/src/mesa/main/get_hash_params.py
>> b/src/mesa/main/get_hash_params.py
>> index c961fee..ab7a900 100644
>> --- a/src/mesa/main/get_hash_params.py
>> +++ b/src/mesa/main/get_hash_params.py
>> @@ -741,6 +741,15 @@ descriptor=[
>> # GL_ARB_vertex_attrib_binding
>>[ "MAX_VERTEX_ATTRIB_RELATIVE_OFFSET",
>> "CONTEXT_ENUM(Const.MaxVertexAttribRelativeOffset), NO_EXTRA" ],
>>[ "MAX_VERTEX_ATTRIB_BINDINGS",
>> "CONTEXT_ENUM(Const.MaxVertexAttribBindings), NO_EXTRA" ],
>> +
>> +# GL_ARB_shader_image_load_store
>> + [ "MAX_IMAGE_UNITS", "CONTEXT_INT(Const.
Re: [Mesa-dev] [PATCH 02/11] mesa: Add ARB_shader_image_load_store to the extension table.
Chris Forbes writes:
> Does this want to be enabled in compatibility? I had assumed we
> wouldn't, for the same reasons we don't enable texbo there.
Hmm... I don't see why not. The extension was specifically written
against the GL 3.2 compatibility profile.
>
> On Mon, Nov 25, 2013 at 6:00 PM, Francisco Jerez
> wrote:
>> ---
>> src/mesa/main/extensions.c | 1 +
>> src/mesa/main/mtypes.h | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
>> index 104618c..19cf34d 100644
>> --- a/src/mesa/main/extensions.c
>> +++ b/src/mesa/main/extensions.c
>> @@ -123,6 +123,7 @@ static const struct extension extension_table[] = {
>> { "GL_ARB_seamless_cube_map",
>> o(ARB_seamless_cube_map), GL, 2009 },
>> { "GL_ARB_shader_atomic_counters",
>> o(ARB_shader_atomic_counters), GL, 2011 },
>> { "GL_ARB_shader_bit_encoding",
>> o(ARB_shader_bit_encoding), GL, 2010 },
>> + { "GL_ARB_shader_image_load_store",
>> o(ARB_shader_image_load_store), GL, 2011 },
>> { "GL_ARB_shader_objects", o(dummy_true),
>>GL, 2002 },
>> { "GL_ARB_shader_stencil_export",
>> o(ARB_shader_stencil_export), GL, 2009 },
>> { "GL_ARB_shader_texture_lod",
>> o(ARB_shader_texture_lod), GL, 2009 },
>> diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
>> index ecfb5e0..e9750f4 100644
>> --- a/src/mesa/main/mtypes.h
>> +++ b/src/mesa/main/mtypes.h
>> @@ -3348,6 +3348,7 @@ struct gl_extensions
>> GLboolean ARB_seamless_cube_map;
>> GLboolean ARB_shader_atomic_counters;
>> GLboolean ARB_shader_bit_encoding;
>> + GLboolean ARB_shader_image_load_store;
>> GLboolean ARB_shader_stencil_export;
>> GLboolean ARB_shader_texture_lod;
>> GLboolean ARB_shading_language_packing;
>> --
>> 1.8.3.4
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgpBtywb49XDQ.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: add get sample position
Am 25.11.2013 11:57, schrieb Dave Airlie:
> This just always returns 0.5,0.5 as the position.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/llvmpipe/lp_context.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_context.c
> b/src/gallium/drivers/llvmpipe/lp_context.c
> index 9a6d13b..678f852 100644
> --- a/src/gallium/drivers/llvmpipe/lp_context.c
> +++ b/src/gallium/drivers/llvmpipe/lp_context.c
> @@ -122,6 +122,15 @@ llvmpipe_render_condition ( struct pipe_context *pipe,
> llvmpipe->render_cond_cond = condition;
> }
>
> +static void
> +llvmpipe_get_sample_position( struct pipe_context *pipe,
> + unsigned sample_count,
> + unsigned sample_index,
> + float *out_value )
> +{
> + out_value[0] = out_value[1] = 0.5;
Shouldn't the result actually be different in theory according to
half_pixel_center? I guess noone really would care though.
> +}
> +
> struct pipe_context *
> llvmpipe_create_context( struct pipe_screen *screen, void *priv )
> {
> @@ -150,6 +159,7 @@ llvmpipe_create_context( struct pipe_screen *screen, void
> *priv )
> llvmpipe->pipe.flush = do_flush;
>
> llvmpipe->pipe.render_condition = llvmpipe_render_condition;
> + llvmpipe->pipe.get_sample_position = llvmpipe_get_sample_position;
>
> llvmpipe_init_blend_funcs(llvmpipe);
> llvmpipe_init_clip_funcs(llvmpipe);
>
Otherwise this looks good.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: don't assert/crash on invalid clear color
Am 25.11.2013 09:51, schrieb Dave Airlie:
> From: Dave Airlie
>
> So GL4.3 spec pretty much says glClear on integer buffers is undefined,
> then we have a piglit multisample test
> ext_framebuffer_multisample-int-draw-buffers-alpha-to-coverage
> that actually does undefined things but doesn't rely on the results except
> not crashing.
>
> (The tests binds 3 colorbuffers, one int, 2 float to an fbo and then calls
> glClear).
>
> This stops llvmpipe from crashing with is worse than undefined imho, though
> I'm not
> sure if the test should be fixed, and also a new test written to show this
> undefined
> behaviour outside multisamples.
>
> Signed-off-by: Dave Airlie
> ---
> src/gallium/drivers/llvmpipe/lp_rast.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
> b/src/gallium/drivers/llvmpipe/lp_rast.c
> index af661e9..75e1593 100644
> --- a/src/gallium/drivers/llvmpipe/lp_rast.c
> +++ b/src/gallium/drivers/llvmpipe/lp_rast.c
> @@ -142,9 +142,11 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
> if (util_format_is_pure_sint(format)) {
> util_format_write_4i(format, arg.clear_color.i, 0, &uc, 0, 0,
> 0, 1, 1);
> }
> -else {
> - assert(util_format_is_pure_uint(format));
> +else if (util_format_is_pure_uint(format)) {
> util_format_write_4ui(format, arg.clear_color.ui, 0, &uc, 0,
> 0, 0, 1, 1);
> +} else {
> + util_pack_color(arg.clear_color.f,
> + scene->fb.cbufs[i]->format, &uc);
> }
>
> util_fill_box(scene->cbufs[i].map,
>
Oh I probably thought such framebuffers were illegal when I wrote it
that way. But doesn't look like that's the case at all.
This patch looks ok, but I wonder if it wouldn't make sense to
restructure this whole function so simply the decision if int or
"ordinary" float path be taken would be per attachment, rather than do
it for the complete framebuffer and then still have to handle the float
case inside the int case anyway...
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: Extra gc null check for glXMakeCurrent
On 11/25/2013 07:23 AM, Juha-Pekka Heikkila wrote:
> Extra null check before accessing user given context pointer.
oldGC can never be NULL. If there is no current context, it will point
to dummyContext.
> Signed-off-by: Juha-Pekka Heikkila
> ---
> src/glx/glxcurrent.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/glx/glxcurrent.c b/src/glx/glxcurrent.c
> index a6884cf..b9f259e 100644
> --- a/src/glx/glxcurrent.c
> +++ b/src/glx/glxcurrent.c
> @@ -234,7 +234,7 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
> _glapi_check_multithread();
>
> __glXLock();
> - if (oldGC == gc &&
> + if (oldGC == gc && gc != NULL &&
> gc->currentDrawable == draw && gc->currentReadable == read) {
>__glXUnlock();
>return True;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/8] mesa: expose AMD_vertex_shader_layer in the core profile only
On 11/24/2013 07:41 PM, Jordan Justen wrote:
> On Sun, Nov 24, 2013 at 2:55 AM, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> It needs glFramebufferTexture, which isn't available in the compatibility
>> profile.
>> ---
>> src/mesa/main/extensions.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
>> index 104618c..f7e7e4d 100644
>> --- a/src/mesa/main/extensions.c
>> +++ b/src/mesa/main/extensions.c
>> @@ -300,7 +300,7 @@ static const struct extension extension_table[] = {
>> { "GL_AMD_performance_monitor",
>> o(AMD_performance_monitor), GL, 2007 },
>> { "GL_AMD_seamless_cubemap_per_texture",
>> o(AMD_seamless_cubemap_per_texture),GL, 2009 },
>> { "GL_AMD_shader_stencil_export",
>> o(ARB_shader_stencil_export), GL, 2009 },
>> - { "GL_AMD_vertex_shader_layer",
>> o(AMD_vertex_shader_layer), GL, 2012 },
>> + { "GL_AMD_vertex_shader_layer",
>> o(AMD_vertex_shader_layer), GLC,2012 },
>
> Seems fine, but not required.
>
> This would need to be reverted if GS4 was made available in compat,
> which I don't think is currently planned.
True, but right now i965 (on master) will report
GL_AMD_vertex_shader_layer is supported in the 3.0 compatibility
profile, but apps can't actually use it. We should either make this
extension core-only, as Marek has done, or add an extension that make
the other layer-related functionality available in pre-3.2 contexts, as
the AMD extension spec suggests.
Until someone does a bunch more work, this patch is
Reviewed-by: Ian Romanick
> -Jordan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965/gs: Properly skip GS binding table upload when no GS active.
Previously, in brw_gs_upload_binding_table(), we checked whether
brw->gs.prog_data was NULL in order to determine whether a geometry
shader was active. This didn't work: brw->gs.prog_data starts off as
NULL, but it is set to non-NULL when a geometry shader program is
built, and then never set to NULL again. As a result, if we called
brw_gs_upload_binding_table() while there was no geometry shader
active, but a geometry shader had previously been active, it would
refer to a stale (and possibly freed) prog_data structure.
This patch fixes the problem by modifying
brw_gs_upload_binding_table() to use the proper technique to determine
whether a geometry shader is active: by checking whether
brw->geometry_program is NULL.
I suspect this may address the crash reported in comment 2 of bug
71870.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71870
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/drivers/dri/i965/brw_binding_tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_binding_tables.c
b/src/mesa/drivers/dri/i965/brw_binding_tables.c
index 0a322dc..b39bd10 100644
--- a/src/mesa/drivers/dri/i965/brw_binding_tables.c
+++ b/src/mesa/drivers/dri/i965/brw_binding_tables.c
@@ -128,7 +128,7 @@ static void
brw_gs_upload_binding_table(struct brw_context *brw)
{
/* If there's no GS, skip changing anything. */
- if (!brw->gs.prog_data)
+ if (brw->geometry_program == NULL)
return;
brw_upload_binding_table(brw, BRW_NEW_GS_BINDING_TABLE, &brw->gs.base);
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965/gs: Set GS prog_data to NULL if there is no GS program.
The previous commit fixes a bug wherein we would incorrectly refer to stale geometry shader prog_data when no geometry shader was active. This patch reduces the likelihood of that sort of bug occurring in the future by setting prog_data to NULL whenever there is no GS program. Cc: mesa-sta...@lists.freedesktop.org --- src/mesa/drivers/dri/i965/brw_vec4_gs.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_vec4_gs.c b/src/mesa/drivers/dri/i965/brw_vec4_gs.c index b52d646..018b0b6 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4_gs.c +++ b/src/mesa/drivers/dri/i965/brw_vec4_gs.c @@ -259,6 +259,13 @@ brw_upload_gs_prog(struct brw_context *brw) brw->vue_map_geom_out = brw->vue_map_vs; brw->state.dirty.brw |= BRW_NEW_VUE_MAP_GEOM_OUT; } + + /* Other state atoms had better not try to access prog_data, since + * there's no GS program. + */ + brw->gs.prog_data = NULL; + brw->gs.base.prog_data = NULL; + return; } -- 1.8.4.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: Track known prime buffers for re-use
On Fri, Nov 22, 2013 at 05:35:54AM -0800, Keith Packard wrote:
> If the application sends us a file descriptor pointing at a prime
> buffer that we've already got, we have to re-use the same bo_gem
> structure or chaos will result.
>
> Track the set of all known prime objects and look to see if the kernel
> has returned one of those for a new file descriptor.
>
> Signed-off-by: Keith Packard
> ---
>
> This one took a while to find -- multiple bo_gem structs pointing at
> the same gem handle would either cause the object to be destroyed
> before we were done using it, or we'd end up sending the same
> gem_handle for multiple buffers.
>
> This looks a lot like the named object handling stuff, as one would
> expect.
Yeah, it unfortunately took a few rounds of kernel fixes and other
haggling to get the semantics right on this one. The kernel atm promises
to userspace (minus one big in a racy corner case no one should care
about, still need to fix that one) that it'll return the same gem handle
if userspace already has one for the underlying object.
We need that to make sure userspace doesn't submit the same bo in execbuf
multiple times and then upsets the kernel - we'll reject such batches as
userspace bugs.
I guess I should have reviewed userspace when doing the relevant kernel
fixes, shame on me. Two questions below.
>
> intel/intel_bufmgr_gem.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index df6fcec..2897bb2 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -112,6 +112,7 @@ typedef struct _drm_intel_bufmgr_gem {
>
> drmMMListHead named;
> drmMMListHead vma_cache;
> +drmMMListHead prime;
> int vma_count, vma_open, vma_max;
>
> uint64_t gtt_size;
> @@ -2451,8 +2452,25 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr
> *bufmgr, int prime_fd, int s
> uint32_t handle;
> drm_intel_bo_gem *bo_gem;
> struct drm_i915_gem_get_tiling get_tiling;
> + drmMMListHead *list;
>
> ret = drmPrimeFDToHandle(bufmgr_gem->fd, prime_fd, &handle);
> +
> + /*
> + * See if the kernel has already returned this buffer to us. Just as
> + * for named buffers, we must not create two bo's pointing at the same
> + * kernel object
> + */
> + for (list = bufmgr_gem->prime.next;
> + list != &bufmgr_gem->prime;
> + list = list->next) {
> + bo_gem = DRMLISTENTRY(drm_intel_bo_gem, list, name_list);
> + if (bo_gem->gem_handle == handle) {
> + drm_intel_gem_bo_reference(&bo_gem->bo);
> + return &bo_gem->bo;
> + }
> + }
> +
> if (ret) {
> fprintf(stderr,"ret is %d %d\n", ret, errno);
> return NULL;
> @@ -2487,8 +2505,8 @@ drm_intel_bo_gem_create_from_prime(drm_intel_bufmgr
> *bufmgr, int prime_fd, int s
> bo_gem->has_error = false;
> bo_gem->reusable = false;
>
> - DRMINITLISTHEAD(&bo_gem->name_list);
> DRMINITLISTHEAD(&bo_gem->vma_list);
> + DRMLISTADDTAIL(&bo_gem->name_list, &bufmgr_gem->prime);
Won't this result in us having fun when a buffer is both imported from a
prime buffer and then also used with legacy flink? Or is this something
the X server won't support?
The second one is about exporting: With flink names we also add the name
to the lookup list in drm_intel_gem_bo_flink. I think we should do the
same for exported prime buffers just as a precaution - the kernel will
return the (existing) gem name also for a prime buffer that has been
exported by yourself. I guess that would imply insane userspace, but
better safe than sorry.
Cheers, Daniel
>
> VG_CLEAR(get_tiling);
> get_tiling.handle = bo_gem->gem_handle;
> @@ -3301,5 +3319,7 @@ drm_intel_bufmgr_gem_init(int fd, int batch_size)
> DRMINITLISTHEAD(&bufmgr_gem->vma_cache);
> bufmgr_gem->vma_max = -1; /* unlimited by default */
>
> + DRMINITLISTHEAD(&bufmgr_gem->prime);
> +
> return &bufmgr_gem->bufmgr;
> }
> --
> 1.8.4.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: Extra gc null check for glXMakeCurrent
Extra null check before accessing user given context pointer.
Signed-off-by: Juha-Pekka Heikkila
---
src/glx/glxcurrent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glx/glxcurrent.c b/src/glx/glxcurrent.c
index a6884cf..b9f259e 100644
--- a/src/glx/glxcurrent.c
+++ b/src/glx/glxcurrent.c
@@ -234,7 +234,7 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
_glapi_check_multithread();
__glXLock();
- if (oldGC == gc &&
+ if (oldGC == gc && gc != NULL &&
gc->currentDrawable == draw && gc->currentReadable == read) {
__glXUnlock();
return True;
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Allocate vec4_visitor's uniform_size and uniform_vector_size arrays dynamically.
On 11/22/2013 08:05 PM, Francisco Jerez wrote:
Petri Latvala writes:
[...]
@@ -325,8 +326,9 @@ public:
*/
dst_reg output_reg[BRW_VARYING_SLOT_COUNT];
const char *output_reg_annotation[BRW_VARYING_SLOT_COUNT];
- int uniform_size[MAX_UNIFORMS];
- int uniform_vector_size[MAX_UNIFORMS];
+ unsigned uniform_param_count;
+ int* uniform_size;
+ int* uniform_vector_size;
int uniforms;
All the code around you uses the 'type *identifier' convention, please
keep it consistent.
*slap on forehead* note to self, disable muscle memory. Fixing that.
src_reg shader_start_time;
[...]
@@ -556,7 +558,7 @@ brw_gs_emit(struct brw_context *brw,
if (likely(!(INTEL_DEBUG& DEBUG_NO_DUAL_OBJECT_GS))) {
c->prog_data.dual_instanced_dispatch = false;
- vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, true /* no_spills */);
+ vec4_gs_visitor v(brw, c, prog, shader, mem_ctx, true /* no_spills */,
param_count);
Another possibility would be to set 'c.prog_data.base.nr_params =
param_count' here and in brw_vs_emit(), so you'd have the same value
available from the constructor of vec4_visitor without all the parameter
changes.
When trying this change, I began to wonder if I'm using the right values
at all. What is that nr_params supposed to be for code elsewhere?
vec4_visitor::setup_uniforms() sets it to this->uniforms * 4, but
param_count that I passed from do_vs_prog() to brw_vs_emit() is
num_uniform_components * 4, yielding (close to) this->uniforms * 4 * 4.
Close to means that my test program gives param_count being 92, and
this->uniforms * 4 in setup_uniforms() is 24.
Is vec4_visitor::setup_uniforms() supposed to be the authoritative
source of the uniform counts or is that nr_params assignment just for
the pre-gen6 hack in the same function? Is nr_params supposed to be the
number of uniform components or uniforms? To my understanding
param_count in do_vs_prog() is the number of uniform components required
to hold all uniforms with a vec4 for each one (float or otherwise), are
the floats packed to vec4s anywhere?
--
Petri Latvala
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
On Mon, Nov 25, 2013 at 09:57:23AM +0100, Daniel Vetter wrote: > On Fri, Nov 22, 2013 at 02:12:13PM -0800, Kristian Høgsberg wrote: > > I don't know what else you'd propose? Pass an X visual in the ioctl? > > An EGL config? This is our name space, we can add stuff as we need > > (as Keith is doing here). include/uapi/drm/drm_fourcc.h is the > > canonical source for these values and we should add > > DRM_FORMAT_SARGB there to make sure we don't clash. > > Well that's kinda the problem. If you don't expect the kernel to clash > with whatever mesa is using internally then we should add it to the > kernel, first. That's kinda what Dave's recent rant has all been about. > > The other issue was that originally the idea behind fourcc was to have one > formate namespace shared between drm, v4l and whomever else cares. If > people are happy to drop that idea on the floor I won't shed a single > tear. I broke that idea alredy when I cooked up the current drm fourccs. I didn't cross check them with any other fourcc source, so I'm 100% sure most of them don't match anything else. -- Ville Syrjälä Intel OTC ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] llvmpipe: add get sample position
This just always returns 0.5,0.5 as the position.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/llvmpipe/lp_context.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/drivers/llvmpipe/lp_context.c
b/src/gallium/drivers/llvmpipe/lp_context.c
index 9a6d13b..678f852 100644
--- a/src/gallium/drivers/llvmpipe/lp_context.c
+++ b/src/gallium/drivers/llvmpipe/lp_context.c
@@ -122,6 +122,15 @@ llvmpipe_render_condition ( struct pipe_context *pipe,
llvmpipe->render_cond_cond = condition;
}
+static void
+llvmpipe_get_sample_position( struct pipe_context *pipe,
+ unsigned sample_count,
+ unsigned sample_index,
+ float *out_value )
+{
+ out_value[0] = out_value[1] = 0.5;
+}
+
struct pipe_context *
llvmpipe_create_context( struct pipe_screen *screen, void *priv )
{
@@ -150,6 +159,7 @@ llvmpipe_create_context( struct pipe_screen *screen, void
*priv )
llvmpipe->pipe.flush = do_flush;
llvmpipe->pipe.render_condition = llvmpipe_render_condition;
+ llvmpipe->pipe.get_sample_position = llvmpipe_get_sample_position;
llvmpipe_init_blend_funcs(llvmpipe);
llvmpipe_init_clip_funcs(llvmpipe);
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] llvmpipe fake msaa
These two patches fake MSAA support for drisw and llvmpipe, Discuss... :-) Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gallium/drisw: add multisample buffer support
This adds support for multisample to drisw, even if we fake
multisample in the drivers we should at least do best effort,
and not fail to render.
Signed-off-by: Dave Airlie
---
src/gallium/state_trackers/dri/sw/drisw.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/dri/sw/drisw.c
b/src/gallium/state_trackers/dri/sw/drisw.c
index 9f00a53..24e9e2f 100644
--- a/src/gallium/state_trackers/dri/sw/drisw.c
+++ b/src/gallium/state_trackers/dri/sw/drisw.c
@@ -167,6 +167,13 @@ drisw_flush_frontbuffer(struct dri_context *ctx,
if (!ctx)
return;
+ if (drawable->stvis.samples > 1) {
+ /* Resolve the front buffer. */
+ dri_pipe_blit(ctx->st->pipe,
+drawable->textures[ST_ATTACHMENT_FRONT_LEFT],
+drawable->msaa_textures[ST_ATTACHMENT_FRONT_LEFT]);
+ }
+
ptex = drawable->textures[statt];
if (ptex) {
@@ -201,8 +208,12 @@ drisw_allocate_textures(struct dri_context *stctx,
/* remove outdated textures */
if (resized) {
- for (i = 0; i < ST_ATTACHMENT_COUNT; i++)
+ for (i = 0; i < ST_ATTACHMENT_COUNT; i++) {
pipe_resource_reference(&drawable->textures[i], NULL);
+
+ if (drawable->stvis.samples > 1)
+pipe_resource_reference(&drawable->msaa_textures[i], NULL);
+ }
}
memset(&templ, 0, sizeof(templ));
@@ -235,6 +246,17 @@ drisw_allocate_textures(struct dri_context *stctx,
drawable->textures[statts[i]] =
screen->base.screen->resource_create(screen->base.screen, &templ);
+
+ if (drawable->stvis.samples > 1) {
+ enum st_attachment_type att = statts[i];
+ templ.nr_samples = drawable->stvis.samples;
+ drawable->msaa_textures[att] =
screen->base.screen->resource_create(screen->base.screen, &templ);
+ dri_pipe_blit(stctx->st->pipe,
+ drawable->msaa_textures[att],
+ drawable->textures[att]);
+ } else {
+ pipe_resource_reference(&drawable->msaa_textures[statts[i]], NULL);
+ }
}
drawable->old_w = width;
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] llvmpipe: start faking multisample support
From: Dave Airlie
We've talked in the past about just faking multisample support
in the sw drivers as much as we possibly can, this just adds enough
to llvmpipe to do that.
It produces some valid fails in piglit, like the accuracy tests
and the texelFetch tests fail due to lack of second texel,
Some fails we might be able to mitigate but not sure what we'd gain,
like alpha-to-one.
Some of the format tests fail so could do with more investigation.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c | 7 ++-
src/gallium/drivers/llvmpipe/lp_screen.c| 4 ++--
src/gallium/drivers/llvmpipe/lp_surface.c | 8
3 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
index 6d8dc8c..b732b72 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c
@@ -1920,11 +1920,13 @@ emit_sample(struct lp_build_tgsi_soa_context *bld,
num_derivs = 1;
break;
case TGSI_TEXTURE_2D:
+ case TGSI_TEXTURE_2D_MSAA:
case TGSI_TEXTURE_RECT:
num_offsets = 2;
num_derivs = 2;
break;
case TGSI_TEXTURE_2D_ARRAY:
+ case TGSI_TEXTURE_2D_ARRAY_MSAA:
layer_coord = 2;
num_offsets = 2;
num_derivs = 2;
@@ -2088,10 +2090,12 @@ emit_fetch_texels( struct lp_build_tgsi_soa_context
*bld,
dims = 1;
break;
case TGSI_TEXTURE_2D:
+ case TGSI_TEXTURE_2D_MSAA:
case TGSI_TEXTURE_RECT:
dims = 2;
break;
case TGSI_TEXTURE_2D_ARRAY:
+ case TGSI_TEXTURE_2D_ARRAY_MSAA:
layer_coord = 2;
dims = 2;
break;
@@ -2104,7 +2108,8 @@ emit_fetch_texels( struct lp_build_tgsi_soa_context *bld,
}
/* always have lod except for buffers ? */
- if (target != TGSI_TEXTURE_BUFFER) {
+ if (target != TGSI_TEXTURE_BUFFER && target != TGSI_TEXTURE_2D_MSAA &&
+ target != TGSI_TEXTURE_2D_ARRAY_MSAA) {
explicit_lod = lp_build_emit_fetch(&bld->bld_base, inst, 0, 3);
lod_property = lp_build_lod_property(&bld->bld_base, inst, 0);
}
diff --git a/src/gallium/drivers/llvmpipe/lp_screen.c
b/src/gallium/drivers/llvmpipe/lp_screen.c
index f61df98..34d536b 100644
--- a/src/gallium/drivers/llvmpipe/lp_screen.c
+++ b/src/gallium/drivers/llvmpipe/lp_screen.c
@@ -218,11 +218,11 @@ llvmpipe_get_param(struct pipe_screen *screen, enum
pipe_cap param)
case PIPE_CAP_CONSTANT_BUFFER_OFFSET_ALIGNMENT:
return 16;
case PIPE_CAP_START_INSTANCE:
- case PIPE_CAP_TEXTURE_MULTISAMPLE:
case PIPE_CAP_MIN_MAP_BUFFER_ALIGNMENT:
case PIPE_CAP_CUBE_MAP_ARRAY:
return 0;
case PIPE_CAP_TEXTURE_BUFFER_OBJECTS:
+ case PIPE_CAP_TEXTURE_MULTISAMPLE:
return 1;
case PIPE_CAP_MAX_TEXTURE_BUFFER_SIZE:
return 65536;
@@ -327,7 +327,7 @@ llvmpipe_is_format_supported( struct pipe_screen *_screen,
target == PIPE_TEXTURE_3D ||
target == PIPE_TEXTURE_CUBE);
- if (sample_count > 1)
+ if (sample_count > 4)
return FALSE;
if (bind & PIPE_BIND_RENDER_TARGET) {
diff --git a/src/gallium/drivers/llvmpipe/lp_surface.c
b/src/gallium/drivers/llvmpipe/lp_surface.c
index f033c46..5c059d7 100644
--- a/src/gallium/drivers/llvmpipe/lp_surface.c
+++ b/src/gallium/drivers/llvmpipe/lp_surface.c
@@ -180,14 +180,6 @@ static void lp_blit(struct pipe_context *pipe,
struct llvmpipe_context *lp = llvmpipe_context(pipe);
struct pipe_blit_info info = *blit_info;
- if (info.src.resource->nr_samples > 1 &&
- info.dst.resource->nr_samples <= 1 &&
- !util_format_is_depth_or_stencil(info.src.resource->format) &&
- !util_format_is_pure_integer(info.src.resource->format)) {
- debug_printf("llvmpipe: color resolve unimplemented\n");
- return;
- }
-
if (util_try_blit_via_copy_region(pipe, &info)) {
return; /* done */
}
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Intel-gfx] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888
On Fri, Nov 22, 2013 at 02:12:13PM -0800, Kristian Høgsberg wrote: > I don't know what else you'd propose? Pass an X visual in the ioctl? > An EGL config? This is our name space, we can add stuff as we need > (as Keith is doing here). include/uapi/drm/drm_fourcc.h is the > canonical source for these values and we should add > DRM_FORMAT_SARGB there to make sure we don't clash. Well that's kinda the problem. If you don't expect the kernel to clash with whatever mesa is using internally then we should add it to the kernel, first. That's kinda what Dave's recent rant has all been about. The other issue was that originally the idea behind fourcc was to have one formate namespace shared between drm, v4l and whomever else cares. If people are happy to drop that idea on the floor I won't shed a single tear. In the end I'll expect that someone will make a funny collision between all the different projects anyway, so meh. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] llvmpipe: don't assert/crash on invalid clear color
From: Dave Airlie
So GL4.3 spec pretty much says glClear on integer buffers is undefined,
then we have a piglit multisample test
ext_framebuffer_multisample-int-draw-buffers-alpha-to-coverage
that actually does undefined things but doesn't rely on the results except
not crashing.
(The tests binds 3 colorbuffers, one int, 2 float to an fbo and then calls
glClear).
This stops llvmpipe from crashing with is worse than undefined imho, though I'm
not
sure if the test should be fixed, and also a new test written to show this
undefined
behaviour outside multisamples.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/llvmpipe/lp_rast.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_rast.c
b/src/gallium/drivers/llvmpipe/lp_rast.c
index af661e9..75e1593 100644
--- a/src/gallium/drivers/llvmpipe/lp_rast.c
+++ b/src/gallium/drivers/llvmpipe/lp_rast.c
@@ -142,9 +142,11 @@ lp_rast_clear_color(struct lp_rasterizer_task *task,
if (util_format_is_pure_sint(format)) {
util_format_write_4i(format, arg.clear_color.i, 0, &uc, 0, 0,
0, 1, 1);
}
-else {
- assert(util_format_is_pure_uint(format));
+else if (util_format_is_pure_uint(format)) {
util_format_write_4ui(format, arg.clear_color.ui, 0, &uc, 0, 0,
0, 1, 1);
+} else {
+ util_pack_color(arg.clear_color.f,
+ scene->fb.cbufs[i]->format, &uc);
}
util_fill_box(scene->cbufs[i].map,
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] docs: describe the INTEL_* envvars that do exist
I've pushed these now, including dropping the old names for those debug bits. I've left the stats stuff as-is for now, but suggested more useful options in the docs. On Mon, Nov 25, 2013 at 4:44 AM, Kenneth Graunke wrote: > On 11/23/2013 09:13 PM, Chris Forbes wrote: >> Signed-off-by: Chris Forbes >> --- >> docs/envvars.html | 32 >> 1 file changed, 32 insertions(+) >> >> diff --git a/docs/envvars.html b/docs/envvars.html >> index 81e74e6..d831826 100644 >> --- a/docs/envvars.html >> +++ b/docs/envvars.html >> @@ -121,6 +121,38 @@ See the Xlib software driver >> page for details. >> i945/i965 driver environment variables (non-Gallium) >> >> >> +INTEL_NO_HW - if set to 1, prevents batches from being submitted to the >> hardware. >> + This is useful for debugging hangs, etc. >> +INTEL_DEBUG - a comma-separated list of named flags, which do various >> things: >> + >> + tex - emit messages about textures. >> + state - emit messages about state flag tracking >> + blit - emit messages about blit operations >> + miptree - emit messages about miptrees >> + fall/perf - emit messages about performance issues > > Not sure if the old names are worth documenting. I guess if people find > old text on wikis or something that says INTEL_DEBUG=fall, they'll know > what it means. > > We might want to actually just drop the 'fall' name at this > point...people seem to have moved over completely. > >> + perfmon - emit messages about AMD_performance_monitor >> + bat - emit batch information >> + pix - emit messages about pixel operations >> + buf - emit messages about buffer objects >> + reg - emit messages about regions >> + fbo - emit messages about framebuffers >> + fs/wm - dump shader assembly for fragment shaders > > I've pretty much universally moved over to INTEL_DEBUG=fs too, but I > don't know about others. > >> + gs - dump shader assembly for geometry shaders >> + sync - emit messages about synchronization >> + prim - emit messages about drawing primitives >> + vert - emit messages about vertex assembly >> + dri - emit messages about the DRI interface >> + sf - emit messages about the strips & fans unit (for old gens, >> includes the SF program) >> + stats - ? > > This enables statistics counters for the vertex fetcher (on all > generations), and for other units on Gen4-5. That said, the counters > aren't exposed other than reading registers, and on Gen6+ you can't even > use intel_reg_read due to hardware contexts. > > Frankly, it seems pretty useless, and I think we ought to delete it. > >> + urb - emit messages about URB setup >> + vs - dump shader assembly for vertex shaders >> + clip - emit messages about the clip unit (for old gens, includes the >> CLIP program) >> + aub - dump batches into an AUB trace for use with simulation >> tools >> + shader_time - record how much GPU time is spent in each shader >> + no16 - suppress generation of 16-wide fragment shaders. useful for >> debugging broken shaders >> + blorp - emit messages about the blorp operations (blits & >> clears) >> + nodualobj - suppress generation of dual-object geometry shader >> code >> + >> > > Thanks for doing this, Chris. For the series: > Reviewed-by: Kenneth Graunke ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/dri: Support DRI Image extension version 7 (v3)
On 11/25/2013 05:38 AM, Ben Skeggs wrote: On Mon, Nov 25, 2013 at 1:57 PM, wrote: From: Christopher James Halse Rogers http://cgit.freedesktop.org/~keithp/mesa/log/?h=dri3 Ben, Christopher's patches have apparently been on the mesa dev lists since April, with various reviews and comments, and also supporting most (all ?) prime-aware drivers. Is there any chance that you could sync the overlapping work in Keith's tree so we don't end up with two "competing" patchsets to review, aiming at doing more or less the same thing? Thanks Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
