Re: [Mesa-dev] [PATCH] st/mesa: skip draw calls with pipe_draw_info::count == 0
You can add my tested-by to the patch. -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Patch v2] osmesa: link with libunwind if enabled (v2)
Yes, please do. Alexandre Demers On Fri, May 26, 2017, 10:17 Brian Paul wrote: > On 05/25/2017 09:09 PM, Alexandre Demers wrote: > > Fixes linking error in libOSmesa when using libunwind. > > > > CXXLDlibOSMesa.la > > src/gallium/auxiliary/.libs/libgallium.a(u_debug_stack.o): In function > `symbol_name_cached': > > ./src/gallium/auxiliary/util/u_debug_stack.c:87: undefined reference to > `_ULx86_64_get_proc_name' > > src/gallium/auxiliary/.libs/libgallium.a(u_debug_stack.o): In function > `debug_backtrace_capture': > > ./src/gallium/auxiliary/util/u_debug_stack.c:114: undefined reference to > `_Ux86_64_getcontext' > > ./src/gallium/auxiliary/util/u_debug_stack.c:115: undefined reference to > `_ULx86_64_init_local' > > ./src/gallium/auxiliary/util/u_debug_stack.c:117: undefined reference to > `_ULx86_64_step' > > ./src/gallium/auxiliary/util/u_debug_stack.c:123: undefined reference to > `_ULx86_64_get_reg' > > ./src/gallium/auxiliary/util/u_debug_stack.c:124: undefined reference to > `_ULx86_64_get_proc_info' > > ./src/gallium/auxiliary/util/u_debug_stack.c:120: undefined reference to > `_ULx86_64_step' > > collect2: error: ld returned 1 exit status > > > > v2 : Fixes title and adds the original error it is fixing. > > > > Signed-off-by: Alexandre Demers > > --- > > src/gallium/targets/osmesa/Makefile.am | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/src/gallium/targets/osmesa/Makefile.am > b/src/gallium/targets/osmesa/Makefile.am > > index 6d340f1d92..2b4af57d5b 100644 > > --- a/src/gallium/targets/osmesa/Makefile.am > > +++ b/src/gallium/targets/osmesa/Makefile.am > > @@ -66,7 +66,8 @@ lib@OSMESA_LIB@_la_LIBADD = \ > > $(top_builddir)/src/mapi/glapi/libglapi.la \ > > $(SHARED_GLAPI_LIB) \ > > $(OSMESA_LIB_DEPS) \ > > - $(CLOCK_LIB) > > + $(CLOCK_LIB) \ > > + $(LIBUNWIND_LIBS) > > > > if HAVE_GALLIUM_LLVM > > AM_CPPFLAGS += -DGALLIUM_LLVMPIPE > > Looks OK to me. > > Reviewed-by: Brian Paul > > Do you need me to push this for you? > > -Brian > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Patch v2] osmesa: link with libunwind if enabled (v2)
Fixes linking error in libOSmesa when using libunwind. CXXLDlibOSMesa.la src/gallium/auxiliary/.libs/libgallium.a(u_debug_stack.o): In function `symbol_name_cached': ./src/gallium/auxiliary/util/u_debug_stack.c:87: undefined reference to `_ULx86_64_get_proc_name' src/gallium/auxiliary/.libs/libgallium.a(u_debug_stack.o): In function `debug_backtrace_capture': ./src/gallium/auxiliary/util/u_debug_stack.c:114: undefined reference to `_Ux86_64_getcontext' ./src/gallium/auxiliary/util/u_debug_stack.c:115: undefined reference to `_ULx86_64_init_local' ./src/gallium/auxiliary/util/u_debug_stack.c:117: undefined reference to `_ULx86_64_step' ./src/gallium/auxiliary/util/u_debug_stack.c:123: undefined reference to `_ULx86_64_get_reg' ./src/gallium/auxiliary/util/u_debug_stack.c:124: undefined reference to `_ULx86_64_get_proc_info' ./src/gallium/auxiliary/util/u_debug_stack.c:120: undefined reference to `_ULx86_64_step' collect2: error: ld returned 1 exit status v2 : Fixes title and adds the original error it is fixing. Signed-off-by: Alexandre Demers --- src/gallium/targets/osmesa/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/targets/osmesa/Makefile.am b/src/gallium/targets/osmesa/Makefile.am index 6d340f1d92..2b4af57d5b 100644 --- a/src/gallium/targets/osmesa/Makefile.am +++ b/src/gallium/targets/osmesa/Makefile.am @@ -66,7 +66,8 @@ lib@OSMESA_LIB@_la_LIBADD = \ $(top_builddir)/src/mapi/glapi/libglapi.la \ $(SHARED_GLAPI_LIB) \ $(OSMESA_LIB_DEPS) \ - $(CLOCK_LIB) + $(CLOCK_LIB) \ + $(LIBUNWIND_LIBS) if HAVE_GALLIUM_LLVM AM_CPPFLAGS += -DGALLIUM_LLVMPIPE -- 2.13.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] osmesa: link with libunwind if enabled
Fixes linking error in libOSmesa when using libunwind. Signed-off-by: Alexandre Demers --- src/gallium/targets/osmesa/Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/targets/osmesa/Makefile.am b/src/gallium/targets/osmesa/Makefile.am index 6d340f1d92..2b4af57d5b 100644 --- a/src/gallium/targets/osmesa/Makefile.am +++ b/src/gallium/targets/osmesa/Makefile.am @@ -66,7 +66,8 @@ lib@OSMESA_LIB@_la_LIBADD = \ $(top_builddir)/src/mapi/glapi/libglapi.la \ $(SHARED_GLAPI_LIB) \ $(OSMESA_LIB_DEPS) \ - $(CLOCK_LIB) + $(CLOCK_LIB) \ + $(LIBUNWIND_LIBS) if HAVE_GALLIUM_LLVM AM_CPPFLAGS += -DGALLIUM_LLVMPIPE -- 2.13.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] winsys/radeon: (trivial) rename variable for consistency
Signed-off-by: Alexandre Demers
---
src/gallium/drivers/radeon/radeon_uvd.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index fb1491a..81fba95 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -108,7 +108,7 @@ static void set_reg(struct ruvd_decoder *dec, unsigned reg,
uint32_t val)
/* send a command to the VCPU through the GPCOM registers */
static void send_cmd(struct ruvd_decoder *dec, unsigned cmd,
-struct pb_buffer* buf, uint32_t off,
+struct pb_buffer* buf, uint32_t offset,
enum radeon_bo_usage usage, enum radeon_bo_domain domain)
{
int reloc_idx;
@@ -119,12 +119,12 @@ static void send_cmd(struct ruvd_decoder *dec, unsigned
cmd,
if (!dec->use_legacy) {
uint64_t addr;
addr = dec->ws->buffer_get_virtual_address(buf);
- addr = addr + off;
+ addr = addr + offset;
set_reg(dec, RUVD_GPCOM_VCPU_DATA0, addr);
set_reg(dec, RUVD_GPCOM_VCPU_DATA1, addr >> 32);
} else {
- off += dec->ws->buffer_get_reloc_offset(buf);
- set_reg(dec, RUVD_GPCOM_VCPU_DATA0, off);
+ offset += dec->ws->buffer_get_reloc_offset(buf);
+ set_reg(dec, RUVD_GPCOM_VCPU_DATA0, offset);
set_reg(dec, RUVD_GPCOM_VCPU_DATA1, reloc_idx * 4);
}
set_reg(dec, RUVD_GPCOM_VCPU_CMD, cmd << 1);
--
2.10.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Possible typo in commit 5ec140c1 - mapi: Massage code to allow clang to compile.
Hi Matt, I saw your commit 5ec140c1 pass by and I think there is a typo in it. You use "HAVE_FUNC_ATTRIBUTE_VISIBIITY" thrice in the patch and I suspect there is a missing "L" to form "HAVE_FUNC_ATTRIBUTE_VISIBILITY" instead. Cheers -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Better explain why we are lowering the num_tile_pipes value for TAHITI (v2)
v2: Clarify the relation between num_tiles_pipes and GB_TILE_MODE and the fix needed for Tahiti as suggested by Marek. Signed-off-by: Alexandre Demers --- src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c index 49c310c..73ef051 100644 --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c @@ -405,8 +405,10 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws) radeon_get_drm_value(ws->fd, RADEON_INFO_NUM_TILE_PIPES, NULL, &ws->info.num_tile_pipes); -/* The kernel returns 12 for some cards for an unknown reason. - * I thought this was supposed to be a power of two. +/* "num_tiles_pipes" must be equal to the number of pipes (Px) in the +/* pipe config field of the GB_TILE_MODE array. Only one card (Tahiti) +/* reports a different value (12). Fix it by setting what's in the +/* GB_TILE_MODE array (8). */ if (ws->gen == DRV_SI && ws->info.num_tile_pipes == 12) ws->info.num_tile_pipes = 8; -- 2.7.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Better explain why we are lowering the num_tile_pipes value for TAHITI
On 2016-02-10 05:14, Marek Olšák wrote: On Wed, Feb 10, 2016 at 2:11 AM, Alexandre Demers wrote: Signed-off-by: Alexandre Demers --- src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c index 49c310c..aab81f9 100644 --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c @@ -405,8 +405,9 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws) radeon_get_drm_value(ws->fd, RADEON_INFO_NUM_TILE_PIPES, NULL, &ws->info.num_tile_pipes); -/* The kernel returns 12 for some cards for an unknown reason. - * I thought this was supposed to be a power of two. +/* Tahiti have a max_tile_pipes of 12 exceptionally. However, we + * work with power of two, so let's set it to the nearest power of + * two value. */ This is even worse. :) The proper explanation should be: "num_tiles_pipes" must be equal to the number of pipes (Px) in the pipe config field of the GB_TILE_MODE array. Only one card (Tahiti) reports a different value (12). Fix it by setting what's in the GB_TILE_MODE array (8). Marek I agree, sending a new version of the patch with exactly that comment. No confusion possible. ;) Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Better explain why we are lowering the num_tile_pipes value for TAHITI
On Tue, 9 Feb 2016 at 22:38 Michel Dänzer wrote: > On 10.02.2016 10:11, Alexandre Demers wrote: > > Signed-off-by: Alexandre Demers > > --- > > src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c > b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c > > index 49c310c..aab81f9 100644 > > --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c > > +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c > > @@ -405,8 +405,9 @@ static boolean do_winsys_init(struct > radeon_drm_winsys *ws) > > radeon_get_drm_value(ws->fd, RADEON_INFO_NUM_TILE_PIPES, > NULL, > > &ws->info.num_tile_pipes); > > > > -/* The kernel returns 12 for some cards for an unknown > reason. > > - * I thought this was supposed to be a power of two. > > +/* Tahiti have a max_tile_pipes of 12 exceptionally. > However, we > > + * work with power of two, so let's set it to the nearest > power of > > + * two value. > > */ > > Not sure that's better I'm afraid. It doesn't look like 12 is actually a > possible hardware configuration, it might simply be a kernel driver bug. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > On the other hand, the current comment isn't true either (and probably farther from the truth): it's not true that we don't know why the kernel returns 12 or which cards/gpus are affected (only tahiti is concerned). If someone has to investigate this portion of code later in time, it will be even harder to understand why the comment was added: it gives no clue about the reported bug it fixes nor any information we have about the specific GPU identified and the fact that this value is known to be the one set in the kernel driver. While it could be true that this is a driver bug, I don't have any way to verify it. Also, according to what is available under ci_gpu_init() @ si.c#n3254 (where max_tile_pipes is defined), the value "12" was already flagged as problematic (there is a comment under tile_config for the default case). This comment was inserted by Alex Deucher himself in the initial commit (0ce635d67f8c65f9f804abd77b63a65c08107e79). And finally, if I understand correctly what Alex Deucher summed up under the thread "[PATCH] winsys/radeon: fix a wrong NUM_TILE_PIPES value from the kernel", he doesn't remember clearly where and why the value was defined as 12, most probably a hardware value, but it needed to be mapped to 8 for software usage. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Better explain why we are lowering the num_tile_pipes value for TAHITI
Signed-off-by: Alexandre Demers --- src/gallium/winsys/radeon/drm/radeon_drm_winsys.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c index 49c310c..aab81f9 100644 --- a/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c +++ b/src/gallium/winsys/radeon/drm/radeon_drm_winsys.c @@ -405,8 +405,9 @@ static boolean do_winsys_init(struct radeon_drm_winsys *ws) radeon_get_drm_value(ws->fd, RADEON_INFO_NUM_TILE_PIPES, NULL, &ws->info.num_tile_pipes); -/* The kernel returns 12 for some cards for an unknown reason. - * I thought this was supposed to be a power of two. +/* Tahiti have a max_tile_pipes of 12 exceptionally. However, we + * work with power of two, so let's set it to the nearest power of + * two value. */ if (ws->gen == DRV_SI && ws->info.num_tile_pipes == 12) ws->info.num_tile_pipes = 8; -- 2.7.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/radeon: fix a wrong NUM_TILE_PIPES value from the kernel
On Tue, 9 Feb 2016 at 15:17 Alex Deucher wrote:
> On Tue, Feb 9, 2016 at 12:47 PM, Marek Olšák wrote:
> > On Tue, Feb 9, 2016 at 6:17 PM, Alexandre Demers
> > wrote:
> >>> +/* The kernel returns 12 for some cards for an unknown
> >>> reason.
> >>> + * I thought this was supposed to be a power of two.
> >>> + */
> >>> +if (ws->gen == DRV_SI && ws->info.num_tile_pipes == 12)
> >>> +ws->info.num_tile_pipes = 8;
> >>> +
> >>
> >> I may be late in the conversation, but shouldn't we have a look at why
> the
> >> value reported by the kernel is wrong for "some" cards? Which ones and
> why
> >> should be identified. It seems to be limited to Southern Islands as far
> as
> >> we know for now, which limits the scope for now.
> >>
> >> Also, about the patch itself, even if only some cards were reported to
> be
> >> problematic, why would we limit it to "ws->gen == DRV_SI"? Any cards
> >> reporting a wrong value should be treated the same way by mapping its
> value
> >> from 12 to 8, no?
> >
> > No. Only one card is affected (Tahiti or Pitcairn, I don't remember
> > which one). No other card reports 12.
> >
> > There is no point in looking into why the value is wrong and I haven't
> > been able to find where the value had come from. It's part of the
> > kernel ABI now anyway. Userspace won't use it anymore.
>
> I did it when I added SI support. I think I get the value from tcore
> or some hw features header. I don't remember the details. Anyway, I
> think it may have been a hw value (related to the number of memory
> channels) whereas from a sw perspective, we'd use 8 for tiling
> computations. E.g., when we set up rdev->config.si.tile_config which
> is what we used to use, we set it to 8.
>
> Alex
>
Ok, I had a look at what you were pointing. There was even a comment in
si_gpu_init() about tile_config for the case of the problematic value:
rdev->config.si.tile_config = 0;
switch (rdev->config.si.num_tile_pipes) {
[...]
case 8:
default:
/* XXX what about 12? */
rdev->config.si.tile_config |= (3 << 0);
break;
[...]
Should we just clarify the comment in Mesa's committed patch according to
Alex's explanation?
Alexandre Demers
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/radeon: fix a wrong NUM_TILE_PIPES value from the kernel
On Tue, 9 Feb 2016 at 12:47 Marek Olšák wrote: > On Tue, Feb 9, 2016 at 6:17 PM, Alexandre Demers > wrote: > >> +/* The kernel returns 12 for some cards for an unknown > >> reason. > >> + * I thought this was supposed to be a power of two. > >> + */ > >> +if (ws->gen == DRV_SI && ws->info.num_tile_pipes == 12) > >> +ws->info.num_tile_pipes = 8; > >> + > > > > I may be late in the conversation, but shouldn't we have a look at why > the > > value reported by the kernel is wrong for "some" cards? Which ones and > why > > should be identified. It seems to be limited to Southern Islands as far > as > > we know for now, which limits the scope for now. > > > > Also, about the patch itself, even if only some cards were reported to be > > problematic, why would we limit it to "ws->gen == DRV_SI"? Any cards > > reporting a wrong value should be treated the same way by mapping its > value > > from 12 to 8, no? > > No. Only one card is affected (Tahiti or Pitcairn, I don't remember > which one). No other card reports 12. > > There is no point in looking into why the value is wrong and I haven't > been able to find where the value had come from. It's part of the > kernel ABI now anyway. Userspace won't use it anymore. > > Marek > Well, meanwhile, I went on and I had a look at the kernel settings. Here is the answer and the "problem": This was returned by radeon_info_ioctl(), case RADEON_INFO_NUM_TILE_PIPES, else if (rdev->family >= CHIP_TAHITI) *value = rdev->config.si.max_tile_pipes; ( http://lxr.free-electrons.com/source/drivers/gpu/drm/radeon/radeon_kms.c#L353 ) Searching where max_tile_pipes was set, it seems the value comes from si_gpu_init(), case CHIP_TAHITI, rdev->config.si.max_tile_pipes = 12 ( https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/si.c ) This is probably wrong, all other GPU having a power of 2 value (I had a look at ni.c, si.c, evergreen.c). Either that or we have a special case for Tahiti. Also, if this is a special case, while comparing how things works between si.c and cik.c, I saw that (si | cik)_tiling_mode_table_init() were not exactly mapping gpus the same way: si.c uses the family, while cik.c uses the max_tile_pipes value and defaults any value over 8 to be treated as 16. If this can be of any help / reflection... Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] winsys/radeon: fix a wrong NUM_TILE_PIPES value from the kernel
> +/* The kernel returns 12 for some cards for an unknown reason. > + * I thought this was supposed to be a power of two. > + */ > +if (ws->gen == DRV_SI && ws->info.num_tile_pipes == 12) > +ws->info.num_tile_pipes = 8; > + I may be late in the conversation, but shouldn't we have a look at why the value reported by the kernel is wrong for "some" cards? Which ones and why should be identified. It seems to be limited to Southern Islands as far as we know for now, which limits the scope for now. Also, about the patch itself, even if only some cards were reported to be problematic, why would we limit it to "ws->gen == DRV_SI"? Any cards reporting a wrong value should be treated the same way by mapping its value from 12 to 8, no? My late two cents here. Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] State of Geometry shader instancing on radeonsi
Good to have your input. I'll work on it. Marek Olšák wrote: >I think I didn't tell you how I'd like the viewport and scissor states >to be implemented. Here it is: > >1 r600_atom for all 16 viewports >1 r600_atom for all 16 scissors > >Each atom should have a bitmask saying which "slots" are dirty. (same >principle as resource slots) > >The "emit" functions should only set dirty viewports/scissors registers. > >Marek > > > >On Thu, Mar 26, 2015 at 10:18 PM, Alexandre Demers > wrote: >> Update on radeonsi's GL_ARB_viewport_array: even though I don't have much >> time right now, the easy part is done. I should push my changes to my git >> tree soon. I'll let you know where it is. >> >> However, I may need some help for the last part, mostly because r600g >> doesn't help a lot on that matter. Then again, I'll let you know if needed. >> >> Alexandre Demers >> >> >> On 2015-03-04 21:45, Alexandre Demers wrote: >>> >>> Then you can count me as working on ARB_viewport_array. >>> >>> Alexandre Demers >>> >>> On 2015-02-25 14:25, Marek Olšák wrote: >>>> >>>> Nobody is working on ARB_gpu_shader5 for radeonsi. >>>> >>>> Marek >>>> >>>> >>>> >>>> On Wed, Feb 25, 2015 at 6:41 PM, Ilia Mirkin >>>> wrote: >>>>> >>>>> On Wed, Feb 25, 2015 at 11:24 AM, Alexandre Demers >>>>> wrote: >>>>>> >>>>>> Hi everyone, >>>>>> >>>>>> I'd like to know if someone is working on Geometry shader instancing >>>>>> for radeonsi or if there is already a work in progress somewhere I >>>>>> would have missed. I might be interested in giving it a try and then >>>>>> on GL_ARB_viewport_array. >>>>> >>>>> While there's no harm in working on GS instancing on its own, note >>>>> that it's only a small part of the ARB_gpu_shader5 extension, so won't >>>>> be immediately useful until the other pieces are completed (which will >>>>> mostly involve adding LLVM support for the ops in question if they're >>>>> not there yet, and then wiring them up). >>>>> >>>>> ARB_viewport_array is a much more self-contained extension. Note that >>>>> ARB_fragment_layer_viewport will automatically get enabled once you >>>>> claim multiple viewports, so make sure to make gl_ViewportIndex work >>>>> in fp as well if you decide to do it. You may have to pass it as a >>>>> varying "by hand", not sure... IIRC I had to do that in r600. There >>>>> are piglits that cover the various cases. >>>>> >>>>> [Hopefully Marek and/or some of the other AMD guys will pipe up if >>>>> they've worked on any of these things and just haven't published yet.] >>>>> >>>>>-ilia >>>>> ___ >>>>> mesa-dev mailing list >>>>> mesa-dev@lists.freedesktop.org >>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev >>> >>> >> >> >> --- >> This email has been checked for viruses by Avast antivirus software. >> http://www.avast.com >> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] State of Geometry shader instancing on radeonsi
Update on radeonsi's GL_ARB_viewport_array: even though I don't have much time right now, the easy part is done. I should push my changes to my git tree soon. I'll let you know where it is. However, I may need some help for the last part, mostly because r600g doesn't help a lot on that matter. Then again, I'll let you know if needed. Alexandre Demers On 2015-03-04 21:45, Alexandre Demers wrote: Then you can count me as working on ARB_viewport_array. Alexandre Demers On 2015-02-25 14:25, Marek Olšák wrote: Nobody is working on ARB_gpu_shader5 for radeonsi. Marek On Wed, Feb 25, 2015 at 6:41 PM, Ilia Mirkin wrote: On Wed, Feb 25, 2015 at 11:24 AM, Alexandre Demers wrote: Hi everyone, I'd like to know if someone is working on Geometry shader instancing for radeonsi or if there is already a work in progress somewhere I would have missed. I might be interested in giving it a try and then on GL_ARB_viewport_array. While there's no harm in working on GS instancing on its own, note that it's only a small part of the ARB_gpu_shader5 extension, so won't be immediately useful until the other pieces are completed (which will mostly involve adding LLVM support for the ops in question if they're not there yet, and then wiring them up). ARB_viewport_array is a much more self-contained extension. Note that ARB_fragment_layer_viewport will automatically get enabled once you claim multiple viewports, so make sure to make gl_ViewportIndex work in fp as well if you decide to do it. You may have to pass it as a varying "by hand", not sure... IIRC I had to do that in r600. There are piglits that cover the various cases. [Hopefully Marek and/or some of the other AMD guys will pipe up if they've worked on any of these things and just haven't published yet.] -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallivm: (trivial) Fix typo in comment introduced by 70dc8a
Fix typo in comment introduced by 70dc8a Signed-off-by: Alexandre Demers --- src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp index d60db91..4ede90b 100644 --- a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp +++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp @@ -502,7 +502,7 @@ lp_build_create_jit_compiler_for_module(LLVMExecutionEngineRef *OutJIT, #if HAVE_LLVM >= 0x0306 builder.setMCJITMemoryManager(std::unique_ptr(MM)); - MM = NULL; // onwership taken by std::unique_ptr + MM = NULL; // ownership taken by std::unique_ptr #else builder.setMCJITMemoryManager(MM); #endif -- 2.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] State of Geometry shader instancing on radeonsi
Then you can count me as working on ARB_viewport_array. Alexandre Demers On 2015-02-25 14:25, Marek Olšák wrote: Nobody is working on ARB_gpu_shader5 for radeonsi. Marek On Wed, Feb 25, 2015 at 6:41 PM, Ilia Mirkin wrote: On Wed, Feb 25, 2015 at 11:24 AM, Alexandre Demers wrote: Hi everyone, I'd like to know if someone is working on Geometry shader instancing for radeonsi or if there is already a work in progress somewhere I would have missed. I might be interested in giving it a try and then on GL_ARB_viewport_array. While there's no harm in working on GS instancing on its own, note that it's only a small part of the ARB_gpu_shader5 extension, so won't be immediately useful until the other pieces are completed (which will mostly involve adding LLVM support for the ops in question if they're not there yet, and then wiring them up). ARB_viewport_array is a much more self-contained extension. Note that ARB_fragment_layer_viewport will automatically get enabled once you claim multiple viewports, so make sure to make gl_ViewportIndex work in fp as well if you decide to do it. You may have to pass it as a varying "by hand", not sure... IIRC I had to do that in r600. There are piglits that cover the various cases. [Hopefully Marek and/or some of the other AMD guys will pipe up if they've worked on any of these things and just haven't published yet.] -ilia ___ 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] State of Geometry shader instancing on radeonsi
Hi everyone, I'd like to know if someone is working on Geometry shader instancing for radeonsi or if there is already a work in progress somewhere I would have missed. I might be interested in giving it a try and then on GL_ARB_viewport_array. Cheers. Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Use R600_MAX_VIEWPORTS instead of 16
You are right, I missed that one. I'll send a v2 to fix it.
Alexandre Demers
On 2015-02-25 01:36, Ilia Mirkin wrote:
On Wed, Feb 25, 2015 at 1:34 AM, Alexandre Demers
wrote:
Lets define R600_MAX_VIEWPORTS instead of using 16 here and there
in the code when looping through viewports and scissors. It is
easier to understand what this number represents.
Signed-off-by: Alexandre Demers
---
src/gallium/drivers/r600/evergreen_state.c | 10 +-
src/gallium/drivers/r600/r600_hw_context.c | 2 +-
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_pipe.h | 6 --
src/gallium/drivers/r600/r600_state.c | 4 ++--
5 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 8aa8082..f0b04f0 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2293,8 +2293,8 @@ static void cayman_init_atom_start_cs(struct r600_context
*rctx)
r600_store_context_reg(cb, R_028200_PA_SC_WINDOW_OFFSET, 0);
r600_store_context_reg(cb, R_02820C_PA_SC_CLIPRECT_RULE, 0x);
- r600_store_context_reg_seq(cb, R_0282D0_PA_SC_VPORT_ZMIN_0, 2 * 16);
- for (tmp = 0; tmp < 16; tmp++) {
+ r600_store_context_reg_seq(cb, R_0282D0_PA_SC_VPORT_ZMIN_0, 2 *
R600_MAX_VIEWPORTS);
+ for (tmp = 0; tmp < R600_MAX_VIEWPORTS; tmp++) {
r600_store_value(cb, 0); /* R_0282D0_PA_SC_VPORT_ZMIN_0 */
r600_store_value(cb, fui(1.0)); /* R_0282D4_PA_SC_VPORT_ZMAX_0
*/
}
@@ -2727,8 +2727,8 @@ void evergreen_init_atom_start_cs(struct r600_context
*rctx)
r600_store_context_reg(cb, R_02820C_PA_SC_CLIPRECT_RULE, 0x);
r600_store_context_reg(cb, R_028230_PA_SC_EDGERULE, 0x);
- r600_store_context_reg_seq(cb, R_0282D0_PA_SC_VPORT_ZMIN_0, 2 * 16);
- for (tmp = 0; tmp < 16; tmp++) {
+ r600_store_context_reg_seq(cb, R_0282D0_PA_SC_VPORT_ZMIN_0, 2 *
R600_MAX_VIEWPORTS);
+ for (tmp = 0; tmp < R600_MAX_VIEWPORTS; tmp++) {
r600_store_value(cb, 0); /* R_0282D0_PA_SC_VPORT_ZMIN_0 */
r600_store_value(cb, fui(1.0)); /* R_0282D4_PA_SC_VPORT_ZMAX_0
*/
}
@@ -3458,7 +3458,7 @@ void evergreen_init_state_functions(struct r600_context
*rctx)
r600_init_atom(rctx, &rctx->dsa_state.atom, id++, r600_emit_cso_state,
0);
r600_init_atom(rctx, &rctx->poly_offset_state.atom, id++,
evergreen_emit_polygon_offset, 6);
r600_init_atom(rctx, &rctx->rasterizer_state.atom, id++,
r600_emit_cso_state, 0);
- for (i = 0; i < 16; i++) {
+ for (i = 0; i < R600_MAX_VIEWPORTS; i++) {
r600_init_atom(rctx, &rctx->viewport[i].atom, id++,
r600_emit_viewport_state, 8);
r600_init_atom(rctx, &rctx->scissor[i].atom, id++,
evergreen_emit_scissor_state, 4);
rctx->viewport[i].idx = i;
diff --git a/src/gallium/drivers/r600/r600_hw_context.c
b/src/gallium/drivers/r600/r600_hw_context.c
index cd57eed..7961a96 100644
--- a/src/gallium/drivers/r600/r600_hw_context.c
+++ b/src/gallium/drivers/r600/r600_hw_context.c
@@ -307,7 +307,7 @@ void r600_begin_new_cs(struct r600_context *ctx)
ctx->poly_offset_state.atom.dirty = true;
ctx->vgt_state.atom.dirty = true;
ctx->sample_mask.atom.dirty = true;
- for (i = 0; i < 16; i++) {
+ for (i = 0; i < R600_MAX_VIEWPORTS; i++) {
ctx->scissor[i].atom.dirty = true;
ctx->viewport[i].atom.dirty = true;
}
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index c8a0e9c..24d901e 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -374,7 +374,7 @@ static int r600_get_param(struct pipe_screen* pscreen, enum
pipe_cap param)
return 8;
case PIPE_CAP_MAX_VIEWPORTS:
- return 16;
+ return R600_MAX_VIEWPORTS;
/* Timer queries, present when the clock frequency is non zero. */
case PIPE_CAP_QUERY_TIME_ELAPSED:
diff --git a/src/gallium/drivers/r600/r600_pipe.h
b/src/gallium/drivers/r600/r600_pipe.h
index 7237854..ac69895 100644
--- a/src/gallium/drivers/r600/r600_pipe.h
+++ b/src/gallium/drivers/r600/r600_pipe.h
@@ -38,6 +38,8 @@
#define R600_NUM_ATOMS 73
+#define R600_MAX_VIEWPORTS 16
+
/* read caches */
#define R600_CONTEXT_INV_VERTEX_CACHE (R600_CONTEXT_PRIVATE_FLAG <<
0)
#define R600_CONTEXT_INV_TEX_CACHE (R600_CONTEXT_PRIVATE_FLAG <<
1)
@@ -443,12 +445,12 @@ struct r600_context {
struct r600_poly_offset_state poly_offset_state;
struct r600_cso_state rasterizer_state;
struct r600_sample_mask sample_mask;
-
Re: [Mesa-dev] [PATCH v2] r600g: Implement GL_ARB_sample_shading
Tested with v3. I get the same result as before: everything is fine
except the gs-atan-vec2 test.
I don't know if this is of any value, but running the command manually
in a shell gives the following:
/home/ademers/projects/display/piglit/bin/shader_runner
/home/ademers/projects/display/piglit/generated_tests/spec/glsl-1.50/execution/built-in-functions/gs-atan-vec4.shader_test
-auto
PIGLIT: {"result": "pass" }
I assume the test ran correctly, but not in the context of the piglit
run, am I right?
Alexandre Demers
On 15/09/14 01:15 AM, Alexandre Demers wrote:
Sorry for the delay, I've been away for work and with not much free
time lately.
I'll have a look at it as soon as possible.
Alexandre Demers
On 10/09/14 06:16 AM, Glenn Kennard wrote:
On Sat, 06 Sep 2014 04:00:01 +0200, Alexandre Demers
wrote:
Thanks Marek, you were right.
So, on cayman, after comparing results from both runs, it seems
there is only one regression which is gs-atan-vec2 under glsl-1.50:
piglit/bin/shader_runner
/home/ademers/projects/display/piglit/generated_tests/spec/glsl-1.50/execution/built-in-functions/gs-atan-vec2.shader_test
-auto
The returned value is the following:
Probe color at (5,0)
Expected: 0.00 1.00 0.00 1.00
Observed: 1.00 0.00 0.00 1.00
I've found that some of the piglit geometry shader tests tend to fail
once one GPU reset has occurred, and persist until the next power
cycle. Did you do a cold restart after the x crash and re-running the
tests? Might be worth trying just re-running the failing test after a
restart and see if it goes away.
/Glenn
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] r600g: Implement GL_ARB_sample_shading
Sorry for the delay, I've been away for work and with not much free time lately. I'll have a look at it as soon as possible. Alexandre Demers On 10/09/14 06:16 AM, Glenn Kennard wrote: On Sat, 06 Sep 2014 04:00:01 +0200, Alexandre Demers wrote: Thanks Marek, you were right. So, on cayman, after comparing results from both runs, it seems there is only one regression which is gs-atan-vec2 under glsl-1.50: piglit/bin/shader_runner /home/ademers/projects/display/piglit/generated_tests/spec/glsl-1.50/execution/built-in-functions/gs-atan-vec2.shader_test -auto The returned value is the following: Probe color at (5,0) Expected: 0.00 1.00 0.00 1.00 Observed: 1.00 0.00 0.00 1.00 I've found that some of the piglit geometry shader tests tend to fail once one GPU reset has occurred, and persist until the next power cycle. Did you do a cold restart after the x crash and re-running the tests? Might be worth trying just re-running the failing test after a restart and see if it goes away. /Glenn ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] r600g: Implement GL_ARB_sample_shading
Thanks Marek, you were right. So, on cayman, after comparing results from both runs, it seems there is only one regression which is gs-atan-vec2 under glsl-1.50: piglit/bin/shader_runner /home/ademers/projects/display/piglit/generated_tests/spec/glsl-1.50/execution/built-in-functions/gs-atan-vec2.shader_test -auto The returned value is the following: Probe color at (5,0) Expected: 0.00 1.00 0.00 1.00 Observed: 1.00 0.00 0.00 1.00 Overall, here are the result summary comparing "before the patch" and "after the patch": all 17474/1871617514/18755 spec 15903/1710615943/17145 glsl-1.50 3059/31063060/3106 execution 1628/16721629/1672 built-in-functions 1485/14871486/1487 gs-atan-vec2 passfail Add this to my results with Tesseract and it is definitively an improvement. Alexandre Demers On 05/09/14 11:19 AM, Marek Olšák wrote: You can skip glx tests using these piglit-run parameters: -x glx -x makeCurrent That should prevent X from crashing. Marek On Fri, Sep 5, 2014 at 7:07 AM, Alexandre Demers wrote: I've been testing your patch v2 on cayman. Here are my results. For now, my piglit runs are not conclusive because a quick run fails even without your patch: almost at the end of the run, X crashes. However, using Tesseract as you suggested gave good results. First, it fixes a visual glitch appearing on object's edges. Also, being at the same position and pointing at the same place resulted in a FPS rate greatly improved (from 21 fps to 37 fps). So it seems good on cayman. I'll try to confirm it even further with a good piglit run if I find a way to run it correctly first without the patch. -- Alexandre Demers ___ 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 v2] r600g: Implement GL_ARB_sample_shading
I've been testing your patch v2 on cayman. Here are my results. For now, my piglit runs are not conclusive because a quick run fails even without your patch: almost at the end of the run, X crashes. However, using Tesseract as you suggested gave good results. First, it fixes a visual glitch appearing on object's edges. Also, being at the same position and pointing at the same place resulted in a FPS rate greatly improved (from 21 fps to 37 fps). So it seems good on cayman. I'll try to confirm it even further with a good piglit run if I find a way to run it correctly first without the patch. -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Implement GL_ARB_sample_shading
Hi Glenn, I've tried applying your patch on the latest mesa code and it could not be applied properly. Could you rebase your patch? I would be happy to test it on Cayman for you once done. Cheers. -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: fix omx default installation folder
Making default OMX installation folder follows the same pattern as
other state trackers / libs. Fixes bug 80615.
Signed-off-by: Alexandre Demers
---
configure.ac | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 98efa43..a684390 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1794,16 +1794,12 @@ AC_ARG_WITH([vdpau-libdir],
[VDPAU_LIB_INSTALL_DIR='${libdir}/vdpau'])
AC_SUBST([VDPAU_LIB_INSTALL_DIR])
-OMX_LIB_INSTALL_DIR_DEFAULT=''
-if test "x$enable_omx" = xyes; then
-OMX_LIB_INSTALL_DIR_DEFAULT=`$PKG_CONFIG --variable=pluginsdir
libomxil-bellagio`
-fi
-
+dnl Directory for OMX libs
AC_ARG_WITH([omx-libdir],
[AS_HELP_STRING([--with-omx-libdir=DIR],
-[directory for the OMX libraries])],
+[directory for the OMX libraries @<:@default=${libdir}/bellagio@:>@])],
[OMX_LIB_INSTALL_DIR="$withval"],
-[OMX_LIB_INSTALL_DIR="$OMX_LIB_INSTALL_DIR_DEFAULT"])
+[OMX_LIB_INSTALL_DIR="${libdir}/bellagio"])
AC_SUBST([OMX_LIB_INSTALL_DIR])
dnl Directory for OpenCL libs
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: (trivial) Fixing a typo
Signed-off-by: Alexandre Demers
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index faf1485..98efa43 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1603,7 +1603,7 @@ fi
AC_ARG_WITH([egl-driver-dir],
[AS_HELP_STRING([--with-egl-driver-dir=DIR],
-[directory for EGL drivers [[default=${libdir}/egl]]])],
+[directory for EGL drivers
@<:@default=${libdir}/egl@:>@])],
[EGL_DRIVER_INSTALL_DIR="$withval"],
[EGL_DRIVER_INSTALL_DIR='${libdir}/egl'])
AC_SUBST([EGL_DRIVER_INSTALL_DIR])
--
2.0.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/7] loader: Use dlsym to get our udev symbols instead of explicit linking.
This patch fixes bug 71543 where libudev.so.0 and libudev.so.1 are in conflict. With this patch, I was able to launch Garry's Mod (which previously would crash before showing anything). So you can add Tested-by: Alexandre Demers -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Fix --enable-XX-bit flags by moving LT_INIT where it should
Moving LT_INIT after setting completely (AM_)C(XX)FLAGS and LDFLAGS. LT_INIT needs them as they are expected to be used all along the compilation when the macro runs its tests to determine among other things the host type. For info, see http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html Fixes https://bugs.freedesktop.org/show_bug.cgi?id=50754 Signed-off-by: Alexandre Demers Tested-by: Tapani Palli --- configure.ac | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index fb16338..d41595d 100644 --- a/configure.ac +++ b/configure.ac @@ -51,9 +51,6 @@ AX_PYTHON_MODULE([libxml2], [needed]) AC_PROG_SED AC_PROG_MKDIR_P -LT_PREREQ([2.2]) -LT_INIT([disable-static]) - AX_PROG_BISON([], AS_IF([test ! -f "$srcdir/src/glsl/glcpp/glcpp-parse.c"], [AC_MSG_ERROR([bison not found - unable to compile glcpp-parse.y])])) @@ -1956,6 +1953,14 @@ dnl Add user CFLAGS and CXXFLAGS CFLAGS="$CFLAGS $USER_CFLAGS" CXXFLAGS="$CXXFLAGS $USER_CXXFLAGS" +dnl +dnl LT_INIT adds tests to determine host based on some variables like (AM_)C(XX)FLAGS and (AM_)LDFLAGS. +dnl They need to be set before calling LT_INIT so the macro can configure things correctly when cross_compiling. +dnl This will allow --enable-xx-bit to work as expected. +dnl +LT_PREREQ([2.2]) +LT_INIT([disable-static]) + dnl Substitute the config AC_CONFIG_FILES([Makefile src/Makefile -- 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] Updating forgotten GL feature completion for r600
I don't have commit rights. I'd appreciate if someone could commit it for me. Also, I think it should be a candidat for 9.2 branch. Alexandre Demers On 10/20/2013 01:56 PM, Marek Olšák wrote: Reviewed-by: Marek Olšák Marek On Sun, Oct 20, 2013 at 7:48 PM, Alexandre Demers wrote: --- docs/GL3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index c269f19..a56e7fe 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -71,7 +71,7 @@ Base vertex offset(GL_ARB_draw_elements_base_vertex) DONE (i965, r300, r600, sw Frag shader coord (GL_ARB_fragment_coord_conventions) DONE (i965, r300, r600, swrast) Provoking vertex (GL_ARB_provoking_vertex)DONE (i965, r300, r600, swrast) Seamless cubemaps (GL_ARB_seamless_cube_map) DONE (i965, r600) -Multisample textures (GL_ARB_texture_multisample) DONE (i965) +Multisample textures (GL_ARB_texture_multisample) DONE (i965, r600) Frag depth clamp (GL_ARB_depth_clamp) DONE (i965, r600, swrast) Fence objects (GL_ARB_sync) DONE (i965, r300, r600, swrast) GLX_ARB_create_context_profileDONE -- 1.8.4.1 ___ 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] Updating forgotten GL feature completion for r600
--- docs/GL3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index c269f19..a56e7fe 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -71,7 +71,7 @@ Base vertex offset(GL_ARB_draw_elements_base_vertex) DONE (i965, r300, r600, sw Frag shader coord (GL_ARB_fragment_coord_conventions) DONE (i965, r300, r600, swrast) Provoking vertex (GL_ARB_provoking_vertex)DONE (i965, r300, r600, swrast) Seamless cubemaps (GL_ARB_seamless_cube_map) DONE (i965, r600) -Multisample textures (GL_ARB_texture_multisample) DONE (i965) +Multisample textures (GL_ARB_texture_multisample) DONE (i965, r600) Frag depth clamp (GL_ARB_depth_clamp) DONE (i965, r600, swrast) Fence objects (GL_ARB_sync) DONE (i965, r300, r600, swrast) GLX_ARB_create_context_profileDONE -- 1.8.4.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] docs/GL3.txt not up to date?
On 10/18/2013 06:19 PM, Ian Romanick wrote: On 10/18/2013 11:31 AM, Alexandre Demers wrote: Hi, I was looking at the latest commits and some comments here and there. Is it me or is docs/GL3.txt not up to date? I don't know of you're up to date or not, but GL3.txt almost surely is not. For the current example, I was looking at today's git version cedfd79be205f302a82635354679cd2ecaf3cc57, so pretty up to date. For example, on Sept 24th ( http://web.archiveorange.com/archive/v/PjyyP3KOnlzH11QKVtyC), Marek was confirming GL_ARB_texture_multisample support for r600 and si (CIK missing). Thus, it should be listed as implemented for r600. And from my understanding, it was completed for the 9.2 release, so GL3.txt should have been updated before that. Intel pushed its latest patches to complete the 3.2 and 3.3 features in the last couple of days, but the GL3.txt was not updated at the same time. GLSL 1.50 and 3.30 should be listed as DONE for at least Intel. What I'm saying is I most of the time learn going through commits or Phoronix that a new feature is now considered done than from GL3.txt. GL3.txt should be updated at the same time as features are considered completed by a dev if it is truly complete. When a feature is completed, both GL3.txt and the release notes should be updated. It's /really/ easy to over look both of those, however. I know, it seems to be a bad habit. At some point, there is always someone who sends a patch just to update the GL3.txt file because he saw a few things changed and features' notes were not systematically updated. Same goes for the release notes. But I understand it is easy to forget it. Thanks. I know, I can find it by other means, but why not just make sure we are updating the doc at the right moment? My two cents as a tester... -- Alexandre Demers ___ 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] docs/GL3.txt not up to date?
Hi, I was looking at the latest commits and some comments here and there. Is it me or is docs/GL3.txt not up to date? For example, on Sept 24th ( http://web.archiveorange.com/archive/v/PjyyP3KOnlzH11QKVtyC), Marek was confirming GL_ARB_texture_multisample support for r600 and si (CIK missing). Thus, it should be listed as implemented for r600. And from my understanding, it was completed for the 9.2 release, so GL3.txt should have been updated before that. Intel pushed its latest patches to complete the 3.2 and 3.3 features in the last couple of days, but the GL3.txt was not updated at the same time. GLSL 1.50 and 3.30 should be listed as DONE for at least Intel. What I'm saying is I most of the time learn going through commits or Phoronix that a new feature is now considered done than from GL3.txt. GL3.txt should be updated at the same time as features are considered completed by a dev if it is truly complete. I know, I can find it by other means, but why not just make sure we are updating the doc at the right moment? My two cents as a tester... -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] about driconf and experimental flags
Simple question: is there a reason why many options and features under development or testing are only available by manually setting env variables? The point is, why isn't there an experimental tab under driconf where we could easily enable or disable the different features? Modifying .drirc manually would also be possible. That way, it would be easier for any enthusiasts or testers to modify the options. Personally, I like to test the latest mesa, but sometimes I forget the available variables. It's an idea that I'm sharing with you and it might have been discussed before. Cheers, -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] anongit.freedesktop.org not available?
Hi, I've been trying all day to sync sources from anongit.freedesktop.org (dri and mesa) and it always ends up by a time out. Is there a problem with the server or the address? Cheers, -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] llvm-config on a biarch machine
I really like this new feature in LLVM. I've been fighting for some time to compile mesa 32bit on 64bit because of Wine in the simplest way possible. Kevin, your patches are interesting and I'm sad to see no answer from any dev. But I also understand that last week's big topics were Android and killing old drivers. Did you try putting the CFLAGS and LDFLAGS under configure.ac to see if they would work there? Maybe they could be defined in your "if" statements. I don't have LLVM 3 on my setup right now, but I may try it soon. Cheers, -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] g3dvl: check for existence of header/libs
May I suggest to fix that one also since there is a missing dependency on d3dx state tracker? https://bugs.freedesktop.org/show_bug.cgi?id=33938 Cheers, -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] r600g and S3TC
Hi all, A simple question: is enabling S3TC supposed to work with latest git on r600g? I'm using latest git and kernel 2.6.38.2. Libdrm is 2.4.24+ (git from a couple of days). Libtxc_dxtn is latest version available from git. When I try R600_ENABLE_S3TC=1 RendererFeatTest.bin64, I only see garbage (automatic screenshots from the application are all black). If I don't use the flag, the extension is disabled and RendererFeatTest works as usual (still as some issues compared to another driver like i915 though like no background and crippled text). -- Alexandre Demers ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Patch against glxinfo: one line per extension
On 11-01-20 03:52 PM, Brian Paul wrote:
On 01/20/2011 12:35 PM, Alexandre Demers wrote:
Hi,
I'd like to propose a patch against glxinfo. Instead of separating the
extensions by a comma, it creates a new line. It's visually easier to
read through the extensions. Also, when doing a diff between supported
extensions by classic driver and gallium driver, it's a lot simpler to
compare the results.
I attached the patch.
At this point there may be programs/scripts that expect the glxinfo
output to be in the current format (which was copied from SGI's
original glxinfo program).
How about a new command line flag to print one extension per line?
-Brian
Here is a new patch. It adds the "-s" flag, which stands for "Print a
single extension per line". That way, glxinfo will output extensions
separated by commas by default as usual, unless the flag is added.
--
Alexandre Demers
diff --git a/src/xdemos/glxinfo.c b/src/xdemos/glxinfo.c
index e4ff3d5..c4e9861 100644
--- a/src/xdemos/glxinfo.c
+++ b/src/xdemos/glxinfo.c
@@ -110,7 +110,7 @@ struct visual_attribs
* Print a list of extensions, with word-wrapping.
*/
static void
-print_extension_list(const char *ext)
+print_extension_list(const char *ext, Bool singleLine)
{
const char *indentString = "";
const int indent = 4;
@@ -127,7 +127,7 @@ print_extension_list(const char *ext)
if (ext[j] == ' ' || ext[j] == 0) {
/* found end of an extension name */
const int len = j - i;
- if (width + len > max) {
+ if ((!singleLine) && (width + len > max)) {
/* start a new line */
printf("\n");
width = indent;
@@ -148,8 +148,15 @@ print_extension_list(const char *ext)
j++;
if (ext[j] == 0)
break;
-printf(", ");
-width += 2;
+if (singleLine) {
+ printf("\n");
+ width = indent;
+ printf("%s", indentString);
+}
+else {
+ printf(", ");
+ width += 2;
+}
}
}
j++;
@@ -412,7 +419,7 @@ print_limits(const char *extensions)
static void
-print_screen_info(Display *dpy, int scrnum, Bool allowDirect, GLboolean limits)
+print_screen_info(Display *dpy, int scrnum, Bool allowDirect, GLboolean
limits, Bool singleLine)
{
Window win;
int attribSingle[] = {
@@ -555,14 +562,14 @@ print_screen_info(Display *dpy, int scrnum, Bool
allowDirect, GLboolean limits)
printf("server glx vendor string: %s\n", serverVendor);
printf("server glx version string: %s\n", serverVersion);
printf("server glx extensions:\n");
- print_extension_list(serverExtensions);
+ print_extension_list(serverExtensions, singleLine);
printf("client glx vendor string: %s\n", clientVendor);
printf("client glx version string: %s\n", clientVersion);
printf("client glx extensions:\n");
- print_extension_list(clientExtensions);
+ print_extension_list(clientExtensions, singleLine);
printf("GLX version: %u.%u\n", glxVersionMajor, glxVersionMinor);
printf("GLX extensions:\n");
- print_extension_list(glxExtensions);
+ print_extension_list(glxExtensions, singleLine);
printf("OpenGL vendor string: %s\n", glVendor);
printf("OpenGL renderer string: %s\n", glRenderer);
printf("OpenGL version string: %s\n", glVersion);
@@ -574,7 +581,7 @@ print_screen_info(Display *dpy, int scrnum, Bool
allowDirect, GLboolean limits)
#endif
printf("OpenGL extensions:\n");
- print_extension_list(glExtensions);
+ print_extension_list(glExtensions, singleLine);
if (limits)
print_limits(glExtensions);
}
@@ -1201,7 +1208,7 @@ find_best_visual(Display *dpy, int scrnum)
static void
usage(void)
{
- printf("Usage: glxinfo [-v] [-t] [-h] [-i] [-b] [-display ]\n");
+ printf("Usage: glxinfo [-v] [-t] [-h] [-i] [-b] [-s] ][-display
]\n");
printf("\t-v: Print visuals info in verbose form.\n");
printf("\t-t: Print verbose table.\n");
printf("\t-display : Print GLX visuals on specified server.\n");
@@ -1209,6 +1216,7 @@ usage(void)
printf("\t-i: Force an indirect rendering context.\n");
printf("\t-b: Find the 'best' visual and print its number.\n");
printf("\t-l: Print interesting OpenGL limits.\n");
+ printf("\t-s: Print a single extension per line.\n");
}
@@ -1222,6 +1230,7 @@ main(int argc, char *argv[])
GLboolean findBest = GL_FALSE;
GLboolean limits = GL_FALSE;
Bool allowDirect = True;
+ Bool singleLine = False;
[Mesa-dev] Patch against glxinfo: one line per extension
Hi,
I'd like to propose a patch against glxinfo. Instead of separating the
extensions by a comma, it creates a new line. It's visually easier to
read through the extensions. Also, when doing a diff between supported
extensions by classic driver and gallium driver, it's a lot simpler to
compare the results.
I attached the patch.
Cheers,
--
Alexandre Demers
diff --git a/src/xdemos/glxinfo.c b/src/xdemos/glxinfo.c
index e4ff3d5..d0903c0 100644
--- a/src/xdemos/glxinfo.c
+++ b/src/xdemos/glxinfo.c
@@ -114,7 +114,6 @@ print_extension_list(const char *ext)
{
const char *indentString = "";
const int indent = 4;
- const int max = 79;
int width, i, j;
if (!ext || !ext[0])
@@ -127,12 +126,6 @@ print_extension_list(const char *ext)
if (ext[j] == ' ' || ext[j] == 0) {
/* found end of an extension name */
const int len = j - i;
- if (width + len > max) {
-/* start a new line */
-printf("\n");
-width = indent;
-printf("%s", indentString);
- }
/* print the extension name between ext[i] and ext[j] */
while (i < j) {
printf("%c", ext[i]);
@@ -148,8 +141,9 @@ print_extension_list(const char *ext)
j++;
if (ext[j] == 0)
break;
-printf(", ");
-width += 2;
+printf("\n");
+width = indent;
+printf("%s", indentString);
}
}
j++;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] State of gallium driver for i915/945
Hi,I've been following the development of mesa and gallium for some time now. Each time a developer talks about the gallium i915/945 driver, it's always in an "almost done" state... However, even now, it doesn't support everything the dri driver does (glxinfo shows less extensions and so on for the gallium driver). Is there a plan to complete the work? What's its state? What still needs to be done? Is there enough information around to do it? Is someone actively working on it? I'd be interested to work on it if something can be done.Thanks,Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
