ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
carbonfiber has quit [Quit: Connection closed for inactivity]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
mbrost_ has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
jenatali: that's a long shot, but would you know what people could do in case a project got took over in a hostile way on github by a maintainer (by throwing out everybody else)?
<karolherbst>
or whom to contact?
<jenatali>
karolherbst: Are you able to elaborate on "a project"?
<jenatali>
Oh this is about MS owning GitHub, not a MS-owned project
<karolherbst>
yeah
<jenatali>
No, GitHub is still pretty compartmentalized, I don't know anybody there
<karolherbst>
ahh sad :(
<HdkR>
karolherbst: They effectively own it at that point, no way to appeal as far as I know
<karolherbst>
yeah.. which is an odd thing though
<karolherbst>
so one could just sack a project and get away with it... sounds dangerous
<HdkR>
That's what forking is for
<jenatali>
I mean you'd have to have permissions in the first place to do that to the primary fork
<karolherbst>
yeah welll...
<karolherbst>
jenatali: yeah.. but sometimes a project is maintained by multiple people
<karolherbst>
and sometimes one just had enough and hated all the others all along
<jenatali>
Which means that either you're the original author, in which case copyright kinda says it's your right to do that, or else someone trusted that person enough
<jenatali>
Yeah... that's fair
<karolherbst>
just curious what would be the proper thing to do at this point
<psykose>
if it's the one i'm thinking about the other people have probably messaged support and we'll see
<psykose>
but a fork would be fine anyway
<karolherbst>
yeah....
<psykose>
is sad though
<karolherbst>
very
<zmike>
WHAT PROJECT IS IT
<karolherbst>
PolyMC
<karolherbst>
dude just kicked everybody and removed the CoC becase of "leftist extrimist" or some other crap reason
<tjaalton>
airlied: we're seeing llvmpipe crashing on armhf running mutter tests with mesa 22.2.1, and looks like there are two commits to llvmpipe in that release by you :)
<airlied>
tjaalton: got a backtrace?
<airlied>
if I had to guess it might be llvmpipe: bind sampler views/images properly. but not sure what could be causing it
<zzag>
emersion: is it a driver bug if a drm connector is connected, i.e. DRM_MODE_CONNECTED, but it has 0 modes, i.e. count_modes == 0?
<marex>
zzag: could it indicate the kernel could not find any suitable mode for the entire pipeline connected to that connector , e.g. due to bandwidth limitations ?
mvlad has joined #dri-devel
<MrCooper>
zackr: beware that the default sorting shows the oldest tags first
<MrCooper>
marex zzag: I think that could also happen if no EDID could be retrieved, e.g. due to a KVM switch or and old VGA monitor
kem has quit [Ping timeout: 480 seconds]
<zzag>
MrCooper: how should the compositor handle such cases? try to use a custom mode, e.g. generated by libxcvt, and check whether it works using an atomic test only commit?
<MrCooper>
good question :)
<marex>
dont use the output ?
<marex>
in case it has no mode, I wonder if there is a safe mode to set
<marex>
in my case, I would consider e.g. two panels connected via different DSI links to the same scanout engine ; if the scanout engine has limited bandwidth, one panel might not have mode ... and what now ?
rasterman has joined #dri-devel
kem has joined #dri-devel
fab has joined #dri-devel
<emersion>
MrCooper: i believe the kernel has a fallback mode list for missing EDID
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<daniels>
zackr: yep, at the top of every job it prints ‘Running in registry.freedesktop.org/mesa/mesa/$container_id’ - that’s a public container URL you can pull when authed with a GitLab personal access token (go to user prefs) with read_registry scope
<daniels>
why do you ask?
jkrzyszt has joined #dri-devel
Company has joined #dri-devel
danvet has joined #dri-devel
tursulin has joined #dri-devel
anshuma1 has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest3361
swalker__ has joined #dri-devel
Guest3361 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
vliaskov has joined #dri-devel
pendingchaos has quit [Read error: Connection reset by peer]
<jadahl>
are there any drivers where there is any benefit of using GBM_BO_USE_CURSOR over plain dumb buffers?
<emersion>
we're talking about small buffers so it doesn't really matter that much
<emersion>
some drivers don't have any "special" cursor plane, they just have all planes the same
<emersion>
so the cursor plane is just like any other plane
<emersion>
and using GBM can unlock modifiers and larger buffers etc
MajorBiscuit has joined #dri-devel
pcercuei has joined #dri-devel
<jadahl>
asking beacuse some drivers trip and fall if you're using USE_CURSOR instead of dumb buffers, so contemplating whether to just stop the usage of gbm for cursor buffers for all drivers
<emersion>
which driver?
<emersion>
we're unconditionally using GBM for cursors in wlroots
<jadahl>
vc4
<emersion>
i think the only place where it doesn't work is virtualbox
<jadahl>
i see panfrost too in the proposed list
<emersion>
vc4 works fine for me
<jadahl>
it seems the issue that the two different gbm_bo's are getting the same fbid
<emersion>
… wut
<emersion>
that really shouldn't be possible
<jadahl>
too bad I kind of bricked my arm laptop so can't debug myself :(
fahien has joined #dri-devel
<emersion>
wlroots also doesn't use GBM_USE_CURSOR
<emersion>
just plain GBM buffers
<emersion>
with GBM_USE_LINEAR if there is no IN_FORMATS
<jadahl>
mutter allocates with USE_CURSOR | USE_WRITE
<emersion>
oh
<jadahl>
then does gbm_bo_write()
<emersion>
USE_WRITE will make GBM use dumb buffers
<emersion>
so it's basically the same as doing that yourself
<jadahl>
O_o
<emersion>
instead, you can use gbm_bo_map() instead
<jadahl>
why are they not getting the bug when using the "manual" dumb buffer helpers then?
<emersion>
maybe GBM has a bug in that codepath, i don't know
<jadahl>
perhaps
<pq>
zzag, if there is no EDID and the connector is old VGA analog, I don't think even the kernel driver could detect whether a programmed video mode works or not. There is literally no feedback over the cable about what the monitor thinks about it.
<pq>
zzag, such an old monitor could even be letting out smoke in that case.
<emersion>
MrCooper: we're talking FBs here not BOs?
<emersion>
are are we, jadahl?
<jadahl>
emersion: different gbm_bo -> same fbid
<emersion>
GBM BO handle, or KMS FB ID?
<jadahl>
according to the debug output in a comment
<jadahl>
what I see is a pointer address to a gbm_bo AFAICS
<emersion>
okay, and a GEM handle?
<emersion>
or the result of addfb2?
<jadahl>
ah, same handle yes
<emersion>
GEM handles are de-duplicated
<jadahl>
from get_handle()
<emersion>
okay, that can be normal then
<emersion>
if it's the same underlying memory
<MrCooper>
the Mesa driver needs to de-duplicate the BOs, or other things will break as well
<jadahl>
MrCooper: you mean gbm_dri.c?
apinheiro has joined #dri-devel
<MrCooper>
no, the driver
<MrCooper>
only the driver can know whether or not it's actually the same kernel BO
<jadahl>
MrCooper: isn't the handle what comes from DRM_IOCTL_MODE_CREATE_DUMB?
<MrCooper>
GBM wouldn't use that?
<jadahl>
yes
<jadahl>
if (USE_WRITE) create_dumb() is what gbm_dri.c does
<MrCooper>
and how is the other gbm_bo created which ends up returning the same GEM handle?
<jadahl>
same way AFAIU
<MrCooper>
sounds like a bug somewhere in or below create_dumb() then
<jadahl>
create_dumb() isn't much...
<jadahl>
can't see anything obvious wrong in how vc4 handles that ioctl either
<MrCooper>
another possibility might be that the first dumb BO was actually already destroyed in the kernel, and the second one reused the same GEM handle
<jadahl>
yea
<jadahl>
but why would it?
<MrCooper>
not sure offhand; might be possible to confirm via DRM debugging output though
<jadahl>
one thing is that it goes b0 = ...; b1 = gbm_bo_create(); gbm_bo_destroy(0); b2 = gbm_bo_create();.. b1.handle and b2.handle are the same
<jadahl>
maybe that triggers some bug
<jadahl>
should open up my pinebook, flip some switches and see if I can get it to boot anything again...
djbw has quit [Read error: Connection reset by peer]
<mripard>
mlankhorst: I'm not sure what the question is?
slattann has quit [Quit: Leaving.]
slattann has joined #dri-devel
kts has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
fab has quit []
fab has joined #dri-devel
kts has quit [Quit: Leaving]
sdutt has joined #dri-devel
<jfalempe>
tzimmermann, may I push the "Fix PLL setup for G200_SE_A" to drm-misc-next ?
<tzimmermann>
jfalempe, sure, go ahead
<jfalempe>
ok thanks
<tzimmermann>
if the buggy commit is in upstream, you can also use -misc-fixes
<tzimmermann>
jfalempe ^
<jfalempe>
so I should push to both drm-misc-next and drm-misc-fixes ?
<tzimmermann>
jfalempe, 'git tag --contains 2dd040946ecf' says the bug is in v5.15. so the patch should go into drm-misc-fixes
<tzimmermann>
jfalempe, do you absolutely need the patch in -misc-next now?
<jfalempe>
no, misc-fixes should be enough
<tzimmermann>
ok. we will sync trees at some later point and the bugfix will reach -misc-next as well
<jfalempe>
ok, thanks, will push that to misc-fixes.
<tzimmermann>
if a bugfix is immediately needed in both trees, one can merge into -misc-next and do 'dim cherry-pick' into -misc-fixes afterwards
<tzimmermann>
it's like 'git cherry-pick' but with adding additional info
<jfalempe>
ok
<jfalempe>
tzimmermann, it doesn't apply to drm-misc-fixes, because it doesn't have the patch 877507bb954e "Provide per-device callbacks for PIXPLLC"
<jfalempe>
but this is just moving code, so the same fix can be done in mgag200_pll.c
fahien has joined #dri-devel
<karolherbst>
jekstrand: are there any rules in vulkan spirv we should be aware of in regards to OpBitcast? I was thinking of using that for shared/scratch mem as well, but zmike is under the impression we have to use aliased variables to deal with different bit_sizes
fab has quit [Remote host closed the connection]
fab has joined #dri-devel
apinheiro has quit [Quit: Leaving]
kts has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<tzimmermann>
jfalempe, then maybe commit it to drm-misc-next
<jfalempe>
ok
fab has quit [Quit: fab]
<tzimmermann>
from there, either cherry-pick with the necessary changes applied, or wait for backporters to add it to stable.
kts has quit [Quit: Leaving]
yuq825 has left #dri-devel [#dri-devel]
lygstate has joined #dri-devel
<lygstate>
What's wrong with windows/ms farmer, it's very slow
alyssa has left #dri-devel [#dri-devel]
<jenatali>
We're discussing in #_oftc_#freedesktop:matrix.org
<daniels>
lygstate: it's 'just' oversubscribed
jewins has joined #dri-devel
fab has joined #dri-devel
kts has joined #dri-devel
mbrost has joined #dri-devel
siqueira has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
melissawen has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
isinyaaa has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
lemes has quit []
isinyaaa has joined #dri-devel
lemes has joined #dri-devel
melissawen has joined #dri-devel
siqueira has joined #dri-devel
heat has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<jekstrand>
karolherbst: Yeah, we can't do that for shared/scratch.
<karolherbst>
:'(
<karolherbst>
well that's annoying
<jekstrand>
karolherbst: For both, you need actual variables. There's no good way to do scratch today.
<karolherbst>
but couldn't we just use uint8 vars and bitcast the offset?
<jekstrand>
karolherbst: Some sort of scratch or local mem and ffma are the two extensions we actually need to get full OpenCL.
<karolherbst>
yeah...
<karolherbst>
getting very close btw: "Pass 2425 Fails 17 Crashes 0 Timeouts 0"
<jekstrand>
karolherbst: Yeah, you can just use uint8 but the perf will suck
<jekstrand>
karolherbst: \o/
<karolherbst>
the issue is with overlapping accesses which I am sure is broken atm
<karolherbst>
like you use shared as 16 bit, and later as 8 bit
<karolherbst>
not sure there are many kernels just casting pointers like that, but...
<jekstrand>
Yup. You'll have to do u8 and u8vec2
<jekstrand>
And the u8vec2 won't be guaranteed to be atomic.
<karolherbst>
uhhh... right...
pcercuei has quit [Read error: Connection reset by peer]
<karolherbst>
jekstrand: another thing we hit yesterday was 1Dbuffer mem objects used as 1D images, which isn't explicit in the kernel
<karolherbst>
apparently that's not that simple in vulkan
<jenatali>
FWIW we use 32-bit vars for shared/scratch and adjust the indexing to match, as well as adding shifts for smaller types or splitting for larger types
<karolherbst>
jenatali: sure, but then you kill atomicity of load/stores, no?
<karolherbst>
though that might be fine if not actually doing atomics
<jenatali>
IIRC atomicity is only required up to 32-bit?
pcercuei has joined #dri-devel
<karolherbst>
I just remember we had some issues were this was causing problems
<karolherbst>
but dunno
<karolherbst>
maybe it's fine
<jenatali>
Oh we have masked store intrinsics actually which turn the store into atomic and/or ops instead of a load/mask/store
<karolherbst>
heh, figures
<jenatali>
Only for shared of course, since scratch is per-thread anyway
<karolherbst>
right
<karolherbst>
but yeah doing non 32 bit as atomics fixes this problem indeed
<jenatali>
Well, and global/ssbo since we also have 32-bit indexing there - though we can go down to 16-bit in some cases but 8-bit is nonexistent in DXIL
<karolherbst>
yeah.. we don't have to use ssbos :)
<jenatali>
Yeah even when we get a BDA equivalent, 8-bit loads and stores will be a separate thing
<karolherbst>
huh
<karolherbst>
weird
<karolherbst>
why though?
* jenatali
shrugs
<jenatali>
You'd have to ask our compiler people, but it's on the roadmap I think
<karolherbst>
ehh..
<karolherbst>
in spir-v you just bitcast to the pointer type and you are done, no variables or other nonesense needed
<karolherbst>
would be surprised if the bda equivalent you get would work differently
<karolherbst>
but probably there are some weird reasons to do that differently
<jenatali>
Yeah maybe it'll be GEP-based, I dunno
<jekstrand>
karolherbst: Not sure what you mean
<karolherbst>
jekstrand: not 100% sure either, but if you create an 1D image from a buffer apparently that matters for the spirv generated... though maybe it doesn't have to be? zmike should know about those details here
<zmike>
what
<jenatali>
karolherbst: CL has different types for 1D textures, and 1D texture-from-buffer
<karolherbst>
zmike: the samplerless read stuff for 1d buffer which is still broken
<zmike>
oh
<zmike>
yeah I think that can't work without mutable descriptors
<karolherbst>
jenatali: not in the kernel
<jenatali>
Yeah, in the kernel?
<karolherbst>
ohhh indeed... why didn't I see that before?
<jenatali>
Yeah image1d_buffer_t is the buffer version
<karolherbst>
okay.. then I was wrong and vbuffer is actually a vimage1Dbuffer thing...
<karolherbst>
zmike: ^^
<zmike>
so it's a rusticl bug?
<karolherbst>
no, you got your vimage images vars, no?
<karolherbst>
ehh
<karolherbst>
vbuffer
<zmike>
sometimes
<karolherbst>
yeah, those are the 1D images from buffer things
<zmike>
I'm using them
<karolherbst>
okay
<zmike>
but the type is still broken sometimes
<karolherbst>
yeah...
<karolherbst>
probably
<karolherbst>
though I am sure I set up the image_view correctly
<karolherbst>
maybe
<zmike>
I'm still not clear on how this is supposed to work
<karolherbst>
it should be the same as the stuff from GL though.. I might have messed something up
<karolherbst>
but you'll get an image/sampler_view with a buffer format
<zmike>
ok
<zmike>
then that explains the fails in that test
<karolherbst>
and in the shader you get the vbuffer image type
<karolherbst>
but for GL it's the same I think
<zmike>
current code should handle it correctly if that's true
<karolherbst>
yeah.. I'll take a look and debug it, shouldn't be hard to figure out what's broken
<karolherbst>
yeah.. target should be PIPE_BUFFER
<karolherbst>
oh well...
<karolherbst>
still figuring out why local_to_global is broken for long16 :(
<karolherbst>
heh "SPIR-V module not valid: Having 16 components for TypeVector requires the Vector16 capability" oops
<zmike>
🚨
<karolherbst>
though it does work for other vec16
<karolherbst>
I think the more annoying part will be to make it work on nvidias blob vk driver as it doesn't yolo stuff like we do
<zmike>
yes, that would require actual correct spirv
srslypascal has quit [Quit: Leaving]
<karolherbst>
I am sure we have a pass to scalarize/split vec8 and vec16 thingies somewhere
luc4 has joined #dri-devel
srslypascal has joined #dri-devel
slattann has quit []
danilo has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
swalker__ has quit [Remote host closed the connection]
MajorBiscuit has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
djbw has joined #dri-devel
srslypascal is now known as Guest3397
srslypascal has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
devilhorns has quit []
Guest3397 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<eric_engestrom>
in shaderdb, does `shared program` mean something I don't know, or is that a typo for `shader program`?
<eric_engestrom>
a quick blame shows it's been there since 2012 (aa4c13d372b9f0ada586e), so... someone would've spotted the typo by now, right?
carbonfiber has joined #dri-devel
<carbonfiber>
On Ubuntu 22.04 running inside of VirtualBox, when trying to start Chrome from the command-line, I get the following error "dri3 extension not supported", this being despite using the "--disable-gpu" option. Is there a way to prevent this error?
fahien has quit []
<cwabbott>
eric_engestrom: report.py counts LOST and GAINED programs which are only in the before or after, on intel this is usually due to gaining/losing SIMD16
<cwabbott>
"shared" means it is in both before and after
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
<eric_engestrom>
cwabbott: ah ok, makes sense; thanks!
* eric_engestrom
wonders if there's another word that would be clearer
<jenatali>
"common"?
Mangix has quit [Read error: Connection reset by peer]
gallo has quit [Killed (NickServ (Too many failed password attempts.))]
gallo has joined #dri-devel
Haaninjo has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
gallo has quit []
gallo has joined #dri-devel
<dj-death>
Is there something to do to be able to assign an issue to someone?
<dj-death>
I can't assign to a colleague
<mareko>
Mesa CI is stuck on the windows-vs2019 job, which is pending and not launching
<daniels>
dj-death: they don’t show up in autocomplete unless they’re part of the project, but you can type in the full username and hit enter
<daniels>
mattst88: known, being looked at
<mattst88>
mareko: ^
<mareko>
merges are timing out
<mareko>
ok
<daniels>
mareko: yeah, we know
<dj-death>
daniels: not for assign apparently
<daniels>
dj-death: hmm. does ‘/assign @foo’ work as a comment?
<dj-death>
daniels: yep, thanks!
<daniels>
nice
<daniels>
(you can also do this for labels etc)
kem has quit [Ping timeout: 480 seconds]
<dj-death>
daniels: that's nice
<kchibisov>
Could someone enlighten me what should I reduce in the shader exactly to solve mesa-22.2.1/src/gallium/drivers/r300/compiler/r300_fragprog_emit.c::emit_alu(): Too many ALU instructions
<kchibisov>
I have a feeling that not all operations count?
<anholt>
kchibisov: seeing the shader might give a clue, but I'm not sure how to answer your question otherwise
<kchibisov>
Though, it probably should be rewritten in some places anyway...
<anholt>
at just 64 instructions for the first r300, eyeballing that shader it doesn't look like it'll fit. you'll probably have to have separate shaders per rectKind.
<kchibisov>
So basically all math counts to that?
<anholt>
yeah, but some math will be more than one op (pow is generally 3 ops on most hw)
<anholt>
stuff like that
<anholt>
negates are often free.
<kchibisov>
Ah, so it's like that.
<kchibisov>
cos also counts?
<anholt>
hopefully the vectorizer is doing something nice for things like your distanceLeft/distanceRight pair, but there may be opportunities
<kchibisov>
anholt: I'd assume using multiple shaders will be better than having one giant shader?
<anholt>
yeah, old hardware like that doesn't want an ubershader
<anholt>
(especially when some of it, like i915, doesn't even have if statements!)
<kchibisov>
And swapping shaders is pretty fast?
<kchibisov>
Though, we would change shaders quite rare...
<anholt>
swapping shaders per character would suck (this is a terminal emulator, yeah?). swapping shaders per style change, probably good.
<kchibisov>
anholt: yeah, but we draw every rect on a screen with one draw call.
<kchibisov>
I mean one draw call per style.
<anholt>
btw, RADEON_DEBUG=vp,fp will give you output about the shader code generated.
<kchibisov>
I mean I don't have r300 GPU.
<kchibisov>
I just noticed the line from the bug report and since I can't debug anything myself decided to ask here.
<kchibisov>
Thx for your help.
<anholt>
if you want to debug, you could build mesa with drm-shim, paste your shader into a .shader_test file in https://github.com/freedesktop/mesa-shader-db and then LD_PRELOAD=<path-to-libradeon_noop_drm_shim.so> ./run <shader_test file>
mbrost has quit [Ping timeout: 480 seconds]
<kchibisov>
That's interesting, thx.
* airlied
should let zmike rebase to newer CTS before me
<zmike>
🤔?🤔?🤔?
<airlied>
lvp boom boom
<zmike>
ah
<zmike>
I've been slacking on that lately
<airlied>
bunch of crashes in common vk runtime pipeline code, had a simple "fix" but now up to 8k fails and counting
<airlied>
dEQP-VK.pipeline.monolithic.stencil.*
<zmike>
yikes
<airlied>
it's one of those I suspect the test change might have been wrong, but I don't want to read the spec that closely :-P
<airlied>
might be a sideswipe between main and a merge from the branch
<airlied>
ah well will dig a bit more later
chipxxx has quit [Ping timeout: 480 seconds]
alyssa has left #dri-devel [#dri-devel]
<Sachiel>
that commit itself should be fine, the merge upwards broke all hell loose... you should be able to just add a .setDefaultColorBlendState() in there in the current main and it'll work
<Sachiel>
airlied: ^
rasterman has quit [Quit: Gettin' stinky!]
Daanct12 has joined #dri-devel
mvlad has quit [Remote host closed the connection]
apinheiro has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
<airlied>
Sachiel: ah yes I thought it was something like that
<airlied>
Sachiel: thanks!
Haaninjo has quit [Quit: Ex-Chat]
gouchi has quit [Remote host closed the connection]
fab has quit [Quit: fab]
mbrost has joined #dri-devel
sdutt has quit []
ngcortes has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
genpaku has quit [Remote host closed the connection]
genpaku has joined #dri-devel
ahajda_ has quit [Ping timeout: 481 seconds]
luc4 has quit []
AndrewR has quit [Remote host closed the connection]
carbonfiber has quit [Quit: Connection closed for inactivity]
AndrewR has quit [Remote host closed the connection]
gawin has joined #dri-devel
<gawin>
kchibisov: if the cell in "Shader opcodes" tab is empty, then the opcode must emulated by others and costs more than 1 instruction https://dri.freedesktop.org/wiki/R300ToDo/
<gawin>
*probably costs more than 1 (some are trivial like mul)
Leopold has quit []
Dr_Who has quit [Read error: Connection reset by peer]