[Mesa-dev] oldest gcc version to support ?
Hi folks, which is the oldest gcc version we need to support ? I see certain quirks for pre 4.4.5 - my Ubuntu Trusty box (now over 2 years old) already has 4.8 ... can we remove that stuff ? (anyways, it's just for non-autoconf builds) --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] what happened to libgallium.so ?
On Thu, Aug 4, 2016 at 7:48 AM, Enrico Weigelt, metux IT consult wrote: > On 03.08.2016 18:09, Marek Olšák wrote: >> It has always been statically linked as far as I remember. >> libgallium.so is a Ubuntu speciality that we don't support. > > on win32 (using scons), it doesn't seem to be the case: > > https://github.com/metux/mesa/blob/a44ed2123ea6c84df9d00cdc12162112f20ed57e/src/glx/SConscript#L44 src/glx isn't gallium. src/glx isn't even used on Windows. That linked file is completely disconnected from everything this thread is about. Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] c99 vs v90
On 04/08/16 01:48, Enrico Weigelt, metux IT consult wrote: On 03.08.2016 23:28, Jose Fonseca wrote: Hi, There are minor inconsistencies. For example, it doesn't support __func__, but doing #define __func__ __FUNCTION__ suffices to make __func__ work compatible. Wait a second ... IIRC, __FUNCTION__ was a non-standard gcc'ism - now msvc support that, but lacks the standardized __func__ ? Seriously ? __FUNCTION__ has been around for a very long time (before 1999), so it's no surprise that MSVC has it. But not implementing __func__ does seem a oversight. I believe they fixed it on MSVC 2015. Anyway, this was just an example. Don't let it upset you. Keeping code portable is full of this small inconsistencies due to bugs/historical-reasons/etc. If this goes under your skin, then it might be better to spare your nerves and do something else. Also MSVC C++ doesn't support many C99 that are not part of C++. Where as GNU C++ munches all. grmpf! To be clear, GNU C++ is the non-standard one here. MSVC is following the spec. It's just a ptty that the C and C++ standard bodies don't strive for consistency. by the way: what's the exact reason for using msvc instead of gcc on win32 ? GCC on Win32 (MinGW) is not reliable (lots of known bugs.) But above all, it's impossible to debug Mingw executables on Windows: one has to use GDB to debug Mingw DLLs/EXEs because Microsft debuggers don't understand DWARF debug info, and one has to use Microsof debugger to debug Microsoft DLLs/EXEs. So it's impossible to debug an app that uses both, which is always the case if the OpenGL driver is built with GCC. But Microsoft has been working on a Clang/LLVM frontend for their compiler, capable of genering debug info on MS format. So I have hopes we could one day switch to it. It still in its early infancy though. hmm, I dont have any msvc here (actually, no windows at all), but I could prepare patches, which other people could test. You could make a fork on github and then register with AppVeyor. yeah, already got it running. can I also deploy it to some VM there and log in via VNC ? No, not that I know of. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error
On 04/08/16 05:07, Nicolas Boichat wrote:
egl/x11 fixup has already be sent here:
https://patchwork.freedesktop.org/patch/101934/
Compile-tested only (on android only).
I was first thinking of modifying most functions in egl_dri2.c to take in
dri2_egl_display *dri2_dpy instead of _EGLDisplay *disp as parameter, so
we do not need to set disp->DriverData early in the dri_initialize_* functions.
But there are some functions that do need disp as well:
- dri2_add_config, to call _eglInitConfig (disp->DriverData does not need to be
set), and to check if extensions are supported.
- dri2_setup_screen (similar reasons)
Ideas to untangle this are welcome. In the mean time, this patch series should
fix crashes and a piglit test.
Nicolas Boichat (4):
egl/wayland: Set disp->DriverData to NULL on error
egl/surfaceless: Set disp->DriverData to NULL on error
egl/drm: Set disp->DriverData to NULL on error
egl/android: Set dpy->DriverData to NULL on error
This patch series fixes egl_khr_fence_sync for me:
Tested-by: Martin Peres
However, egl-create-context-verify-gl-flavor is still crashing, even
with "egl/dri2: dri2_initialize: Do not reference-count TestOnly
display" applied. The issue is that eglGetProcAddress("glGetString")
returns NULL.
Martin
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] non-shared glapi still needed ? [WAS: what happened to libgallium.so ?]
On 04.08.2016 11:21, Marek Olšák wrote: > src/glx isn't gallium. src/glx isn't even used on Windows. That linked > file is completely disconnected from everything this thread is about. ups, I mixed up several threads ... I meant the shared glapi library. (see the other thread "non-shared glapi still needed ?") To summarize up what I've found out so far: * on gnu/linux, using a shared glapi library seems to be default * on win32, only static is supported. Is there some special reason for the need of static lib on win32 ? --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error
On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres
wrote:
> On 04/08/16 05:07, Nicolas Boichat wrote:
>>
>> egl/x11 fixup has already be sent here:
>> https://patchwork.freedesktop.org/patch/101934/
>>
>> Compile-tested only (on android only).
>>
>> I was first thinking of modifying most functions in egl_dri2.c to take in
>> dri2_egl_display *dri2_dpy instead of _EGLDisplay *disp as parameter, so
>> we do not need to set disp->DriverData early in the dri_initialize_*
>> functions.
>>
>> But there are some functions that do need disp as well:
>> - dri2_add_config, to call _eglInitConfig (disp->DriverData does not need
>> to be
>>set), and to check if extensions are supported.
>> - dri2_setup_screen (similar reasons)
>>
>> Ideas to untangle this are welcome. In the mean time, this patch series
>> should
>> fix crashes and a piglit test.
>>
>> Nicolas Boichat (4):
>> egl/wayland: Set disp->DriverData to NULL on error
>> egl/surfaceless: Set disp->DriverData to NULL on error
>> egl/drm: Set disp->DriverData to NULL on error
>> egl/android: Set dpy->DriverData to NULL on error
>>
>
> This patch series fixes egl_khr_fence_sync for me:
> Tested-by: Martin Peres
Thanks!
> However, egl-create-context-verify-gl-flavor is still crashing, even with
> "egl/dri2: dri2_initialize: Do not reference-count TestOnly display"
> applied. The issue is that eglGetProcAddress("glGetString") returns NULL.
That's surprising, Michel said that my patch fixed that issue. Did you
try reverting "9ee683f877 (egl/dri2: Add reference count for
dri2_egl_display)" to confirm that my original patch broke it?
Best,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] c99 vs v90
On 04.08.2016 11:38, Jose Fonseca wrote: > __FUNCTION__ has been around for a very long time (before 1999), so it's > no surprise that MSVC has it. But not implementing __func__ does seem a > oversight. I believe they fixed it on MSVC 2015. hmm, okay. as long as we're supporting msvc'03, I'd suggest moving everything to __FUNCTION__, which seems to be the most portable one right now. When, one day, we move up to msvc'15, we can reconsider moving to __func__. > To be clear, GNU C++ is the non-standard one here. MSVC is following > the spec. It's just a ptty that the C and C++ standard bodies don't > strive for consistency. Now I'm getting confused ... C++ standard has __func__, but C doesnt ? >> by the way: what's the exact reason for using msvc instead of gcc on >> win32 ? > > GCC on Win32 (MinGW) is not reliable (lots of known bugs.) But above > all, it's impossible to debug Mingw executables on Windows: one has to > use GDB to debug Mingw DLLs/EXEs because Microsft debuggers don't > understand DWARF debug info, and one has to use Microsof debugger to > debug Microsoft DLLs/EXEs. So it's impossible to debug an app that uses > both, which is always the case if the OpenGL driver is built with GCC. hmm, sure that this is still the case ? (I knowledge on win32 development quite limited - last time I actively did that must be decades ago ...) > But Microsoft has been working on a Clang/LLVM frontend for their > compiler, capable of genering debug info on MS format. So I have hopes > we could one day switch to it. It still in its early infancy though. hmm, what about building w/ clang anyways ? >> can I also deploy it to some VM there and log in via VNC ? > > No, not that I know of. hmm, so I can't actually test the win32 builds :( --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] oldest gcc version to support ?
On 08/04/2016 09:57 AM, Enrico Weigelt, metux IT consult wrote: > Hi folks, > > > which is the oldest gcc version we need to support ? > > I see certain quirks for pre 4.4.5 - my Ubuntu Trusty box > (now over 2 years old) already has 4.8 ... can we remove > that stuff ? > > (anyways, it's just for non-autoconf builds) > > If there aren't too many I would keep them. Regards, Vedran -- Vedran Miletić vedran.miletic.net ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] c99 vs v90
On 04/08/16 11:25, Enrico Weigelt, metux IT consult wrote: On 04.08.2016 11:38, Jose Fonseca wrote: __FUNCTION__ has been around for a very long time (before 1999), so it's no surprise that MSVC has it. But not implementing __func__ does seem a oversight. I believe they fixed it on MSVC 2015. hmm, okay. as long as we're supporting msvc'03, I'd suggest moving everything to __FUNCTION__, which seems to be the most portable one right now. When, one day, we move up to msvc'15, we can reconsider moving to __func__. As I said, #define __func__ __FUNCTION__ neatly solves the problem. To be clear, GNU C++ is the non-standard one here. MSVC is following the spec. It's just a ptty that the C and C++ standard bodies don't strive for consistency. Now I'm getting confused ... C++ standard has __func__, but C doesnt ? No. It's nothing to do with __func__. C++ lacks C99 things like structure initializers. by the way: what's the exact reason for using msvc instead of gcc on win32 ? GCC on Win32 (MinGW) is not reliable (lots of known bugs.) But above all, it's impossible to debug Mingw executables on Windows: one has to use GDB to debug Mingw DLLs/EXEs because Microsft debuggers don't understand DWARF debug info, and one has to use Microsof debugger to debug Microsoft DLLs/EXEs. So it's impossible to debug an app that uses both, which is always the case if the OpenGL driver is built with GCC. hmm, sure that this is still the case ? (I knowledge on win32 development quite limited - last time I actively did that must be decades ago ...) I'm definitely sure. I know there are projects out there hapilly using MinGW. And we use MinGW for development too. But it's not production ready. But Microsoft has been working on a Clang/LLVM frontend for their compiler, capable of genering debug info on MS format. So I have hopes we could one day switch to it. It still in its early infancy though. hmm, what about building w/ clang anyways ? No idea what you're asking. Anyway, I think satisfied your curiosity and provided enough feedback. You'll just gonna have to figure the rest yourself. can I also deploy it to some VM there and log in via VNC ? No, not that I know of. hmm, so I can't actually test the win32 builds :( Just push your experiments into a branch in github, and Appveyor will test it. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3
Hi Andy, Thanks for testing my patches. On Thu, Aug 4, 2016 at 5:23 AM, Andy Furniss wrote: > Nayan Deshmukh wrote: > >> Hi Christian >> >> On Wed, Aug 3, 2016 at 6:16 PM, Christian König >> wrote: >> >> Sorry for the delay I've been on vacation for a week. >>> >>> Good to hear back from you !! >>> >> >> >> Where you able to fix the problem Andy reported? I was able to >>> rather easily reproduce that. >>> >>> I have tested it on my system and my friend's system and it seems >>> to be >>> >> working fine. It would be great if Andy can confirm the same. >> > > I am still seeing some artifacts though not the same as last patches and > un-scaled on first look appears OK but it isn't. > > Does the scaling happen before CSC? I ask as on unscaled which doesn't > show any line/block type artifacts, there are sometimes what look like > gamma shifts. There is also a slight shift in image position vs default > or bicubic. > > The scaling happens after CSC. Just to really confuse me I also managed to get mpv to produce a > different result from mplayer on one particular test, they usually look > the same. I did already correct for their differing behaviors WRT using > 601 and 709 CSC. > > That 's really wierd I haven't tested them on mpv, I was just using mplayer for testing purposes. I will test it with mpv and see how it goes. > Pendulum again just fullscreen this time as you can't really see > anything wrong windowed. > I believe there is some misunderstanding here, I was able to see the artifacts in the video that you sent me previously. But I was not able to replicate them with the pendulum video on my system. Same case this time the pendulum video plays fine this time too. I am attacing a video of it here https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E/view?usp=sharing Regards, Nayan. > > https://drive.google.com/file/d/0BxP5-S1t9VEEcW02VkVYWDdZd1E > /view?usp=sharing > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error
On 04/08/16 13:08, Nicolas Boichat wrote:
On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres
wrote:
On 04/08/16 05:07, Nicolas Boichat wrote:
egl/x11 fixup has already be sent here:
https://patchwork.freedesktop.org/patch/101934/
Compile-tested only (on android only).
I was first thinking of modifying most functions in egl_dri2.c to take in
dri2_egl_display *dri2_dpy instead of _EGLDisplay *disp as parameter, so
we do not need to set disp->DriverData early in the dri_initialize_*
functions.
But there are some functions that do need disp as well:
- dri2_add_config, to call _eglInitConfig (disp->DriverData does not need
to be
set), and to check if extensions are supported.
- dri2_setup_screen (similar reasons)
Ideas to untangle this are welcome. In the mean time, this patch series
should
fix crashes and a piglit test.
Nicolas Boichat (4):
egl/wayland: Set disp->DriverData to NULL on error
egl/surfaceless: Set disp->DriverData to NULL on error
egl/drm: Set disp->DriverData to NULL on error
egl/android: Set dpy->DriverData to NULL on error
This patch series fixes egl_khr_fence_sync for me:
Tested-by: Martin Peres
Thanks!
However, egl-create-context-verify-gl-flavor is still crashing, even with
"egl/dri2: dri2_initialize: Do not reference-count TestOnly display"
applied. The issue is that eglGetProcAddress("glGetString") returns NULL.
That's surprising, Michel said that my patch fixed that issue. Did you
try reverting "9ee683f877 (egl/dri2: Add reference count for
dri2_egl_display)" to confirm that my original patch broke it?
Yes, reverting the patch fixes the issue.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error
On Thu, Aug 4, 2016 at 7:17 PM, Martin Peres
wrote:
>
>
> On 04/08/16 13:08, Nicolas Boichat wrote:
>>
>> On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres
>> wrote:
>>>
>>> On 04/08/16 05:07, Nicolas Boichat wrote:
egl/x11 fixup has already be sent here:
https://patchwork.freedesktop.org/patch/101934/
Compile-tested only (on android only).
I was first thinking of modifying most functions in egl_dri2.c to take
in
dri2_egl_display *dri2_dpy instead of _EGLDisplay *disp as parameter, so
we do not need to set disp->DriverData early in the dri_initialize_*
functions.
But there are some functions that do need disp as well:
- dri2_add_config, to call _eglInitConfig (disp->DriverData does not
need
to be
set), and to check if extensions are supported.
- dri2_setup_screen (similar reasons)
Ideas to untangle this are welcome. In the mean time, this patch series
should
fix crashes and a piglit test.
Nicolas Boichat (4):
egl/wayland: Set disp->DriverData to NULL on error
egl/surfaceless: Set disp->DriverData to NULL on error
egl/drm: Set disp->DriverData to NULL on error
egl/android: Set dpy->DriverData to NULL on error
>>>
>>> This patch series fixes egl_khr_fence_sync for me:
>>> Tested-by: Martin Peres
>>
>>
>> Thanks!
>>
>>> However, egl-create-context-verify-gl-flavor is still crashing, even with
>>> "egl/dri2: dri2_initialize: Do not reference-count TestOnly display"
>>> applied. The issue is that eglGetProcAddress("glGetString") returns NULL.
>>
>>
>> That's surprising, Michel said that my patch fixed that issue. Did you
>> try reverting "9ee683f877 (egl/dri2: Add reference count for
>> dri2_egl_display)" to confirm that my original patch broke it?
>
>
> Yes, reverting the patch fixes the issue.
Ok, let's see how I understand eglGetProcAddress should work in this case:
- eglapi.c:eglGetProcAddress
- egldriver.c:_eglGetDriverProc
- egldriver.c:_eglMatchDriver, dpy->Options.TestOnly = EGL_TRUE
- egldriver.c:_eglMatchAndInitialize
- Calls drv->API.Initialize = egl_dri2.c:dri2_initialize
- Returns EGL_TRUE as TestOnly is true (before "egl/dri2:
dri2_initialize: Do not reference-count TestOnly display", it would
return EGL_FALSE, so eglGetProcAddress would fail)
So I don't really see how 9ee683f877 + "egl/dri2: dri2_initialize: Do
not reference-count TestOnly display" would fail (while reverting
9ee683f877 would work).
Any chance you could help tracing through the code? Or at least enable
debugging output?
Thanks!
Best,
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 97136] [softpipe] piglit egl-create-context-verify-gl-flavor regression
https://bugs.freedesktop.org/show_bug.cgi?id=97136 Nicolas Boichat changed: What|Removed |Added Status|NEW |ASSIGNED CC||drink...@chromium.org --- Comment #1 from Nicolas Boichat --- This patch https://patchwork.freedesktop.org/patch/102770/ should fix it, can you please try it out? Thanks! -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 97136] [softpipe] piglit egl-create-context-verify-gl-flavor regression
https://bugs.freedesktop.org/show_bug.cgi?id=97136 Nicolas Boichat changed: What|Removed |Added CC|nico...@boichat.ch | -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Intel: Please help define the common rectangle primitive type
Hi,
This is my definition so far, which is an intersection of AMD and NV rectangles:
Definition and behavior:
- The rectangle primitive is defined by its first 3 vertices.
- The 4th vertex is derived (extrapolated) during rasterization.
- It's treated as a triangle by all stages before rasterization.
- The rectangle edges must be parallel or perpendicular to X and Y
axes ("axis-aligned), i.e. the rectangle can only be rotated in
90-degree increments and flipped over.
- It must be rasterized as a rectangle (no diagonal tearing allowed,
no artifacts on the diagonal allowed)
The behavior is undefined:
- if the rectangle edges are not axis-aligned.
- if Z coordinates of all 3 vertices are not equal.
- if the rectangle intersects the clip space boundaries. (all options
are allowed: clip, cull, or accept the primitive)
- if clip planes, clip distances, or cull distances are enabled.
- if face culling is enabled. (face determination is undefined)
Likewise, the content of gl_FrontFacing is undefined.
It's possible to implement this on top of GL_NV_fill_rectangle. It's
not possible to implement GL_NV_fill_rectangle on top of this.
What do we need to add to accommodate Intel?
Thanks,
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] radeonsi: move spi_ps_input_addr override outside of the loop
For the series: Reviewed-by: Marek Olšák Marek On Wed, Aug 3, 2016 at 10:56 PM, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > --- > src/gallium/drivers/radeonsi/si_shader.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/src/gallium/drivers/radeonsi/si_shader.c > b/src/gallium/drivers/radeonsi/si_shader.c > index 455f604..64c367e 100644 > --- a/src/gallium/drivers/radeonsi/si_shader.c > +++ b/src/gallium/drivers/radeonsi/si_shader.c > @@ -5990,10 +5990,10 @@ void si_shader_binary_read_config(struct > radeon_shader_binary *binary, > } > break; > } > - > - if (!conf->spi_ps_input_addr) > - conf->spi_ps_input_addr = conf->spi_ps_input_ena; > } > + > + if (!conf->spi_ps_input_addr) > + conf->spi_ps_input_addr = conf->spi_ps_input_ena; > } > > void si_shader_apply_scratch_relocs(struct si_context *sctx, > -- > 2.7.4 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: import prime buffers in the current context, not screen
This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and
fixes many applications when using DRI3:
- Totem with libva on hw-accelerated decoding
- obs-studio, using Window Capture (Xcomposite) as a Source
- gstreamer with VAAPI
Cc: mesa-sta...@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759
Tested-by: Fabrice Bellet
Signed-off-by: Martin Peres
---
I have been testing the patch on my main desktop for a day and did not
encounter any issue with it. This is however quite a corner case and
most people never had this issue anyway.
If this patch is not accepted, then we will need to change the loader's
GetBuffers() method so as it either does not import the buffers or takes
the context as a parameter.
src/mesa/drivers/dri/i965/intel_screen.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index ae51c40..169d578 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -702,8 +702,11 @@ intel_create_image_from_fds(__DRIscreen *screen,
int *fds, int num_fds, int *strides, int *offsets,
void *loaderPrivate)
{
+ GET_CURRENT_CONTEXT(ctx);
struct intel_screen *intelScreen = screen->driverPrivate;
+ struct brw_context *brw = brw_context(ctx);
struct intel_image_format *f;
+ dri_bufmgr *bufmgr;
__DRIimage *image;
int i, index;
@@ -744,8 +747,26 @@ intel_create_image_from_fds(__DRIscreen *screen,
size = end;
}
- image->bo = drm_intel_bo_gem_create_from_prime(intelScreen->bufmgr,
- fds[0], size);
+ /* Let's import the buffer into the current context instead of the current
+* screen as some applications like gstreamer, totem, or obs create multiple
+* X connections which end up creating multiple screens and thus multiple
+* buffer managers. They then proceed to use a different X connection than
+* the one used by the currently-bound context to call GLXBindTexImageExt()
+* which should then import the buffer in the current bound context and not
+* the current screen. This is done properly upstairs for texture management
+* so we need to mirror this behaviour if we don't want the kernel rejecting
+* our pushbuffers as the buffer would not have been imported by the same
+* buffer manager that sent the pushbuffer referencing it.
+*
+* If there is no context currently bound, then revert to using the screen's
+* buffer manager and hope for the best...
+*/
+ if (brw)
+ bufmgr = brw->bufmgr;
+ else
+ bufmgr = intelScreen->bufmgr;
+
+ image->bo = drm_intel_bo_gem_create_from_prime(bufmgr, fds[0], size);
if (image->bo == NULL) {
free(image);
return NULL;
--
2.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Intel: Please help define the common rectangle primitive type
Hey Marek, Thanks for working on this!
On Aug 4, 2016 7:39 AM, "Marek Olšák" wrote:
>
> Hi,
>
> This is my definition so far, which is an intersection of AMD and NV
rectangles:
>
> Definition and behavior:
> - The rectangle primitive is defined by its first 3 vertices.
> - The 4th vertex is derived (extrapolated) during rasterization.
> - It's treated as a triangle by all stages before rasterization.
> - The rectangle edges must be parallel or perpendicular to X and Y
> axes ("axis-aligned), i.e. the rectangle can only be rotated in
> 90-degree increments and flipped over.
> - It must be rasterized as a rectangle (no diagonal tearing allowed,
> no artifacts on the diagonal allowed)
More requirements:
- Must be solid
- No cut index (GS is supposed to be fine and Tess looks OK too)
Our hardware docs *say* that the vertices have to come in a particular
order. That said, I've gotten it wrong without the hardware exploding
before. I think we could write a Piglit test that checks all the orders
and test for it fairly easily.
Also, clipping... The docs say that we can't clip them with the normal
clipper. It also says that we need to disable the viewport which means we
are left with no clipping whatsoever and OOB rectangles may write to random
memory outside the surface. This is bad. Without further experimentation,
I can't say how much of this is true and how much of it is just
recommendation. Given that RECTLIST is intended for internal operations
only, it could be anywhere on that spectrum and may be different on
different hardware. We could, in theory apply the viewport and do clipping
either in a geometry shader or as something we append onto the end of the
VS. A bit ugly, but it would work.
My reading of the docs seems to indicate that it's treated like a TRILIST
all the way through until right before rasterization where it's handled
differently. If true, that may imply that it will work fine and the
failure mode for disobeying the rules is just wonky rectangles. In any
case, *lots* of Piglit tests are in order, especially ones that break or
bend the rules.
> The behavior is undefined:
> - if the rectangle edges are not axis-aligned.
> - if Z coordinates of all 3 vertices are not equal.
> - if the rectangle intersects the clip space boundaries. (all options
> are allowed: clip, cull, or accept the primitive)
> - if clip planes, clip distances, or cull distances are enabled.
> - if face culling is enabled. (face determination is undefined)
> Likewise, the content of gl_FrontFacing is undefined.
>
> It's possible to implement this on top of GL_NV_fill_rectangle. It's
> not possible to implement GL_NV_fill_rectangle on top of this.
>
> What do we need to add to accommodate Intel?
>
> Thanks,
> Marek
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] egl/x11_dri3: disable WL_bind_wayland_display for devices without render nodes
On 20/06/16 12:05, Axel Davy wrote:
Hi,
The three patches make sense to me.
Reviewed-by: Axel Davy
Can someone push these patches for me?
Thanks
Frank
On 17/06/2016 19:41, Frank Binns wrote :
Up until now, DRI3 was only used for devices that have render nodes,
unless
overridden via an environment variable, with it falling back to DRI2
otherwise.
This limitation was there in order to support WL_bind_wayland_display
as it
requires client opened device node fds to be authenticated, which
isn't possible
when using DRI3. This is an unfortunate compromise as DRI3 provides
security
benefits over DRI2.
Instead, allow DRI3 to be used for devices without render nodes but
don't
advertise WL_bind_wayland_display in this case. Applications that
need this
extension can still be run by disabling DRI3 support via the
LIBGL_DRI3_DISABLE
environment variable.
Signed-off-by: Frank Binns
---
src/egl/drivers/dri2/platform_x11.c | 3 ++-
src/egl/drivers/dri2/platform_x11_dri3.c | 33
+---
2 files changed, 7 insertions(+), 29 deletions(-)
diff --git a/src/egl/drivers/dri2/platform_x11.c
b/src/egl/drivers/dri2/platform_x11.c
index c0a4005..1b50889 100644
--- a/src/egl/drivers/dri2/platform_x11.c
+++ b/src/egl/drivers/dri2/platform_x11.c
@@ -1335,7 +1335,8 @@ dri2_initialize_x11_dri3(_EGLDriver *drv,
_EGLDisplay *disp)
disp->Extensions.EXT_buffer_age = EGL_TRUE;
#ifdef HAVE_WAYLAND_PLATFORM
- disp->Extensions.WL_bind_wayland_display = EGL_TRUE;
+ if (dri2_dpy->device_name)
+ disp->Extensions.WL_bind_wayland_display = EGL_TRUE;
#endif
if (dri2_dpy->conn) {
diff --git a/src/egl/drivers/dri2/platform_x11_dri3.c
b/src/egl/drivers/dri2/platform_x11_dri3.c
index 9363a8a..b781987 100644
--- a/src/egl/drivers/dri2/platform_x11_dri3.c
+++ b/src/egl/drivers/dri2/platform_x11_dri3.c
@@ -437,29 +437,6 @@ struct dri2_egl_display_vtbl
dri3_x11_display_vtbl = {
.get_dri_drawable = dri3_get_dri_drawable,
};
-static char *
-dri3_get_device_name(int fd)
-{
- char *ret = NULL;
-
- ret = drmGetRenderDeviceNameFromFd(fd);
- if (ret)
- return ret;
-
- /* For dri3, render node support is required for
WL_bind_wayland_display.
-* In order not to regress on older systems without kernel or libdrm
-* support, fall back to dri2. User can override it with environment
-* variable if they don't need to use that extension.
-*/
- if (getenv("EGL_FORCE_DRI3") == NULL) {
- _eglLog(_EGL_WARNING, "Render node support not available,
falling back to dri2");
- _eglLog(_EGL_WARNING, "If you want to force dri3, set
EGL_FORCE_DRI3 environment variable");
- } else
- ret = loader_get_device_name_for_fd(fd);
-
- return ret;
-}
-
EGLBoolean
dri3_x11_connect(struct dri2_egl_display *dri2_dpy)
{
@@ -539,11 +516,11 @@ dri3_x11_connect(struct dri2_egl_display
*dri2_dpy)
return EGL_FALSE;
}
- dri2_dpy->device_name = dri3_get_device_name(dri2_dpy->fd);
- if (!dri2_dpy->device_name) {
- close(dri2_dpy->fd);
- return EGL_FALSE;
- }
+ /* Only try to get a render device name since it's only needed for
+* WL_bind_wayland_display and dri3 doesn't provide a mechanism for
+* authenticating client opened device node fds. If this fails then
+* don't advertise the extension. */
+ dri2_dpy->device_name = drmGetRenderDeviceNameFromFd(dri2_dpy->fd);
return EGL_TRUE;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] __func__ vs. __FUNCTION__
On Aug 4, 2016 12:46 AM, "Enrico Weigelt, metux IT consult" < enrico.weig...@gr13.net> wrote: > > On 03.08.2016 12:20, Eric Engestrom wrote: > > > BTW, c99_compat.h has a #define for __func__ where needed, so this > > change (removing use of __FUNCTION__) is a good one indeed :) > > Did a few experiments w/ gcc vs msvc. The common denominator is > both define __FUNCTION__, so I moved there and dropped the defines > in c99_compat.h. Can we please move towards the standard and not away from it? MSVC has support for __func__ now at least in C++ in recent versions. They will probably gain it eventually for C as well. > See: https://github.com/metux/mesa/commits/WIP_cleanup > > > --mtx > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH RESEND] loader: fix sysfs uevent file parsing
When trying to get a device name for an fd using sysfs, it would always fail
as it was expecting key/value pairs to be delimited by '\0', which is not the
case.
Signed-off-by: Frank Binns
Reviewed-by: Eric Engestrom
---
src/loader/loader.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/loader/loader.c b/src/loader/loader.c
index 56ffc5d..3e60e4c 100644
--- a/src/loader/loader.c
+++ b/src/loader/loader.c
@@ -645,7 +645,7 @@ sysfs_get_device_name_for_fd(int fd)
unsigned int maj, min;
FILE *f;
char buf[0x40];
- static const char match[9] = "\0DEVNAME=";
+ static const char match[9] = "\nDEVNAME=";
int expected = 1;
if (dev_node_from_fd(fd, &maj, &min) < 0)
@@ -668,8 +668,10 @@ sysfs_get_device_name_for_fd(int fd)
}
strcpy(buf, "/dev/");
- if (fgets(buf + 5, sizeof(buf) - 5, f))
+ if (fgets(buf + 5, sizeof(buf) - 5, f)) {
+ buf[strcspn(buf, "\n")] = '\0';
device_name = strdup(buf);
+ }
fclose(f);
return device_name;
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH RESEND] wayland-drm: add missing NULL check
Although malloc is unlikely to fail check its return value nevertheless. Signed-off-by: Frank Binns Reviewed-by: Eric Engestrom --- src/egl/wayland/wayland-drm/wayland-drm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/egl/wayland/wayland-drm/wayland-drm.c b/src/egl/wayland/wayland-drm/wayland-drm.c index e00d9be..4fc1252 100644 --- a/src/egl/wayland/wayland-drm/wayland-drm.c +++ b/src/egl/wayland/wayland-drm/wayland-drm.c @@ -265,6 +265,8 @@ wayland_drm_init(struct wl_display *display, char *device_name, struct wl_drm *drm; drm = malloc(sizeof *drm); + if (!drm) + return NULL; drm->display = display; drm->device_name = strdup(device_name); -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] __func__ vs. __FUNCTION__
On 08/04/2016 07:56 AM, Jason Ekstrand wrote: On Aug 4, 2016 12:46 AM, "Enrico Weigelt, metux IT consult" mailto:enrico.weig...@gr13.net>> wrote: > > On 03.08.2016 12:20, Eric Engestrom wrote: > > > BTW, c99_compat.h has a #define for __func__ where needed, so this > > change (removing use of __FUNCTION__) is a good one indeed :) > > Did a few experiments w/ gcc vs msvc. The common denominator is > both define __FUNCTION__, so I moved there and dropped the defines > in c99_compat.h. Can we please move towards the standard and not away from it? MSVC has support for __func__ now at least in C++ in recent versions. They will probably gain it eventually for C as well. I second that. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error
On 04/08/16 15:17, Nicolas Boichat wrote:
On Thu, Aug 4, 2016 at 7:17 PM, Martin Peres
wrote:
On 04/08/16 13:08, Nicolas Boichat wrote:
On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres
wrote:
On 04/08/16 05:07, Nicolas Boichat wrote:
egl/x11 fixup has already be sent here:
https://patchwork.freedesktop.org/patch/101934/
Compile-tested only (on android only).
I was first thinking of modifying most functions in egl_dri2.c to take
in
dri2_egl_display *dri2_dpy instead of _EGLDisplay *disp as parameter, so
we do not need to set disp->DriverData early in the dri_initialize_*
functions.
But there are some functions that do need disp as well:
- dri2_add_config, to call _eglInitConfig (disp->DriverData does not
need
to be
set), and to check if extensions are supported.
- dri2_setup_screen (similar reasons)
Ideas to untangle this are welcome. In the mean time, this patch series
should
fix crashes and a piglit test.
Nicolas Boichat (4):
egl/wayland: Set disp->DriverData to NULL on error
egl/surfaceless: Set disp->DriverData to NULL on error
egl/drm: Set disp->DriverData to NULL on error
egl/android: Set dpy->DriverData to NULL on error
This patch series fixes egl_khr_fence_sync for me:
Tested-by: Martin Peres
Thanks!
However, egl-create-context-verify-gl-flavor is still crashing, even with
"egl/dri2: dri2_initialize: Do not reference-count TestOnly display"
applied. The issue is that eglGetProcAddress("glGetString") returns NULL.
That's surprising, Michel said that my patch fixed that issue. Did you
try reverting "9ee683f877 (egl/dri2: Add reference count for
dri2_egl_display)" to confirm that my original patch broke it?
Yes, reverting the patch fixes the issue.
Ok, let's see how I understand eglGetProcAddress should work in this case:
- eglapi.c:eglGetProcAddress
- egldriver.c:_eglGetDriverProc
- egldriver.c:_eglMatchDriver, dpy->Options.TestOnly = EGL_TRUE
- egldriver.c:_eglMatchAndInitialize
- Calls drv->API.Initialize = egl_dri2.c:dri2_initialize
- Returns EGL_TRUE as TestOnly is true (before "egl/dri2:
dri2_initialize: Do not reference-count TestOnly display", it would
return EGL_FALSE, so eglGetProcAddress would fail)
So I don't really see how 9ee683f877 + "egl/dri2: dri2_initialize: Do
not reference-count TestOnly display" would fail (while reverting
9ee683f877 would work).
Any chance you could help tracing through the code? Or at least enable
debugging output?
Sorry for the noise, a make clean fixed the issue :s
I can confirm that "egl/dri2: dri2_initialize: Do not reference-count
TestOnly display" fixes the issue, you can add my Tested-by!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] egl/*: Set disp->DriverData to NULL on error
On Thu, Aug 4, 2016 at 10:43 PM, Martin Peres
wrote:
>
>
> On 04/08/16 15:17, Nicolas Boichat wrote:
>>
>> On Thu, Aug 4, 2016 at 7:17 PM, Martin Peres
>> wrote:
>>>
>>>
>>>
>>> On 04/08/16 13:08, Nicolas Boichat wrote:
On Thu, Aug 4, 2016 at 5:52 PM, Martin Peres
wrote:
>
>
> On 04/08/16 05:07, Nicolas Boichat wrote:
>>
>>
>>
>> egl/x11 fixup has already be sent here:
>> https://patchwork.freedesktop.org/patch/101934/
>>
>> Compile-tested only (on android only).
>>
>> I was first thinking of modifying most functions in egl_dri2.c to take
>> in
>> dri2_egl_display *dri2_dpy instead of _EGLDisplay *disp as parameter,
>> so
>> we do not need to set disp->DriverData early in the dri_initialize_*
>> functions.
>>
>> But there are some functions that do need disp as well:
>> - dri2_add_config, to call _eglInitConfig (disp->DriverData does not
>> need
>> to be
>>set), and to check if extensions are supported.
>> - dri2_setup_screen (similar reasons)
>>
>> Ideas to untangle this are welcome. In the mean time, this patch
>> series
>> should
>> fix crashes and a piglit test.
>>
>> Nicolas Boichat (4):
>> egl/wayland: Set disp->DriverData to NULL on error
>> egl/surfaceless: Set disp->DriverData to NULL on error
>> egl/drm: Set disp->DriverData to NULL on error
>> egl/android: Set dpy->DriverData to NULL on error
>>
>
> This patch series fixes egl_khr_fence_sync for me:
> Tested-by: Martin Peres
Thanks!
> However, egl-create-context-verify-gl-flavor is still crashing, even
> with
> "egl/dri2: dri2_initialize: Do not reference-count TestOnly display"
> applied. The issue is that eglGetProcAddress("glGetString") returns
> NULL.
That's surprising, Michel said that my patch fixed that issue. Did you
try reverting "9ee683f877 (egl/dri2: Add reference count for
dri2_egl_display)" to confirm that my original patch broke it?
>>>
>>>
>>>
>>> Yes, reverting the patch fixes the issue.
>>
>>
>> Ok, let's see how I understand eglGetProcAddress should work in this case:
>> - eglapi.c:eglGetProcAddress
>> - egldriver.c:_eglGetDriverProc
>> - egldriver.c:_eglMatchDriver, dpy->Options.TestOnly = EGL_TRUE
>> - egldriver.c:_eglMatchAndInitialize
>> - Calls drv->API.Initialize = egl_dri2.c:dri2_initialize
>> - Returns EGL_TRUE as TestOnly is true (before "egl/dri2:
>> dri2_initialize: Do not reference-count TestOnly display", it would
>> return EGL_FALSE, so eglGetProcAddress would fail)
>>
>> So I don't really see how 9ee683f877 + "egl/dri2: dri2_initialize: Do
>> not reference-count TestOnly display" would fail (while reverting
>> 9ee683f877 would work).
>>
>> Any chance you could help tracing through the code? Or at least enable
>> debugging output?
>
>
> Sorry for the noise, a make clean fixed the issue :s
>
> I can confirm that "egl/dri2: dri2_initialize: Do not reference-count
> TestOnly display" fixes the issue, you can add my Tested-by!
Great! Thanks Martin.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] oldest gcc version to support ?
On Aug 4, 2016 2:57 AM, "Enrico Weigelt, metux IT consult" < enrico.weig...@gr13.net> wrote: > > Hi folks, > > > which is the oldest gcc version we need to support ? > > I see certain quirks for pre 4.4.5 - my Ubuntu Trusty box > (now over 2 years old) already has 4.8 ... can we remove > that stuff ? The BSDs are still stuck at 4.2+patches for licensing reasons and they use Mesa for graphics. I think at some point, they'll get clang in core and they can start building with that. There are ancient RHEL versions where the GCC version is so old that they build a newer GCC just so they can build Mesa. One of these days, we'll move past GCC 4.2 but for now it's not too much of a burden to keep it working. --Jason > (anyways, it's just for non-autoconf builds) > > > --mtx > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3
Nayan Deshmukh wrote: Hi Andy, Thanks for testing my patches. NP The scaling happens after CSC. OK, thanks. I believe there is some misunderstanding here, I was able to see the artifacts in the video that you sent me previously. But I was not able to replicate them Yea, I got that - just thought you may want to see how they had changed. with the pendulum video on my system. Same case this time the pendulum video plays fine this time too. I am attacing a video of it here https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E/view?usp=sharing Hmm, that's interesting for a few reasons. Though my monitor won't do 1366x768 I can replicate the same scale factor windowed with mplayer ... -xy 768/576 ... At first glance only level 2 is obviously artifacted (though very close inspection shows others are slightly). Levels: for some reason your vid has the black bars at 0 but the content isn't scaled - like your mplayer didn't expand tv to pc on playback. This shouldn't happen by default. Do you have some extra config somewhere like in $HOME/.mplayer, if so maybe better to test without. Most important - though the vp9 compression may be to blame I can't really see any difference between the levels in that vid. In fact closely comparing just your level 1 to my (admittedly uncompressed) level 1 and 0 output scaled the same plus unstretched levels wise it looks to me like you are getting level 0 on this test. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Intel: Please help define the common rectangle primitive type
On Thu, Aug 4, 2016 at 3:31 PM, Jason Ekstrand wrote:
> Hey Marek, Thanks for working on this!
>
> On Aug 4, 2016 7:39 AM, "Marek Olšák" wrote:
>>
>> Hi,
>>
>> This is my definition so far, which is an intersection of AMD and NV
>> rectangles:
>>
>> Definition and behavior:
>> - The rectangle primitive is defined by its first 3 vertices.
>> - The 4th vertex is derived (extrapolated) during rasterization.
>> - It's treated as a triangle by all stages before rasterization.
>> - The rectangle edges must be parallel or perpendicular to X and Y
>> axes ("axis-aligned), i.e. the rectangle can only be rotated in
>> 90-degree increments and flipped over.
>> - It must be rasterized as a rectangle (no diagonal tearing allowed,
>> no artifacts on the diagonal allowed)
>
> More requirements:
> - Must be solid
I take it you mean the polygon mode.
> - No cut index (GS is supposed to be fine and Tess looks OK too)
I'd be OK with dropping GS and Tess support for rectangles.
>
> Our hardware docs *say* that the vertices have to come in a particular
> order. That said, I've gotten it wrong without the hardware exploding
> before. I think we could write a Piglit test that checks all the orders and
> test for it fairly easily.
This is the most tricky one. I'd need a clear definition of what "a
particular order" means. The rasterization order is different between
windows and FBOs.
>
> Also, clipping... The docs say that we can't clip them with the normal
> clipper. It also says that we need to disable the viewport which means we
> are left with no clipping whatsoever and OOB rectangles may write to random
> memory outside the surface. This is bad. Without further experimentation,
> I can't say how much of this is true and how much of it is just
> recommendation. Given that RECTLIST is intended for internal operations
> only, it could be anywhere on that spectrum and may be different on
> different hardware. We could, in theory apply the viewport and do clipping
> either in a geometry shader or as something we append onto the end of the
> VS. A bit ugly, but it would work.
I declared clipping as undefined, including frustum clipping. That
means all vertices must be inside the viewport and all user clipping
must be disabled.
If your driver uses guard bands (which skips clipping), it probably
also uses a scissor test of some kind to cull pixels out of viewport
bounds.
It's not clear yet whether or not this information gathering will be any useful.
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: import prime buffers in the current context, not screen
Martin Peres writes: > This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and > fixes many applications when using DRI3: > - Totem with libva on hw-accelerated decoding > - obs-studio, using Window Capture (Xcomposite) as a Source > - gstreamer with VAAPI > > Cc: mesa-sta...@lists.freedesktop.org > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759 > Tested-by: Fabrice Bellet > Signed-off-by: Martin Peres > --- > > I have been testing the patch on my main desktop for a day and did not > encounter any issue with it. This is however quite a corner case and > most people never had this issue anyway. > > If this patch is not accepted, then we will need to change the loader's > GetBuffers() method so as it either does not import the buffers or takes > the context as a parameter. Not sure if you've seen, but the gallium drivers are doing an fstat on the DRM fd, hashing the st_dev/st_ino/st_rdev, and reusing an existing screen when it matches. This might be really useful for Intel, too. signature.asc Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Question about tesselation shader out varyings and transform feedback
Hi,
these days I have been trying to fix a test that uses transform feedback
on the out varying of a tessellation shader. The relevant part on that
shader is like this:
layout (vertices=4) out;
out block { vec4 value; } user_out[];
The test tries to use block.value as the varying name when calling
glTransformFeedbackVaryings, in order to get the data of the 4 vertices.
The test fails because on link time, it doesn't find that varying name.
On mesa, when linked, mesa tfeedback_candidate_generator (at
src/compiler/glsl/link_varyings) adds to the hashmap of possible
varyings for transform feedback the following names: block[0].value,
block[1].value, block[2].value, block[3].value. If I change the test to
use those 4 varyings names, instead of try to get the array directly,
the test passes.
So now is the moment to justify who is wrong per-spec, if mesa or the
test. At this moment Im biased to conclude that the test is wrong. But
after reading transform feedback specs (ext, feedback2, feedback3, gl44)
and tessellation shader, I was not able to find anything.
Could someone (I bet that the best person is Timothy Arceri) guide me a
little to know in which part of the spec should I look for?
Thanks in advance.
BR
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: fix active attribs with atifragshader
On 07/14/2016 10:43 PM, Miklós Máté wrote:
On 07/07/2016 07:11 PM, Miklós Máté wrote:
On 06/26/2016 09:48 PM, Miklós Máté wrote:
Only include the ones that can be used by the shader.
This fixes texture coordinates, which were completely wrong,
because WPOS was included in the list of attribs. It also
increases performance noticeably.
Signed-off-by: Miklós Máté
---
src/mesa/swrast/s_context.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/swrast/s_context.c b/src/mesa/swrast/s_context.c
index 0a5fc7e..a63179c 100644
--- a/src/mesa/swrast/s_context.c
+++ b/src/mesa/swrast/s_context.c
@@ -504,7 +504,8 @@ _swrast_update_active_attribs(struct gl_context
*ctx)
attribsMask &= ~VARYING_BIT_POS; /* WPOS is always handled
specially */
}
else if (ctx->ATIFragmentShader._Enabled) {
- attribsMask = ~0; /* XXX fix me */
+ attribsMask = VARYING_BIT_COL0 | VARYING_BIT_COL1 |
+VARYING_BIT_FOGC | VARYING_BITS_TEX_ANY;
}
else {
/* fixed function */
ping?
ping?
Can anyone please review this?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swrast: fix active attribs with atifragshader
On 08/04/2016 10:40 AM, Miklós Máté wrote:
On 07/14/2016 10:43 PM, Miklós Máté wrote:
On 07/07/2016 07:11 PM, Miklós Máté wrote:
On 06/26/2016 09:48 PM, Miklós Máté wrote:
Only include the ones that can be used by the shader.
This fixes texture coordinates, which were completely wrong,
because WPOS was included in the list of attribs. It also
increases performance noticeably.
Signed-off-by: Miklós Máté
---
src/mesa/swrast/s_context.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/mesa/swrast/s_context.c b/src/mesa/swrast/s_context.c
index 0a5fc7e..a63179c 100644
--- a/src/mesa/swrast/s_context.c
+++ b/src/mesa/swrast/s_context.c
@@ -504,7 +504,8 @@ _swrast_update_active_attribs(struct gl_context
*ctx)
attribsMask &= ~VARYING_BIT_POS; /* WPOS is always handled
specially */
}
else if (ctx->ATIFragmentShader._Enabled) {
- attribsMask = ~0; /* XXX fix me */
+ attribsMask = VARYING_BIT_COL0 | VARYING_BIT_COL1 |
+VARYING_BIT_FOGC | VARYING_BITS_TEX_ANY;
}
else {
/* fixed function */
ping?
ping?
Can anyone please review this?
I think few people know swrast and this particular extension.
Looks OK to me though.
Reviewed-by: Brian Paul
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] vl: add a lanczos interpolation filter v3
Hi Andy, On Thu, Aug 4, 2016 at 8:48 PM, Andy Furniss wrote: > Nayan Deshmukh wrote: > >> Hi Andy, >> >> Thanks for testing my patches. >> > > NP > > > The scaling happens after CSC. >>> >> > OK, thanks. > > > I believe there is some misunderstanding here, I was able to see the >> artifacts in the video that you sent me previously. But I was not >> able to replicate them >> > > Yea, I got that - just thought you may want to see how they had changed. > > with the pendulum video on my system. Same case this time the >> pendulum video plays fine this time too. I am attacing a video of it >> here >> >> https://drive.google.com/file/d/0B1s62k5GtdBwOVAtOUVaU0V5c1E >> /view?usp=sharing >> > > Hmm, that's interesting for a few reasons. > > Though my monitor won't do 1366x768 I can replicate the same scale > factor windowed with mplayer ... -xy 768/576 ... > > At first glance only level 2 is obviously artifacted (though very close > inspection shows others are slightly). > > Levels: for some reason your vid has the black bars at 0 but the content > isn't scaled - like your mplayer didn't expand tv to pc on playback. > This shouldn't happen by default. Do you have some extra config > somewhere like in $HOME/.mplayer, if so maybe better to test without. > > Most important - though the vp9 compression may be to blame I can't > really see any difference between the levels in that vid. > > In fact closely comparing just your level 1 to my (admittedly > uncompressed) level 1 and 0 output scaled the same plus unstretched > levels wise it looks to me like you are getting level 0 on this test. > You are right it I am getting level 0 only. I have a PRIME configuration and I forgot to set DRI_PRIME to 1. But for some reason, I am not able to create a screen recording when I use my AMD card. So, for now, I can't reproduce the artifacts you are having so can't debug them too :( Regards, Nayan. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 3/4] gallium/winsys/kms: Move display target handle lookup to separate function (v2)
On 2016-08-02 03:46:27, Tomasz Figa wrote:
> As a preparation to use the lookup in more than once place, move the
> code that looks up given KMS/GEM handle to a separate function. This
> change should not introduce any functional changes.
>
> v2: Split into separate patch.
> Move lookup code into separate function.
>
> Signed-off-by: Tomasz Figa
> CC:
> ---
> src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 33
> ---
> 1 file changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> index 65dbf70..cb02b22 100644
> --- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> +++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c
> @@ -211,6 +211,26 @@ kms_sw_displaytarget_map(struct sw_winsys *ws,
> }
>
> static struct kms_sw_displaytarget *
> +kms_sw_displaytarget_lookup(struct kms_sw_winsys *kms_sw,
> +unsigned int kms_handle)
I don't think the 'lookup' name is appropriate, since it has the
ref-count side effect. Instead of 'lookup', how about import, or
find_and_import or something similar?
With that fixed,
Series Reviewed-by: Jordan Justen
> +{
> + struct kms_sw_displaytarget *kms_sw_dt;
> +
> + LIST_FOR_EACH_ENTRY(kms_sw_dt, &kms_sw->bo_list, link) {
> + if (kms_sw_dt->handle == kms_handle) {
> + kms_sw_dt->ref_count++;
> +
> + DEBUG_PRINT("KMS-DEBUG: imported buffer %u (size %u)\n",
> + kms_sw_dt->handle, kms_sw_dt->size);
> +
> + return kms_sw_dt;
> + }
> + }
> +
> + return NULL;
> +}
> +
> +static struct kms_sw_displaytarget *
> kms_sw_displaytarget_add_from_prime(struct kms_sw_winsys *kms_sw, int fd,
> unsigned width, unsigned height,
> unsigned stride)
> @@ -287,15 +307,10 @@ kms_sw_displaytarget_from_handle(struct sw_winsys *ws,
> *stride = kms_sw_dt->stride;
>return (struct sw_displaytarget *)kms_sw_dt;
> case DRM_API_HANDLE_TYPE_KMS:
> - LIST_FOR_EACH_ENTRY(kms_sw_dt, &kms_sw->bo_list, link) {
> - if (kms_sw_dt->handle == whandle->handle) {
> -kms_sw_dt->ref_count++;
> -
> -DEBUG_PRINT("KMS-DEBUG: imported buffer %u (size %u)\n",
> kms_sw_dt->handle, kms_sw_dt->size);
> -
> -*stride = kms_sw_dt->stride;
> -return (struct sw_displaytarget *)kms_sw_dt;
> - }
> + kms_sw_dt = kms_sw_displaytarget_lookup(kms_sw, whandle->handle);
> + if (kms_sw_dt) {
> + *stride = kms_sw_dt->stride;
> + return (struct sw_displaytarget *)kms_sw_dt;
>}
>/* fallthrough */
> default:
> --
> 2.8.0.rc3.226.g39d4020
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] freedreno/a2xx: fix comparison out of range warnings
Hi Eric,
after your question:
[snip]
I expect, with enums having varying size, that this cast will
not always work.
[snip]
I started a script for testing with variable enum sizes and compilers...
If does makes sense to you, I'll try to loop from 1 to n (suggestions?) and
build with gcc and clang (and others?) to find the case you're taking about.
I'm also thinking about a negative test...
What do you think?
Cheers,
Francesco
2016-08-01 14:10 GMT+02:00 Eric Engestrom :
> On Sat, Jul 30, 2016 at 09:49:57AM +0200, Francesco Ansanelli wrote:
> > Signed-off-by: Francesco Ansanelli
> > ---
> > src/gallium/drivers/freedreno/a2xx/fd2_screen.c |8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/gallium/drivers/freedreno/a2xx/fd2_screen.c
> b/src/gallium/drivers/freedreno/a2xx/fd2_screen.c
> > index fe4849b..007b9e6 100644
> > --- a/src/gallium/drivers/freedreno/a2xx/fd2_screen.c
> > +++ b/src/gallium/drivers/freedreno/a2xx/fd2_screen.c
> > @@ -61,7 +61,7 @@ fd2_screen_is_format_supported(struct pipe_screen
> *pscreen,
> >
> > if ((usage & (PIPE_BIND_SAMPLER_VIEW |
> > PIPE_BIND_VERTEX_BUFFER)) &&
> > - (fd2_pipe2surface(format) != ~0u)) {
> > + (fd2_pipe2surface(format) != (enum
> a2xx_sq_surfaceformat)~0)) {
>
> You said the compiler warning goes away, but is the condition guaranteed
> to hit? I expect, with enums having varying size, that this cast will
> not always work. I agree with Rob Herring, adding the error value to the
> enum is better.
>
> > retval |= usage & (PIPE_BIND_SAMPLER_VIEW |
> > PIPE_BIND_VERTEX_BUFFER);
> > }
> > @@ -70,7 +70,7 @@ fd2_screen_is_format_supported(struct pipe_screen
> *pscreen,
> > PIPE_BIND_DISPLAY_TARGET |
> > PIPE_BIND_SCANOUT |
> > PIPE_BIND_SHARED)) &&
> > - (fd2_pipe2color(format) != ~0u)) {
> > + (fd2_pipe2color(format) != (enum
> a2xx_colorformatx)~0)) {
> > retval |= usage & (PIPE_BIND_RENDER_TARGET |
> > PIPE_BIND_DISPLAY_TARGET |
> > PIPE_BIND_SCANOUT |
> > @@ -78,12 +78,12 @@ fd2_screen_is_format_supported(struct pipe_screen
> *pscreen,
> > }
> >
> > if ((usage & PIPE_BIND_DEPTH_STENCIL) &&
> > - (fd_pipe2depth(format) != ~0u)) {
> > + (fd_pipe2depth(format) != (enum
> adreno_rb_depth_format)~0)) {
> > retval |= PIPE_BIND_DEPTH_STENCIL;
> > }
> >
> > if ((usage & PIPE_BIND_INDEX_BUFFER) &&
> > - (fd_pipe2index(format) != ~0u)) {
> > + (fd_pipe2index(format) != (enum
> pc_di_index_size)~0)) {
> > retval |= PIPE_BIND_INDEX_BUFFER;
> > }
> >
> > --
> > 1.7.9.5
> >
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
from subprocess import call
def main():
lastEnum = 1
compiler = 'clang'
out_file = open("gen.c","w")
out_file.write('#include \n\n')
out_file.write('enum E\n')
out_file.write('{\n')
for enum in range(0, lastEnum):
out_file.write(' e{enum}'.format(enum=enum))
if enum + 1 != lastEnum:
out_file.write(',')
out_file.write('\n')
out_file.write('};\n\n')
out_file.write('enum E\n')
out_file.write('test()\n')
out_file.write('{\n')
out_file.write(' return ~0;\n')
out_file.write('}\n\n')
out_file.write('int\n')
out_file.write('main()\n')
out_file.write('{\n')
out_file.write(' if (test() == (enum E)~0)\n')
out_file.write('printf("Success\\n");\n')
out_file.write(' else\n')
out_file.write('printf("Error\\n");\n\n')
out_file.write(' return 0;\n')
out_file.write('}\n')
out_file.close()
call(["cat", "gen.c"]);
call([compiler, "-Wall", "-Wextra", "gen.c", "-o", "genc"]);
call(["./genc"]);
if __name__ == '__main__':
main()
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture
From: Marek Olšák Some ideas copied from Jakob Sinclair's implementation, but the color clearing is completely different. --- docs/GL3.txt | 2 +- docs/relnotes/12.1.0.html | 1 + src/gallium/drivers/r600/r600_pipe.c | 2 +- src/gallium/drivers/radeon/r600_texture.c | 69 +++ src/gallium/drivers/radeonsi/si_pipe.c| 2 +- 5 files changed, 73 insertions(+), 3 deletions(-) diff --git a/docs/GL3.txt b/docs/GL3.txt index c185c69..5dcfc31 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -185,21 +185,21 @@ GL 4.3, GLSL 4.30 -- all DONE: nvc0, radeonsi GL_ARB_texture_query_levels DONE (all drivers that support GLSL 1.30) GL_ARB_texture_storage_multisampleDONE (all drivers that support GL_ARB_texture_multisample) GL_ARB_texture_view DONE (i965, nv50, r600, llvmpipe, softpipe, swr) GL_ARB_vertex_attrib_binding DONE (all drivers) GL 4.4, GLSL 4.40: GL_MAX_VERTEX_ATTRIB_STRIDE DONE (all drivers) GL_ARB_buffer_storage DONE (i965, nv50, nvc0, r600, radeonsi) - GL_ARB_clear_texture DONE (i965, nv50, nvc0) + GL_ARB_clear_texture DONE (i965, nv50, nvc0, r600, radeonsi) GL_ARB_enhanced_layouts DONE (i965) - compile-time constant expressions DONE - explicit byte offsets for blocksDONE - forced alignment within blocks DONE - specified vec4-slot component numbers DONE (i965) - specified transform/feedback layout DONE - input/output block locationsDONE GL_ARB_multi_bind DONE (all drivers) GL_ARB_query_buffer_objectDONE (i965/hsw+, nvc0) GL_ARB_texture_mirror_clamp_to_edge DONE (i965, nv50, nvc0, r600, radeonsi, llvmpipe, softpipe, swr) diff --git a/docs/relnotes/12.1.0.html b/docs/relnotes/12.1.0.html index 3935bb0..ed98d13 100644 --- a/docs/relnotes/12.1.0.html +++ b/docs/relnotes/12.1.0.html @@ -37,20 +37,21 @@ TBD. New features Note: some of the new features are only available with certain drivers. +GL_ARB_clear_texture on r600, radeonsi GL_ARB_enhanced_layouts on i965 GL_ARB_shader_group_vote on nvc0 GL_ARB_ES3_1_compatibility on i965 GL_EXT_window_rectangles on nv50, nvc0 GL_KHR_texture_compression_astc_sliced_3d on i965 Bug fixes TBD. diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c index 39a310a..5f69a5d 100644 --- a/src/gallium/drivers/r600/r600_pipe.c +++ b/src/gallium/drivers/r600/r600_pipe.c @@ -276,20 +276,21 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: case PIPE_CAP_TEXTURE_FLOAT_LINEAR: case PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR: case PIPE_CAP_TGSI_TXQS: case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS: case PIPE_CAP_INVALIDATE_BUFFER: case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS: case PIPE_CAP_QUERY_MEMORY_INFO: case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT: case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: + case PIPE_CAP_CLEAR_TEXTURE: return 1; case PIPE_CAP_DEVICE_RESET_STATUS_QUERY: return rscreen->b.info.drm_major == 2 && rscreen->b.info.drm_minor >= 43; case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: return !R600_BIG_ENDIAN && rscreen->b.info.has_userptr; case PIPE_CAP_COMPUTE: return rscreen->b.chip_class > R700; @@ -348,21 +349,20 @@ static int r600_get_param(struct pipe_screen* pscreen, enum pipe_cap param) case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER: case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS: case PIPE_CAP_FRAGMENT_COLOR_CLAMPED: case PIPE_CAP_VERTEX_COLOR_CLAMPED: case PIPE_CAP_USER_VERTEX_BUFFERS: case PIPE_CAP_TEXTURE_GATHER_OFFSETS: case PIPE_CAP_VERTEXID_NOBASE: case PIPE_CAP_DEPTH_BOUNDS_TEST: case PIPE_CAP_FORCE_PERSAMPLE_INTERP: case PIPE_CAP_SHAREABLE_SHADERS: - case PIPE_CAP_CLEAR_TEXTURE: case PIPE_CAP_DRAW_PARAMETERS: case PIPE_CAP_TGSI_PACK_HALF_FLOAT: case PIPE_CAP_MULTI_DRAW_INDIRECT: case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS: case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL: case PIPE_CAP_TGSI_FS_FACE_IS_INTEGER_SYSVAL: case PIPE_CAP_SHADER_BUFFER_OFFSET_ALIGNMENT: case PIPE_CAP_GENERATE_MIPMAP: case PIPE_CAP_STRING_MARKER: case PIPE_CAP_QUERY_BUFFER_OBJECT: diff --git a/src/gallium/drivers/radeon/r600_texture.c b/src/gallium
Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture
On Thu, Aug 4, 2016 at 7:56 PM, Marek Olšák wrote: > From: Marek Olšák > > Some ideas copied from Jakob Sinclair's implementation, but the color > clearing is completely different. > --- > docs/GL3.txt | 2 +- > docs/relnotes/12.1.0.html | 1 + > src/gallium/drivers/r600/r600_pipe.c | 2 +- > src/gallium/drivers/radeon/r600_texture.c | 69 > +++ > src/gallium/drivers/radeonsi/si_pipe.c| 2 +- > 5 files changed, 73 insertions(+), 3 deletions(-) > > diff --git a/docs/GL3.txt b/docs/GL3.txt > index c185c69..5dcfc31 100644 > --- a/docs/GL3.txt > +++ b/docs/GL3.txt > @@ -185,21 +185,21 @@ GL 4.3, GLSL 4.30 -- all DONE: nvc0, radeonsi >GL_ARB_texture_query_levels DONE (all drivers > that support GLSL 1.30) >GL_ARB_texture_storage_multisampleDONE (all drivers > that support GL_ARB_texture_multisample) >GL_ARB_texture_view DONE (i965, nv50, > r600, llvmpipe, softpipe, swr) >GL_ARB_vertex_attrib_binding DONE (all drivers) > > > GL 4.4, GLSL 4.40: > >GL_MAX_VERTEX_ATTRIB_STRIDE DONE (all drivers) >GL_ARB_buffer_storage DONE (i965, nv50, > nvc0, r600, radeonsi) > - GL_ARB_clear_texture DONE (i965, nv50, > nvc0) > + GL_ARB_clear_texture DONE (i965, nv50, > nvc0, r600, radeonsi) >GL_ARB_enhanced_layouts DONE (i965) >- compile-time constant expressions DONE >- explicit byte offsets for blocksDONE >- forced alignment within blocks DONE >- specified vec4-slot component numbers DONE (i965) >- specified transform/feedback layout DONE >- input/output block locationsDONE >GL_ARB_multi_bind DONE (all drivers) >GL_ARB_query_buffer_objectDONE (i965/hsw+, > nvc0) >GL_ARB_texture_mirror_clamp_to_edge DONE (i965, nv50, > nvc0, r600, radeonsi, llvmpipe, softpipe, swr) > diff --git a/docs/relnotes/12.1.0.html b/docs/relnotes/12.1.0.html > index 3935bb0..ed98d13 100644 > --- a/docs/relnotes/12.1.0.html > +++ b/docs/relnotes/12.1.0.html > @@ -37,20 +37,21 @@ TBD. > > > > New features > > > Note: some of the new features are only available with certain drivers. > > > > +GL_ARB_clear_texture on r600, radeonsi > GL_ARB_enhanced_layouts on i965 > GL_ARB_shader_group_vote on nvc0 > GL_ARB_ES3_1_compatibility on i965 > GL_EXT_window_rectangles on nv50, nvc0 > GL_KHR_texture_compression_astc_sliced_3d on i965 > > > Bug fixes > > TBD. > diff --git a/src/gallium/drivers/r600/r600_pipe.c > b/src/gallium/drivers/r600/r600_pipe.c > index 39a310a..5f69a5d 100644 > --- a/src/gallium/drivers/r600/r600_pipe.c > +++ b/src/gallium/drivers/r600/r600_pipe.c > @@ -276,20 +276,21 @@ static int r600_get_param(struct pipe_screen* pscreen, > enum pipe_cap param) > case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: > case PIPE_CAP_TEXTURE_FLOAT_LINEAR: > case PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR: > case PIPE_CAP_TGSI_TXQS: > case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS: > case PIPE_CAP_INVALIDATE_BUFFER: > case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS: > case PIPE_CAP_QUERY_MEMORY_INFO: > case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT: > case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: > + case PIPE_CAP_CLEAR_TEXTURE: > return 1; > > case PIPE_CAP_DEVICE_RESET_STATUS_QUERY: > return rscreen->b.info.drm_major == 2 && > rscreen->b.info.drm_minor >= 43; > > case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: > return !R600_BIG_ENDIAN && rscreen->b.info.has_userptr; > > case PIPE_CAP_COMPUTE: > return rscreen->b.chip_class > R700; > @@ -348,21 +349,20 @@ static int r600_get_param(struct pipe_screen* pscreen, > enum pipe_cap param) > case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER: > case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS: > case PIPE_CAP_FRAGMENT_COLOR_CLAMPED: > case PIPE_CAP_VERTEX_COLOR_CLAMPED: > case PIPE_CAP_USER_VERTEX_BUFFERS: > case PIPE_CAP_TEXTURE_GATHER_OFFSETS: > case PIPE_CAP_VERTEXID_NOBASE: > case PIPE_CAP_DEPTH_BOUNDS_TEST: > case PIPE_CAP_FORCE_PERSAMPLE_INTERP: > case PIPE_CAP_SHAREABLE_SHADERS: > - case PIPE_CAP_CLEAR_TEXTURE: > case PIPE_CAP_DRAW_PARAMETERS: > case PIPE_CAP_TGSI_PACK_HALF_FLOAT: > case PIPE_CAP_MULTI_DRAW_INDIRECT: > case PIPE_CAP_MULTI_DRAW_INDIRECT_PARAMS: > case PIPE_CAP_TGSI_FS_POSITION_IS_SYSVAL: > case PIPE_CAP_T
Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture
I believe that clear depth stencil is meant to respect the render condition, while clear texture is not. In nouveau I "solved" this by ignoring the render condition in the clear depth stencil function too, since nothing in Mesa relied on it iirc. On Aug 4, 2016 12:57, "Marek Olšák" wrote: > From: Marek Olšák > > Some ideas copied from Jakob Sinclair's implementation, but the color > clearing is completely different. > --- > docs/GL3.txt | 2 +- > docs/relnotes/12.1.0.html | 1 + > src/gallium/drivers/r600/r600_pipe.c | 2 +- > src/gallium/drivers/radeon/r600_texture.c | 69 > +++ > src/gallium/drivers/radeonsi/si_pipe.c| 2 +- > 5 files changed, 73 insertions(+), 3 deletions(-) > > diff --git a/docs/GL3.txt b/docs/GL3.txt > index c185c69..5dcfc31 100644 > --- a/docs/GL3.txt > +++ b/docs/GL3.txt > @@ -185,21 +185,21 @@ GL 4.3, GLSL 4.30 -- all DONE: nvc0, radeonsi >GL_ARB_texture_query_levels DONE (all drivers > that support GLSL 1.30) >GL_ARB_texture_storage_multisampleDONE (all drivers > that support GL_ARB_texture_multisample) >GL_ARB_texture_view DONE (i965, nv50, > r600, llvmpipe, softpipe, swr) >GL_ARB_vertex_attrib_binding DONE (all drivers) > > > GL 4.4, GLSL 4.40: > >GL_MAX_VERTEX_ATTRIB_STRIDE DONE (all drivers) >GL_ARB_buffer_storage DONE (i965, nv50, > nvc0, r600, radeonsi) > - GL_ARB_clear_texture DONE (i965, nv50, > nvc0) > + GL_ARB_clear_texture DONE (i965, nv50, > nvc0, r600, radeonsi) >GL_ARB_enhanced_layouts DONE (i965) >- compile-time constant expressions DONE >- explicit byte offsets for blocksDONE >- forced alignment within blocks DONE >- specified vec4-slot component numbers DONE (i965) >- specified transform/feedback layout DONE >- input/output block locationsDONE >GL_ARB_multi_bind DONE (all drivers) >GL_ARB_query_buffer_objectDONE (i965/hsw+, > nvc0) >GL_ARB_texture_mirror_clamp_to_edge DONE (i965, nv50, > nvc0, r600, radeonsi, llvmpipe, softpipe, swr) > diff --git a/docs/relnotes/12.1.0.html b/docs/relnotes/12.1.0.html > index 3935bb0..ed98d13 100644 > --- a/docs/relnotes/12.1.0.html > +++ b/docs/relnotes/12.1.0.html > @@ -37,20 +37,21 @@ TBD. > > > > New features > > > Note: some of the new features are only available with certain drivers. > > > > +GL_ARB_clear_texture on r600, radeonsi > GL_ARB_enhanced_layouts on i965 > GL_ARB_shader_group_vote on nvc0 > GL_ARB_ES3_1_compatibility on i965 > GL_EXT_window_rectangles on nv50, nvc0 > GL_KHR_texture_compression_astc_sliced_3d on i965 > > > Bug fixes > > TBD. > diff --git a/src/gallium/drivers/r600/r600_pipe.c > b/src/gallium/drivers/r600/r600_pipe.c > index 39a310a..5f69a5d 100644 > --- a/src/gallium/drivers/r600/r600_pipe.c > +++ b/src/gallium/drivers/r600/r600_pipe.c > @@ -276,20 +276,21 @@ static int r600_get_param(struct pipe_screen* > pscreen, enum pipe_cap param) > case PIPE_CAP_CONDITIONAL_RENDER_INVERTED: > case PIPE_CAP_TEXTURE_FLOAT_LINEAR: > case PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR: > case PIPE_CAP_TGSI_TXQS: > case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS: > case PIPE_CAP_INVALIDATE_BUFFER: > case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS: > case PIPE_CAP_QUERY_MEMORY_INFO: > case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT: > case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED: > + case PIPE_CAP_CLEAR_TEXTURE: > return 1; > > case PIPE_CAP_DEVICE_RESET_STATUS_QUERY: > return rscreen->b.info.drm_major == 2 && > rscreen->b.info.drm_minor >= 43; > > case PIPE_CAP_RESOURCE_FROM_USER_MEMORY: > return !R600_BIG_ENDIAN && rscreen->b.info.has_userptr; > > case PIPE_CAP_COMPUTE: > return rscreen->b.chip_class > R700; > @@ -348,21 +349,20 @@ static int r600_get_param(struct pipe_screen* > pscreen, enum pipe_cap param) > case PIPE_CAP_TGSI_FS_COORD_PIXEL_CENTER_INTEGER: > case PIPE_CAP_TGSI_CAN_COMPACT_CONSTANTS: > case PIPE_CAP_FRAGMENT_COLOR_CLAMPED: > case PIPE_CAP_VERTEX_COLOR_CLAMPED: > case PIPE_CAP_USER_VERTEX_BUFFERS: > case PIPE_CAP_TEXTURE_GATHER_OFFSETS: > case PIPE_CAP_VERTEXID_NOBASE: > case PIPE_CAP_DEPTH_BOUNDS_TEST: > case PIPE_CAP_FORCE_PERSAMPLE_INTERP: > case PIPE_CAP_SHAREABLE_SHADERS: > - case PIPE_CAP_CLEAR_TEXTURE: > case PIPE_CAP_DRAW_PARA
Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture
On Thu, Aug 4, 2016 at 8:04 PM, Ilia Mirkin wrote: > I believe that clear depth stencil is meant to respect the render condition, > while clear texture is not. In nouveau I "solved" this by ignoring the > render condition in the clear depth stencil function too, since nothing in > Mesa relied on it iirc. OK. v2 is coming. BTW, did you notice that your clear_render_target implementation is wrong with respect to Gallium? :) Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Intel: Please help define the common rectangle primitive type
On Aug 4, 2016 10:33 AM, "Marek Olšák" wrote:
>
> On Thu, Aug 4, 2016 at 3:31 PM, Jason Ekstrand
wrote:
> > Hey Marek, Thanks for working on this!
> >
> > On Aug 4, 2016 7:39 AM, "Marek Olšák" wrote:
> >>
> >> Hi,
> >>
> >> This is my definition so far, which is an intersection of AMD and NV
> >> rectangles:
> >>
> >> Definition and behavior:
> >> - The rectangle primitive is defined by its first 3 vertices.
> >> - The 4th vertex is derived (extrapolated) during rasterization.
> >> - It's treated as a triangle by all stages before rasterization.
> >> - The rectangle edges must be parallel or perpendicular to X and Y
> >> axes ("axis-aligned), i.e. the rectangle can only be rotated in
> >> 90-degree increments and flipped over.
> >> - It must be rasterized as a rectangle (no diagonal tearing allowed,
> >> no artifacts on the diagonal allowed)
> >
> > More requirements:
> > - Must be solid
>
> I take it you mean the polygon mode.
Yes
> > - No cut index (GS is supposed to be fine and Tess looks OK too)
>
> I'd be OK with dropping GS and Tess support for rectangles.
I don't know that we need to but the docs say cut index doesn't work.
> >
> > Our hardware docs *say* that the vertices have to come in a particular
> > order. That said, I've gotten it wrong without the hardware exploding
> > before. I think we could write a Piglit test that checks all the
orders and
> > test for it fairly easily.
>
> This is the most tricky one. I'd need a clear definition of what "a
> particular order" means. The rasterization order is different between
> windows and FBOs.
The docs say that you have to do it as follows:
v2---+
| \ |
| \ |
| \|
v1--v0
It also says that the fourth vertex is computed as v2 + v0 - v1 and had
some words about screen alignment. But those are the docs which don't tell
you how it works but rather "if you program it this way it will work". In
reality it probably just takes the different edges from the different
vertices or something like that. I don't know the details.
> > Also, clipping... The docs say that we can't clip them with the normal
> > clipper. It also says that we need to disable the viewport which means
we
> > are left with no clipping whatsoever and OOB rectangles may write to
random
> > memory outside the surface. This is bad. Without further
experimentation,
> > I can't say how much of this is true and how much of it is just
> > recommendation. Given that RECTLIST is intended for internal operations
> > only, it could be anywhere on that spectrum and may be different on
> > different hardware. We could, in theory apply the viewport and do
clipping
> > either in a geometry shader or as something we append onto the end of
the
> > VS. A bit ugly, but it would work.
>
> I declared clipping as undefined, including frustum clipping. That
> means all vertices must be inside the viewport and all user clipping
> must be disabled.
>
> If your driver uses guard bands (which skips clipping), it probably
> also uses a scissor test of some kind to cull pixels out of viewport
> bounds.
I'll have to look a little closer but we may be able to do that.
> It's not clear yet whether or not this information gathering will be any
useful.
I think everyone agrees that the extension is useful, especially for glamor
and the like. At some point we need to just draft something, plumb it
through, write Piglit tests, and keep speccing until we can all do it.
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture
On Aug 4, 2016 13:17, "Marek Olšák" wrote: > > On Thu, Aug 4, 2016 at 8:04 PM, Ilia Mirkin wrote: > > I believe that clear depth stencil is meant to respect the render condition, > > while clear texture is not. In nouveau I "solved" this by ignoring the > > render condition in the clear depth stencil function too, since nothing in > > Mesa relied on it iirc. > > OK. v2 is coming. > > BTW, did you notice that your clear_render_target implementation is > wrong with respect to Gallium? :) Yes, I just never bothered to fix it up, since afaik only the proprietary d3d10 st depends on that. More important that clear texture ignores the condition, as that's a real use case. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture (v2)
From: Marek Olšák
Some ideas copied from Jakob Sinclair's implementation, but the color
clearing is completely different.
v2: remove leftover code, disable conditional rendering
---
docs/GL3.txt | 2 +-
docs/relnotes/12.1.0.html | 1 +
src/gallium/drivers/r600/r600_blit.c | 6 ++-
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/radeon/r600_texture.c | 66 +++
src/gallium/drivers/radeonsi/si_blit.c| 6 ++-
src/gallium/drivers/radeonsi/si_pipe.c| 2 +-
7 files changed, 80 insertions(+), 5 deletions(-)
diff --git a/docs/GL3.txt b/docs/GL3.txt
index c185c69..5dcfc31 100644
--- a/docs/GL3.txt
+++ b/docs/GL3.txt
@@ -185,21 +185,21 @@ GL 4.3, GLSL 4.30 -- all DONE: nvc0, radeonsi
GL_ARB_texture_query_levels DONE (all drivers that
support GLSL 1.30)
GL_ARB_texture_storage_multisampleDONE (all drivers that
support GL_ARB_texture_multisample)
GL_ARB_texture_view DONE (i965, nv50,
r600, llvmpipe, softpipe, swr)
GL_ARB_vertex_attrib_binding DONE (all drivers)
GL 4.4, GLSL 4.40:
GL_MAX_VERTEX_ATTRIB_STRIDE DONE (all drivers)
GL_ARB_buffer_storage DONE (i965, nv50,
nvc0, r600, radeonsi)
- GL_ARB_clear_texture DONE (i965, nv50, nvc0)
+ GL_ARB_clear_texture DONE (i965, nv50,
nvc0, r600, radeonsi)
GL_ARB_enhanced_layouts DONE (i965)
- compile-time constant expressions DONE
- explicit byte offsets for blocksDONE
- forced alignment within blocks DONE
- specified vec4-slot component numbers DONE (i965)
- specified transform/feedback layout DONE
- input/output block locationsDONE
GL_ARB_multi_bind DONE (all drivers)
GL_ARB_query_buffer_objectDONE (i965/hsw+, nvc0)
GL_ARB_texture_mirror_clamp_to_edge DONE (i965, nv50,
nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
diff --git a/docs/relnotes/12.1.0.html b/docs/relnotes/12.1.0.html
index 3935bb0..ed98d13 100644
--- a/docs/relnotes/12.1.0.html
+++ b/docs/relnotes/12.1.0.html
@@ -37,20 +37,21 @@ TBD.
New features
Note: some of the new features are only available with certain drivers.
+GL_ARB_clear_texture on r600, radeonsi
GL_ARB_enhanced_layouts on i965
GL_ARB_shader_group_vote on nvc0
GL_ARB_ES3_1_compatibility on i965
GL_EXT_window_rectangles on nv50, nvc0
GL_KHR_texture_compression_astc_sliced_3d on i965
Bug fixes
TBD.
diff --git a/src/gallium/drivers/r600/r600_blit.c
b/src/gallium/drivers/r600/r600_blit.c
index a6c5b44..8f2e2a6 100644
--- a/src/gallium/drivers/r600/r600_blit.c
+++ b/src/gallium/drivers/r600/r600_blit.c
@@ -29,21 +29,25 @@
enum r600_blitter_op /* bitmask */
{
R600_SAVE_FRAGMENT_STATE = 1,
R600_SAVE_TEXTURES = 2,
R600_SAVE_FRAMEBUFFER= 4,
R600_DISABLE_RENDER_COND = 8,
R600_CLEAR = R600_SAVE_FRAGMENT_STATE,
- R600_CLEAR_SURFACE = R600_SAVE_FRAGMENT_STATE | R600_SAVE_FRAMEBUFFER,
+ /* GL_ARB_clear_texture should ignore the render condition, but
+* Gallium shouldn't. Follow OpenGL.
+*/
+ R600_CLEAR_SURFACE = R600_SAVE_FRAGMENT_STATE | R600_SAVE_FRAMEBUFFER |
+R600_DISABLE_RENDER_COND,
R600_COPY_BUFFER = R600_DISABLE_RENDER_COND,
R600_COPY_TEXTURE = R600_SAVE_FRAGMENT_STATE | R600_SAVE_FRAMEBUFFER |
R600_SAVE_TEXTURES |
R600_DISABLE_RENDER_COND,
R600_BLIT = R600_SAVE_FRAGMENT_STATE | R600_SAVE_FRAMEBUFFER |
R600_SAVE_TEXTURES,
R600_DECOMPRESS= R600_SAVE_FRAGMENT_STATE | R600_SAVE_FRAMEBUFFER |
R600_DISABLE_RENDER_COND,
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index 39a310a..5f69a5d 100644
--- a/src/gallium/drivers/r600/r600_pipe.c
+++ b/src/gallium/drivers/r600/r600_pipe.c
@@ -276,20 +276,21 @@ static int r600_get_param(struct pipe_screen* pscreen,
enum pipe_cap param)
case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
case PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR:
case PIPE_CAP_TGSI_TXQS:
case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
case PIPE_CAP_INVALIDATE_BUFFER:
case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
case PIPE_CAP_QUERY_MEMORY_INFO:
case PIPE_CAP_FRAMEBUFFER_NO_ATTACHMENT:
case PIPE_CAP_POLYGON_OFFSET_UNITS_UNSCALED:
+ case PIPE_CAP_CLEAR_TEXTURE:
return 1;
case PIPE_CAP_DEVICE_RESET_STATUS_QUERY:
Re: [Mesa-dev] OpenCL for radeon Hawaii?
Thanks Jan, This is what it comes up with https://gist.github.com/fommil/c97d4c8fb2790e28ecaf8d334ebf1746 Are there any demo apps I could expect to run with this? What is involved in writing missing functionality? Number of platforms 1 Platform Name Clover Platform Vendor Mesa Platform Version OpenCL 1.1 Mesa 12.0.1 Platform Profile FULL_PROFILE Platform Extensions cl_khr_icd Platform Extensions function suffix MESA Platform Name Clover Number of devices 1 Device Name AMD HAWAII (DRM 2.43.0 / 4.6.4-1-ARCH, LLVM 3.8.0) Device Vendor AMD Device Vendor ID 0x1002 Device Version OpenCL 1.1 Mesa 12.0.1 Driver Version 12.0.1 Device OpenCL C Version OpenCL C 1.1 Device Type GPU Device Profile FULL_PROFILE Max compute units 44 Max clock frequency 1090MHz Max work item dimensions 3 Max work item sizes 256x256x256 Max work group size 256 Preferred work group size multiple 64 Preferred / native vector sizes char 16 / 16 short 8 / 8 int 4 / 4 long 2 / 2 half 0 / 0 (n/a) float 4 / 4 double 2 / 2 (cl_khr_fp64) Half-precision Floating-point support (n/a) Single-precision Floating-point support (core) Denormals No Infinity and NANs Yes Round to nearest Yes Round to zero No Round to infinity No IEEE754-2008 fused multiply-add No Support is emulated in software No Correctly-rounded divide and sqrt operations No Double-precision Floating-point support (cl_khr_fp64) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Correctly-rounded divide and sqrt operations No Address bits 32, Little-Endian Global memory size 1073741824 (1024MiB) Error Correction support No Max memory allocation 268435456 (256MiB) Unified memory for Host and Device Yes Minimum alignment for any data type 128 bytes Alignment of base address 1024 bits (128 bytes) Global Memory cache type None Image support No Local memory type Local Local memory size 32768 (32KiB) Max constant buffer size 268435456 (256MiB) Max number of constant args 16 Max size of kernel argument 1024 Queue properties Out-of-order execution No Profiling Yes Profiling timer resolution 0ns Execution capabilities Run OpenCL kernels Yes Run native kernels No Device Available Yes Compiler Available Yes Device Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_fp64 NULL platform behavior clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) Clover clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [MESA] clCreateContext(NULL, ...) [default] Success [MESA] clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) Success (1) Platform Name Clover Device Name AMD HAWAII (DRM 2.43.0 / 4.6.4-1-ARCH, LLVM 3.8.0) clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) Success (1) Platform Name Clover Device Name AMD HAWAII (DRM 2.43.0 / 4.6.4-1-ARCH, LLVM 3.8.0) ICD loader properties ICD loader Name OpenCL ICD Loader ICD loader Vendor OCL Icd free software ICD loader Version 2.2.9 ICD loader Profile OpenCL 2.1 On 3 August 2016 at 21:33, Jan Vesely wrote: > Hi, > > you can use clinfo utility to check whether OpenCL has been setup > correctly. It won't be able to run luxmark, but simpler stuff should > work. > > Jan > > On Wed, 2016-08-03 at 20:45 +0100, Sam Halliday wrote: >> Hello everybody, >> >> I recently got a Radeon R9 290x (aka Hawaii). I run ArchLinux, which >> has >> mesa 12.0.1. >> >> I am keen to try out mesa's partial OpenCL implementation. Ideally to >> use a BLAS implementation such as https://github.com/CNugteren/CLBlas >> t >> but I'd also be happy to just write something basic like dense >> matrix/matrix multiplication in OpenCL. >> >> >> However, when I tried to run the "luxmark" OpenCL benchmark (the only >> way I could think to test if my card is supported), I got this error >> >> [PathOCLBaseRenderThread::0] Compiling kernels >> [PathOCLBaseRenderThread::0] PathOCL kernel compilation error ERROR >> clBuildProgram[CL_INVALID_BUILD_OPTIONS]: >> RUNTIME ERROR: PathOCLBase kernel compilation error >> >> which, I'm guessing, means that my GPU isn't supported for OpenCL by >> mesa yet. Is that correct? (I don't know how to get any more output >> or >> logs than this). >> >> >> Could somebody please help by letting me know if there is a ticket I >> could subscribe to track progress of support for my card (a simple >> search of the bug database didn't bring up anything obvious). This >> message is to the -dev list, so I am suppose I am saying that I am >> prepared to get my hands dirty... but I am primarily a Scala >> developer >> and haven't done any C in years so the extent of my help is limited. >> >> If somebo
[Mesa-dev] [PATCH 2/2] i965: Respect miptree offsets in intel_readpixels_tiled_memcpy()
Respect intel_miptree_slice::x_offset,y_offset and
intel_mipmap_tree::offset. All three may be non-zero when glReadPixels
is called on an EGLImage created from the non-base slice of a miptree.
Patch 2/2 that fixes test
'dEQP-EGL.functional.image.create.gles2_cubemap_*'.
Reported-by: Haixia Shi
Diagnosed-by: Haixia Shi
Cc: Jason Ekstrand
Cc: Mark Janes
Cc: mesa-sta...@lists.freedesktop.org
Change-Id: I4b397b27e55a743a7094d29fb0a6a4b6b34352b0
---
src/mesa/drivers/dri/i965/intel_pixel_read.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_pixel_read.c
b/src/mesa/drivers/dri/i965/intel_pixel_read.c
index a486d6e..cacd7e2 100644
--- a/src/mesa/drivers/dri/i965/intel_pixel_read.c
+++ b/src/mesa/drivers/dri/i965/intel_pixel_read.c
@@ -110,22 +110,6 @@ intel_readpixels_tiled_memcpy(struct gl_context * ctx,
if (ctx->_ImageTransferState)
return false;
- /* This renderbuffer can come from a texture. In this case, we impose
-* some of the same restrictions we have for textures and adjust for
-* miplevels.
-*/
- if (rb->TexImage) {
- if (rb->TexImage->TexObject->Target != GL_TEXTURE_2D &&
- rb->TexImage->TexObject->Target != GL_TEXTURE_RECTANGLE)
- return false;
-
- int level = rb->TexImage->Level + rb->TexImage->TexObject->MinLevel;
-
- /* Adjust x and y offset based on miplevel */
- xoffset += irb->mt->level[level].level_x;
- yoffset += irb->mt->level[level].level_y;
- }
-
/* It is possible that the renderbuffer (or underlying texture) is
* multisampled. Since ReadPixels from a multisampled buffer requires a
* multisample resolve, we can't handle this here
@@ -169,6 +153,9 @@ intel_readpixels_tiled_memcpy(struct gl_context * ctx,
return false;
}
+ xoffset += irb->mt->level[irb->mt_level].slice[irb->mt_layer].x_offset;
+ yoffset += irb->mt->level[irb->mt_level].slice[irb->mt_layer].y_offset;
+
dst_pitch = _mesa_image_row_stride(pack, width, format, type);
/* For a window-system renderbuffer, the buffer is actually flipped
@@ -201,7 +188,7 @@ intel_readpixels_tiled_memcpy(struct gl_context * ctx,
xoffset * cpp, (xoffset + width) * cpp,
yoffset, yoffset + height,
pixels - (ptrdiff_t) yoffset * dst_pitch - (ptrdiff_t) xoffset * cpp,
- bo->virtual,
+ bo->virtual + irb->mt->offset,
dst_pitch, irb->mt->pitch,
brw->has_swizzling,
irb->mt->tiling,
--
2.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*
Hi Intel folks, could one of you please run this through Jenkins? I verified manually that it fixes the listed dEQP tests on Skylake. Chad Versace (2): i965: Fix miptree layout for EGLImage-based renderbuffers i965: Respect miptree offsets in intel_readpixels_tiled_memcpy() src/mesa/drivers/dri/i965/intel_fbo.c| 13 + src/mesa/drivers/dri/i965/intel_pixel_read.c | 21 - 2 files changed, 17 insertions(+), 17 deletions(-) -- 2.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Fix miptree layout for EGLImage-based renderbuffers
When glEGLImageTargetRenderbufferStorageOES() was given an EGLImage created from the non-base slice of a miptree, intel_image_target_renderbuffer_storage() forgot to apply the intra-tile offsets __DRIimage::tile_x,tile_y to the miptree layout. This patch fixes the problem with a quick hack suitable for cherry-picking. A proper fix requires more thorough plumbing in intel_miptree_create_layout() and brw_tex_layout(). Patch 1/2 that fixes test 'dEQP-EGL.functional.image.create.gles2_cubemap_*'. Reported-by: Haixia Shi Diagnosed-by: Haixia Shi Cc: Jason Ekstrand Cc: Mark Janes Cc: mesa-sta...@lists.freedesktop.org Change-Id: I8a64b0048a1ee9e714ebb3f33fffd8334036450b --- src/mesa/drivers/dri/i965/intel_fbo.c | 13 + 1 file changed, 13 insertions(+) diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c b/src/mesa/drivers/dri/i965/intel_fbo.c index 707a9d2..c4a5048 100644 --- a/src/mesa/drivers/dri/i965/intel_fbo.c +++ b/src/mesa/drivers/dri/i965/intel_fbo.c @@ -374,6 +374,19 @@ intel_image_target_renderbuffer_storage(struct gl_context *ctx, if (!irb->mt) return; + /* Adjust the miptree's upper-left coordinate. +* +* FIXME: Adjusting the miptree's layout outside of +* intel_miptree_create_layout() is fragile. Plumb the adjustment through +* intel_miptree_create_layout() and brw_tex_layout(). +*/ + irb->mt->level[0].level_x = image->tile_x; + irb->mt->level[0].level_y = image->tile_y; + irb->mt->level[0].slice[0].x_offset = image->tile_x; + irb->mt->level[0].slice[0].y_offset = image->tile_y; + irb->mt->total_width += image->tile_x; + irb->mt->total_height += image->tile_y; + rb->InternalFormat = image->internal_format; rb->Width = image->width; rb->Height = image->height; -- 2.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 08/12] gallium/radeon/winsyses: print CS submission error number
On Tue, Aug 2, 2016 at 4:38 PM, Nicolai Hähnle wrote:
> On 29.07.2016 23:42, Marek Olšák wrote:
>>
>> From: Marek Olšák
>>
>> ---
>> src/gallium/winsys/amdgpu/drm/amdgpu_cs.c | 2 +-
>> src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>> b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>> index fb517b9..35e1b48 100644
>> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_cs.c
>> @@ -935,7 +935,7 @@ void amdgpu_cs_submit_ib(void *job, int thread_index)
>> fprintf(stderr, "amdgpu: Not enough memory for command
>> submission.\n");
>>else
>> fprintf(stderr, "amdgpu: The CS has been rejected, "
>> - "see dmesg for more information.\n");
>> + "see dmesg for more information (%i).\n", r);
>>
>>amdgpu_fence_signalled(cs->fence);
>> } else {
>> diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
>> b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
>> index 606c38d..4a6f005 100644
>> --- a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
>> +++ b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
>> @@ -447,7 +447,7 @@ void radeon_drm_cs_emit_ioctl_oneshot(void *job, int
>> thread_index)
>> }
>> } else {
>> fprintf(stderr, "radeon: The kernel rejected CS, "
>> -"see dmesg for more information.\n");
>> +"see dmesg for more information (%i).\n", r);
>> }
>> }
>>
>>
>
> It would be nice to use strerror_r here:
>
> char buf[128];
> strerror_r(-r, buf, sizeof(buf));
> ... then use buf ...
>
> That would also get rid of the ENOMEM special case.
Are you sure that's a good idea? It returns "Cannot allocate memory"
for ENOMEM, which is slightly different from "Not enough memory for
command submission."
Marek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*
I'll test it. Chad Versace writes: > Hi Intel folks, could one of you please run this through Jenkins? > I verified manually that it fixes the listed dEQP tests on Skylake. > > Chad Versace (2): > i965: Fix miptree layout for EGLImage-based renderbuffers > i965: Respect miptree offsets in intel_readpixels_tiled_memcpy() > > src/mesa/drivers/dri/i965/intel_fbo.c| 13 + > src/mesa/drivers/dri/i965/intel_pixel_read.c | 21 - > 2 files changed, 17 insertions(+), 17 deletions(-) > > -- > 2.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenCL for radeon Hawaii?
Hi, On Thu, 2016-08-04 at 20:54 +0100, Sam Halliday wrote: > Thanks Jan, > > This is what it comes up with > https://gist.github.com/fommil/c97d4c8fb2790e28ecaf8d334ebf1746 looks OK. > > Are there any demo apps I could expect to run with this? I was able to successfully run GEGL(GIMP) image manipulation kernels (one test fails on what seems like rounding errors), image magick(or was that graphics magick?) image kernels should also work. I saw some work mentioning bitcoin mining. see also Aaron's email about CLBlast. > What is > involved in writing missing functionality? depends on what you need. OpenCL 1.1 is mostly there. If the application needs missing CLC library builtin, that's easy to add (mostly just copying form amd's opensourced version). there might be bugs/missing features in the compiler (different levels of difficulty, usually needs some level of understanding GCN ISA, docs are available). llvm backend is in heavy development so some bugs might be fixed by just using more recent version. some pl were working on runtime side of opencl 1.2, not sure what the status is there. more complex features (like printf) need to touch multiple projects. OpenCL 2.x features (like SVM) are lot of work. if you have an app you'd like to see running, just file a bug. jan > > Number of platforms 1 > Platform Name Clover > Platform Vendor Mesa > Platform Version OpenCL 1.1 Mesa 12.0.1 > Platform Profile FULL_PROFILE > Platform Extensions cl_khr_icd > Platform Extensions function suffix MESA > Platform Name Clover > Number of devices 1 > Device Name AMD HAWAII (DRM 2.43.0 / 4.6.4-1-ARCH, LLVM 3.8.0) > Device Vendor AMD > Device Vendor ID 0x1002 > Device Version OpenCL 1.1 Mesa 12.0.1 > Driver Version 12.0.1 > Device OpenCL C Version OpenCL C 1.1 > Device Type GPU > Device Profile FULL_PROFILE > Max compute units 44 > Max clock frequency 1090MHz > Max work item dimensions 3 > Max work item sizes 256x256x256 > Max work group size 256 > Preferred work group size multiple 64 > Preferred / native vector sizes > char 16 / 16 > short 8 / 8 > int 4 / 4 > long 2 / 2 > half 0 / 0 (n/a) > float 4 / 4 > double 2 / 2 (cl_khr_fp64) > Half-precision Floating-point support (n/a) > Single-precision Floating-point support (core) > Denormals No > Infinity and NANs Yes > Round to nearest Yes > Round to zero No > Round to infinity No > IEEE754-2008 fused multiply-add No > Support is emulated in software No > Correctly-rounded divide and sqrt operations No > Double-precision Floating-point support (cl_khr_fp64) > Denormals Yes > Infinity and NANs Yes > Round to nearest Yes > Round to zero Yes > Round to infinity Yes > IEEE754-2008 fused multiply-add Yes > Support is emulated in software No > Correctly-rounded divide and sqrt operations No > Address bits 32, Little-Endian > Global memory size 1073741824 (1024MiB) > Error Correction support No > Max memory allocation 268435456 (256MiB) > Unified memory for Host and Device Yes > Minimum alignment for any data type 128 bytes > Alignment of base address 1024 bits (128 bytes) > Global Memory cache type None > Image support No > Local memory type Local > Local memory size 32768 (32KiB) > Max constant buffer size 268435456 (256MiB) > Max number of constant args 16 > Max size of kernel argument 1024 > Queue properties > Out-of-order execution No > Profiling Yes > Profiling timer resolution 0ns > Execution capabilities > Run OpenCL kernels Yes > Run native kernels No > Device Available Yes > Compiler Available Yes > Device Extensions cl_khr_global_int32_base_atomics > cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics > cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store > cl_khr_fp64 > NULL platform behavior > clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) Clover > clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [MESA] > clCreateContext(NULL, ...) [default] Success [MESA] > clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in > platform > clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) Success (1) > Platform Name Clover > Device Name AMD HAWAII (DRM 2.43.0 / 4.6.4-1-ARCH, LLVM 3.8.0) > clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices > found in platform > clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found > in platform > clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) Success (1) > Platform Name Clover > Device Name AMD HAWAII (DRM 2.43.0 / 4.6.4-1-ARCH, LLVM 3.8.0) > ICD loader properties > ICD loader Name OpenCL ICD Loader > ICD loader Vendor OCL Icd free software > ICD loader Version 2.2.9 > ICD loader Profile OpenCL 2.1 > > On 3 August 2016 at 21:33, Jan Vesely wrote: > > > > Hi, > > > > you can use clinfo utility to check whether OpenCL has been setup > > correctly. It won't be able to run luxmark, but simpler stuff > > should > > work. > > > > Jan > > > > On Wed, 2016-08-03 at 20:45 +0100, Sam Halliday wrote: > > > > > > Hello everybody, > > > > > > I recently got a R
[Mesa-dev] [PATCH 2/5] glsl: Refactor implicit conversion into its own helper
v2: Refactor also the conversion to constant and replacement code
(Timothy).
Signed-off-by: Andres Gomez
---
src/compiler/glsl/ast_function.cpp | 166 +++--
1 file changed, 86 insertions(+), 80 deletions(-)
diff --git a/src/compiler/glsl/ast_function.cpp
b/src/compiler/glsl/ast_function.cpp
index 9dcec50..e30c70c 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -836,6 +836,62 @@ convert_component(ir_rvalue *src, const glsl_type
*desired_type)
return (constant != NULL) ? (ir_rvalue *) constant : (ir_rvalue *) result;
}
+
+/**
+ * Perform automatic type and constant conversion of constructor parameters
+ *
+ * This implements the rules in the "Implicit Conversions" rules, not the
+ * "Conversion and Scalar Constructors".
+ *
+ * After attempting the implicit conversion, an attempt to convert into a
+ * constant valued expression is also done.
+ *
+ * The \c from \c ir_rvalue is converted "in place".
+ *
+ * \param from Operand that is being converted
+ * \param to Base type the operand will be converted to
+ * \param state GLSL compiler state
+ *
+ * \return
+ * If the attempt to convert into a constant expression succeeds, \c true is
+ * returned. Otherwise \c false is returned.
+ */
+static bool
+implicitly_convert_component(ir_rvalue * &from, const glsl_base_type to,
+ struct _mesa_glsl_parse_state *state)
+{
+ ir_rvalue *result = from;
+
+ if (to != from->type->base_type) {
+ const glsl_type *desired_type =
+ glsl_type::get_instance(to,
+ from->type->vector_elements,
+ from->type->matrix_columns);
+
+ if (from->type->can_implicitly_convert_to(desired_type, state)) {
+ /* Even though convert_component() implements the constructor
+ * conversion rules (not the implicit conversion rules), its safe
+ * to use it here because we already checked that the implicit
+ * conversion is legal.
+ */
+ result = convert_component(from, desired_type);
+ }
+ }
+
+ ir_rvalue *const constant = result->constant_expression_value();
+
+ if (constant != NULL)
+ result = constant;
+
+ if (from != result) {
+ from->replace_with(result);
+ from = result;
+ }
+
+ return constant != NULL;
+}
+
+
/**
* Dereference a specific component from a scalar, vector, or matrix
*/
@@ -918,53 +974,30 @@ process_vec_mat_constructor(exec_list *instructions,
/* Type cast each parameter and, if possible, fold constants. */
foreach_in_list_safe(ir_rvalue, ir, &actual_parameters) {
- ir_rvalue *result = ir;
-
- /* Apply implicit conversions (not the scalar constructor rules!). See
- * the spec quote above. */
- if (constructor_type->base_type != result->type->base_type) {
- const glsl_type *desired_type =
-glsl_type::get_instance(constructor_type->base_type,
-ir->type->vector_elements,
-ir->type->matrix_columns);
- if (result->type->can_implicitly_convert_to(desired_type, state)) {
-/* Even though convert_component() implements the constructor
- * conversion rules (not the implicit conversion rules), its safe
- * to use it here because we already checked that the implicit
- * conversion is legal.
- */
-result = convert_component(ir, desired_type);
- }
- }
+ /* Apply implicit conversions (not the scalar constructor rules, see the
+ * spec quote above!) and attempt to convert the parameter to a constant
+ * valued expression. After doing so, track whether or not all the
+ * parameters to the constructor are trivially constant valued
+ * expressions.
+ */
+ all_parameters_are_constant &=
+ implicitly_convert_component(ir, constructor_type->base_type, state);
if (constructor_type->is_matrix()) {
- if (result->type != constructor_type->column_type()) {
+ if (ir->type != constructor_type->column_type()) {
_mesa_glsl_error(loc, state, "type error in matrix constructor: "
"expected: %s, found %s",
constructor_type->column_type()->name,
- result->type->name);
+ ir->type->name);
return ir_rvalue::error_value(ctx);
}
- } else if (result->type != constructor_type->get_scalar_type()) {
+ } else if (ir->type != constructor_type->get_scalar_type()) {
_mesa_glsl_error(loc, state, "type error in vector constructor: "
"expected: %s, found %s",
constructor_type->get_scalar_type()->name,
- result->type->name);
+ ir->typ
[Mesa-dev] [PATCH 3/5] glsl: struct constructors/initializers only allow implicit conversions
When an argument for a structure constructor or initializer doesn't
match the expected type, only Section 4.1.10 “Implicit Conversions”
are allowed to try to match that expected type.
From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:
" The arguments to the constructor will be used to set the structure's
fields, in order, using one argument per field. Each argument must
be the same type as the field it sets, or be a type that can be
converted to the field's type according to Section 4.1.10 “Implicit
Conversions.”"
From page 35 (page 41 of the PDF) of the GLSL 4.20 spec:
" In all cases, the innermost initializer (i.e., not a list of
initializers enclosed in curly braces) applied to an object must
have the same type as the object being initialized or be a type that
can be converted to the object's type according to section 4.1.10
"Implicit Conversions". In the latter case, an implicit conversion
will be done on the initializer before the assignment is done."
v2: Remove also the now redundant constant conversion, the
constant_record_constructor helper and the replacement code
(Timothy).
Fixes GL44-CTS.shading_language_420pack.initializer_list_negative
Signed-off-by: Andres Gomez
---
src/compiler/glsl/ast_function.cpp | 104 -
1 file changed, 55 insertions(+), 49 deletions(-)
diff --git a/src/compiler/glsl/ast_function.cpp
b/src/compiler/glsl/ast_function.cpp
index e30c70c..9b1fa45 100644
--- a/src/compiler/glsl/ast_function.cpp
+++ b/src/compiler/glsl/ast_function.cpp
@@ -1161,24 +1161,6 @@ process_array_constructor(exec_list *instructions,
/**
- * Try to convert a record constructor to a constant expression
- */
-static ir_constant *
-constant_record_constructor(const glsl_type *constructor_type,
- exec_list *parameters, void *mem_ctx)
-{
- foreach_in_list(ir_instruction, node, parameters) {
- ir_constant *constant = node->as_constant();
- if (constant == NULL)
-return NULL;
- node->replace_with(constant);
- }
-
- return new(mem_ctx) ir_constant(constructor_type, parameters);
-}
-
-
-/**
* Determine if a list consists of a single scalar r-value
*/
bool
@@ -1709,53 +1691,77 @@ process_record_constructor(exec_list *instructions,
struct _mesa_glsl_parse_state *state)
{
void *ctx = state;
+ /* From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:
+*
+*"The arguments to the constructor will be used to set the structure's
+* fields, in order, using one argument per field. Each argument must
+* be the same type as the field it sets, or be a type that can be
+* converted to the field's type according to Section 4.1.10 “Implicit
+* Conversions.”"
+*
+* From page 35 (page 41 of the PDF) of the GLSL 4.20 spec:
+*
+*"In all cases, the innermost initializer (i.e., not a list of
+* initializers enclosed in curly braces) applied to an object must
+* have the same type as the object being initialized or be a type that
+* can be converted to the object's type according to section 4.1.10
+* "Implicit Conversions". In the latter case, an implicit conversion
+* will be done on the initializer before the assignment is done."
+*/
exec_list actual_parameters;
- process_parameters(instructions, &actual_parameters,
- parameters, state);
+ const unsigned parameter_count =
+ process_parameters(instructions, &actual_parameters, parameters,
+state);
- exec_node *node = actual_parameters.get_head_raw();
- for (unsigned i = 0; i < constructor_type->length; i++) {
- ir_rvalue *ir = (ir_rvalue *) node;
+ if (parameter_count != constructor_type->length) {
+ _mesa_glsl_error(loc, state,
+ "%s parameters in constructor for `%s'",
+ parameter_count > constructor_type->length
+ ? "too many": "insufficient",
+ constructor_type->name);
+ return ir_rvalue::error_value(ctx);
+ }
- if (node->is_tail_sentinel()) {
- _mesa_glsl_error(loc, state,
- "insufficient parameters to constructor for `%s'",
- constructor_type->name);
- return ir_rvalue::error_value(ctx);
- }
+ bool all_parameters_are_constant = true;
- if (apply_implicit_conversion(constructor_type->fields.structure[i].type,
- ir, state)) {
- node->replace_with(ir);
- } else {
+ int i = 0;
+ /* Type cast each parameter and, if possible, fold constants. */
+ foreach_in_list_safe(ir_rvalue, ir, &actual_parameters) {
+
+ const glsl_struct_field *struct_field =
+ &constructor_type->fields.structure[i];
+
+ /* Apply implicit conversions (not the scalar constructor
Re: [Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*
I saw no regressions from these tests. However, I wasn't able to run the dEQP-EGL tests the last time I tried. What branch of dEQP are you running? InternalError (Runtime check failed: '(m_capabilities & CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at egluNativeDisplay.cpp:70) -Mark Chad Versace writes: > Hi Intel folks, could one of you please run this through Jenkins? > I verified manually that it fixes the listed dEQP tests on Skylake. > > Chad Versace (2): > i965: Fix miptree layout for EGLImage-based renderbuffers > i965: Respect miptree offsets in intel_readpixels_tiled_memcpy() > > src/mesa/drivers/dri/i965/intel_fbo.c| 13 + > src/mesa/drivers/dri/i965/intel_pixel_read.c | 21 - > 2 files changed, 17 insertions(+), 17 deletions(-) > > -- > 2.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] oldest gcc version to support ?
On 04.08.2016 17:10, Jason Ekstrand wrote: Hi, > The BSDs are still stuck at 4.2+patches for licensing reasons and they > use Mesa for graphics. I think at some point, they'll get clang in core > and they can start building with that. There are ancient RHEL versions > where the GCC version is so old that they build a newer GCC just so they > can build Mesa. One of these days, we'll move past GCC 4.2 but for now > it's not too much of a burden to keep it working. I'd guess they're using autoconf, correct ? The stuff I'm talking about is just for scons builds, which AFAIK is only for win32 / msvc. (see c99_compat.h) --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*
On 05/08/16 00:24, Mark Janes wrote: I saw no regressions from these tests. However, I wasn't able to run the dEQP-EGL tests the last time I tried. What branch of dEQP are you running? InternalError (Runtime check failed: '(m_capabilities & CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at egluNativeDisplay.cpp:70) -Mark Err, get rid of this assert, it is a false positive. Things just work anyway. Chad, since you are on the other side now, maybe you could fix the situation of dEQP on Linux ;) Martin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OpenCL for radeon Hawaii?
On Thu, Aug 4, 2016 at 2:54 PM, Sam Halliday wrote: > Thanks Jan, > > This is what it comes up with > https://gist.github.com/fommil/c97d4c8fb2790e28ecaf8d334ebf1746 > > Are there any demo apps I could expect to run with this? What is > involved in writing missing functionality? > I'll let others address the demo apps question for the most part. I know tstellard has worked with opencv compatibility a bit, I had previously tried GEGL, attempted luxmark/juliaGPU, and some of the FinanceBench that Phoronix uses is runnable. I previously ran BFGMiner for bitcoin mining as well. Things you can try to do to improve the current situation: 1) If an application fails to compile CL kernels, it'd be good to get build logs and kernels so that the cause can be investigated. Often, the issue is because clover/libclc don't have an implementation of that functionality. You can dump the list of kernels and the LLVM IR when a program runs by doing the following: CLOVER_DEBUG_FILE=clover_dump CLOVER_DEBUG=clc,llvm,asm PATH_TO_YOUR_TEST_PROGRAM That'll generate a set of files called clover_dump.cl, clover_dump.ll, clover_dump.asm with: a) The CL source that the program tried to compile b) The LLVM IR for the CL source. c) The generated machine code for the LLVM IR on your card. If the CL source is missing built-in function implementations, libclc ( libclc.llvm.org) will gladly accept patches to implement them. If you want to just do a test-compile of the CL source, I use the following command (with libclc/llvm/mesa all in /usr/local/): clang -S -emit-llvm -o $1.ll -include /usr/local/include/clc/clc.h -I/usr/local/include/ -Dcl_clang_storage_class_specifiers -target amdgcn-- -mcpu=pitcairn -c $1 2) If the application crashes outright (such as CLBlast), it could be because we are missing CL API functions that should be implemented, or because the program is abusing the spec. My general thought is that it's most rewarding to pick an application that you want to see working, and then keep fixing things until it runs. That mostly has meant implementing libclc built-ins for me. I've been working on getting MultiCoreWare's cppamp driver working on Mesa/Clover ( https://bitbucket.org/multicoreware/hcc/wiki/Home). We're only 4-ish built-ins (and a static keyword from CL 1.2's storage class specifiers) away from that working, which would be nice. Beyond cppamp, I'd be interested in someone tracking down more precision tests for the floating point and geometric functions that we haven't implemented yet and turning those into piglit tests (or at least identifying projects that have those tests and how to build/run them). --Aaron > > Number of platforms 1 > Platform Name Clover > Platform Vendor Mesa > Platform Version OpenCL 1.1 Mesa 12.0.1 > Platform Profile FULL_PROFILE > Platform Extensions cl_khr_icd > Platform Extensions function suffix MESA > Platform Name Clover > Number of devices 1 > Device Name AMD HAWAII (DRM 2.43.0 / 4.6.4-1-ARCH, LLVM 3.8.0) > Device Vendor AMD > Device Vendor ID 0x1002 > Device Version OpenCL 1.1 Mesa 12.0.1 > Driver Version 12.0.1 > Device OpenCL C Version OpenCL C 1.1 > Device Type GPU > Device Profile FULL_PROFILE > Max compute units 44 > Max clock frequency 1090MHz > Max work item dimensions 3 > Max work item sizes 256x256x256 > Max work group size 256 > Preferred work group size multiple 64 > Preferred / native vector sizes > char 16 / 16 > short 8 / 8 > int 4 / 4 > long 2 / 2 > half 0 / 0 (n/a) > float 4 / 4 > double 2 / 2 (cl_khr_fp64) > Half-precision Floating-point support (n/a) > Single-precision Floating-point support (core) > Denormals No > Infinity and NANs Yes > Round to nearest Yes > Round to zero No > Round to infinity No > IEEE754-2008 fused multiply-add No > Support is emulated in software No > Correctly-rounded divide and sqrt operations No > Double-precision Floating-point support (cl_khr_fp64) > Denormals Yes > Infinity and NANs Yes > Round to nearest Yes > Round to zero Yes > Round to infinity Yes > IEEE754-2008 fused multiply-add Yes > Support is emulated in software No > Correctly-rounded divide and sqrt operations No > Address bits 32, Little-Endian > Global memory size 1073741824 (1024MiB) > Error Correction support No > Max memory allocation 268435456 (256MiB) > Unified memory for Host and Device Yes > Minimum alignment for any data type 128 bytes > Alignment of base address 1024 bits (128 bytes) > Global Memory cache type None > Image support No > Local memory type Local > Local memory size 32768 (32KiB) > Max constant buffer size 268435456 (256MiB) > Max number of constant args 16 > Max size of kernel argument 1024 > Queue properties > Out-of-order execution No > Profiling Yes > Profiling timer resolution 0ns > Execution capabilities > Run OpenCL kernels Yes > Run native kernels No > Device Available Yes > Compiler Available Yes > Device Extensions cl_khr_global_int32_base_atomics > cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics > cl_kh
Re: [Mesa-dev] [PATCH] i965: import prime buffers in the current context, not screen
On 04/08/16 19:04, Eric Anholt wrote: Martin Peres writes: This mirrors the codepath taken by DRI2 in IntelSetTexBuffer2() and fixes many applications when using DRI3: - Totem with libva on hw-accelerated decoding - obs-studio, using Window Capture (Xcomposite) as a Source - gstreamer with VAAPI Cc: mesa-sta...@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71759 Tested-by: Fabrice Bellet Signed-off-by: Martin Peres --- I have been testing the patch on my main desktop for a day and did not encounter any issue with it. This is however quite a corner case and most people never had this issue anyway. If this patch is not accepted, then we will need to change the loader's GetBuffers() method so as it either does not import the buffers or takes the context as a parameter. Not sure if you've seen, but the gallium drivers are doing an fstat on the DRM fd, hashing the st_dev/st_ino/st_rdev, and reusing an existing screen when it matches. This might be really useful for Intel, too. Thanks, I did not know this :) This is sort of what the first patch in bugzilla was proposing but it won't work when mixing DRI2 and DRI3 because they use different nodes on xf86-video-intel (not on modesetting, both use card0) and thus, we still cannot guarantee that an application will have only one bufmgr per GPU. However, it would still reduce the number of buffer managers, which is likely a good idea. I could also do this in mesa, since this is where sharing buffers between contexts is actually happening. It still feels like a workaround though to rely on this. Not that this fix also feels like a workaround, but it is a workaround for the API of the DRI3 loader. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] glsl: struct constructors/initializers only allow implicit conversions
On Thu, 2016-08-04 at 23:55 +0300, Andres Gomez wrote:
> When an argument for a structure constructor or initializer doesn't
> match the expected type, only Section 4.1.10 “Implicit Conversions”
> are allowed to try to match that expected type.
>
> From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:
>
> " The arguments to the constructor will be used to set the
> structure's
> fields, in order, using one argument per field. Each argument
> must
> be the same type as the field it sets, or be a type that can be
> converted to the field's type according to Section 4.1.10
> “Implicit
> Conversions.”"
>
> From page 35 (page 41 of the PDF) of the GLSL 4.20 spec:
>
> " In all cases, the innermost initializer (i.e., not a list of
> initializers enclosed in curly braces) applied to an object must
> have the same type as the object being initialized or be a type
> that
> can be converted to the object's type according to section 4.1.10
> "Implicit Conversions". In the latter case, an implicit
> conversion
> will be done on the initializer before the assignment is done."
>
> v2: Remove also the now redundant constant conversion, the
> constant_record_constructor helper and the replacement code
> (Timothy).
>
> Fixes GL44-CTS.shading_language_420pack.initializer_list_negative
>
> Signed-off-by: Andres Gomez
> ---
> src/compiler/glsl/ast_function.cpp | 104 ---
> --
> 1 file changed, 55 insertions(+), 49 deletions(-)
>
> diff --git a/src/compiler/glsl/ast_function.cpp
> b/src/compiler/glsl/ast_function.cpp
> index e30c70c..9b1fa45 100644
> --- a/src/compiler/glsl/ast_function.cpp
> +++ b/src/compiler/glsl/ast_function.cpp
> @@ -1161,24 +1161,6 @@ process_array_constructor(exec_list
> *instructions,
>
>
> /**
> - * Try to convert a record constructor to a constant expression
> - */
> -static ir_constant *
> -constant_record_constructor(const glsl_type *constructor_type,
> - exec_list *parameters, void *mem_ctx)
> -{
> - foreach_in_list(ir_instruction, node, parameters) {
> - ir_constant *constant = node->as_constant();
> - if (constant == NULL)
> - return NULL;
> - node->replace_with(constant);
> - }
> -
> - return new(mem_ctx) ir_constant(constructor_type, parameters);
> -}
> -
> -
> -/**
> * Determine if a list consists of a single scalar r-value
> */
> bool
> @@ -1709,53 +1691,77 @@ process_record_constructor(exec_list
> *instructions,
> struct _mesa_glsl_parse_state *state)
> {
> void *ctx = state;
> + /* From page 32 (page 38 of the PDF) of the GLSL 1.20 spec:
> +*
> +*"The arguments to the constructor will be used to set the
> structure's
> +* fields, in order, using one argument per field. Each
> argument must
> +* be the same type as the field it sets, or be a type that
> can be
> +* converted to the field's type according to Section 4.1.10
> “Implicit
> +* Conversions.”"
> +*
> +* From page 35 (page 41 of the PDF) of the GLSL 4.20 spec:
> +*
> +*"In all cases, the innermost initializer (i.e., not a list
> of
> +* initializers enclosed in curly braces) applied to an
> object must
> +* have the same type as the object being initialized or be a
> type that
> +* can be converted to the object's type according to section
> 4.1.10
> +* "Implicit Conversions". In the latter case, an implicit
> conversion
> +* will be done on the initializer before the assignment is
> done."
> +*/
> exec_list actual_parameters;
>
> - process_parameters(instructions, &actual_parameters,
> - parameters, state);
> + const unsigned parameter_count =
> + process_parameters(instructions, &actual_parameters,
> parameters,
> +state);
>
> - exec_node *node = actual_parameters.get_head_raw();
> - for (unsigned i = 0; i < constructor_type->length; i++) {
> - ir_rvalue *ir = (ir_rvalue *) node;
> + if (parameter_count != constructor_type->length) {
> + _mesa_glsl_error(loc, state,
> + "%s parameters in constructor for `%s'",
> + parameter_count > constructor_type->length
> + ? "too many": "insufficient",
> + constructor_type->name);
> + return ir_rvalue::error_value(ctx);
> + }
Thanks for you patience with this series :) The parameter check above
is a nice cleanup too thanks. Patches 2 and 3 are:
Reviewed-by: Timothy Arceri
>
> - if (node->is_tail_sentinel()) {
> - _mesa_glsl_error(loc, state,
> - "insufficient parameters to constructor
> for `%s'",
> - constructor_type->name);
> - return ir_rvalue::error_value(ctx);
> - }
> + bool all_parameters_are_constant = true;
>
> - if (apply_impl
[Mesa-dev] [PATCH - Mesa 08/10] i965: Make BLORP's BlitFramebuffer follow the GL 4.4 sRGB rules.
OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode
and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is
enabled. This is technically incompatible in certain cases, but is
more consistent across GL, ES, and WebGL, and more flexible.
The NVIDIA 367.35 drivers appear to follow this behavior.
For the awful spec analysis, please read Piglit's
tests/spec/arb_framebuffer_srgb/blit.c, which explains the differences
between GL 4.1, 4.2, 4.3 (2012), 4.3 (2013), and 4.4, and why this
is the right rule to implement.
Note that ctx->Color.sRGBEnabled is initialized to _mesa_is_gles(ctx),
and ES doesn't have enable/disable flags for GL_FRAMEBUFFER_SRGB, so
it's effectively on all the time. This means the ES behavior should
be unchanged.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 20bbe7f..b903de1 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -61,11 +61,14 @@ do_blorp_blit(struct brw_context *brw, GLbitfield
buffer_bit,
GLfloat dstX0, GLfloat dstY0, GLfloat dstX1, GLfloat dstY1,
GLenum filter, bool mirror_x, bool mirror_y)
{
+ const struct gl_context *ctx = &brw->ctx;
+
/* Find source/dst miptrees */
struct intel_mipmap_tree *src_mt = find_miptree(buffer_bit, src_irb);
struct intel_mipmap_tree *dst_mt = find_miptree(buffer_bit, dst_irb);
- const bool es = _mesa_is_gles(&brw->ctx);
+ const bool do_srgb = ctx->Color.sRGBEnabled;
+
/* Do the blit */
brw_blorp_blit_miptrees(brw,
src_mt, src_irb->mt_level, src_irb->mt_layer,
@@ -75,7 +78,7 @@ do_blorp_blit(struct brw_context *brw, GLbitfield buffer_bit,
srcX0, srcY0, srcX1, srcY1,
dstX0, dstY0, dstX1, dstY1,
filter, mirror_x, mirror_y,
- es, es);
+ do_srgb, do_srgb);
dst_irb->need_downsample = true;
}
--
2.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Switching to the GL 4.4 sRGB rules for glBlitFramebuffer().
Hello, This combined patch series updates both Piglit and Mesa to implement the modern GL 4.4+ rules for sRGB encoding/decoding in BlitFramebuffer(). The new GL 4.4 rules make it possible to match the behavior of ES 3.x (always encode and decode), and the old behavior (never encode or decode). If GL_FRAMEBUFFER_SRGB is enabled, encode and decode happen. If not, no conversions apply. This is a change in behavior, which could break applications. Paul Berry wrote Piglit tests in 2012 which matched the NVIDIA driver behavior at the time, which was to never apply conversions. It appears that NVIDIA has changed their behavior, and now implements the GL 4.4 rules. They fail the Piglit tests, but begin passing after my patches. I'm told that AMD/Catalyst follows the 4.4+ rules too, but I haven't tested that personally. Left 4 Dead 2 used to require the old behavior, but I retested with these patches, and it seems to be working fine. I'm assuming they updated their application when the closed drivers changed behavior. I've updated Gallium, Meta, and i965/blorp. Please review - this will impact everyone. I highly recommend reading patch 3, as it summarizes the changes in all GL 4.x specs. Because working on sRGB drives people insane, here's an ode to non-linear colorspaces: sRGB rules, GL broke some rendering glistened brightly some rendering grew bleak spec reformulations greatly bewilder surprisingly reasonable GL became should review go badly, submitter's rationality goes b'bye Thanks, --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH - Piglit 03/10] Change arb_framebuffer_srgb/blit to follow GL 4.4+ rules.
OpenGL originally never did sRGB decode/encode for BlitFramebuffer.
OpenGL ES 3.x has always done sRGB decode/encode for BlitFramebuffer.
OpenGL 4.x specifications attempted to unify this behavior, and
ultimately settled on doing decode/encode if GL_FRAMEBUFFER_SRGB is
enabled, which allows the full flexibility. In the process, 4.1,
4.2, early 4.3, and later 4.3 all had somewhat broken rules.
This test was originally written when the latest specification (early
4.3) contained completely contradictory rules, and so simply enforced
a "copy the data unchanged" policy. This patch updates it to follow
the rules they finally settled on for GL 4.4 and 4.5.
Thanks to Gu Yang and Miao Qiankun for their help analyzing the
differences between the various specifications.
This fixes 20 subtests with NVIDIA 367.35 on a GTX 980:
- blit {renderbuffer,texture} {linear_to_srgb,srgb_to_linear}
{downsample, msaa, scaled, single_sampled, upsample} enabled
This will break those test cases for Mesa drivers. I have patches
to make i965 handle the updated rules correctly.
Signed-off-by: Kenneth Graunke
---
tests/spec/arb_framebuffer_srgb/blit.c | 160 ++---
1 file changed, 128 insertions(+), 32 deletions(-)
diff --git a/tests/spec/arb_framebuffer_srgb/blit.c
b/tests/spec/arb_framebuffer_srgb/blit.c
index ff07ad7..7518d37f 100644
--- a/tests/spec/arb_framebuffer_srgb/blit.c
+++ b/tests/spec/arb_framebuffer_srgb/blit.c
@@ -25,37 +25,30 @@
*
* Test the sRGB behaviour of blits.
*
- * The GL 4.3 spec is contradictory about how blits should be handled
- * when the source or destination buffer is sRGB. From section 18.3.1
- * Blitting Pixel Rectangles:
+ * The various GL 4.x specifications contain a lot of conflicting rules
+ * about how blits should be handled when the source or destination buffer
+ * is sRGB.
*
- * (1) When values are taken from the read buffer, if the value of
- * FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer
- * attachment corresponding to the read buffer is SRGB (see
- * section 9.2.3), the red, green, and blue components are
+ * Here are the latest rules from GL 4.4 (October 18th, 2013)
+ * section 18.3.1 Blitting Pixel Rectangles:
+ *
+ * (1) When values are taken from the read buffer, if [[FRAMEBUFFER_SRGB
+ * is enabled and]] the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
+ * for the framebuffer attachment corresponding to the read buffer is
+ * SRGB (see section 9.2.3), the red, green, and blue components are
* converted from the non-linear sRGB color space according to
* equation 8.14.
*
- * (2) When values are taken from the read buffer, no linearization is
- * performed even if the format of the buffer is SRGB.
- *
- * (3) When values are written to the draw buffers, blit operations
+ * (2) When values are written to the draw buffers, blit operations
* bypass most of the fragment pipeline. The only fragment
* operations which affect a blit are the pixel ownership test,
* the scissor test, and sRGB conversion (see section
* 17.3.9). Color, depth, and stencil masks (see section 17.4.2)
* are ignored.
*
- * (4) If SAMPLE_BUFFERS for either the read framebuffer or draw
- * framebuffer is greater than zero, no copy is performed and an
- * INVALID_OPERATION error is generated if the dimensions of the
- * source and destination rectangles provided to BlitFramebuffer
- * are not identical, or if the formats of the read and draw
- * framebuffers are not identical.
- *
* And from section 17.3.9 sRGB Conversion:
*
- * (5) If FRAMEBUFFER_SRGB is enabled and the value of
+ * (3) If FRAMEBUFFER_SRGB is enabled and the value of
* FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer
* attachment corresponding to the destination buffer is SRGB1
* (see section 9.2.3), the R, G, and B values after blending are
@@ -64,19 +57,89 @@
* the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is not SRGB,
* then ... [no conversion is applied].
*
- * Paragraphs (1) and (2) seem irreconcilable: the first says that
- * linearization should happen when reading from SRGB buffers, the
- * second says that it shouldn't.
+ * Rules differ in other specifications:
+ *
+ * ---
+ *
+ * ES 3.0 contains identical rules, however, ES has no FRAMEBUFFER_SRGB
+ * setting. References to that are deleted, making encode and decode
+ * happen regardless.
+ *
+ * ---
+ *
+ * The GL 4.3 revision from February 14th, 2013 deletes the bracketed
+ * text in paragraph (1), which appears to indicate that sRGB decode
+ * should happen regardless of the GL_FRAMEBUFFER_SRGB setting.
+ *
+ * This forces decode, but allows encode or no encode. This makes it
+ * impossible to do blits in a linear colorspace, which is not ideal.
+ *
+ * I believe
[Mesa-dev] [PATCH - Piglit 01/10] Delete fbo-srgb-blit test.
This appears to be redundant with spec/arb_framebuffer_srgb/blit
which tests many more configurations.
---
tests/all.py| 1 -
tests/fbo/CMakeLists.gl.txt | 1 -
tests/fbo/fbo-srgb-blit.c | 145
3 files changed, 147 deletions(-)
delete mode 100644 tests/fbo/fbo-srgb-blit.c
diff --git a/tests/all.py b/tests/all.py
index e76f157..6cacbd3 100644
--- a/tests/all.py
+++ b/tests/all.py
@@ -2801,7 +2801,6 @@ with profile.group_manager(
g(['fbo-blit'], run_concurrent=False)
g(['fbo-copypix'], run_concurrent=False)
g(['fbo-readdrawpix'], run_concurrent=False)
-g(['fbo-srgb-blit'])
g(['fbo-sys-blit'], run_concurrent=False)
g(['fbo-sys-sub-blit'], run_concurrent=False)
g(['fbo-generatemipmap-versus-READ_FRAMEBUFFER'])
diff --git a/tests/fbo/CMakeLists.gl.txt b/tests/fbo/CMakeLists.gl.txt
index 0476b10..2e2cac9 100644
--- a/tests/fbo/CMakeLists.gl.txt
+++ b/tests/fbo/CMakeLists.gl.txt
@@ -81,7 +81,6 @@ piglit_add_executable (fbo-readpixels-depth-formats
fbo-readpixels-depth-formats
piglit_add_executable (fbo-rg fbo-rg.c)
piglit_add_executable (fbo-scissor-blit fbo-scissor-blit.c)
piglit_add_executable (fbo-srgb fbo-srgb.c)
-piglit_add_executable (fbo-srgb-blit fbo-srgb-blit.c)
IF (UNIX)
target_link_libraries (fbo-srgb m)
ENDIF (UNIX)
diff --git a/tests/fbo/fbo-srgb-blit.c b/tests/fbo/fbo-srgb-blit.c
deleted file mode 100644
index 8c7eff4..000
--- a/tests/fbo/fbo-srgb-blit.c
+++ /dev/null
@@ -1,145 +0,0 @@
-/*
- * Copyright © 2011 Henri Verbeet
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- *
- */
-
-/** @file fbo-srgb-blit.c
- *
- * Test FBO blits between sRGB and linear textures. Blits should happen in
- * linear color space.
- */
-
-#include "piglit-util-gl.h"
-
-PIGLIT_GL_TEST_CONFIG_BEGIN
-
- config.supports_gl_compat_version = 10;
-
- config.window_visual = PIGLIT_GL_VISUAL_DOUBLE | PIGLIT_GL_VISUAL_RGB;
-
-PIGLIT_GL_TEST_CONFIG_END
-
-static GLuint src_tex, dst_tex;
-static GLuint src_fbo, dst_fbo;
-static uint32_t *tex_data;
-static bool has_fb_srgb;
-
-static void blit_rect(GLenum src_format, GLenum dst_format, float x, float y,
float w, float h, bool stretch)
-{
- glBindTexture(GL_TEXTURE_2D, src_tex);
- glTexImage2D(GL_TEXTURE_2D, 0, src_format, 16, 16, 0, GL_BGRA,
GL_UNSIGNED_INT_8_8_8_8_REV, tex_data);
-
- glBindTexture(GL_TEXTURE_2D, dst_tex);
- glTexImage2D(GL_TEXTURE_2D, 0, dst_format, 16, 16, 0, GL_BGRA,
GL_UNSIGNED_INT_8_8_8_8_REV, NULL);
-
- glBindFramebufferEXT(GL_READ_FRAMEBUFFER_EXT, src_fbo);
- glFramebufferTexture2DEXT(GL_READ_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, src_tex, 0);
-
- if (has_fb_srgb)
- glEnable(GL_FRAMEBUFFER_SRGB_EXT);
- glBindFramebufferEXT(GL_DRAW_FRAMEBUFFER_EXT, dst_fbo);
- glFramebufferTexture2DEXT(GL_DRAW_FRAMEBUFFER_EXT,
GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, dst_tex, 0);
-
- if (stretch)
- {
- glBlitFramebufferEXT(7, 7, 9, 9, 0, 0, 8, 16,
GL_COLOR_BUFFER_BIT, GL_LINEAR);
- if (has_fb_srgb)
- glDisable(GL_FRAMEBUFFER_SRGB_EXT);
- glBlitFramebufferEXT(7, 7, 9, 9, 8, 0, 16, 16,
GL_COLOR_BUFFER_BIT, GL_LINEAR);
- }
- else
- {
- glBlitFramebufferEXT(0, 0, 8, 16, 0, 0, 8, 16,
GL_COLOR_BUFFER_BIT, GL_LINEAR);
- if (has_fb_srgb)
- glDisable(GL_FRAMEBUFFER_SRGB_EXT);
- glBlitFramebufferEXT(8, 0, 16, 16, 8, 0, 16, 16,
GL_COLOR_BUFFER_BIT, GL_LINEAR);
- }
-
- glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, piglit_winsys_fbo);
-
- glBindTexture(GL_TEXTURE_2D, dst_tex);
- glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
- glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
- glT
[Mesa-dev] [PATCH - Piglit 02/10] Make multisample accuracy test set GL_FRAMEBUFFER_SRGB when resolving.
For a long time, the Mesa i965 driver has contained a hack to override
color spaces to sRGB when doing multisample resolves, with the following
justification:
* It has been observed that mulitisample resolves produce slightly better
* looking images when averaging is done using destination format. NVIDIA's
* proprietary OpenGL driver also follow this approach. So, we choose to
* follow it in our driver.
*
* When multisampling, if the source and destination formats are equal
* (aside from the color space), we choose to blit in sRGB space to get
* this higher quality image.
I've never understood the purpose of this hack. It sort of makes sense
in a "never decode, never encode" world. But with the new GL 4.4 rules,
where encoding and decoding is optional, I'm not sure that it has any
place - the colorspaces should be application directed.
That said, this Piglit test appears to expect that resolves will be
done in the sRGB color space for TEST_TYPE_SRGB, so let's make it
explicitly request OpenGL to make that happen.
This makes a number of subtests pass on NVIDIA 367.35 on a GTX 980:
- accuracy {2,4,8,32} srgb depthstencil
- accuracy {2,4,8,32} srgb depthstencil linear
- accuracy {2,4,8,32} srgb small depthstencil
- accuracy {2,4,8,32} srgb small depthstencil linear
(The 16x and all_samples variants still fail on NVIDIA.)
No change on i965, as it currently ignores GL_FRAMEBUFFER_SRGB but
has the hack to do resolves in sRGB regardless. It will soon drop
the hack, but start respecting GL_FRAMEBUFFER_SRGB.
Signed-off-by: Kenneth Graunke
---
tests/spec/ext_framebuffer_multisample/common.cpp | 4
1 file changed, 4 insertions(+)
diff --git a/tests/spec/ext_framebuffer_multisample/common.cpp
b/tests/spec/ext_framebuffer_multisample/common.cpp
index 735bcc5..b6df91c 100644
--- a/tests/spec/ext_framebuffer_multisample/common.cpp
+++ b/tests/spec/ext_framebuffer_multisample/common.cpp
@@ -326,10 +326,14 @@ Test::resolve(Fbo *fbo, GLbitfield which_buffers)
glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo->handle);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, resolve_fbo.handle);
resolve_fbo.set_viewport();
+
+ if (srgb)
+ glEnable(GL_FRAMEBUFFER_SRGB);
glBlitFramebuffer(0, 0, fbo->config.width, fbo->config.height,
0, 0, resolve_fbo.config.width,
resolve_fbo.config.height,
which_buffers, filter_mode);
+ glDisable(GL_FRAMEBUFFER_SRGB);
}
/**
--
2.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH - Mesa 06/10] Revert "st/mesa: use sRGB formats for MSAA resolving if destination is sRGB"
This reverts commit 4e549ddb500cf677b6fa16d9ebdfa67cc23da097,
dropping the hack from Gallium that I just deleted from i965.
See the previous commit for rationale.
---
src/mesa/state_tracker/st_cb_blit.c | 32
1 file changed, 32 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_blit.c
b/src/mesa/state_tracker/st_cb_blit.c
index 826152d..5e7c34c 100644
--- a/src/mesa/state_tracker/st_cb_blit.c
+++ b/src/mesa/state_tracker/st_cb_blit.c
@@ -46,34 +46,6 @@
static void
-st_adjust_blit_for_msaa_resolve(struct pipe_blit_info *blit)
-{
- /* Even though we do multisample resolves at the time of the blit, OpenGL
-* specification defines them as if they happen at the time of rendering,
-* which means that the type of averaging we do during the resolve should
-* only depend on the source format; the destination format should be
-* ignored. But, specification doesn't seem to be strict about it.
-*
-* It has been observed that mulitisample resolves produce slightly better
-* looking images when averaging is done using destination format. NVIDIA's
-* proprietary OpenGL driver also follows this approach.
-*
-* When multisampling, if the source and destination formats are equal
-* (aside from the color space), we choose to blit in sRGB space to get
-* this higher quality image.
-*/
- if (blit->src.resource->nr_samples > 1 &&
- blit->dst.resource->nr_samples <= 1) {
- blit->dst.format = blit->dst.resource->format;
-
- if (util_format_is_srgb(blit->dst.resource->format))
- blit->src.format = util_format_srgb(blit->src.resource->format);
- else
- blit->src.format = util_format_linear(blit->src.resource->format);
- }
-}
-
-static void
st_BlitFramebuffer(struct gl_context *ctx,
struct gl_framebuffer *readFB,
struct gl_framebuffer *drawFB,
@@ -232,8 +204,6 @@ st_BlitFramebuffer(struct gl_context *ctx,
blit.src.box.z = srcAtt->Zoffset + srcAtt->CubeMapFace;
blit.src.format = util_format_linear(srcObj->pt->format);
- st_adjust_blit_for_msaa_resolve(&blit);
-
st->pipe->blit(st->pipe, &blit);
dstRb->defined = true; /* front buffer tracking */
}
@@ -270,8 +240,6 @@ st_BlitFramebuffer(struct gl_context *ctx,
blit.src.box.z = srcSurf->u.tex.first_layer;
blit.src.format = util_format_linear(srcSurf->format);
- st_adjust_blit_for_msaa_resolve(&blit);
-
st->pipe->blit(st->pipe, &blit);
dstRb->defined = true; /* front buffer tracking */
}
--
2.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH - Mesa 05/10] i965: Drop the "do resolves in sRGB" hack.
I've never quite understood the purpose of this hack - supposedly,
doing resolves in the sRGB colorspace is slightly more accurate.
Currently, BlitFramebuffer() ignores sRGB encoding and decoding
on OpenGL, although it encodes and decodes in GLES 3.x.
The updated OpenGL 4.4 rules also allow for encoding and decoding
if GL_FRAMEBUFFER_SRGB is enabled, allowing the application to
control what colorspace blits are done in. I don't think this hack
makes any sense in such a world - the application can do what it
wants, and we shouldn't second guess them.
A related Piglit patch, "Make multisample accuracy test set
GL_FRAMEBUFFER_SRGB when resolving." makes the Piglit MSAA accuracy
test explicitly request SRGB encoding/decoding during resolves when
running "srgb" subtests. Without that patch, this commit will regress
those tests, but with it, they should continue to work just fine.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 24
1 file changed, 24 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index a54680e..7532aac 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -1659,30 +1659,6 @@ brw_blorp_blit_miptrees(struct brw_context *brw,
brw_blorp_surface_info_init(brw, ¶ms.dst, dst_mt, dst_level,
dst_layer, dst_format, true);
- /* Even though we do multisample resolves at the time of the blit, OpenGL
-* specification defines them as if they happen at the time of rendering,
-* which means that the type of averaging we do during the resolve should
-* only depend on the source format; the destination format should be
-* ignored. But, specification doesn't seem to be strict about it.
-*
-* It has been observed that mulitisample resolves produce slightly better
-* looking images when averaging is done using destination format. NVIDIA's
-* proprietary OpenGL driver also follow this approach. So, we choose to
-* follow it in our driver.
-*
-* When multisampling, if the source and destination formats are equal
-* (aside from the color space), we choose to blit in sRGB space to get
-* this higher quality image.
-*/
- if (params.src.num_samples > 1 &&
- _mesa_get_format_color_encoding(dst_mt->format) == GL_SRGB &&
- _mesa_get_srgb_format_linear(src_mt->format) ==
- _mesa_get_srgb_format_linear(dst_mt->format)) {
- assert(brw->format_supported_as_render_target[dst_mt->format]);
- params.dst.brw_surfaceformat = brw->render_target_format[dst_mt->format];
- params.src.brw_surfaceformat =
brw_format_for_mesa_format(dst_mt->format);
- }
-
/* When doing a multisample resolve of a GL_LUMINANCE32F or GL_INTENSITY32F
* texture, the above code configures the source format for L32_FLOAT or
* I32_FLOAT, and the destination format for R32_FLOAT. On Sandy Bridge,
--
2.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH - Mesa 04/10] i965: Bail on the BLT path if BlitFramebuffer requires sRGB conversion.
Modern OpenGL BlitFramebuffer require sRGB encode/decode when
GL_FRAMEBUFFER_SRGB is enabled. The blitter can't handle this,
so we need to bail. On Gen4-5, this means falling back to Meta,
which should handle it.
We allow sRGB <-> sRGB blits, as decode then encode ought to be a noop
(other than potential precision loss, which nobody wants anyway).
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_blit.c | 4 ++--
src/mesa/drivers/dri/i965/intel_fbo.c | 8
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_blit.c
b/src/mesa/drivers/dri/i965/intel_blit.c
index 23e1ab6..8df5b48 100644
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -211,8 +211,8 @@ intel_miptree_blit(struct brw_context *brw,
return false;
/* No sRGB decode or encode is done by the hardware blitter, which is
-* consistent with what we want in the callers (glCopyTexSubImage(),
-* glBlitFramebuffer(), texture validation, etc.).
+* consistent with what we want in many callers (glCopyTexSubImage(),
+* texture validation, etc.).
*/
mesa_format src_format = _mesa_get_srgb_format_linear(src_mt->format);
mesa_format dst_format = _mesa_get_srgb_format_linear(dst_mt->format);
diff --git a/src/mesa/drivers/dri/i965/intel_fbo.c
b/src/mesa/drivers/dri/i965/intel_fbo.c
index 707a9d2..573c3a8 100644
--- a/src/mesa/drivers/dri/i965/intel_fbo.c
+++ b/src/mesa/drivers/dri/i965/intel_fbo.c
@@ -828,6 +828,14 @@ intel_blit_framebuffer_with_blitter(struct gl_context *ctx,
return mask;
}
+ if (ctx->Color.sRGBEnabled &&
+ _mesa_get_format_color_encoding(src_irb->mt->format) !=
+ _mesa_get_format_color_encoding(dst_irb->mt->format)) {
+perf_debug("glBlitFramebuffer() with sRGB conversion cannot be "
+ "handled by BLT path.\n");
+return mask;
+ }
+
if (!intel_miptree_blit(brw,
src_irb->mt,
src_irb->mt_level, src_irb->mt_layer,
--
2.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH - Mesa 10/10] st/mesa: Make Gallium's BlitFramebuffer follow the GL 4.4 sRGB rules.
OpenGL 4.4 specifies that BlitFramebuffer should perform sRGB encode
and decode like ES 3.x does, but only when GL_FRAMEBUFFER_SRGB is
enabled. This is technically incompatible in certain cases, but is
more consistent across GL, ES, and WebGL, and more flexible.
The NVIDIA 367.35 drivers appear to follow this behavior.
For the awful spec analysis, please read Piglit's
tests/spec/arb_framebuffer_srgb/blit.c, which explains the differences
between GL 4.1, 4.2, 4.3 (2012), 4.3 (2013), and 4.4, and why this
is the right rule to implement.
Signed-off-by: Kenneth Graunke
---
src/mesa/state_tracker/st_cb_blit.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
Whoever designed this interface did a very nice job. Making this change
was really simple. I wrote the obvious code, tested it with llvmpipe,
and it appears to be working.
diff --git a/src/mesa/state_tracker/st_cb_blit.c
b/src/mesa/state_tracker/st_cb_blit.c
index 5e7c34c..cfcf3f7 100644
--- a/src/mesa/state_tracker/st_cb_blit.c
+++ b/src/mesa/state_tracker/st_cb_blit.c
@@ -44,6 +44,14 @@
#include "util/u_format.h"
+static void
+st_adjust_blit_for_srgb(struct pipe_blit_info *blit, bool framebuffer_srgb)
+{
+ if (!framebuffer_srgb) {
+ blit->dst.format = util_format_linear(blit->dst.format);
+ blit->src.format = util_format_linear(blit->src.format);
+ }
+}
static void
st_BlitFramebuffer(struct gl_context *ctx,
@@ -197,12 +205,14 @@ st_BlitFramebuffer(struct gl_context *ctx,
blit.dst.resource = dstSurf->texture;
blit.dst.level = dstSurf->u.tex.level;
blit.dst.box.z = dstSurf->u.tex.first_layer;
- blit.dst.format = util_format_linear(dstSurf->format);
+ blit.dst.format = dstSurf->format;
blit.src.resource = srcObj->pt;
blit.src.level = srcAtt->TextureLevel;
blit.src.box.z = srcAtt->Zoffset + srcAtt->CubeMapFace;
- blit.src.format = util_format_linear(srcObj->pt->format);
+ blit.src.format = srcObj->pt->format;
+
+ st_adjust_blit_for_srgb(&blit, ctx->Color.sRGBEnabled);
st->pipe->blit(st->pipe, &blit);
dstRb->defined = true; /* front buffer tracking */
@@ -233,12 +243,14 @@ st_BlitFramebuffer(struct gl_context *ctx,
blit.dst.resource = dstSurf->texture;
blit.dst.level = dstSurf->u.tex.level;
blit.dst.box.z = dstSurf->u.tex.first_layer;
- blit.dst.format = util_format_linear(dstSurf->format);
+ blit.dst.format = dstSurf->format;
blit.src.resource = srcSurf->texture;
blit.src.level = srcSurf->u.tex.level;
blit.src.box.z = srcSurf->u.tex.first_layer;
- blit.src.format = util_format_linear(srcSurf->format);
+ blit.src.format = srcSurf->format;
+
+ st_adjust_blit_for_srgb(&blit, ctx->Color.sRGBEnabled);
st->pipe->blit(st->pipe, &blit);
dstRb->defined = true; /* front buffer tracking */
--
2.9.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH - Mesa 09/10] meta: Make Meta's BlitFramebuffer() follow the GL 4.4 sRGB rules.
Just avoid whacking GL_FRAMEBUFFER_SRGB altogether, so we respect
the application's setting. This appears to work.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/common/meta_blit.c | 80 +
1 file changed, 28 insertions(+), 52 deletions(-)
Metaaa!!!
diff --git a/src/mesa/drivers/common/meta_blit.c
b/src/mesa/drivers/common/meta_blit.c
index d6d3a42..8a79725 100644
--- a/src/mesa/drivers/common/meta_blit.c
+++ b/src/mesa/drivers/common/meta_blit.c
@@ -606,7 +606,6 @@ blitframebuffer_texture(struct gl_context *ctx,
GLenum filter, GLint flipX, GLint flipY,
GLboolean glsl_version, GLboolean do_depth)
{
- struct save_state *save = &ctx->Meta->Save[ctx->Meta->SaveStackDepth - 1];
int att_index = do_depth ? BUFFER_DEPTH : readFb->_ColorReadBufferIndex;
const struct gl_renderbuffer_attachment *readAtt =
&readFb->Attachment[att_index];
@@ -719,57 +718,32 @@ blitframebuffer_texture(struct gl_context *ctx,
fb_tex_blit.samp_obj = _mesa_meta_setup_sampler(ctx, texObj, target, filter,
srcLevel);
- /* For desktop GL, we do our blits with no net sRGB decode or encode.
-*
-* However, if both the src and dst can be srgb decode/encoded, enable them
-* so that we do any blending (from scaling or from MSAA resolves) in the
-* right colorspace.
-*
-* Our choice of not doing any net encode/decode is from the GL 3.0
-* specification:
-*
-* "Blit operations bypass the fragment pipeline. The only fragment
-* operations which affect a blit are the pixel ownership test and the
-* scissor test."
-*
-* The GL 4.4 specification disagrees and says that the sRGB part of the
-* fragment pipeline applies, but this was found to break applications
-* (such as Left 4 Dead 2).
-*
-* However, for ES 3.0, we follow the specification and perform sRGB
-* decoding and encoding. The specification has always been clear in
-* the ES world, and hasn't changed over time.
-*/
if (ctx->Extensions.EXT_texture_sRGB_decode) {
- bool src_srgb = _mesa_get_format_color_encoding(rb->Format) == GL_SRGB;
- if (save->API == API_OPENGLES2 && ctx->Version >= 30) {
- /* From the ES 3.0.4 specification, page 198:
- * "When values are taken from the read buffer, if the value of
- * FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING for the framebuffer
- * attachment corresponding to the read buffer is SRGB (see section
- * 6.1.13), the red, green, and blue components are converted from
- * the non-linear sRGB color space according to equation 3.24.
- *
- * When values are written to the draw buffers, blit operations
- * bypass the fragment pipeline. The only fragment operations which
- * affect a blit are the pixel ownership test, the scissor test,
- * and sRGB conversion (see section 4.1.8)."
- */
- _mesa_set_sampler_srgb_decode(ctx, fb_tex_blit.samp_obj,
- src_srgb ? GL_DECODE_EXT
-: GL_SKIP_DECODE_EXT);
- _mesa_set_framebuffer_srgb(ctx, drawFb->Visual.sRGBCapable);
- } else {
- if (src_srgb && drawFb->Visual.sRGBCapable) {
-_mesa_set_sampler_srgb_decode(ctx, fb_tex_blit.samp_obj,
- GL_DECODE_EXT);
-_mesa_set_framebuffer_srgb(ctx, GL_TRUE);
- } else {
-_mesa_set_sampler_srgb_decode(ctx, fb_tex_blit.samp_obj,
- GL_SKIP_DECODE_EXT);
-/* set_framebuffer_srgb was set by _mesa_meta_begin(). */
- }
- }
+ /* The GL 4.4 spec, section 18.3.1 ("Blitting Pixel Rectangles") says:
+ *
+ *"When values are taken from the read buffer, if FRAMEBUFFER_SRGB
+ * is enabled and the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING
+ * for the framebuffer attachment corresponding to the read buffer
+ * is SRGB (see section 9.2.3), the red, green, and blue components
+ * are converted from the non-linear sRGB color space according to
+ * equation 3.24.
+ *
+ * When values are written to the draw buffers, blit operations
+ * bypass most of the fragment pipeline. The only fragment
+ * operations which affect a blit are the pixel ownership test,
+ * the scissor test, and sRGB conversion (see section 17.3.9)."
+ *
+ * ES 3.0 contains nearly the exact same text, but omits the part
+ * about GL_FRAMEBUFFER_SRGB as that doesn't exist in ES. Mesa
+ * defaults it to on for ES contexts, so we can safely check it.
+ */
+ const bool decode =
+ ctx->Color.sRGBEnabled &&
+
[Mesa-dev] [PATCH - Mesa 07/10] i965: Make BLORP do sRGB encode/decode on ES 2 as well.
This should have no effect, as all drivers which support BLORP also support ES 3.0 - so ES 2.0 would be promoted and follow the ES 3 rules. ES 1.0 doesn't have BlitFramebuffer. This is purely to clarify the next patch a bit. Signed-off-by: Kenneth Graunke --- src/mesa/drivers/dri/i965/brw_blorp_blit.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp index 7532aac..20bbe7f 100644 --- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp +++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp @@ -65,7 +65,7 @@ do_blorp_blit(struct brw_context *brw, GLbitfield buffer_bit, struct intel_mipmap_tree *src_mt = find_miptree(buffer_bit, src_irb); struct intel_mipmap_tree *dst_mt = find_miptree(buffer_bit, dst_irb); - const bool es3 = _mesa_is_gles3(&brw->ctx); + const bool es = _mesa_is_gles(&brw->ctx); /* Do the blit */ brw_blorp_blit_miptrees(brw, src_mt, src_irb->mt_level, src_irb->mt_layer, @@ -75,7 +75,7 @@ do_blorp_blit(struct brw_context *brw, GLbitfield buffer_bit, srcX0, srcY0, srcX1, srcY1, dstX0, dstY0, dstX1, dstY1, filter, mirror_x, mirror_y, - es3, es3); + es, es); dst_irb->need_downsample = true; } -- 2.9.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Intel: Please help define the common rectangle primitive type
On Thursday, August 4, 2016 11:28:28 AM PDT Jason Ekstrand wrote: > > > - No cut index (GS is supposed to be fine and Tess looks OK too) > > > > I'd be OK with dropping GS and Tess support for rectangles. > > I don't know that we need to but the docs say cut index doesn't work. Perhaps we should throw a GL error when using rectangles if primitive restart (i.e. cut index) is enabled. I could potentially see GS being useful - maybe someone would want to do layered rendering with rectangles, and generate rectangles for each? Tessellation on rectangles seems pretty nonsensical. Thanks so much for doing this, Marek. We really need to define a common extension all three vendors can use, and then add support for it in Glamor. Then we'll have horizontal tearing instead of awful diagonal tearing... signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv/gen7_pipeline: Set PixelShaderKillPixel when needed
According to the IVB PRM Vol2 P1, this bit must be set if a pixel shader contains a discard instruction. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97207 Cc: "12.0" Signed-off-by: Nanley Chery --- src/intel/vulkan/gen7_pipeline.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_pipeline.c index 8ce50be..d1b18e0 100644 --- a/src/intel/vulkan/gen7_pipeline.c +++ b/src/intel/vulkan/gen7_pipeline.c @@ -297,6 +297,7 @@ genX(graphics_pipeline_create)( wm.LineEndCapAntialiasingRegionWidth = 0; /* 0.5 pixels */ wm.LineAntialiasingRegionWidth = 1; /* 1.0 pixels */ wm.PointRasterizationRule = RASTRULE_UPPER_RIGHT; + wm.PixelShaderKillPixel= wm_prog_data->uses_kill; wm.PixelShaderComputedDepthMode= wm_prog_data->computed_depth_mode; wm.PixelShaderUsesSourceDepth = wm_prog_data->uses_src_depth; wm.PixelShaderUsesSourceW = wm_prog_data->uses_src_w; -- 2.9.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Question about tesselation shader out varyings and transform feedback
On Thu, 2016-08-04 at 18:36 +0200, Alejandro Piñeiro wrote:
> Hi,
>
> these days I have been trying to fix a test that uses transform
> feedback
> on the out varying of a tessellation shader. The relevant part on
> that
> shader is like this:
>
> layout (vertices=4) out;
>
> out block { vec4 value; } user_out[];
>
> The test tries to use block.value as the varying name when calling
> glTransformFeedbackVaryings, in order to get the data of the 4
> vertices.
> The test fails because on link time, it doesn't find that varying
> name.
>
> On mesa, when linked, mesa tfeedback_candidate_generator (at
> src/compiler/glsl/link_varyings) adds to the hashmap of possible
> varyings for transform feedback the following names: block[0].value,
> block[1].value, block[2].value, block[3].value. If I change the test
> to
> use those 4 varyings names, instead of try to get the array directly,
> the test passes.
>
> So now is the moment to justify who is wrong per-spec, if mesa or the
> test. At this moment Im biased to conclude that the test is wrong.
> But
> after reading transform feedback specs (ext, feedback2, feedback3,
> gl44)
> and tessellation shader, I was not able to find anything.
>
> Could someone (I bet that the best person is Timothy Arceri) guide me
> a
> little to know in which part of the spec should I look for?
For block arrays block[0].value,> block[1].value, block[2].value,
block[3].value are the correct strings for matching transform feedback
varyings. I forget which spec states this but its in there somewhere I
recall looking for it and finding it.
However user_out[] looks like it would be coming from a tess control
shader right? In which case we would want to ignore the outer array,
however I'm not sure how well Mesa supports transform feedback from
tcs.
>
> Thanks in advance.
>
> BR
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/radeon: implement ARB_clear_texture (v2)
On 08/05/2016 05:42 AM, Marek Olšák wrote:
> From: Marek Olšák
>
> Some ideas copied from Jakob Sinclair's implementation, but the color
> clearing is completely different.
>
> v2: remove leftover code, disable conditional rendering
> ---
> docs/GL3.txt | 2 +-
> docs/relnotes/12.1.0.html | 1 +
> src/gallium/drivers/r600/r600_blit.c | 6 ++-
> src/gallium/drivers/r600/r600_pipe.c | 2 +-
> src/gallium/drivers/radeon/r600_texture.c | 66
> +++
> src/gallium/drivers/radeonsi/si_blit.c| 6 ++-
> src/gallium/drivers/radeonsi/si_pipe.c| 2 +-
> 7 files changed, 80 insertions(+), 5 deletions(-)
>
> diff --git a/docs/GL3.txt b/docs/GL3.txt
> index c185c69..5dcfc31 100644
> --- a/docs/GL3.txt
> +++ b/docs/GL3.txt
> @@ -185,21 +185,21 @@ GL 4.3, GLSL 4.30 -- all DONE: nvc0, radeonsi
>GL_ARB_texture_query_levels DONE (all drivers
> that support GLSL 1.30)
>GL_ARB_texture_storage_multisampleDONE (all drivers
> that support GL_ARB_texture_multisample)
>GL_ARB_texture_view DONE (i965, nv50,
> r600, llvmpipe, softpipe, swr)
>GL_ARB_vertex_attrib_binding DONE (all drivers)
>
>
> GL 4.4, GLSL 4.40:
>
>GL_MAX_VERTEX_ATTRIB_STRIDE DONE (all drivers)
>GL_ARB_buffer_storage DONE (i965, nv50,
> nvc0, r600, radeonsi)
> - GL_ARB_clear_texture DONE (i965, nv50,
> nvc0)
> + GL_ARB_clear_texture DONE (i965, nv50,
> nvc0, r600, radeonsi)
>GL_ARB_enhanced_layouts DONE (i965)
>- compile-time constant expressions DONE
>- explicit byte offsets for blocksDONE
>- forced alignment within blocks DONE
>- specified vec4-slot component numbers DONE (i965)
>- specified transform/feedback layout DONE
>- input/output block locationsDONE
>GL_ARB_multi_bind DONE (all drivers)
>GL_ARB_query_buffer_objectDONE (i965/hsw+,
> nvc0)
>GL_ARB_texture_mirror_clamp_to_edge DONE (i965, nv50,
> nvc0, r600, radeonsi, llvmpipe, softpipe, swr)
> diff --git a/docs/relnotes/12.1.0.html b/docs/relnotes/12.1.0.html
> index 3935bb0..ed98d13 100644
> --- a/docs/relnotes/12.1.0.html
> +++ b/docs/relnotes/12.1.0.html
> @@ -37,20 +37,21 @@ TBD.
>
>
>
> New features
>
>
> Note: some of the new features are only available with certain drivers.
>
>
>
> +GL_ARB_clear_texture on r600, radeonsi
> GL_ARB_enhanced_layouts on i965
> GL_ARB_shader_group_vote on nvc0
> GL_ARB_ES3_1_compatibility on i965
> GL_EXT_window_rectangles on nv50, nvc0
> GL_KHR_texture_compression_astc_sliced_3d on i965
>
>
> Bug fixes
>
> TBD.
> diff --git a/src/gallium/drivers/r600/r600_blit.c
> b/src/gallium/drivers/r600/r600_blit.c
> index a6c5b44..8f2e2a6 100644
> --- a/src/gallium/drivers/r600/r600_blit.c
> +++ b/src/gallium/drivers/r600/r600_blit.c
> @@ -29,21 +29,25 @@
>
> enum r600_blitter_op /* bitmask */
> {
> R600_SAVE_FRAGMENT_STATE = 1,
> R600_SAVE_TEXTURES = 2,
> R600_SAVE_FRAMEBUFFER= 4,
> R600_DISABLE_RENDER_COND = 8,
>
> R600_CLEAR = R600_SAVE_FRAGMENT_STATE,
>
> - R600_CLEAR_SURFACE = R600_SAVE_FRAGMENT_STATE | R600_SAVE_FRAMEBUFFER,
> + /* GL_ARB_clear_texture should ignore the render condition, but
> + * Gallium shouldn't. Follow OpenGL.
> + */
> + R600_CLEAR_SURFACE = R600_SAVE_FRAGMENT_STATE | R600_SAVE_FRAMEBUFFER |
> + R600_DISABLE_RENDER_COND,
>
> R600_COPY_BUFFER = R600_DISABLE_RENDER_COND,
>
> R600_COPY_TEXTURE = R600_SAVE_FRAGMENT_STATE | R600_SAVE_FRAMEBUFFER |
> R600_SAVE_TEXTURES |
>R600_DISABLE_RENDER_COND,
>
> R600_BLIT = R600_SAVE_FRAGMENT_STATE | R600_SAVE_FRAMEBUFFER |
> R600_SAVE_TEXTURES,
>
> R600_DECOMPRESS= R600_SAVE_FRAGMENT_STATE | R600_SAVE_FRAMEBUFFER |
> R600_DISABLE_RENDER_COND,
>
> diff --git a/src/gallium/drivers/r600/r600_pipe.c
> b/src/gallium/drivers/r600/r600_pipe.c
> index 39a310a..5f69a5d 100644
> --- a/src/gallium/drivers/r600/r600_pipe.c
> +++ b/src/gallium/drivers/r600/r600_pipe.c
> @@ -276,20 +276,21 @@ static int r600_get_param(struct pipe_screen* pscreen,
> enum pipe_cap param)
> case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
> case PIPE_CAP_TEXTURE_FLOAT_LINEAR:
> case PIPE_CAP_TEXTURE_HALF_FLOAT_LINEAR:
> case PIPE_CAP_TGSI_TXQS:
> case PIPE_CAP_COPY_BETWEEN_COMPRESSED_AND_PLAIN_FORMATS:
> case PIPE_CAP_INVALIDATE_BUFFER:
> case PIPE_CAP_SURFACE_REINTERPRET_BLOCKS:
>
Re: [Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*
On 08/04/2016 02:24 PM, Mark Janes wrote: I saw no regressions from these tests. However, I wasn't able to run the dEQP-EGL tests the last time I tried. What branch of dEQP are you running? InternalError (Runtime check failed: '(m_capabilities & CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at egluNativeDisplay.cpp:70) I'm using git://git.kiwitree.net/~chadversary/deqp branch master commit dd2f4f958fadf324eee34796d582929111b4e41c which includes a few build fixes against aosp/master. I configured, built, and ran deqp like this: cmake -GNinja -DDEQP_TARGET=x11_egl -DCMAKE_BUILD_TYPE=Debug ninja cd modules/egl ./deqp-egl --deqp-case='dEQP-EGL.functional.image.create.gles2_cubemap_*' ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] i965: Fix dEQP-EGL.functional.image.create.gles2_cubemap_*
On 08/04/2016 02:28 PM, Martin Peres wrote: On 05/08/16 00:24, Mark Janes wrote: I saw no regressions from these tests. However, I wasn't able to run the dEQP-EGL tests the last time I tried. What branch of dEQP are you running? InternalError (Runtime check failed: '(m_capabilities & CAPABILITY_GET_DISPLAY_PLATFORM) == 0' at egluNativeDisplay.cpp:70) -Mark Err, get rid of this assert, it is a false positive. Things just work anyway. Chad, since you are on the other side now, maybe you could fix the situation of dEQP on Linux ;) I have some patches in my personal branch that fixes some Linux build issues and adds gbm support. I'll upstream them to AOSP as soon as I figure out how. I'm still *really* new and slightly lost :/ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] nir: make use of nir_cf_list_extract() helper
--- src/compiler/nir/nir_opt_dead_cf.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/compiler/nir/nir_opt_dead_cf.c b/src/compiler/nir/nir_opt_dead_cf.c index 81c1b65..3551124 100644 --- a/src/compiler/nir/nir_opt_dead_cf.c +++ b/src/compiler/nir/nir_opt_dead_cf.c @@ -128,8 +128,7 @@ opt_constant_if(nir_if *if_stmt, bool condition) : &if_stmt->else_list; nir_cf_list list; - nir_cf_extract(&list, nir_before_cf_list(cf_list), - nir_after_cf_list(cf_list)); + nir_cf_list_extract(&list, cf_list); nir_cf_reinsert(&list, nir_after_cf_node(&if_stmt->cf_node)); nir_cf_node_remove(&if_stmt->cf_node); } -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv/gen7_pipeline: Set PixelShaderKillPixel when needed
Drp... There's more work to do here to get the behavior 100% correct on gen7 but this fixes a bug and is a step in the right direction. Reviewed-by: Jason Ekstrand Unfortunately, gen7 is a bit crazy so the simple solution doesn't cover all the cases. For the full fix take a look at https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/gen7_wm_state.c#n74 and https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/gen7_wm_state.c#n81 and maybe https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/gen7_wm_state.c#n119 --Jason On Aug 4, 2016 4:45 PM, "Nanley Chery" wrote: > According to the IVB PRM Vol2 P1, this bit must be set if a pixel shader > contains a discard instruction. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97207 > Cc: "12.0" > Signed-off-by: Nanley Chery > --- > src/intel/vulkan/gen7_pipeline.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/intel/vulkan/gen7_pipeline.c b/src/intel/vulkan/gen7_ > pipeline.c > index 8ce50be..d1b18e0 100644 > --- a/src/intel/vulkan/gen7_pipeline.c > +++ b/src/intel/vulkan/gen7_pipeline.c > @@ -297,6 +297,7 @@ genX(graphics_pipeline_create)( > wm.LineEndCapAntialiasingRegionWidth = 0; /* 0.5 pixels */ > wm.LineAntialiasingRegionWidth = 1; /* 1.0 pixels */ > wm.PointRasterizationRule = RASTRULE_UPPER_RIGHT; > + wm.PixelShaderKillPixel= wm_prog_data->uses_kill; > wm.PixelShaderComputedDepthMode= > wm_prog_data->computed_depth_mode; > wm.PixelShaderUsesSourceDepth = > wm_prog_data->uses_src_depth; > wm.PixelShaderUsesSourceW = > wm_prog_data->uses_src_w; > -- > 2.9.0 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] cairo as state tracker
Hi folks, I'd like to get the cairo's gallium backend running again (hasn't been maintained for a long time and doesn't fit at all to recent mesa). The main problem I've got here is that gallium API is mesa-internal, so I'd like to do some steps on making it (semi-)public. I'm aware that it's still in flux, so we'll have an strict version dependency for quite some time - but I can live with that for now. I haven't yet understood, how to the different pieces work together, so any help is greatly appreciated. Let's start w/ a simple DRM usecase (no X involved). The big steps would IMHO be: #1: open the DRM device, setup fb and crtc #2: map a framebuffer (in the first steps I'd like to use cairo's image surface - IOW: softraster - and later move to gallium operations step by step) #2: initialize the GPU driver #3: start sending some render commands to the GPU. Maybe someone could give me some hints on how these things actually could look like ? --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Copy bitmask of VBOs in the VAO on gl{Push, Pop}Attrib.
From: Mathias Fröhlich
Hi all,
The below was found by inspection.
Please review.
Thanks
Mathias
On gl{Push,Pop}Attrib(GL_CLIENT_VERTEX_ARRAY_BIT) take
care that gl_vertex_array_object::VertexAttribBufferMask
matches the bound buffer object in the
gl_vertex_array_object::VertexBinding array.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/attrib.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/main/attrib.c b/src/mesa/main/attrib.c
index f859191..ff5f0f1 100644
--- a/src/mesa/main/attrib.c
+++ b/src/mesa/main/attrib.c
@@ -1489,6 +1489,8 @@ copy_array_object(struct gl_context *ctx,
/* _Enabled must be the same than on push */
dest->_Enabled = src->_Enabled;
+ /* The bitmask of bound VBOs needs to match the VertexBinding array */
+ dest->VertexAttribBufferMask = src->VertexAttribBufferMask;
dest->NewArrays = src->NewArrays;
}
--
2.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] util: Move _mesa_fsl/util_last_bit into util/bitscan.h
From: Mathias Fröhlich
Hi Brian,
As requested with the initial creation of util/bitscan.h
now move other bitscan related functions into util.
Make use of win32 intrinsics for util_last_bit/fls if present.
Signed-off-by: Mathias Fröhlich
Any testing especially on win32 is apprechiated.
Please review
Mathias
---
src/compiler/glsl/glsl_to_nir.cpp | 2 +-
src/gallium/auxiliary/util/u_math.h | 64 --
src/mesa/drivers/dri/i965/brw_cs.c| 2 +-
src/mesa/drivers/dri/i965/brw_draw.c | 10 +--
src/mesa/drivers/dri/i965/brw_fs_nir.cpp | 6 +-
src/mesa/drivers/dri/i965/brw_program.c | 2 +-
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_gs_visitor.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 2 +-
src/mesa/main/imports.h | 45 -
src/mesa/program/prog_to_nir.c| 6 +-
src/util/bitscan.h| 80 +++
12 files changed, 97 insertions(+), 126 deletions(-)
diff --git a/src/compiler/glsl/glsl_to_nir.cpp
b/src/compiler/glsl/glsl_to_nir.cpp
index 20302e3..d3cc5b4 100644
--- a/src/compiler/glsl/glsl_to_nir.cpp
+++ b/src/compiler/glsl/glsl_to_nir.cpp
@@ -146,7 +146,7 @@ glsl_to_nir(const struct gl_shader_program *shader_prog,
shader->info.name = ralloc_asprintf(shader, "GLSL%d", shader_prog->Name);
if (shader_prog->Label)
shader->info.label = ralloc_strdup(shader, shader_prog->Label);
- shader->info.num_textures = _mesa_fls(sh->Program->SamplersUsed);
+ shader->info.num_textures = util_last_bit(sh->Program->SamplersUsed);
shader->info.num_ubos = sh->NumUniformBlocks;
shader->info.num_abos = shader_prog->NumAtomicBuffers;
shader->info.num_ssbos = sh->NumShaderStorageBlocks;
diff --git a/src/gallium/auxiliary/util/u_math.h
b/src/gallium/auxiliary/util/u_math.h
index 1661e63..a923271 100644
--- a/src/gallium/auxiliary/util/u_math.h
+++ b/src/gallium/auxiliary/util/u_math.h
@@ -347,70 +347,6 @@ util_half_inf_sign(int16_t x)
/**
- * Find last bit set in a word. The least significant bit is 1.
- * Return 0 if no bits are set.
- */
-static inline unsigned
-util_last_bit(unsigned u)
-{
-#if defined(HAVE___BUILTIN_CLZ)
- return u == 0 ? 0 : 32 - __builtin_clz(u);
-#else
- unsigned r = 0;
- while (u) {
- r++;
- u >>= 1;
- }
- return r;
-#endif
-}
-
-/**
- * Find last bit set in a word. The least significant bit is 1.
- * Return 0 if no bits are set.
- */
-static inline unsigned
-util_last_bit64(uint64_t u)
-{
-#if defined(HAVE___BUILTIN_CLZLL)
- return u == 0 ? 0 : 64 - __builtin_clzll(u);
-#else
- unsigned r = 0;
- while (u) {
- r++;
- u >>= 1;
- }
- return r;
-#endif
-}
-
-/**
- * Find last bit in a word that does not match the sign bit. The least
- * significant bit is 1.
- * Return 0 if no bits are set.
- */
-static inline unsigned
-util_last_bit_signed(int i)
-{
- if (i >= 0)
- return util_last_bit(i);
- else
- return util_last_bit(~(unsigned)i);
-}
-
-/* Returns a bitfield in which the first count bits starting at start are
- * set.
- */
-static inline unsigned
-u_bit_consecutive(unsigned start, unsigned count)
-{
- assert(start + count <= 32);
- if (count == 32)
- return ~0;
- return ((1u << count) - 1) << start;
-}
-
-/**
* Return float bits.
*/
static inline unsigned
diff --git a/src/mesa/drivers/dri/i965/brw_cs.c
b/src/mesa/drivers/dri/i965/brw_cs.c
index 655adc1..6685acd 100644
--- a/src/mesa/drivers/dri/i965/brw_cs.c
+++ b/src/mesa/drivers/dri/i965/brw_cs.c
@@ -220,7 +220,7 @@ brw_upload_cs_prog(struct brw_context *brw)
return;
brw->cs.base.sampler_count =
- _mesa_fls(ctx->ComputeProgram._Current->Base.SamplersUsed);
+ util_last_bit(ctx->ComputeProgram._Current->Base.SamplersUsed);
brw_cs_populate_key(brw, &key);
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index d7a1ba3..9b1e18c 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -452,15 +452,15 @@ brw_try_draw_prims(struct gl_context *ctx,
* index.
*/
brw->wm.base.sampler_count =
- _mesa_fls(ctx->FragmentProgram._Current->Base.SamplersUsed);
+ util_last_bit(ctx->FragmentProgram._Current->Base.SamplersUsed);
brw->gs.base.sampler_count = ctx->GeometryProgram._Current ?
- _mesa_fls(ctx->GeometryProgram._Current->Base.SamplersUsed) : 0;
+ util_last_bit(ctx->GeometryProgram._Current->Base.SamplersUsed) : 0;
brw->tes.base.sampler_count = ctx->TessEvalProgram._Current ?
- _mesa_fls(ctx->TessEvalProgram._Current->Base.SamplersUsed) : 0;
+ util_last_bit(ctx->TessEvalProgram._Current->Base.SamplersUsed) : 0;
brw->tcs.base.sampler_count = ctx->TessCtrlProgram._Current ?
- _mesa_fls(ctx->TessCtrlProgram._Current->Base
Re: [Mesa-dev] cairo as state tracker
On 05.08.2016 06:48, Enrico Weigelt, metux IT consult wrote: ... replying to myself... ;-o > Let's start w/ a simple DRM usecase (no X involved). The big steps > would IMHO be: > #1: open the DRM device, setup fb and crtc If I'm correct, the first thing to do is to get a proper winsys, right ? So, in my DRM case I would open the drm device and probe for the actual hardware and instanciate the corresponding winsys, eg. i915_drm_winsys. Then create a proper pipe for that device. Or just use the appropriate helpers in from drm-helper.h ? Is there some function that does all that, including the probing, together at once ? (some pipe_drm_create_screen(int fd) ...) > #2: map a framebuffer (in the first steps I'd like to use cairo's > image surface - IOW: softraster - and later move to gallium > operations step by step) Is that already done by the _*create_screen() step ? By the way: what exactly does struct pipe_screen represent ? An pipe and screen (for certain hw) together ? Is that the centerpiece of all further operations, similar to cairo's cairo_device_t ? --mtx ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
